🥇Տվյալների բազայի նախագծման հիմունքներ - PostgreSQL, Cassandra և MongoDB-ի համեմատություն

Բարև ընկերներ։ Մայիսյան արձակուրդների երկրորդ մաս մեկնելուց առաջ ձեզ հետ կիսվում ենք այն նյութով, որը թարգմանել ենք դասընթացի նոր հոսքի մեկնարկի ակնկալիքով։ «Հարաբերական DBMS».

Հավելվածների մշակողները շատ ժամանակ են ծախսում՝ համեմատելով բազմաթիվ գործառնական տվյալների բազաները՝ ընտրելու այն մեկը, որը լավագույնս համապատասխանում է նախատեսված աշխատանքային ծանրաբեռնվածությանը: Կարիքները կարող են ներառել տվյալների պարզեցված մոդելավորում, գործարքների երաշխիքներ, կարդալու/գրելու կատարողականություն, հորիզոնական մասշտաբավորում և սխալների հանդուրժողականություն: Ավանդաբար, ընտրությունը սկսվում է տվյալների բազայի կատեգորիայից՝ SQL կամ NoSQL, քանի որ յուրաքանչյուր կատեգորիա ներկայացնում է փոխզիջումների հստակ փաթեթ: Բարձր կատարողականությունը ցածր հետաձգման և բարձր թողունակության առումով սովորաբար դիտվում է որպես ոչ առևտրի պահանջ և, հետևաբար, կարևոր է ցանկացած նմուշի տվյալների բազայի համար:

Այս հոդվածի նպատակն է օգնել հավելվածների մշակողներին ճիշտ ընտրություն կատարել SQL-ի և NoSQL-ի միջև՝ հավելվածների տվյալների մոդելավորման համատեքստում: Մենք կդիտարկենք մեկ SQL տվյալների բազա, այն է՝ PostgreSQL, և երկու NoSQL տվյալների բազա՝ Cassandra և MongoDB, որպեսզի ծածկենք տվյալների բազայի նախագծման հիմունքները, ինչպիսիք են աղյուսակների ստեղծումը, դրանք համալրելը, աղյուսակից տվյալներ կարդալը և դրանք ջնջելը: Հաջորդ հոդվածում մենք անպայման կդիտարկենք ինդեքսները, գործարքները, JOIN-ները, TTL հրահանգները և JSON-ի վրա հիմնված տվյալների բազայի ձևավորումը:

Ո՞րն է տարբերությունը SQL-ի և NoSQL-ի միջև:

SQL տվյալների բազաները մեծացնում են կիրառման ճկունությունը ACID գործարքային երաշխիքների միջոցով, ինչպես նաև նրանց կարողությունը՝ տվյալների հարցում անսպասելիորեն օգտագործելով JOIN-ները, գոյություն ունեցող նորմալացված հարաբերական տվյալների բազայի մոդելների վերևում:

Հաշվի առնելով դրանց միաձույլ/մեկ հանգույցի ճարտարապետությունը և ավելորդության համար Master-slave կրկնօրինակման մոդելի օգտագործումը, ավանդական 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): Ինչպես ցույց է տրված ստորև բերված աղյուսակում, YCQL-ը՝ YugaByte DB API-ն, որը համատեղելի է Cassandra-ի հետ, ավելացնում է միայնակ և բազմաբանալի ACID գործարքների և գլոբալ երկրորդական ինդեքսների հասկացությունները NoSQL API-ին՝ դրանով իսկ սկիզբ դնելով գործարքային NoSQL տվյալների բազաների դարաշրջանին: Բացի այդ, YCQL-ը՝ YugaByte DB API-ն, որը համատեղելի է PostgreSQL-ի հետ, ավելացնում է SQL API-ին գրելու գծային մասշտաբի և սխալների ավտոմատ հանդուրժողականության հասկացությունները՝ աշխարհ բերելով SQL տվյալների բազաները: Քանի որ YugaByte DB-ն իր բնույթով գործարքային է, NoSQL API-ն այժմ կարող է օգտագործվել առաքելության համար կարևոր տվյալների համատեքստում:

Ինչպես նախկինում ասվել է հոդվածում «Ներկայացնելով YSQL. PostgreSQL համատեղելի բաշխված SQL API YugaByte DB-ի համար», YugaByte DB-ում SQL-ի կամ NoSQL-ի միջև ընտրությունը լիովին կախված է հիմքում ընկած ծանրաբեռնվածության բնութագրերից.

Եթե ձեր հիմնական աշխատանքային ծանրաբեռնվածությունը բազմաբանալի JOIN գործողություններն են, ապա YSQL-ն ընտրելիս հասկացեք, որ ձեր բանալիները կարող են բաշխվել մի քանի հանգույցների վրա, ինչը հանգեցնում է ավելի մեծ հետաձգման և/կամ ավելի ցածր թողունակության, քան NoSQL-ը:
Հակառակ դեպքում, ընտրեք երկու NoSQL API-ներից որևէ մեկը՝ նկատի ունենալով, որ դուք ավելի լավ կատարողականություն կստանաք միաժամանակ մեկ հանգույցից մատուցվող հարցումների արդյունքում: YugaByte DB-ն կարող է ծառայել որպես միասնական գործառնական տվյալների բազա իրական աշխարհի բարդ հավելվածների համար, որոնք պետք է միաժամանակ կառավարեն բազմաթիվ աշխատանքային բեռներ:

Հաջորդ բաժնում Տվյալների մոդելավորման լաբորատորիան հիմնված է PostgreSQL և Cassandra API համատեղելի YugaByte DB տվյալների բազաների վրա՝ ի տարբերություն հայրենական տվյալների բազաների: Այս մոտեցումը շեշտում է նույն տվյալների բազայի կլաստերի երկու տարբեր API-ների (երկու տարբեր նավահանգիստների) հետ փոխգործակցության դյուրինությունը՝ ի տարբերություն երկու տարբեր տվյալների բազաների լիովին անկախ կլաստերների օգտագործման:
Հետևյալ բաժիններում մենք կանդրադառնանք տվյալների մոդելավորման լաբորատորիային՝ լուսաբանելու ընդգրկված տվյալների բազաների տարբերություններն ու որոշ ընդհանրությունները:

Տվյալների մոդելավորման լաբորատորիա

Տվյալների բազայի տեղադրում

Հաշվի առնելով տվյալների մոդելի նախագծման շեշտադրումը (ոչ թե բարդ տեղակայման ճարտարապետությունները), մենք կտեղադրենք տվյալների բազաները Docker կոնտեյներներում տեղական մեքենայի վրա, այնուհետև կհամագործակցենք նրանց հետ՝ օգտագործելով իրենց համապատասխան հրամանի տողերը:

PostgreSQL & Cassandra համատեղելի 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

MongoDB- ը

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

Cassandra

cqlsh Կասանդրայի և նրա համատեղելի տվյալների բազաների հետ CQL (Cassandra Query Language) միջոցով փոխազդելու հրամանի տող է: Օգտագործման հեշտության համար YugaByte DB-ն ունի cqlsh կատալոգում bin.
Նշենք, որ CQL-ը ոգեշնչվել է SQL-ից և ունի աղյուսակների, տողերի, սյունակների և ինդեքսների նմանատիպ հասկացություններ: Այնուամենայնիվ, որպես NoSQL լեզու, այն ավելացնում է որոշակի սահմանափակումներ, որոնց մեծ մասը մենք կանդրադառնանք նաև այլ հոդվածներում:

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

MongoDB- ը

Mongo հրամանի տող է 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)
);

Cassandra

Cassandra-ում աղյուսակ ստեղծելը շատ նման է 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- ը

MongoDB-ն տվյալները կազմակերպում է տվյալների շտեմարաններում (Տվյալների բազա) (նման է Keyspace-ին Cassandra-ում), որտեղ կան Հավաքածուներ (նման աղյուսակների), որոնք պարունակում են Փաստաթղթեր (նման է աղյուսակի տողերին): 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)

Cassandra

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'};

MongoDB- ը

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}'
);

Cassandra

Ընդհանուր արտահայտություն INSERT Cassandra-ում շատ նման է PostgreSQL-ին: Այնուամենայնիվ, իմաստաբանության մեջ կա մեկ մեծ տարբերություն. Կասանդրայում INSERT իրականում վիրահատություն է UPSERT, որտեղ վերջին արժեքները ավելացվում են տողին, եթե տողը արդեն գոյություն ունի:

Տվյալների մուտքագրումը նման է PostgreSQL-ին INSERT վեր

MongoDB- ը

Չնայած MongoDB-ն Cassandra-ի նման NoSQL տվյալների բազա է, դրա ներդրման գործողությունը ոչ մի ընդհանուր բան չունի Cassandra-ի իմաստային վարքագծի հետ: 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 կատարողականի հետ, որի մասին մենք ավելի վաղ խոսեցինք: Այս ցանկությունը հանգեցնում է ցանկացած խաչաձեւ աղյուսակային և առանցքային փոխազդեցության ամեն հնարավոր կրճատման: Հարցմանը պատասխանելիս այն կարող է մեծ ուշացում առաջացնել միջհանգույցային հաղորդակցության մեջ և, հետևաբար, ավելի լավ է ընդհանրապես խուսափել: Օրինակ, Cassandra-ն պահանջում է, որ հարցումները սահմանափակվեն որոշակի օպերատորներով (միայն =, 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;

Cassandra

Վերը թվարկված 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- ը

Ինչպես ցույց է տրված նախորդ օրինակներում, 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;

Cassandra

Նման է վերը նշված PostgreSQL օրինակին:

MongoDB- ը

db.music.find( {} );

Տվյալների խմբագրում աղյուսակում

PostgreSQL

PostgreSQL-ը հրահանգներ է տալիս UPDATE տվյալները փոխելու համար: Նա հնարավորություններ չունի UPSERT, այնպես որ այս հայտարարությունը ձախողվի, եթե տողն այլևս չկա տվյալների բազայում:

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

Cassandra

Կասանդրան ունի UPDATE նման է PostgreSQL-ին: UPDATE ունի նույն իմաստաբանությունը UPSERT, նմանատիպ INSERT.

Նման է վերը նշված PostgreSQL օրինակին:

MongoDB- ը
Գործողություն թարմացնել () 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';

Cassandra

Նման է վերը նշված PostgreSQL օրինակին:

MongoDB- ը

MongoDB-ն ունի երկու տեսակի գործողություն՝ փաստաթղթերը ջնջելու համար ջնջել One () /ջնջել Շատերը() и հեռացնել (). Երկու տեսակներն էլ ջնջում են փաստաթղթերը, բայց տարբեր արդյունքներ են տալիս:

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

Աղյուսակի ջնջում

PostgreSQL

DROP TABLE Music;

Cassandra

Նման է վերը նշված PostgreSQL օրինակին:

MongoDB- ը

db.music.drop();

Ամփոփում

SQL-ի և NoSQL-ի միջև ընտրության վերաբերյալ բանավեճը մոլեգնում է ավելի քան 10 տարի: Այս բանավեճի երկու հիմնական ասպեկտ կա՝ տվյալների բազայի շարժիչի ճարտարապետություն (միաձույլ, գործարքային SQL ընդդեմ բաշխված, ոչ գործարքային NoSQL) և տվյալների բազայի նախագծման մոտեցում (ձեր տվյալների մոդելավորում SQL-ում ընդդեմ NoSQL հարցումների մոդելավորում):

YugaByte DB-ի նման բաշխված գործարքային տվյալների բազայի միջոցով տվյալների բազայի ճարտարապետության մասին բանավեճը հեշտությամբ կարելի է դադարեցնել: Քանի որ տվյալների ծավալները դառնում են ավելի մեծ, քան այն, ինչ կարելի է գրել մեկ հանգույցում, անհրաժեշտ է դառնում լիովին բաշխված ճարտարապետություն, որն աջակցում է գրելու գծային մասշտաբայնությունը ավտոմատ բեկորային/վերահավասարակշռման միջոցով:

Բացի այդ, ինչպես նշված է հոդվածներից մեկում Google Cloud- ըԳործարքային, խիստ հետևողական ճարտարապետություններն այժմ ավելի շատ են օգտագործվում զարգացման ավելի լավ շարժունություն ապահովելու համար, քան ոչ գործարքային, ի վերջո հետևողական ճարտարապետությունները:

Վերադառնալով տվյալների բազայի նախագծման քննարկմանը, արդարացի է ասել, որ նախագծման երկու մոտեցումներն էլ (SQL և NoSQL) անհրաժեշտ են իրական աշխարհի ցանկացած բարդ հավելվածի համար: SQL «տվյալների մոդելավորման» մոտեցումը թույլ է տալիս ծրագրավորողներին ավելի հեշտությամբ բավարարել փոփոխվող բիզնեսի պահանջները, մինչդեռ NoSQL «հարցման մոդելավորման» մոտեցումը թույլ է տալիս նույն մշակողներին աշխատել մեծ ծավալի տվյալների վրա՝ ցածր ուշացումով և բարձր թողունակությամբ: Այս պատճառով է, որ YugaByte DB-ն տրամադրում է SQL և NoSQL API-ներ ընդհանուր միջուկում, այլ ոչ թե խթանում է մոտեցումներից մեկը: Բացի այդ, տվյալների բազայի հանրաճանաչ լեզուների հետ համատեղելիություն ապահովելով, ներառյալ PostgreSQL-ը և Cassandra-ն, YugaByte DB-ն ապահովում է, որ մշակողները ստիպված չեն լինի այլ լեզու սովորել բաշխված, խիստ հետևողական տվյալների բազայի շարժիչի հետ աշխատելու համար:

Այս հոդվածում մենք նայեցինք, թե ինչպես են տվյալների բազայի նախագծման հիմունքները տարբերվում PostgreSQL-ի, Cassandra-ի և MongoDB-ի միջև: Հետագա հոդվածներում մենք կանդրադառնանք նախագծման առաջադեմ հասկացություններին, ինչպիսիք են ինդեքսները, գործարքները, JOIN-ները, TTL հրահանգները և JSON փաստաթղթերը:

Մաղթում ենք ձեզ հանգստյան օրեր և հրավիրում ենք ձեզ անվճար վեբինար, որը տեղի կունենա մայիսի 14-ին։

Source: www.habr.com

Տվյալների բազայի նախագծման հիմունքներ - Համեմատելով PostgreSQL, Cassandra և MongoDB

Добавить комментарий Չեղարկել պատասխանել