Асновы праектавання баз дадзеных - параўнанне PostgreSQL, Cassandra і MongoDB

Добры дзень, сябры. Перад сыходам на другую частку травеньскіх свят дзелімся з вамі матэрыялам, які мы перавялі напярэдадні запуску новага струменя па курсе. "Рэляцыйныя СКБД".

Распрацоўнікі прыкладанняў марнуюць шмат часу на параўнанне некалькіх аперацыйных баз дадзеных, каб выбраць тую, якая лепш за ўсё падыдзе для меркаванай працоўнай нагрузкі. Запатрабаванні могуць уключаць у сябе спрошчанае мадэляванне дадзеных, транзакцыйныя гарантыі, прадукцыйнасць чытання/запісы, гарызантальнае маштабаванне і адмоваўстойлівасць. Па традыцыі выбар пачынаецца з катэгорыі базы дадзеных, SQL ці NoSQL, паколькі кожная катэгорыя падае выразны набор кампрамісаў. Высокая прадукцыйнасць з пункту гледжання нізкай затрымкі і высокай прапускной здольнасці звычайна разглядаецца як патрабаванне, якое не дапускае кампрамісаў, і таму з'яўляецца неабходным для любой базы дадзеных з выбаркі.

Мэта гэтага артыкула - дапамагчы распрацоўнікам прыкладанняў зрабіць правільны выбар паміж SQL і NoSQL у кантэксце мадэлявання дадзеных прыкладання. Мы разгледзім адну SQL базу дадзеных, а менавіта PostgreSQL і дзве NoSQL базы дадзеных - Cassandra і MongoDB, каб распавесці пра асновы праектавання баз дадзеных, такія як стварэнне табліц, іх запаўненне, чытанне дадзеных з табліцы і іх выдаленне. У наступным артыкуле мы абавязкова разгледзім азначнікі, транзакцыі, JOIN'ы, дырэктывы TTL і праектаванне баз дадзеных на аснове JSON.

У чым адрозненне SQL ад NoSQL?

SQL базы дадзеных падвышаюць гнуткасць прыкладання дзякуючы транзакцыйным гарантыям ACID, а таксама дзякуючы сваёй здольнасці запытваць дадзеныя з дапамогай JOIN нечаканымі спосабамі па-над існымі нармалізаванымі мадэлямі рэляцыйных баз дадзеных.

Улічваючы іх маналітную/аднавузлавую архітэктуру і выкарыстанне мадэлі рэплікацыі master-slave для надмернасці, традыцыйныя SQL базы дадзеных не маюць двух важных асаблівасцяў – лінейнай маштабаванасці запісу (г.зн. аўтаматычнага падзелу на некалькі вузлоў) і аўтаматычнай/нулявой страты дадзеных. Гэта значыць, што аб'ём атрымоўваных дадзеных не можа перавышаць максімальны прапускны запіс аднаго вузла. Акрамя гэтага, некаторая часовая страта дадзеных павінна быць улічана пры адмоваўстойлівасці (у архітэктуры без падзелу рэсурсаў). Тут трэба мець на ўвазе, што нядаўнія коміты яшчэ не адбіліся ў падпарадкаванай (slave) копіі. Абнаўленні без прастою таксама цяжкадасягальныя ў 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 з'яўляецца першай у свеце базай дадзеных з адкрытым зыходным кодам, якая адначасова сумяшчальная з & ) і SQL (PostgreSQL). Як паказана ў табліцы ніжэй, YCQL, API YugaByte DB сумяшчальнае з Cassandra, дадае паняцці адно-і шматключавыя ACID транзакцыі і глабальныя другасныя індэксы ў API NoSQL, тым самым адкрываючы эру транзакцыйных NoSQL баз дадзеных. Акрамя таго, YCQL, API YugaByte DB сумяшчальнае з PostgreSQL, дадае паняцці лінейнага маштабавання запісу і аўтаматычнай адмоваўстойлівасці да SQL API, уяўляючы свеце размеркаваныя SQL базы дадзеных. Паколькі база дадзеных YugaByte DB з'яўляецца па сваёй сутнасці транзакцыйнай, то API NoSQL зараз можна выкарыстоўваць у кантэксце крытычна важных дадзеных.

Як раней было сказана ў артыкуле "Introducing YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB", выбар паміж SQL або NoSQL у YugaByte DB цалкам залежыць ад характарыстык асноўнай працоўнай нагрузкі:

• Калі асноўная працоўная нагрузка - гэта шматключавыя аперацыі з JOIN'амі, то пры выбары YSQL, разумейце, што вашыя ключы могуць быць размеркаваны па некалькіх вузлам, што прывядзе да больш высокай затрымкі і/ці паніжэнню прапускной здольнасці, чым у NoSQL.
• У адваротным выпадку, абярыце любы з двух NoSQL API, памятаючы аб тым, што вы атрымаеце больш высокую прадукцыйнасць у выніку запытаў, якія абслугоўваюцца з аднаго вузла за раз. YugaByte DB можа служыць адзінай аперацыйнай базай дадзеных для рэальных складаных прыкладанняў, у якіх неабходна кіраваць некалькімі працоўнымі нагрузкамі адначасова.

У аснове лабараторыі мадэлявання дадзеных (Data modeling lab) у наступнай частцы ляжаць сумяшчальныя з 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 прама ў тэчцы bin.

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

Касандра

сqlsh - Гэта абалонка каманднага радка для ўзаемадзеяння з Cassandra і яе сумяшчальнымі базамі дадзеных праз CQL (мова запытаў Cassandra). Для зручнасці выкарыстання YugaByte DB пастаўляецца з cqlsh у каталогу bin.
Звярніце ўвагу, што CQL быў натхнёны SQL і мае аналагічныя паняцці табліц, радкоў, слупкоў і індэксаў. Аднак, як мова NoSQL, ён дадае пэўны набор абмежаванняў, большасць з якіх мы таксама разгледзім у іншых артыкулах.

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

MongoDB

Монго - гэта абалонка каманднага радка для ўзаемадзеяння з MongoDB. Яе можна знайсці ў каталогу bin усталёўкі 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 вельмі падобна на PostgreSQL. Адным з асноўных адрозненняў з'яўляецца адсутнасць абмежаванняў цэласнасці (напрыклад, NOT NULL), але гэта ўваходзіць у зону адказнасці дадатку, а не NoSQL базы дадзеных. Першасны ключ складаецца з ключа часткі (слупок Artist у прыкладзе ніжэй) і набору слупкоў кластарызацыі (слупок 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 арганізуе дадзеныя ў базы дадзеных (Database) (аналагічна Keyspace у Cassandra), дзе ёсць калекцыі (Collections) (аналагічна табліцам), у якіх ляжаць дакументы (Documents) (аналагічна радкам у табліцы). У MongoDB у прынцыпе не патрабуецца вызначэнне першапачатковай схемы. Каманда "use database", паказаная ніжэй, стварае асобнік базы дадзеных пры першым выкліку і змяняе кантэкст для зноў створанай базы дадзеных. Нават калекцыі не трэба ствараць відавочна, яны ствараюцца аўтаматычна, проста пры даданні першага дакумента ў новую калекцыю. Звярніце ўвагу, што 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 у Cassandra выглядае вельмі падобна на аналагічнае ў PostgreSQL. Аднак маецца адно вялікае адрозненне ў семантыцы. У Cassandra INSERT фактычна з'яўляецца аперацыяй UPSERT, дзе ў радок дадаюцца апошнія значэнні, у выпадку, калі радок ужо існуе.

Увод дадзеных адбываецца аналагічна PostgreSQL INSERT вышэй

.

MongoDB

Нягледзячы на ​​тое, што MongoDB з'яўляецца NoSQL базай дадзеных, падобна Cassandra, яе аперацыя занясення дадзеных не мае нічога агульнага з семантычным паводзінамі ў 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;

Касандра

З пералічаных вышэй запытаў PostgreSQL толькі першы будзе працаваць у Cassandra без змен, паколькі аператар 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';

Касандра

У Cassandra ёсць UPDATE аналагічны PostgreSQL. UPDATE мае тую ж семантыку UPSERT, падобна INSERT.

Аналагічна прыкладу ў PostgreSQL вышэй.

MongoDB
Аперацыя update () у 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 траўня.

Крыніца: habr.com