Деректер базасын жобалау негіздері – PostgreSQL, Cassandra және MongoDB салыстыру

Сәлем достар. Мамыр мерекелерінің екінші бөлігіне аттанар алдында біз сіздермен курста жаңа ағынның басталуына орай аударған материалмен бөлісеміз. «Реляциялық ДҚБЖ».

Қолданбаларды әзірлеушілер жоспарланған жұмыс көлеміне сәйкес келетінін таңдау үшін бірнеше операциялық дерекқорларды салыстыруға көп уақыт жұмсайды. Қажеттіліктерге деректерді оңайлатылған модельдеу, транзакциялық кепілдіктер, оқу/жазу өнімділігі, көлденең масштабтау және ақауларға төзімділік кіруі мүмкін. Дәстүрлі түрде таңдау дерекқор санатынан басталады, SQL немесе NoSQL, өйткені әрбір санат нақты келіссөздер жиынтығын ұсынады. Төмен кідіріс және жоғары өткізу қабілеттілігі тұрғысынан жоғары өнімділік әдетте айырбастауға жатпайтын талап ретінде қарастырылады және сондықтан кез келген үлгі дерекқор үшін маңызды.

Бұл мақаланың мақсаты қолданбаларды әзірлеушілерге қолданба деректерін модельдеу контекстінде SQL және NoSQL арасында дұрыс таңдау жасауға көмектесу болып табылады. Кестелерді жасау, оларды толтыру, кестеден деректерді оқу және оны жою сияқты мәліметтер базасын жобалау негіздерін қамту үшін бір SQL дерекқорын, атап айтқанда PostgreSQL және екі NoSQL дерекқорын, Cassandra және MongoDB қарастырамыз. Келесі мақалада біз индекстерді, транзакцияларды, JOINдарды, TTL директиваларын және JSON негізіндегі дерекқор дизайнын міндетті түрде қарастырамыз.

SQL мен NoSQL арасындағы айырмашылық неде?

SQL дерекқорлары ACID транзакциялық кепілдіктері арқылы қолданбаның икемділігін, сондай-ақ олардың қалыпты реляциялық дерекқор үлгілерінің үстіне күтпеген жолдармен JOIN арқылы деректерді сұрау мүмкіндігін арттырады.

Олардың монолитті/бір түйінді архитектурасын және резервтеу үшін негізгі-құлдық репликация үлгісін пайдалануды ескере отырып, дәстүрлі SQL дерекқорларында екі маңызды мүмкіндік жоқ - сызықтық жазу масштабтамасы (яғни, бірнеше түйіндер бойынша автоматты түрде бөлу) және автоматты/нөлдік деректер жоғалуы. Бұл алынған деректер көлемі бір түйіннің максималды жазу өткізу қабілетінен аспайтынын білдіреді. Бұған қоса, ақауларға төзімділікте кейбір уақытша деректер жоғалуы ескерілуі керек (ортақ ештеңе жоқ архитектурада). Бұл жерде сіз соңғы жасалған міндеттемелер құлдық көшірмеде әлі көрсетілмегенін есте ұстағаныңыз жөн. SQL дерекқорларында тоқтаусыз жаңартуларға қол жеткізу де қиын.

NoSQL дерекқорлары әдетте табиғаты бойынша таратылады, яғни. оларда деректер бөлімдерге бөлініп, бірнеше түйіндер бойынша таратылады. Олар денормальизацияны қажет етеді. Бұл сіз жіберген нақты сұрауларға жауап беру үшін енгізілген деректерді де бірнеше рет көшіру керек дегенді білдіреді. Жалпы мақсат - оқу кезінде қол жетімді үзінділер санын азайту арқылы жоғары өнімділікке қол жеткізу. Бұл NoSQL сұрауларыңызды үлгілеуді талап ететінін білдіреді, ал SQL деректеріңізді модельдеуді талап етеді.

NoSQL таратылған кластерде жоғары өнімділікке қол жеткізуге бағытталған және бұл ACID транзакциясының жоғалуы, JOIN және дәйекті жаһандық қайталама индекстерді қамтитын көптеген дерекқорды жобалаудың негізгі негіздемесі болып табылады.

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, Cassandra-мен үйлесімді YugaByte DB API NoSQL API-ге бір және көп кілтті ACID транзакциялары және жаһандық қайталама индекстер ұғымдарын қосады, осылайша транзакциялық NoSQL дерекқорлары дәуірін бастайды. Сонымен қатар, YCQL, PostgreSQL-пен үйлесімді YugaByte DB API, SQL API-ге сызықтық жазу масштабтауы және автоматты қатеге төзімділік ұғымдарын қосады, бұл бүкіл әлемге таратылған SQL дерекқорларын әкеледі. YugaByte DB транзакциялық сипатта болғандықтан, NoSQL API енді миссия үшін маңызды деректер контексінде пайдаланылуы мүмкін.

Мақалада бұрын айтылғандай «YSQL-мен таныстыру: YugaByte DB үшін PostgreSQL үйлесімді таратылған SQL API», 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

Кассандра

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

Кассандра

Кассандрада кесте құру PostgreSQL-ге өте ұқсас. Негізгі айырмашылықтардың бірі - тұтастық шектеулерінің болмауы (мысалы, 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 сияқты), онда Құжаттар (кестедегі жолдарға ұқсас) бар Жинақтар (кестелерге ұқсас) бар. 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'};

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

Кассандра

Жалпы өрнек INSERT Кассандрада PostgreSQL-дегіге өте ұқсас. Дегенмен, семантикада бір үлкен айырмашылық бар. Кассандрада INSERT шын мәнінде операция болып табылады UPSERT, егер жол бұрыннан бар болса, соңғы мәндер жолға қосылады.

Деректерді енгізу PostgreSQL-ге ұқсас INSERT жоғары

.

MongoDB

MongoDB Cassandra сияқты 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, және тек бір көрсетілген кестемен жұмыс жасаңыз және in 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

Алдыңғы мысалдарда көрсетілгендей, 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 мысалына ұқсас.

MongoDB

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
Операция жаңарту () 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

MongoDB-де құжаттарды жою операциясының екі түрі бар - deleteOne() /deleteMany() и алып тастау (). Екі түрі де құжаттарды жояды, бірақ әртүрлі нәтижелерді береді.

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

Кестені жою

PostgreSQL

DROP TABLE Music;

Кассандра

Жоғарыдағы 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 мамырда өтеді.

Ақпарат көзі: www.habr.com