Өгөгдлийн сангийн дизайны үндэс - PostgreSQL, Кассандра болон MongoDB-г харьцуулах

Сайн уу найзуудаа. XNUMX-р сарын амралтын хоёр дахь хэсэгт явахын өмнө бид курсийн шинэ урсгал эхлэхийг угтан орчуулсан материалаа та бүхэнтэй хуваалцаж байна. "Харилцааны DBMS".

Аппликейшн хөгжүүлэгчид төлөвлөсөн ажлын ачаалалд хамгийн сайн тохирохыг сонгохын тулд олон үйлдлийн мэдээллийн сангуудыг харьцуулан маш их цаг зарцуулдаг. Хялбаршуулсан өгөгдлийн загварчлал, гүйлгээний баталгаа, унших/бичих гүйцэтгэл, хэвтээ масштаб, алдааны хүлцэл зэргийг багтааж болно. Уламжлал ёсоор бол сонголт нь өгөгдлийн сангийн категори болох SQL эсвэл NoSQL-ээс эхэлдэг, учир нь категори бүр нь тодорхой нөхцлүүдийг харуулдаг. Хоцрогдол багатай, өндөр дамжуулах чадварын хувьд өндөр гүйцэтгэл нь ерөнхийдөө арилжааны бус шаардлага гэж үздэг тул аливаа түүвэр мэдээллийн санд зайлшгүй шаардлагатай байдаг.

Энэхүү нийтлэлийн зорилго нь програм хөгжүүлэгчдэд програмын өгөгдлийн загварчлалын хүрээнд SQL болон NoSQL хоёрын хооронд зөв сонголт хийхэд туслах явдал юм. Бид нэг SQL мэдээллийн бааз болох PostgreSQL болон хоёр NoSQL мэдээллийн сан болох Кассандра ба MongoDB-ийг авч үзэх болно, тухайлбал хүснэгт үүсгэх, тэдгээрийг бөглөх, хүснэгтээс өгөгдлийг унших, устгах зэрэг мэдээллийн сангийн дизайны үндсийг хамарна. Дараагийн өгүүллээр бид индекс, гүйлгээ, JOIN, TTL удирдамж, JSON-д суурилсан өгөгдлийн сангийн дизайныг үзэх болно.

SQL болон NoSQL хоёрын ялгаа юу вэ?

SQL өгөгдлийн сангууд нь ACID гүйлгээний баталгаагаар дамжуулан хэрэглээний уян хатан байдлыг нэмэгдүүлж, одоогийн хэвийн харилцаатай өгөгдлийн сангийн загвар дээр JOIN-г ашиглан санаанд оромгүй байдлаар өгөгдөл хайх чадварыг нэмэгдүүлдэг.

Цул/нэг зангилааны архитектур болон нөөцлөхдөө мастер-боол хуулбарлах загварыг ашигласнаар уламжлалт SQL өгөгдлийн санд шугаман бичих өргөтгөх чадвар (өөрөөр хэлбэл олон зангилаанд автоматаар хуваах) болон автомат/тэг өгөгдөл алдагдах гэсэн хоёр чухал шинж чанар дутагдаж байна. Энэ нь хүлээн авсан өгөгдлийн хэмжээ нь нэг зангилааны хамгийн их бичих чадвараас хэтэрч болохгүй гэсэн үг юм. Нэмж дурдахад, зарим нэг түр зуурын өгөгдлийн алдагдлыг алдааг тэсвэрлэх чадварт (хуваалцсан юу ч байхгүй архитектурт) харгалзан үзэх шаардлагатай. Энд та сүүлийн үеийн амлалтууд боолын хуулбарт хараахан тусгагдаагүй байгааг санах хэрэгтэй. Сул зогсолтгүй шинэчлэлтүүдийг SQL мэдээллийн санд хийхэд хэцүү байдаг.

NoSQL мэдээллийн сангууд нь ихэвчлэн байгалиасаа хуваарилагддаг, өөрөөр хэлбэл. Тэдгээрийн дотор өгөгдлийг хэсэг болгон хувааж, хэд хэдэн зангилаанд хуваарилдаг. Тэд хэвийн бус байдлыг шаарддаг. Энэ нь таны илгээсэн тодорхой хүсэлтэд хариу өгөхийн тулд оруулсан өгөгдлийг хэд хэдэн удаа хуулах ёстой гэсэн үг юм. Ерөнхий зорилго нь унших явцад ашиглах боломжтой хэлтэрхийний тоог багасгах замаар өндөр гүйцэтгэлтэй байх явдал юм. Энэ нь NoSQL нь асуулгыг загварчлахыг шаарддаг бол SQL нь таны өгөгдлийг загварчлахыг шаарддаг гэсэн үг юм.

NoSQL нь тархсан кластерт өндөр гүйцэтгэлд хүрэхэд чиглэдэг бөгөөд энэ нь ACID гүйлгээний алдагдал, НЭГДСЭН гүйлгээ, дэлхийн хоёрдогч индексийг багтаасан олон тооны мэдээллийн сангийн дизайны солилцооны үндэс суурь юм.

NoSQL өгөгдлийн сангууд нь шугаман бичих чадавх, алдааны өндөр тэсвэрлэх чадвартай байдаг ч гүйлгээний баталгаа алдагдсан нь чухал ач холбогдолтой өгөгдөлд тохиромжгүй болгодог гэсэн маргаан байдаг.

Дараах хүснэгтэд NoSQL дэх өгөгдлийн загварчлал нь SQL-ээс хэрхэн ялгаатай болохыг харуулж байна.

SQL ба NoSQL: Яагаад хоёулаа хэрэгтэй байна вэ?

Amazon.com, Netflix, Uber, Airbnb зэрэг олон тооны хэрэглэгчидтэй бодит ертөнцийн программууд нь нарийн төвөгтэй, олон талт ажлуудыг гүйцэтгэх үүрэгтэй. Жишээлбэл, Amazon.com гэх мэт цахим худалдааны аппликейшн нь хэрэглэгчийн мэдээлэл, бүтээгдэхүүн, захиалга, нэхэмжлэх гэх мэт хөнгөн жинтэй, чухал ач холбогдолтой өгөгдөл, түүнчлэн бүтээгдэхүүний тойм, тусламжийн мессеж, хэрэглэгчийн үйл ажиллагаа, хэрэглэгчийн сэтгэгдэл, зөвлөмж. Мэдээжийн хэрэг, эдгээр програмууд дор хаяж нэг SQL мэдээллийн баазын хамт дор хаяж нэг NoSQL мэдээллийн санд тулгуурладаг. Бүс хоорондын болон дэлхийн системд NoSQL мэдээллийн сан нь тухайн бүс нутагт ажиллаж байгаа найдвартай эх сурвалжийн SQL мэдээллийн санд хадгалагдсан өгөгдлийн гео тархсан кэш болж ажилладаг.

YugaByte DB нь SQL болон NoSQL-г хэрхэн хослуулдаг вэ?

Лог баримжаатай холимог санах ойн систем, автоматаар хуваах, хуваагдсан тараагдсан зөвшилцлийн хуулбар болон ACID тархсан гүйлгээ (Google Spanner-ээс санаа авсан) дээр бүтээгдсэн YugaByte DB нь NoSQL (Cassandra & Redis) болон нэгэн зэрэг нийцтэй дэлхийн анхны нээлттэй эхийн мэдээллийн сан юм. SQL (PostgreSQL). Доорх хүснэгтээс харахад Кассандратай нийцтэй YugaByte DB API болох YCQL нь NoSQL API-д дан болон олон түлхүүрт ACID гүйлгээ, глобал хоёрдогч индекс гэсэн ойлголтуудыг нэмж, улмаар NoSQL гүйлгээний мэдээллийн сангийн эрин үеийг эхлүүлж байна. Нэмж дурдахад PostgreSQL-тэй нийцтэй YugaByte DB API болох YCQL нь SQL API-д шугаман бичих масштаб болон автомат алдааг тэсвэрлэх ойлголтуудыг нэмж, тархсан SQL мэдээллийн сангуудыг дэлхийд авчирдаг. YugaByte DB нь гүйлгээний шинж чанартай тул NoSQL API-г одоо даалгаварт чухал өгөгдлийн хүрээнд ашиглах боломжтой.

Өмнө нь нийтлэлд дурдсанчлан "YSQL-ийг танилцуулж байна: YugaByte DB-д зориулсан PostgreSQL-тэй нийцтэй тархсан SQL API", YugaByte DB дахь SQL эсвэл NoSQL-ийн сонголт нь үндсэн ажлын ачааллын шинж чанараас бүрэн хамаарна.

• Хэрэв таны үндсэн ажлын ачаалал олон түлхүүртэй НЭГДСЭН үйлдлүүд байвал YSQL-г сонгохдоо таны түлхүүрүүд олон зангилаанд тархаж, NoSQL-ээс илүү хоцролт ба/эсвэл дамжуулах чадвар багатай болохыг ойлгоорой.
• Үгүй бол NoSQL API-ийн аль нэгийг нь сонгоод нэг удаад нэг зангилаанаас асуулгын үр дүнд илүү сайн гүйцэтгэлтэй болно гэдгийг санаарай. YugaByte DB нь олон ажлын ачааллыг нэгэн зэрэг удирдах шаардлагатай бодит ертөнц, нарийн төвөгтэй програмуудад зориулсан нэг үйлдлийн мэдээллийн сан болж чаддаг.

Дараагийн хэсэгт байгаа Өгөгдлийн загварчлалын лаборатори нь уугуул өгөгдлийн сангаас ялгаатай нь PostgreSQL болон Cassandra API-тай нийцтэй YugaByte DB мэдээллийн сан дээр суурилдаг. Энэ арга нь хоёр өөр өгөгдлийн сангийн бүрэн бие даасан кластеруудыг ашиглахаас ялгаатай нь нэг мэдээллийн сангийн кластерын хоёр өөр API (хоёр өөр порт дээр)-тэй харилцах хялбар байдлыг онцолдог.
Дараах хэсгүүдэд бид өгөгдлийн загварчлалын лабораторийг авч үзэх болно, үүнд хамрагдсан өгөгдлийн сангийн ялгаа болон зарим нийтлэг шинж чанаруудыг харуулах болно.

Өгөгдлийн загварчлалын лаборатори

Өгөгдлийн сангийн суурилуулалт

Өгөгдлийн загвар дизайныг (цогц байршуулах архитектураас илүү) онцолж байгаа тул бид локал машин дээрх Docker контейнерт мэдээллийн санг суулгаж, дараа нь тус тусын командын мөрийн бүрхүүлийг ашиглан тэдгээртэй харьцах болно.

PostgreSQL & Кассандра-тай нийцтэй YugaByte DB мэдээллийн сан

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

МонгоБ

docker run --name my-mongo -d mongo:latest

Тушаалын мөрөнд нэвтрэх

Харгалзах API-уудын тушаалын мөрийн бүрхүүлийг ашиглан мэдээллийн сантай холбогдоцгооё.

PostgreSQL

psql нь PostgreSQL-тэй харилцах командын мөр юм. Ашиглахад хялбар болгох үүднээс YugaByte DB нь бин хавтсанд psql-тай хамт ирдэг.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Кассандра

cqlsh нь CQL (Cassandra Query Language)-ээр дамжуулан Кассандра болон түүний нийцтэй мэдээллийн сантай харилцах командын мөр юм. Ашиглахад хялбар болгох үүднээс YugaByte DB-г дагалдана cqlsh каталогид bin.
CQL нь SQL-ээс санаа авсан бөгөөд хүснэгт, мөр, багана, индекс гэсэн ижил төстэй ойлголттой болохыг анхаарна уу. Гэсэн хэдий ч, NoSQL хэлний хувьд энэ нь тодорхой хязгаарлалтуудыг нэмдэг бөгөөд тэдгээрийн ихэнхийг бид бусад нийтлэлүүдэд авч үзэх болно.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

МонгоБ

Магадгүй нь MongoDB-тэй харилцах командын шугамын бүрхүүл юм. Үүнийг MongoDB суулгацын бин лавлахаас олж болно.

docker exec -it my-mongo bash 
cd bin
mongo

Хүснэгт үүсгэх

Одоо бид тушаалын мөрийг ашиглан янз бүрийн үйлдлийг гүйцэтгэхийн тулд мэдээллийн сантай харилцаж болно. Янз бүрийн уран бүтээлчдийн бичсэн дууны талаарх мэдээллийг агуулсан хүснэгтийг үүсгэж эхэлцгээе. Эдгээр дуунууд цомгийн хэсэг байж болно. Мөн дууны нэмэлт шинж чанарууд нь гарсан он, үнэ, төрөл, үнэлгээ юм. Бид "шошго" талбараар дамжуулан ирээдүйд хэрэгтэй байж болох нэмэлт шинж чанаруудыг тооцох хэрэгтэй. Энэ нь хагас бүтэцтэй өгөгдлийг түлхүүр-утга хос хэлбэрээр хадгалах боломжтой.

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

Кассандра

Кассандра дээр хүснэгт үүсгэх нь PostgreSQL-тэй маш төстэй юм. Гол ялгаануудын нэг нь бүрэн бүтэн байдлын хязгаарлалт байхгүй (жишээлбэл, NOT NULL), гэхдээ энэ нь NoSQL мэдээллийн бааз биш харин програмын үүрэг юм.. Үндсэн түлхүүр нь хуваалтын түлхүүр (доорх жишээн дэх Уран бүтээлч багана) болон кластерын багана (доорх жишээн дэх SongTitle багана) -аас бүрдэнэ. Хуваалтын түлхүүр нь мөрийг аль хуваалт/хэсэгт байрлуулахыг тодорхойлох ба кластерын баганууд нь одоогийн хэлтэрхий дотор өгөгдлийг хэрхэн зохион байгуулахыг заадаг.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

МонгоБ

MongoDB нь өгөгдлийг өгөгдлийн сан (Мэдээллийн сан) болгон зохион байгуулдаг (Кассандра дахь Keyspace-тэй төстэй), тэнд Баримт бичгүүдийг (хүснэгтийн мөртэй төстэй) агуулсан Цуглуулга (хүснэгттэй төстэй) байдаг. MongoDB дээр үндсэн схемийг тодорхойлох шаардлагагүй. Баг "өгөгдлийн санг ашиглах", доор үзүүлсэн нь анхны дуудлагад мэдээллийн санг үүсгэж, шинээр үүсгэсэн мэдээллийн сангийн контекстийг өөрчилдөг. Цуглуулгууд ч гэсэн тодорхой үүсгэх шаардлагагүй, шинэ цуглуулгад анхны баримтыг нэмэхэд л автоматаар үүсдэг. MongoDB нь туршилтын мэдээллийн санг анхдагчаар ашигладаг тул тодорхой мэдээллийн санг заагаагүй цуглуулгын түвшний аливаа үйлдэл нь анхдагчаар түүн дээр ажиллана гэдгийг анхаарна уу.

use myNewDatabase;

Хүснэгтийн талаар мэдээлэл авах
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Кассандра

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

МонгоБ

use myNewDatabase;
show collections;

Хүснэгтэд өгөгдөл оруулах
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Кассандра

Ерөнхий илэрхийлэл INSERT Кассандра дахь энэ нь PostgreSQL-тэй маш төстэй харагдаж байна. Гэсэн хэдий ч семантикийн хувьд нэг том ялгаа бий. Кассандра хотод INSERT үнэндээ бол мэс засал юм UPSERT, хэрэв мөр аль хэдийн байгаа бол сүүлийн утгуудыг мөрөнд нэмнэ.

Мэдээлэл оруулах нь PostgreSQL-тэй төстэй INSERT их

.

МонгоБ

MongoDB нь Кассандра шиг NoSQL мэдээллийн сан боловч түүний оруулах үйлдэл нь Кассандрагийн семантик үйлдэлтэй ямар ч нийтлэг зүйлгүй. MongoDB дээр оруулах () ямар ч боломж байхгүй UPSERT, энэ нь PostgreSQL-тэй төстэй болгодог. Өгөгдмөл өгөгдөлгүйгээр нэмж байна _idspecified цуглуулгад шинэ баримт бичиг нэмэхэд хүргэнэ.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Хүснэгтийн асуулга

Магадгүй асуулга барих тал дээр SQL болон NoSQL хоёрын хамгийн чухал ялгаа нь ашигласан хэл юм FROM и WHERE. SQL нь илэрхийллийн дараа зөвшөөрнө FROM олон хүснэгт болон илэрхийллийг сонгох WHERE ямар ч төвөгтэй байж болно (үүнд үйл ажиллагаа орно JOIN хүснэгтүүдийн хооронд). Гэсэн хэдий ч NoSQL нь хатуу хязгаарлалт тавих хандлагатай байдаг FROM, зөвхөн нэг заасан хүснэгттэй ажиллах ба дотор WHERE, үндсэн түлхүүрийг үргэлж зааж өгөх ёстой. Энэ нь бидний өмнө нь ярьсан NoSQL-ийн гүйцэтгэлтэй холбоотой. Энэхүү хүсэл нь хүснэгт хоорондын болон түлхүүр хоорондын харилцан үйлчлэлийг боломжит болгон бууруулахад хүргэдэг. Энэ нь хүсэлтэд хариу өгөхдөө зангилаа хоорондын харилцаанд ихээхэн саатал үүсгэж болзошгүй тул ерөнхийдөө зайлсхийх нь дээр. Жишээлбэл, Кассандра асуулга нь тодорхой операторуудад хязгаарлагдахыг шаарддаг (зөвхөн =, IN, <, >, =>, <=) хоёрдогч индекс хүсэхээс бусад тохиолдолд хуваалтын түлхүүрүүд дээр (энд зөвхөн = операторыг зөвшөөрнө).

PostgreSQL

SQL мэдээллийн баазаар хялбархан гүйцэтгэх боломжтой асуулгын гурван жишээг доор харуулав.

• Уран бүтээлчийн бүх дууг харуулах;
• Гарчгийн эхний хэсэгт тохирсон уран бүтээлчийн бүх дууг харуулах;
• Гарчиг нь тодорхой үгтэй, 1.00-аас бага үнэтэй уран бүтээлчийн бүх дууг харуул.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Кассандра

Дээр дурдсан PostgreSQL асуулгаас зөвхөн эхнийх нь Кассандра дээр өөрчлөгдөөгүй ажиллах болно, учир нь оператор LIKE зэрэг кластерын баганад хэрэглэх боломжгүй SongTitle. Энэ тохиолдолд зөвхөн операторуудыг зөвшөөрдөг = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

МонгоБ

Өмнөх жишээнүүдээс харахад MongoDB дээр асуулга үүсгэх үндсэн арга нь юм db.collection.find(). Энэ арга нь цуглуулгын нэрийг тодорхой агуулна (music доорх жишээнд), тиймээс олон цуглуулгаас лавлагаа авахыг хориглоно.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

Хүснэгтийн бүх мөрийг уншиж байна

Бүх мөрүүдийг унших нь бидний өмнө нь авч үзсэн асуулгын хэв маягийн онцгой тохиолдол юм.

PostgreSQL

SELECT * 
FROM Music;

Кассандра

Дээрх PostgreSQL жишээтэй төстэй.

МонгоБ

db.music.find( {} );

Хүснэгт дэх өгөгдлийг засварлах

PostgreSQL

PostgreSQL зааварчилгаа өгдөг UPDATE өгөгдлийг өөрчлөх. Түүнд ямар ч боломж байхгүй UPSERT, тиймээс мөр нь мэдээллийн санд байхгүй бол энэ мэдэгдэл амжилтгүй болно.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Кассандра

Кассандра байна UPDATE PostgreSQL-тэй төстэй. UPDATE ижил семантиктай UPSERT, ижил төстэй INSERT.

Дээрх PostgreSQL жишээтэй төстэй.

МонгоБ
Үйл ажиллагаа шинэчлэх () MongoDB нь одоо байгаа баримт бичгийг бүрэн шинэчлэх эсвэл зөвхөн тодорхой талбаруудыг шинэчлэх боломжтой. Анхдагч байдлаар, энэ нь семантикийг идэвхгүй болгосон зөвхөн нэг баримтыг шинэчилдэг UPSERT. Олон баримт бичиг болон ижил төстэй үйлдлийг шинэчлэх UPSERT үйл ажиллагаанд нэмэлт туг тавих замаар хэрэглэж болно. Жишээлбэл, доорх жишээн дээр тодорхой нэг уран бүтээлчийн төрлийг дуунаас нь үндэслэн шинэчилдэг.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Хүснэгтээс өгөгдлийг устгаж байна

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Кассандра

Дээрх PostgreSQL жишээтэй төстэй.

МонгоБ

MongoDB нь баримтыг устгах хоёр төрлийн үйлдэлтэй deleteOne() /deleteMany() и арилгах (). Хоёр төрөл хоёулаа баримт бичгийг устгадаг боловч өөр үр дүнг өгдөг.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

Хүснэгтийг устгаж байна

PostgreSQL

DROP TABLE Music;

Кассандра

Дээрх PostgreSQL жишээтэй төстэй.

МонгоБ

db.music.drop();

дүгнэлт

SQL болон NoSQL хоёрын хооронд сонголт хийх тухай маргаан 10 гаруй жил үргэлжилж байна. Энэ мэтгэлцээний үндсэн хоёр тал байдаг: өгөгдлийн сангийн хөдөлгүүрийн архитектур (цул, гүйлгээний SQL ба тархсан, гүйлгээний бус NoSQL) ба өгөгдлийн сангийн дизайны арга (SQL дэх өөрийн өгөгдлийг загварчлах, NoSQL дэх асуултуудыг загварчлах).

YugaByte DB гэх мэт тархсан гүйлгээний мэдээллийн баазтай бол мэдээллийн сангийн архитектурын талаарх маргааныг хялбархан зогсоож болно. Өгөгдлийн хэмжээ нь нэг зангилаа руу бичих хэмжээнээс их болох тусам автоматаар хуваах/дахин тэнцвэржүүлэх замаар шугаман бичих өргөтгөлийг дэмждэг бүрэн тархсан архитектур шаардлагатай болно.

Үүнээс гадна, нэг зүйлд дурдсанчлан Google Cloud,Гүйлгээний, хүчтэй нийцтэй архитектурууд нь одоо гүйлгээний бус, эцэст нь тууштай архитектуруудаас илүү сайн хөгжих чадварыг хангахад илүү их ашиглагдаж байна.

Өгөгдлийн сангийн дизайны хэлэлцүүлэгт эргэн ороход дизайны арга барил (SQL ба NoSQL) нь бодит ертөнцийн аливаа нарийн төвөгтэй хэрэглээнд зайлшгүй шаардлагатай гэдгийг хэлэх нь зөв юм. SQL "өгөгдлийн загварчлал" арга нь хөгжүүлэгчдэд өөрчлөгдөж буй бизнесийн шаардлагыг илүү хялбар хангах боломжийг олгодог бол NoSQL "асуулга загварчлал" арга нь ижил хөгжүүлэгчдэд хоцролт багатай, өндөр дамжуулах чадвартай их хэмжээний өгөгдөл дээр ажиллах боломжийг олгодог. Чухам ийм шалтгаанаар YugaByte DB нь аль нэг хандлагыг сурталчлахын оронд SQL болон NoSQL API-г нийтлэг цөмд нийлүүлдэг. Нэмж дурдахад, YugaByte DB нь PostgreSQL болон Cassandra зэрэг алдартай мэдээллийн сангийн хэлтэй нийцтэй байдлыг хангаснаар хөгжүүлэгчид тархсан, өндөр тогтвортой мэдээллийн сангийн хөдөлгүүртэй ажиллахын тулд өөр хэл сурах шаардлагагүй болгодог.

Энэ нийтлэлд бид мэдээллийн баазын дизайны үндэс нь PostgreSQL, Кассандра болон MongoDB хооронд хэрхэн ялгаатай болохыг авч үзсэн. Цаашдын нийтлэлүүдэд бид индекс, гүйлгээ, JOIN, TTL удирдамж, JSON баримт бичиг зэрэг дэвшилтэт дизайны ойлголтуудыг судлах болно.

Амралтын өдрөө сайхан өнгөрүүлэхийг хүсэн ерөөж, таныг урьж байна үнэгүй вэбинар, энэ нь 14-р сарын XNUMX-нд болно.

Эх сурвалж: www.habr.com