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

Tere, sõbrad. Enne lähiaegsete mai pühade teise osa algust jagame teiega materjali, mille oleme tõlkinud seoses uue kursuse voolu käivitamisega. „Suhtelised andmebaasid“.

Rakenduste arendajad kulutavad palju aega erinevate andmebaaside võrdlemiseks, et valida see, mis sobib kõige paremini ettenähtud töökoormusele. Nõuded võivad hõlmata andmemudeli lihtsustamist, tehingu garantiisid, lugemise/kirjutamise jõudlust, horisontaalset skaleeritavust ja tõrketaluvust. Traditsiooniliselt algab valik andmebaasi kategooriast, SQL või NoSQL, kuna iga kategooria pakub selget kompromisside kogumit. Kõrge jõudlus madala viivituse ja suure läbilaskevõime osas peetakse sageli kompromissituks nõudeks ja seetõttu on see vajalik iga valitud andmebaasi jaoks.

Käesoleva artikli eesmärk on aidata rakenduste arendajatel teha õige valik SQL ja NoSQL vahel rakenduse andmemudeli kontekstis. Uurime üht SQL-andmebaasi, nimelt PostgreSQL-i ja kahte NoSQL-andmebaasi – Cassandra ja MongoDB, et rääkida andmebaasi projekteerimise põhitõdedest, näiteks 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 JSONi alusel.

Mis on SQL-i ja NoSQL-i erinevus?

SQL-andmebaasid suurendavad rakenduse paindlikkust ACID-tehingu garantii kaudu ning nende võimega küsida andmeid JOIN-ide kaudu ootamatul viisil olemasolevate normaliseeritud relatsiooniliste andmebaasi mudelite peal.

Arvestades nende monoliitset/ühe sõlme arhitektuuri ja master-slave replikatsioonimudeli kasutamist üleliigsuse tagamiseks, puuduvad traditsioonilistel SQL-andmebaasidel kaks olulist omadust – lineaarne salvestamise skaleeritavus (st automaatne jagamine mitmele sõlmele) ja automaatne/nullkaotus andmeid. See tähendab, et saadud andmete maht ei tohiks ületada ühe sõlme maksimaalset kirjutamise läbilaskevõimet. Lisaks tuleb arvestada, et teatud ajavahemiku jooksul andmed võivad olla kadunud, kui räägime talitlushäiretest (ressursisegmentide jagamata arhitektuur). Siin tuleb meeles pidada, et hiljutised kinnitused pole veel alluvates (slave) koopiates kajastunud. Uuendused ilma seisakuta on samuti SQL-andmebaasides raskesti saavutatavad.

NoSQL-andmebaasid on oma olemuselt tavaliselt hajutatud, st andmed jagatakse sektsioonideks ja jaotatakse mitme sõlme vahel. Need nõuavad denormaliseerimist. See tähendab, et sisestatud andmed tuleb ka mitu korda kopeerida, et vastata konkreetsetele päringutele, mida saadate. Üks peamine eesmärk on saavutada kõrge jõudlus, vähendades lugemise ajal kergesti kätte saadavate shardide arvu. Seetõttu väidetakse, et NoSQL nõuab teilt oma päringute modelleerimist, samas kui SQL nõuab andmete modelleerimist.

NoSQL keskendub kõrge jõudluse saavutamisele hajutatud klastris ja see on peamine alus paljude andmebaasi projekteerimise kompromisside jaoks, mis hõlmavad ACIDi tehingute tagatiste kaotamist, JOIN-e ja kooskõlastatud globaalseid sekundaarindekseid.

On arvamus, et kuigi NoSQL-andmebaasid tagavad lineaarse salvestamise skaleeritavuse ja kõrge talitlushäirete vältimise, teeb tehingutagatiste kaotamine need sobimatuks kriitiliste andmete jaoks.

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

SQL ja NoSQL: Miks on mõlemad vajalikud?

Reaalsetel rakendustel, millel on suur kasutajaskond, nagu Amazon.com, Netflix, Uber ja Airbnb, on keeruliste mitmekesiste ülesannete täitmine. Näiteks peab e-kaubanduse rakendus nagu Amazon.com salvestama kergekaalulisi, kriitiliselt olulisi andmeid, nagu kasutajate, toodete, tellimuste ja arveandmete info, koos raskete, kuid vähem tundlike andmetega, nagu tooteülevaated, klienditeeninduse sõnumid, kasutajate tegevus, tagasiside ja soovitused. Loomulikult tuginevad need rakendused vähemalt ühele SQL-andmebaasile ja vähemalt ühele NoSQL-andmebaasile. Piirkondlikes ja globaalsetes süsteemides toimib NoSQL-andmebaas geograafiliselt jaotatud vahemäluna usaldusväärses allikas, SQL-andmebaas, mis töötab ühes piirkonnas.

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

YugaByte DB, mis on ehitatud logipõhisel segamootoril salvestamise, automaatse shardimise, shardide jagatud konsensuse replikatsiooni ja jaotatud ACID-tehingute jaoks (inspireeritud Google Spannerist), on maailma esimene avatud lähtekoodiga andmebaas, mis on samaaegselt ühilduv NoSQL-i (Cassandra & Redis) ja SQL-i (PostgreSQL) meetoditega. Nagu allolevast tabelist nähtub, lisab YCQL, YugaByte DB Cassandra ühilduv API, ühetasandi ja mitme võtme ACID-tehingute mõisted ning globaalsed sekundaarindeksid NoSQL API-sse, avades seeläbi uue ajastu tehinguliste NoSQL-andmebaaside jaoks. Lisaks sellele lisab YCQL, YugaByte DB PostgreSQL ühilduv API, dokumenteeritud kirjutamislinna lineaarne skaleerimine ja automaatne tõrketaluvus SQL API-sse, tõestades maailmale jaotatud SQL-andmebaaside olemasolu. Kuna YugaByte DB andmebaas on oma olemuselt tehinguline, on nüüd NoSQL API-d võimalik kasutada kriitiliselt oluliste andmete kontekstis.

Kuidas juba varem artiklis „Tutvustame YSQL: PostgreSQL-i ühilduv jaotatud SQL API YugaByte DB jaoks“, on valik SQL-i või NoSQL-i vahel YugaByte DB-s täielikult sõltuv põhikoormuse omadustest:

• Kui põhikoormus koosneb mitme võtme JOIN-operatsioonidest, peate YSQL-i valimisel arvestama, et teie võtmed võivad olla jaotatud mitmele sõlmele, mis toob kaasa suuremaid latentsusaegu ja/või madalamat läbilaskevõimet võrreldes NoSQL-iga.
• Vastasel juhul valige üks kahest NoSQL API-st, pidades meeles, et saate paremat jõudlust päringutes, mida teenindatakse ühe sõlme kaupa. YugaByte DB võib toimida ühtse andmebaasina keerukate rakenduste jaoks, kus tuleb samal ajal hallata mitmeid töökoormusi.

Järgmise osa andmemudeli laboratoorium põhineb YugaByte DB andmebaasidel, mis on ühilduvad PostgreSQL ja Cassandra API-dega, erinevalt algsetest andmebaasidest. See lähenemine rõhutab lihtsust, millega saab suhelda kahe erineva API-ga (kahel erineval pordil) sama andmebaasiklusteri puhul, erinevalt kahe erineva andmebaasi täiesti sõltumatute klastrite kasutamisest.
Järgmistes osades tutvume andmemudeli laboratooriumiga, et illustreerida arutatavate andmebaaside erinevusi ja mõningaid sarnaseid jooni.

Andmemudeli laboratoorium

Andmebaaside installimine

Kuna keskendume andmemudeli projekteerimisele (mitte keerukatele juurutusstruktuuridele), installime andmebaasid Docker konteineritesse kohalikule arvutile ja seejärel suhtleme nendega vastavate käsurea liideste abil.

PostgreSQL ja Cassandra ühilduv YugaByte DB andmebaas

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

Käsurea kaudu juurdepääs

Kõrge, ühendame andmebaasidega, kasutades vastava API jaoks käsurea liidest.

PostgreSQL

psql — see on käsurea liides PostgreSQL-i jaoks. Mugavuse huvides on YugaByte DB 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, mis suhtleb Cassandra ja selle ühilduvate andmebaasidega CQL (Cassandra päringukeel) kaudu. Mugavuse huvides on YugaByte DB varustatud cqlsh kaustas bin.
Pane tähele, et CQL on inspireeritud SQL-ist ja sisaldab sarnaseid mõisteid nagu tabelid, read, veerud ja indeksid. Kuid kui NoSQL keel, lisab see teatud piirangute komplekti, millest enamikku käsitleme ka teistes artiklites.

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

MongoDB

mongo – on käsurea liides MongoDB-ga suhtlemiseks. Seda võib leida MongoDB paigaldamise bin-kaustast.

docker exec -it my-mongo bash 
cd bin
mongo

Tabeli loomine

Praegu saame andmebaasiga suhelda erinevate toimingute täitmiseks käsurea kaudu. Alustame tabeli loomisest, mis salvestab teavet laulude kohta, mille on kirjutanud erinevad esitajad. Need laulud võivad olla osa albumist. Samuti on võimalikud valikulised atribuudid laulu jaoks – väljaandmise aasta, hind, žanr ja reiting. Peame arvestama täiendavate atribuutidega, mis võivad tulevikus vajalikuks osutuda, 'siltide' kaudu. See võib säilitada poolstruktureeritud andmeid võtme-väärtuse paaride kujul.

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

Tabeli loomine Cassandras on väga sarnane PostgreSQL-iga. Üks peamisi erinevusi on jaotuse piirangute puudumine (nt NOT NULL), kuid see kuulub rakenduse vastutusele, mitte NoSQL andmebaasile.. Esmane võti koosneb jaotuse võtme (samba Artist järgmises näites) ja klasterdamise veergude kogumist (samba SongTitle alljärgnevas näites). Jaotuse võti määrab, millises jaotuses/shardis rida asub, ja klasterdamise veerud näitavad, kuidas andmed peavad olema korraldatud hetkelises shardis.

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 korraldab andmeid andmebaaside (Database) (sarnaselt Cassandra Keyspace'ile), kus on kollektsioonid (Collections) (sarnaselt tabelitele), milles on dokumentide (Documents) (sarnaselt tabeli ridadele). MongoDB-s ei ole põhimõtteliselt vajalik algse skeemi määratlemine. Käsk «use database», nagu allpool näidatud, loob andmebaasi eksemplari esmakordsel kutsumisel ja muudab konteksti uuele loodud andmebaasile. Isegi kollektsioone ei pea eraldi looma, need luuakse automaatselt, kui lisatakse esimene dokument uude kollektsiooni. Pange tähele, et MongoDB kasutab vaikimisi testandmebaasi, seega igasugused kollektsioonide taseme toimingud ilma kindla andmebaasi määramiseta, toimuvad vaikimisi selles.

use myNewDatabase;

Teabe saamine tabeli kohta
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

KIRJELDA TABELIT 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

kasuta myNewDatabase;
näita kogusid;

Andmete lisamine 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

Üldiselt on väljend INSERT Cassandra's väga sarnane PostgreSQL-ile. Siiski on üks suur erinevus semantikas. Cassandra INSERT on tegelikult operatsioon UPSERT, kus ritta lisatakse viimasena mõõdetud väärtused, juhul kui rida juba eksisteerib.

Andmete sisestamine toimub sarnaselt PostgreSQL-iga INSERT üle

.

MongoDB

Kuigi MongoDB on NoSQL andmebaas, on selle andmete sisestamise operatsioon Cassandra'ga samaväärne, kuid nende semantika on erinev. MongoDB insert() ei oma võimalusi UPSERT, mistõttu sarnaneb see PostgreSQL-iga. Andmete lisamine ilma _idspecified toob kaasa uue dokumendi lisamise kogu.

db.music.insert( {
artist: "Keegi Sinu Seast",
songTitle: "Helista Täna",
albumTitle: "Veidi Kuulus",
year: 2015,
price: 2.14,
genre: "Kantri",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "Keegi Sinu Seast",
songTitle: "Minu Koer Spot",
albumTitle: "Hei Nüüd",
price: 1.98,
genre: "Kantri",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Vaata Välja, Maailm",
albumTitle:"Raha Algab Siit",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Endiselt Armastuses",
albumTitle:"Raha Algab Siit",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Hea"
}
}
);

Tabeli päring

Võib-olla on SQL ja NoSQL vahel kõige olulisem erinevus päringute koostamise osas väljendite kasutamine KUST ja KUS. SQL võimaldab pärast väljendit KUST valida mitu tabelit, ning väljendiga KUS võib olla ükskõik millise keerukusega (sealhulgas operatsioonid JOIN tabelite vahel). Kuid NoSQL kaldub kehtestama ranged piirangud KUST, töötades ainult ühe määratud tabeliga. KUS, alati peab olema määratud esmavõti. See on seotud NoSQLi jõudluse suurendamise sooviga, millest me varem rääkisime. See soov viib igasuguste ristskeemide ja ristsõlmeline suhtluse vähendamiseni. See võib põhjustada suuri viivitusi sõlmede vahelise suhtlemise ajal päringule vastamisel ning seetõttu on seda parim põhimõtteliselt vältida. Näiteks nõuab Cassandra, et päringud oleksid piiratud teatud operaatoritega (lubatud on ainult =, IN, , =>, <=) sektsioonide võtmete puhul, välja arvatud juhul, kui päring on teisejärguline indeks (siin on lubatud ainult operaator =).

PostgreSQL

Allpool on toodud kolm päringu näidet, mida SQL andmebaas suudab kergesti täita.

• Kuva kõik esineja lood;
• Kuva kõik esineja lood, mis vastavad pealkirja esimesele osale;
• Kuva kõik esineja lood, mille pealkirjas on teatud sõna 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 PostgreSQLis ainult esimene Cassandra's muutmata, kuna operaator LIKE ei saa rakendada klasterdamise veergude, nagu SongTitle. Sel 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 eelnevates näidetes näidatud, on MongoDB põhimeetod päringute loomiseks db.collection.find(). See meetod sisaldab selgelt kogu kollektsiooni nime (music allpooltoodud näites), seetõttu on päring mitme kollektsiooni kohta keelatud.

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

Lugege kõiki tabeli ridu

Küsimine kõikide ridadel — see on lihtsalt erijuht eelnevalt vaadatud päringute mallist.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Sarnane ülaltoodud PostgreSQL näitega.

MongoDB

db.music.find( {} );

Andmete muutmine tabelis

PostgreSQL

PostgreSQL pakub käsku UPDATE andmete muutmiseks. Sellel puuduvad võimalused UPSERT, seega lõpetatakse selle käsu täitmine veaga, kui ridu enam andmebaasis ei ole.

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

Cassandra

Cassandra's on UPDATE analoogne PostgreSQL. UPDATE on sama tähendusega UPSERT, sarnane INSERT.

Sarnane ülaltoodud PostgreSQL näitega.

MongoDB
Tehe update() MongoDB saab täielikult uuendada olemasolevat dokumenti või ainult teatud välju. Vaikimisi uuendab see ainult ühte dokumenti semantika välja lülitamisega. UPSERT. Mitme dokumendi uuendamise ja käitumine on sarnane. UPSERT võib rakendada, seadistades toimingule täiendavad lipud. Nagu näiteks allolevas näites uuendatakse konkreetse esineja žanri tema laulu järgi.

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

Andmete eemaldamine tabelist

PostgreSQL

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

Cassandra

Sarnane ülaltoodud PostgreSQL näitega.

MongoDB

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

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

Tabeli eemaldamine

PostgreSQL

DROP TABLE Music;

Cassandra

Sarnane ülaltoodud PostgreSQL näitega.

MongoDB

db.music.drop();

Kokkuvõte

Arutelud SQL ja NoSQL valikute üle on kestnud juba üle 10 aasta. Selle arutelu kaks peamist aspekti on: andmebaasi tuumaarhitektuur (monoliitne, transaktsiooniline SQL versus jaotatud, mitte transaktsiooniline NoSQL) ja andmebaasi projekteerimise lähenemisviid (andmemudeli loomine SQL-is versus päringute modelleerimine NoSQL-is).

Jaotatud transaktsioonilise andmebaasiga, nagu YugaByte DB, on andmebaasi arhitektuuri arutelud kergesti hajutatavad. Andmehulkade suurenedes, mida ei saa ühte sõlme salvestada, muutub täielikult jaotatud arhitektuur, mis toetab lineaarset kirjutamise skaleeritavust automaatse šarding- ja ümberjaotusega, vajalikuks.

Lisaks sellele, nagu ühes artiklis on öeldud Google Cloud, transaktsioonilised, rangelt kooskõlastatud arhitektuurid on nüüd laiemalt rakendatud, et tagada parem paindlikkus arenduses kui mitte transaktsioonilised, lõplikult kooskõlastatud arhitektuurid.

Tagasi andmebaaside kavandamise arutelu juurde on õiglane öelda, et mõlemad kavandamise lähenemisviisid (SQL ja NoSQL) on vajalikud igasuguste keerukate reaalsete rakenduste jaoks. SQL lähenemisviis 'andmemudelimine' võimaldab arendajatel kergemini rahuldada muutuvaid ärivajadusi, samas kui NoSQL lähenemisviis 'päringute modelleerimine' võimaldab neil samadel arendajatel hallata suuri andmemahtusid, omades samal ajal madalat latentsus aega ja suurt läbilaskevõimet. Just sellepärast pakub YugaByte DB SQL ja NoSQL API-d ühiselt, mitte ei propageeri mõnda ühte lähenemist. Lisaks tagades ühilduvuse populaarsete andmebaasikeeltega, sealhulgas PostgreSQL ja Cassandra, garanteerib YugaByte DB, et arendajatel ei pea olema veel üht keelt, et töötada jaotatud rangelt kooskõlastatud andmebaasi tuumaga.

Selles artiklis uurisime, kuidas andmebaaside kavandamise alused erinevad PostgreSQL, Cassandra ja MongoDB vahel. Järgnevates artiklites sukeldume edasijõudnud kavandamise kontseptsioonidesse, nagu indeksid, tehingud, JOIN’id, TTL direktiivid ja JSON-dokumendid.

Soovime teile meeldivalt kulgeda ülejäänud nädalavahetus ja kutsume teid which is taking place today at 20:00. During the webinar, we will discuss how to build an efficient and scalable data processing system for a small company or startup with minimal costs. As a part of the practice, we will get to know Google Cloud data processing tools. See you there!, mis toimub juba 14. mail.

Allikas: habr.com