🥇 Andmebaasi kavandamise alused – PostgreSQL, Cassandra ja MongoDB võrdlus

Tere, sõbrad. Enne mai pühade teise osa algust jagame teiega materjali, mille oleme tõlkinud uue kursuse voolu käivitamise eel. Relationaalsed andmebaasid.

Rakenduste arendajad kulutavad palju aega, et võrrelda mitmeid operatiivseid andmebaase, et leida see, mis kõige paremini sobib eeldatava töökoormusega. Nõuded võivad hõlmata lihtsat andmemudelite koostamist, tehingute tagatisi, lugemise/kirjutamise jõudlust, horisontraalset skaleerimist ja tõrkekindlust. Traditsiooniliselt algab valik andmebaasi kategooria, SQL või NoSQL, sest iga kategooria pakub selget kompromisside kogumit. Kõrge jõudlus, mis seisneb madalas latentsuses ja kõrges läbilaskevõimes, peetakse tavaliselt kompromissituks nõudmiseks ning seetõttu on see hädavajalik igas valitud andmebaasis.

Selle artikli eesmärk on aidata rakenduste arendajatel teha õige valik SQL ja NoSQL vahel rakenduse andmemudelite kontekstis. Käsitleme üht SQL andmebaasi, nimelt PostgreSQL-i ning kahte NoSQL andmebaasi – Cassandra ja MongoDB, et rääkida andmebaaside projekteerimise alustest, nagu tabelite loomine, nende täitmine, andmete lugemine tabelist ja nende kustutamine. Järgmisel artiklil vaatame kindlasti indekseid, tehinguid, JOIN-e, TTL direktiive ja andmebaaside projekteerimist JSON-i põhjal.

Mis on SQL ja NoSQL erinevus?

SQL andmebaasid suurendavad rakenduse paindlikkust ACID tehingu garantii tõttu ning ka seetõttu, et nad suudavad andmeid küsida JOINidega ootamatutel viisidel olemasolevate normaliseeritud relatsiooniliste andmebaasimudelite üle.

Tuginedes nende monoliitset/ühe sõlme arhitektuuri ja master-slave replikatsioonimudeli kasutamisega andmete ülejääkide tõttu, ei oma traditsioonilised SQL andmebaasid kahte olulist omadust – kirje lineaarset skaleeritavust (st automaatset jagamist mitmele sõlmele) ja automaatset/nullkadu andmeid. See tähendab, et saadud andmete maht ei tohi ületada ühe sõlme maksimaalset kirje läbilaskevõimet. Lisaks sellele tuleb arvestada teatud ajakadu andmetega talitlushäirete korral (ressursside jagamise arhitektuuris). Siin tuleb meeles pidada, et hiljutised commid ei ole veel alluvatesse (slave) koopiatesse jõudnud. Üksikasjade uuendamine ilma seiskamiseta on samuti SQL andmebaasides keeruline.

NoSQL andmedbases on oma olemuselt tavaliselt jagatud, mis tähendab, et andmed jaotatakse osadeks ja jaotatakse mitme sõlme vahel. Need nõuavad denormaliseerimist. See tähendab, et sisestatud andmeid tuleb ka mitu korda kopeerida, et vastata konkreetsetele päringutele, mida saadate. Ühine eesmärk on saavutada kõrge jõudlus, vähendades lugemiseks kättesaadavate shardide arvu. Seega tuleb NoSQL'iga mudelida oma päringud, samas kui SQL nõuab teie andmete modelleerimist.

NoSQL keskendub kõrge jõudluse saavutamisele jaotatud klastris, mis on peamine alus paljude andmebaasi disainikomplekside, sealhulgas ACID'i tehingute kaotuse, JOIN'ide ja järjepidevate globaalsete sekundaarsete indeksite jaoks.

On arvamus, et kuigi NoSQL andmebaasid tagavad lineaarse kirjutamismahu ja kõrge talitluspüsivuse, muudab tehingu garantiide kaotus need kriitiliste andmete jaoks sobimatuks.

Järgmine tabel näitab, kuidas andmemudeldamine NoSQL-is erineb SQL-ist.

SQL ja NoSQL: Miks on mõlemad vajalikud?

Reaalsetes rakendustes, mis teenindavad suurt arvu kasutajaid, nagu Amazon.com, Netflix, Uber ja Airbnb, esinevad keerukad mitmeotstarbelised ülesanded. Näiteks e-kaubanduse rakendus nagu Amazon.com peab haldama kergekaalulisi, kõrge prioriteediga andmeid, nagu kasutajate, toodete, tellimuste ja arvetega seotud informatsioon, koos mahukate, kuid vähem kriitiliste andmetega, nagu tooteülevaated, klienditeeninduse teadete, kasutajate tegevus, tagasiside ja soovitused. Loomulikult toetuvad need rakendused vähemalt ühele SQL andmebaasile ning vähemalt ühele NoSQL andmebaasile. Piirkondlikes ja globaalsetes süsteemides toimib NoSQL andmebaas geograafiliselt jaotatud vahemäluna andmetele, mis on salvestatud usaldusväärses allikas, SQL andmebaas, mis töötab ühes piirkonnas.

Kuidas YugaByte DB ühendab SQL-i ja NoSQL-i?

YugaByte DB on ehitatud logipõhisele hübriidmootorile, mis toetab salvestamist, automaatset jagamist ja jagatud konsensuslike replikatsioonide ning jaotatud ACID-tehingud (inspireeritud Google Spannerist). See on maailma esimene avatud lähtekoodiga andmebaas, mis on samaaegselt ühilduv NoSQL (Cassandra ja Redis) ja SQL (PostgreSQL) süsteemidega. Nagu näidatud allolevas tabelis, lisab YCQL, YugaByte DB Cassandra ühilduv API, ühe- ja mitmemärgiliste ACID-tehingute ning globaalsete teisejärguliste indeksite mõisted NoSQL API-le, avades seeläbi tehinguliste NoSQL andmebaaside ajajärgu. Lisaks lisab YCQL, YugaByte DB PostgreSQL ühilduv API, kirjutamise lineaarset skaleerimist ja automaatset talitlushäirete taluvust SQL API-le, tutvustades maailmale jaotatud SQL andmebaase. Kuna YugaByte DB andmebaas on oma olemuselt tehinguline, saab NoSQL API-d kasutada nüüd kriitiliste andmete kontekstis.

Nagu varem artiklis öeldi «Introducing YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB», sõltub YugaByte DB-s SQL või NoSQL valik täiesti põhilise töökoormuse omadustest:

Kui teie peamine koormus koosneb paljuski JOIN-idega seotud operatsioonidest, siis YSQL-i valimisel pidage meeles, et teie võtmed võivad olla jaotatud mitme sõlme vahel, mis toob kaasa suurema latentsuse ja/või madalama läbilaskevõime võrreldes NoSQL-iga.
Vastasel juhul valige üks kahest NoSQL API-st, pidage meeles, et saate parema jõudluse päringutest, mida teenindatakse ühe sõlme kaupa. YugaByte DB võib toimida ainsa operatiivandmebaasina keerukate reaalsete rakenduste jaoks, kus on vajalik samaaegselt hallata mitut koormust.

Järgmisel jaotisel on andmemudelite labori (Data modeling lab) aluseks YugaByte DB andmebaasid, mis on ühilduvad PostgreSQL-i ja Cassandra API-dega, erinevalt lähteandmebaasidest. See lähenemine rõhutab kahe erineva API (kahel erineval pordi) lihtsat koostööd sama andmebaasiklusteriga, erinevalt kahest täiesti iseseisest erineva andmebaasi klastrist.
Järgmistes jaotistes tutvume andmemudeli laboratooriumiga, et illustreerida käsitletud andmebaaside erinevusi ja mõningaid ühiseid jooni.

Andmemudeli laboratoorium

Andmebaaside installatsioon

Kuna keskendume andmemudeli projekteerimisele (mitte keerukatele juurutamisarhitektuuridele), installime andmebaasid Docker konteineritesse kohalikus arvutis ja seejärel suhtleme nendega vastavate käsurea liidestega.

PostgreSQL ja Cassandra ühilduv andmebaas 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

Kesine ligipääs

Connect the databases using the command line interface for the respective APIs.

PostgreSQL

psql — see on käsurea liides PostgreSQL-iga suhtlemiseks. YugaByte DB on kasutusmugavuse huvides varustatud psql-iga otse bin kaustas.

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

Cassandra

cqlsh — see on käsurea liides, millega suhelda Cassandra ja selle ühilduvate andmebaasidega läbi CQL-i (Cassandra päringute keel). Mugavuse huvides tuleb YugaByte DB koos cqlsh kaustas bin.
Pange tähele, et CQL on inspireeritud SQL-ist ja omab sarnaseid mõisteid nagu tabelid, read, veerud ja indeksid. Kuid, kuna see on NoSQL keel, lisab see teatud piiranguid, millest enamikku käsitleme ka teistes artiklites.

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

MongoDB

mongo – see on käsurea liides MongoDB-ga suhtlemiseks. Seda leidub MongoDB installatsiooni bin kaustas.

docker exec -it my-mongo bash 
cd bin
mongo

Tabeli loomine

Nüüd saame andmebaasiga suhelda erinevate toimingute tegemiseks kasutades käsurea liidest. Alustame tabeli loomisega, mis salvestab erinevate esitajate lood. Need lood võivad olla osa albumist. Samuti on valikuline atribuut loo jaoks – väljaandmise aasta, hind, genre ja hinnang. Peame arvestama ka täiendavaid atribuute, mis võivad tulevikus vajalikuks osutuda, läbi välja «märksõnad». See võib salvestada poolstruktureeritud andmeid võtme-väärtuse paaridena.

PostgreSQL

LOOME TABEL 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,
    PEAMI PALG (Artist, SongTitle)
);

Cassandra

Tabeli loomine Cassandras sarnaneb väga PostgreSQL-iga. Üks peamisi erinevusi on terviklikkuse piirangute (nt NOT NULL) puudumine, kuid see kuulub rakenduse vastutusalasse, mitte NoSQL andmebaasi.. Peamine võti koosneb jaotuse võtmes (veerg Artist allpool toodud näites) ja klasterdamist välistavatest veergudest (veerg SongTitle allpool toodud näites). Jaotuse võti määrab, kuhu jaotusse/shardi rida panna, samas kui klasterdamise veerud näitavad, kuidas andmed peaksid olema korraldatud käesolevas shardis.

LOOME KEYSPACE myapp;
KASUTAME myapp;
LOOME TABEL Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PEAMI PALG (Artist, SongTitle)
);

MongoDB

MongoDB korraldab andmed andmebaasidesse (Database) (sarnane Keyspace'ile Cassandras), milles on kollektsioonid (Collections) (sarnane tabelitele), kus asuvad dokumendid (Documents) (sarnane ridadele tabelis). MongoDB-s ei ole põhimõtteliselt vajalik algse skeemi määramine. Käsk «use database», allpool toodud loob andmebaasi eksemplari esmakordsel kutsel ja muudab konteksti uuesti loodud andmebaasi jaoks. Isegi kogusid ei pea eraldi looma, need luuakse automaatselt, kui lisate esimese dokumendi uude kollektsiooni. Pange tähele, et MongoDB kasutab vaikimisi testandmebaasi, seega kõik kollektsioonitasandi toimingud ilma konkreetse andmebaasi määramiseta teostatakse vaikimisi selles.

kasuta myNewDatabase;

Teabe saamine tabelist
PostgreSQL

d Music
Tabel "public.music"
    Veerg    |         Tüüp          | Jaotamine | Nullable | Vaikimisi 
--------------+-----------------------+-----------+----------+--------
 artist       | karakteri varieerumine(20) |           | mitte null | 
 songtitle    | karakteri varieerumine(30) |           | mitte null | 
 albumtitle   | karakteri varieerumine(25) |           |          | 
 year         | täisarv                |           |          | 
 price        | kahekordne täpsus      |           |          | 
 genre        | karakteri varieerumine(10) |           |          | 
 criticrating | kahekordne täpsus      |           |          | 
 tags         | tekst                  |           |          | 
Indeksid:
    "music_pkey" PEAMISED VÕTME, btree (artist, songtitle)

Cassandra

Küsi TABELI MUSIC kohta;
LOO TABEL myapp.music (
    artist tekst,
    songtitle tekst,
    albumtitle tekst,
    year int,
    price float,
    genre tekst,
    tags tekst,
    PEAMINE VÕTI (artist, songtitle)
) KLUSTERIMISE JÄRJESTUSEGA (songtitle ASC)
    JA vaikeaeg = 0
    JA tehingud = {'enabled': 'false'};

MongoDB

kasuta myNewDatabase;
näita kollektsioone;

Andmete sisestamine tabelisse
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

Kokkuvõttes väljakutse INSERT Cassandra-s on väga sarnane PostgreSQL-i vastavale. Siiski on semantikas suur erinevus. Cassandra INSERT on tegelikult operatsioon UPSERT, kus rida lisatakse viimased väärtused, eeldusel, et rida juba eksisteerib.

Andmete sisestamine toimub sarnaselt PostgreSQL-ile INSERT üle

MongoDB

Kuigi MongoDB on NoSQL andmebaas, sarnaselt Cassandra-le, ei ole selle andmesisestusoperatsioonil midagi ühist Cassandra semantilise käitumisega. MongoDB-s insert() ei oma võimalusi UPSERT, mis teeb selle sarnaseks PostgreSQL-iga. Andmete lisamine toimub vaikimisi ilma _idspecified toob üksuse lisamine kogu.

db.music.insert( { artist: "Keegi, keda sa ei tea", songTitle: "Helista mulle täna", albumTitle: "Kohati kuulus", year: 2015, price: 2.14, genre: "Country", tags: { Composers: ["Smith", "Jones", "Davis"], LengthInSeconds: 214 } } ); db.music.insert( { artist: "Keegi, keda sa ei tea", songTitle: "Minu koer Spot", albumTitle: "Hei nüüd", price: 1.98, genre: "Country", criticRating: 8.4 } ); db.music.insert( { artist: "Acme bänd", songTitle: "Vaata välja, maailm", albumTitle:"Raha tuleb siia", price: 0.99, genre: "Rock" } ); db.music.insert( { artist: "Acme bänd", songTitle: "Endiselt armunud", albumTitle:"Raha tuleb siia", price: 2.47, genre: "Rock", tags: { radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"], tourDates: { Seattle: "20150625", Cleveland: "20150630" }, rotation: "Heavy" } } );

Tabeli päring

Võib-olla on peamine erinevus SQL-i ja NoSQL-i vahel päringute koostamisel sõnastuses FROM ja WHERE. SQL võimaldab pärast väljendit FROM valida mitu tabelit, ja väljend peab olema WHERE iga keerukuse tase (sealhulgas operatsioonid JOIN tabelite vahel). Kuid NoSQL-l on kalduvus seada ranged piirangud FROM, ja töötab ainult ühe määratud tabeliga, ja WHERE, peab alati olema määratud peamine võti. See tuleneb NoSQL-i soovist saavutada suuremat jõudlust, millest oleme varem rääkinud. See soov viib igasuguste tabelitevaheliste ja võtmetevaheliste interaktsioonide vähendamiseni. See võib põhjustada suurt viivitust sõlmede vahelise ühenduse puhul päringule vastamisel, seetõttu tuleks seda põhimõtteliselt vältida. Näiteks nõuab Cassandra, et päringud oleksid piiratud teatud operaatoritega (lubatud on ainult =, IN, , =>, <=) sektsioonide võtmetel, välja arvatud juhud, kus päring on sekundaarse indeksi päring (siin on lubatud ainult operaator =).

PostgreSQL

Järgnevates näidetes on toodud kolm päringut, mida SQL-andmebaas saab kergesti täita.

Tooda välja kõik laulud esitajalt;
Tooda välja kõik laulud esitajalt, mis vastavad pealkirja esimesele osale;
Tooda välja kõik laulud esitajalt, mis sisaldavad teatud sõna pealkirjas ja mille hind on alla 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

Ülaltoodud päringutest töötab PostgreSQL-is ainult esimene Cassandra-s muutumatult, kuna operaatorit LIKE ei saa rakendada klasterdamise veergude, näiteks SongTitle. Sellisel juhul on lubatud ainult operaatorid = ja 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

Nagu näidatud eelnevates näidetes, on MongoDB päringute loomise peamine meetod db.collection.find(). See meetod sisaldab selgelt kollektiivi nime (music allolevas näites), seega on päring mitme kollektsiooni osas keelatud.

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

Loe kõiki tabeli ridu

Kõik ridade lugemine on lihtsalt varasemalt käsitletud päringu mall erijuht.

PostgreSQL

VALI * 
MUUSIKA;

Cassandra

Sarnane eespool PostgreSQL näitele.

MongoDB

db.music.find( {} );

Andmete redigeerimine tabelis

PostgreSQL

PostgreSQL pakub käsku KUUDA andmete muutmiseks. Sellel ei ole võimalusi UPSERT, seetõttu põhjustab selle käsu täitmine vea, kui rida andmebaasis enam ei eksisteeri.

KUUDA Muusika
SETPžanr = 'Disco'
KUS Esitaja = 'The Acme Band' JA LauluPealkiri = 'Still In Love';

Cassandra

Cassandra-l on KUUDA sarnane PostgreSQL. KUUDA omab sama semantikat UPSERT, sarnaselt INSERT.

Sarnane eespool PostgreSQL näitele.

MongoDB
Operatsioon update() MongoDB-s võib täielikult uuendada olemasolevat dokumenti või muuta ainult teatud välju. Vaikimisi uuendab see ainult ühte dokumenti ilma semantikat UPSERT. Mitme dokumendi uuendamine ja käitumine on sarnane UPSERT saab rakendada, seadistades operatsiooni jaoks täiendavad lipud. Näiteks allolevas näites uuendatakse konkreetse esineja žanri tema laulu põhjal.

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

Andmete kustutamine tabelist

PostgreSQL

KUSTUTA MUUSIKA
KUS Esitaja = 'The Acme Band' JA LauluPealkiri = 'Look Out, World';

Cassandra

Sarnane eespool PostgreSQL näitele.

MongoDB

MongoDB-s on kaks tüüpi dokumentide kustutamise operatsioone — deleteOne() /deleteMany() ja remove(). Mõlemad tüübid kustutavad dokumente, kuid tagastavad erinevaid tulemusi.

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

Tabeli kustutamine

PostgreSQL

DROP TABLE Music;

Cassandra

Sarnane eespool PostgreSQL näitele.

MongoDB

db.music.drop();

Kokkuvõte

SQL ja NoSQL vaheline arutelu on kestnud juba üle 10 aasta. Selle arutelu kaks peamist aspekti on: andmebaasi tuumikarhitektuur (monoliitne, tehinguline SQL versus hajutatud, tehinguline NoSQL) ning andmebaasi kavandamise lähenemine (andmemudelite loomine SQL-is versus päringute modelleerimine NoSQL-is).

Hajutatud tehinguandmebaasi nagu YugaByte DB puhul on andmebaasi arhitektuuri arutelud kergesti hajutatud. Kuna andmemahud ületavad ühe sõlme kirjutamisvõimet, muutub täielikult hajutatud arhitektuur, mis toetab lineaarset kirjutamiskaalavust automaatse jaotamise ja ümberjaotamisega, hädavajalikuks.

Nagu üks artikkel ütleb Google Cloud, transaktsioonilised, rangelt kooskõlastatud arhitektuurid on nüüd laiemalt rakendatud, et tagada arenduse parem paindlikkus kui mittetransaktsioonilised, lõppkokkuvõttes kooskõlastatud arhitektuurid.

Naasdes andmebaasi kujundamise arutelule, on õiglane öelda, et mõlemad lähenemisviisid (SQL ja NoSQL) on vajalikud mis tahes keerulise rakenduse jaoks. SQL lähenemine 'andmemudeli moodustamine' võimaldab arendajatel hõlpsamini kohanduda muutuvate äri nõudmistega, samas kui NoSQL lähenemine 'päringute mudeli moodustamine' võimaldab neil arendajatel töötada suurte andmemahtudega, säilitades samal ajal madala latentsuse ja kõrge läbilaskevõime. Just sellepärast pakub YugaByte DB nii SQL kui ka NoSQL API-d ühes tuumas, mitte ei propageeri üht lähenemisviisi. Lisaks, tagades ühilduvuse populaarsete andmebaasikeeltega, sealhulgas PostgreSQL ja Cassandra, garanteerib YugaByte DB, et arendajad ei pea õppima uut keelt, et töötada jaotatud rangelt kooskõlastatud andmebaasi tuumaga.

Selles artiklis uurime, kuidas andmebaasi kavandamise alused erinevad PostgreSQL, Cassandra ja MongoDB puhul. Järgmistes artiklites süveneme edasijõudnud kavandamise kontseptsioonidesse, nagu indeksid, tehingud, JOIN'id, TTL-direktiivid ja JSON-dokumendid.

Soovime teile meeldivate ülejäänud nädalavahetuste mingeid ja kutsume teid tasuta veebinarile, mis toimub juba 14. mail.

Allikas: habr.com

Andmebaaside projekteerimise alused – PostgreSQL, Cassandra ja MongoDB võrdlus