Hello barátok. Mielőtt elindulnánk a májusi ünnepek második felére, megosztjuk veletek azt az anyagot, amelyet lefordítottunk a tanfolyamon egy új stream indulása előtt. .
Az alkalmazásfejlesztők sok időt töltenek több működő adatbázis összehasonlításával, hogy kiválasszák a tervezett munkaterhelésnek leginkább megfelelőt. Az igények magukban foglalhatják az egyszerűsített adatmodellezést, a tranzakciós garanciákat, az olvasási/írási teljesítményt, a vízszintes skálázást és a hibatűrést. Hagyományosan a választás az adatbázis-kategóriával, az SQL-lel vagy a NoSQL-lel kezdődik, mivel mindegyik kategória egyértelmű kompromisszumot tartalmaz. Az alacsony késleltetés és a nagy átviteli sebesség tekintetében fennálló nagy teljesítmény általában nem kompromisszumkövetelmény, ezért minden mintaadatbázisban elengedhetetlen.
Ennek a cikknek az a célja, hogy segítse az alkalmazásfejlesztőket az SQL és a NoSQL közötti helyes választásban az alkalmazásadat-modellezés keretében. Megvizsgálunk egy SQL-adatbázist, nevezetesen a PostgreSQL-t, és két NoSQL-adatbázist, a Cassandra-t és a MongoDB-t, hogy lefedjük az adatbázis-tervezés alapjait, például táblák létrehozását, feltöltését, adatok táblából való kiolvasását és törlését. A következő cikkben minden bizonnyal megvizsgáljuk az indexeket, a tranzakciókat, a JOIN-okat, a TTL-direktívákat és a JSON-alapú adatbázis-tervezést.
Mi a különbség az SQL és a NoSQL között?
Az SQL-adatbázisok az ACID tranzakciós garanciák révén növelik az alkalmazások rugalmasságát, valamint azt a képességüket, hogy a meglévő normalizált relációs adatbázis-modelleken felül váratlan módon JOIN használatával lekérdezzenek adatokat.
Tekintettel monolitikus/egycsomópontos architektúrájára és a mester-szolga replikációs modell használatára a redundanciára, a hagyományos SQL-adatbázisokból hiányzik két fontos tulajdonság: a lineáris írási skálázhatóság (azaz automatikus particionálás több csomópont között) és az automatikus/nulla adatvesztés. Ez azt jelenti, hogy a fogadott adatok mennyisége nem haladhatja meg egyetlen csomópont maximális írási teljesítményét. Ezen túlmenően a hibatűrésnél (megosztott semmi architektúrában) számolni kell némi átmeneti adatvesztéssel. Itt kell szem előtt tartania, hogy a legutóbbi véglegesítések még nem tükröződnek a szolga másolatban. Az SQL-adatbázisokban az állásidő nélküli frissítéseket is nehéz elérni.
A NoSQL adatbázisokat általában a természet terjeszti, pl. bennük az adatok szakaszokra vannak osztva, és több csomópont között vannak elosztva. Denormalizálást igényelnek. Ez azt jelenti, hogy a megadott adatokat is többször át kell másolni, hogy válaszolni tudjanak az Ön által küldött konkrét kérésekre. Az általános cél a nagy teljesítmény elérése az olvasás során elérhető szilánkok számának csökkentésével. Ez azt jelenti, hogy a NoSQL megköveteli a lekérdezések modellezését, míg az SQL megköveteli az adatok modellezését.
A NoSQL az elosztott fürtökben a nagy teljesítmény elérésére összpontosít, és ez az alapja számos adatbázis-tervezési kompromisszumnak, amelyek magukban foglalják az ACID-tranzakciók elvesztését, a JOIN-okat és a következetes globális másodlagos indexeket.
Érvek szerint bár a NoSQL adatbázisok lineáris írási méretezhetőséget és magas hibatűrést biztosítanak, a tranzakciós garanciák elvesztése alkalmatlanná teszi őket a kritikus fontosságú adatok tárolására.
A következő táblázat bemutatja, hogy miben különbözik az adatmodellezés a NoSQL-ben az SQL-től.
SQL és NoSQL: Miért van szükség mindkettőre?
A nagyszámú felhasználóval rendelkező valós alkalmazások, mint például az Amazon.com, a Netflix, az Uber és az Airbnb, összetett, sokrétű feladatok végrehajtásával vannak megbízva. Például egy e-kereskedelmi alkalmazásnak, például az Amazon.com-nak könnyű, rendkívül kritikus adatokat kell tárolnia, például felhasználói információkat, termékeket, rendeléseket, számlákat, valamint súlyos, kevésbé érzékeny adatokat, például termékismertetőket, támogatási üzeneteket, felhasználói tevékenységeket, felhasználói vélemények és ajánlások. Természetesen ezek az alkalmazások legalább egy SQL-adatbázisra, valamint legalább egy NoSQL-adatbázisra támaszkodnak. Régiók közötti és globális rendszerekben a NoSQL-adatbázis földrajzilag elosztott gyorsítótárként működik az egyetlen régióban futó megbízható forrású SQL-adatbázisban tárolt adatok számára.
Hogyan kombinálja a YugaByte DB az SQL-t és a NoSQL-t?
A naplóorientált vegyes tárolómotorra, az automatikus felosztásra, az elosztott konszenzusos replikációra és az ACID elosztott tranzakciókra (a Google Spanner által ihletett) épülő YugaByte DB a világ első nyílt forráskódú adatbázisa, amely egyidejűleg kompatibilis a NoSQL-lel (Cassandra & Redis) és SQL (PostgreSQL). Amint az alábbi táblázatban látható, az YCQL, a Cassandrával kompatibilis YugaByte DB API hozzáadja az egy- és többkulcsos ACID-tranzakciók és a globális másodlagos indexek fogalmát a NoSQL API-hoz, ezzel bevezetve a tranzakciós NoSQL-adatbázisok korszakát. Ezenkívül az YCQL, a PostgreSQL-lel kompatibilis YugaByte DB API hozzáadja a lineáris írási skálázás és az automatikus hibatűrés fogalmát az SQL API-hoz, így elosztott SQL adatbázisokat hoz a világba. Mivel a YugaByte DB tranzakciós jellegű, a NoSQL API már használható a küldetéskritikus adatok kontextusában.
Ahogy a cikkben korábban is szerepelt , az SQL vagy a NoSQL közötti választás a YugaByte DB-ben teljes mértékben az alapul szolgáló munkaterhelés jellemzőitől függ:
- Ha az elsődleges munkaterhelés a többkulcsos JOIN műveletek, akkor az YSQL kiválasztásakor vegye figyelembe, hogy a kulcsok több csomópont között is eloszthatók, ami magasabb késleltetést és/vagy alacsonyabb átviteli sebességet eredményez, mint a NoSQL.
- Ellenkező esetben válassza a két NoSQL API valamelyikét, szem előtt tartva, hogy jobb teljesítményt érhet el az egyszerre egy csomópontból kiszolgált lekérdezések eredményeként. A YugaByte DB egyetlen működő adatbázisként szolgálhat a valós, összetett alkalmazások számára, amelyeknek egyszerre több munkaterhelést kell kezelniük.
A következő részben található adatmodellező labor PostgreSQL és Cassandra API-kompatibilis YugaByte DB adatbázisokon alapul, szemben a natív adatbázisokkal. Ez a megközelítés hangsúlyozza az azonos adatbázis-fürt két különböző API-jával (két különböző porton) történő interakció egyszerűségét, szemben a két különböző adatbázisból álló, teljesen független fürtök használatával.
A következő szakaszokban az adatmodellező labort tekintjük át, hogy szemléltessük a tárgyalt adatbázisok különbségeit és néhány közös jellemzőjét.
Adatmodellező Laboratórium
Adatbázis telepítés
Mivel a hangsúly az adatmodell-tervezésen van (nem pedig az összetett telepítési architektúrákon), az adatbázisokat Docker-tárolókba telepítjük a helyi gépen, majd interakcióba lépünk velük a megfelelő parancssori rendszerhéjak használatával.
PostgreSQL és Cassandra kompatibilis YugaByte DB adatbázis
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_postgresMongoDB
docker run --name my-mongo -d mongo:latestParancssori hozzáférés
Csatlakozzunk az adatbázisokhoz a megfelelő API-khoz tartozó parancssori shell használatával.
PostgreSQL
egy parancssori shell a PostgreSQL-lel való interakcióhoz. A könnyebb használat érdekében a YugaByte DB a bin mappában található psql-lel együtt érkezik.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
egy parancssori shell a Cassandra-val és kompatibilis adatbázisaival való interakcióhoz CQL-n (Cassandra Query Language) keresztül. A könnyebb használat érdekében a YugaByte DB-t mellékeljük cqlsh a katalógusban bin.
Vegye figyelembe, hogy a CQL-t az SQL ihlette, és hasonló fogalmakat tartalmaz a táblázatokról, sorokról, oszlopokról és indexekről. NoSQL nyelvként azonban bizonyos korlátozásokat ad hozzá, amelyek többségére más cikkekben is kitérünk.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
egy parancssori shell a MongoDB-vel való interakcióhoz. A MongoDB telepítésének bin könyvtárában található.
docker exec -it my-mongo bash
cd bin
mongoHozzon létre egy táblázatot
Most már interakcióba léphetünk az adatbázissal, hogy különféle műveleteket hajtsunk végre a parancssor használatával. Kezdjük egy táblázat létrehozásával, amely információkat tárol a különböző előadók által írt dalokról. Ezek a dalok egy album részei lehetnek. A dal opcionális attribútumai a megjelenés éve, az ár, a műfaj és a minősítés is. A "címkék" mezőn keresztül további attribútumokkal kell számolnunk, amelyekre a jövőben szükség lehet. Félig strukturált adatokat képes tárolni kulcs-érték párok formájában.
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
A Cassandra tábla létrehozása nagyon hasonlít a PostgreSQL-hez. Az egyik fő különbség az integritási megszorítások hiánya (pl. NOT NULL), de ez az alkalmazás felelőssége, nem a NoSQL adatbázisé. Az elsődleges kulcs egy partíciókulcsból (az alábbi példában az Előadó oszlopból) és egy csoportos oszlopkészletből áll (az alábbi példában a Dal címe oszlop). A partíciókulcs határozza meg, hogy a sort melyik partícióba/szilánkba kell elhelyezni, a fürtözési oszlopok pedig jelzik, hogyan kell az adatokat az aktuális szilánkon belül rendezni.
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
A MongoDB adatbázisokba (Database) rendezi az adatokat (hasonlóan a Cassandra Keyspace-hez), ahol vannak gyűjtemények (a táblákhoz hasonlóan), amelyek dokumentumokat tartalmaznak (hasonlóan a tábla soraihoz). A MongoDB-ben alapvetően nincs szükség kezdeti séma meghatározására. Csapat "adatbázis használata"Az alább látható, az első hívásnál példányosítja az adatbázist, és megváltoztatja az újonnan létrehozott adatbázis környezetét. Még a gyűjteményeket sem kell kifejezetten létrehozni; automatikusan jönnek létre, egyszerűen amikor hozzáadja az első dokumentumot egy új gyűjteményhez. Vegye figyelembe, hogy a MongoDB alapértelmezés szerint a tesztadatbázist használja, így minden gyűjteményszintű művelet, amely nem határoz meg egy adott adatbázist, alapértelmezés szerint azon fut.
use myNewDatabase;Táblázattal kapcsolatos információk beszerzése
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;Adatok bevitele egy táblázatba
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
Általános kifejezés INSERT a Cassandra nagyon hasonlít a PostgreSQL-hez. Van azonban egy nagy különbség a szemantikában. Cassandrában INSERT valójában egy művelet UPSERT, ahol az utolsó értékek hozzáadódnak a sorhoz, ha a sor már létezik.
Az adatbevitel hasonló a PostgreSQL-hez
INSERTfelett
.
MongoDB
Annak ellenére, hogy a MongoDB egy NoSQL-adatbázis, mint a Cassandra, a beillesztési műveletének semmi köze nincs Cassandra szemantikai viselkedéséhez. A MongoDB-ben nincs lehetősége UPSERT, ami hasonlóvá teszi a PostgreSQL-hez. Alapértelmezett adatok hozzáadása nélkül _idspecified új dokumentumot ad hozzá a gyűjteményhez.
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"
}
}
);
Táblázat lekérdezés
Talán a legjelentősebb különbség az SQL és a NoSQL között a lekérdezés felépítése szempontjából a használt nyelv FROM и WHERE. Az SQL lehetővé teszi a kifejezés után FROM válasszon ki több táblát, és kifejezést a WHERE bármilyen bonyolultságú lehet (beleértve a műveleteket is JOIN táblázatok között). A NoSQL azonban hajlamos szigorú korlátozásokat előírni FROM, és csak egy megadott táblával dolgozzon, és in WHERE, az elsődleges kulcsot mindig meg kell adni. Ez kapcsolódik a NoSQL teljesítménynöveléséhez, amelyről korábban beszéltünk. Ez a vágy a táblázatok és kulcsok közötti interakció minden lehetséges csökkentését eredményezi. Nagy késést okozhat a csomópontok közötti kommunikációban, amikor egy kérésre válaszol, ezért általában a legjobb elkerülni. Például a Cassandra megköveteli, hogy a lekérdezéseket bizonyos operátorokra korlátozzák (csak =, IN, <, >, =>, <=) partíciós kulcsokon, kivéve másodlagos index kérése esetén (itt csak az = operátor megengedett).
PostgreSQL
Az alábbiakban három példa látható olyan lekérdezésekre, amelyeket könnyen végrehajthat egy SQL-adatbázis.
- Egy előadó összes dalának megjelenítése;
- Az előadó összes dalának megjelenítése, amely megfelel a cím első részének;
- Egy előadó összes olyan dalának megjelenítése, amelynek a címe egy bizonyos szót tartalmaz, és az ára 1.00 alatt van.
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
A fent felsorolt PostgreSQL lekérdezések közül csak az első fog változatlanul működni Cassandrában, mivel az operátor LIKE nem alkalmazható olyan klaszterező oszlopokra, mint pl SongTitle. Ebben az esetben csak operátorok engedélyezettek = и 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
Amint az az előző példákban látható, a MongoDB-ben a lekérdezések létrehozásának fő módja a következő . Ez a metódus kifejezetten tartalmazza a gyűjtemény nevét (music az alábbi példában), így több gyűjtemény lekérdezése tilos.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Egy táblázat összes sorának beolvasása
Az összes sor beolvasása egyszerűen a korábban vizsgált lekérdezési minta speciális esete.
PostgreSQL
SELECT *
FROM Music;Cassandra
Hasonló a fenti PostgreSQL példához.
MongoDB
db.music.find( {} );Adatok szerkesztése táblázatban
PostgreSQL
A PostgreSQL utasításokat ad UPDATE az adatok megváltoztatásához. Nincsenek lehetőségei UPSERT, így ez az utasítás meghiúsul, ha a sor már nincs az adatbázisban.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandrának van UPDATE hasonló a PostgreSQL-hez. UPDATE ugyanaz a szemantika UPSERT, hasonló INSERT.
Hasonló a fenti PostgreSQL példához.
MongoDB
Működés a MongoDB-ben teljesen frissíthet egy meglévő dokumentumot, vagy csak bizonyos mezőket frissíthet. Alapértelmezés szerint csak egy dokumentumot frissít, ha a szemantika le van tiltva UPSERT. Több dokumentum frissítése és hasonló viselkedés UPSERT a művelethez további jelzők beállításával lehet alkalmazni. Például az alábbi példában egy adott előadó műfaja a dal alapján frissül.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Adatok eltávolítása a táblázatból
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Hasonló a fenti PostgreSQL példához.
MongoDB
A MongoDB kétféle művelettel rendelkezik a dokumentumok törlésére − и . Mindkét típus törli a dokumentumokat, de eltérő eredményeket ad vissza.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Táblázat törlése
PostgreSQL
DROP TABLE Music;Cassandra
Hasonló a fenti PostgreSQL példához.
MongoDB
db.music.drop();Következtetés
A vita az SQL és a NoSQL közötti választásról több mint 10 éve dúl. Ennek a vitának két fő szempontja van: az adatbázismotor-architektúra (monolit, tranzakciós SQL vs. elosztott, nem tranzakciós NoSQL) és az adatbázis-tervezési megközelítés (az adatok modellezése SQL-ben, illetve a lekérdezések modellezése NoSQL-ben).
Az olyan elosztott tranzakciós adatbázisokkal, mint a YugaByte DB, az adatbázis-architektúráról szóló vita könnyen megnyugtatható. Ahogy az adatmennyiségek nagyobbak lesznek, mint amennyi egyetlen csomópontra írható, egy teljesen elosztott architektúra válik szükségessé, amely támogatja a lineáris írási méretezhetőséget automatikus felosztással/újraegyensúlyozással.
Ráadásul, ahogy az egyik cikkben is szerepel ,Tranzakciós, erősen konzisztens architektúrákat ma már inkább használnak jobb fejlesztési agilitásra, mint a nem tranzakciós, végül konzisztens architektúrákat.
Visszatérve az adatbázis-tervezési vitához, jogos kijelenteni, hogy mindkét tervezési megközelítés (SQL és NoSQL) szükséges minden összetett valós alkalmazáshoz. Az SQL „adatmodellezési” megközelítés lehetővé teszi a fejlesztők számára, hogy könnyebben megfeleljenek a változó üzleti követelményeknek, míg a NoSQL „lekérdezési modellezési” megközelítése lehetővé teszi, hogy ugyanazok a fejlesztők nagy mennyiségű adattal, alacsony késleltetéssel és nagy áteresztőképességgel dolgozzanak. Ez az oka annak, hogy a YugaByte DB SQL és NoSQL API-kat biztosít egy közös magban, nem pedig az egyik megközelítést. Ezenkívül a népszerű adatbázisnyelvekkel, köztük a PostgreSQL-lel és a Cassandra-val való kompatibilitás biztosításával a YugaByte DB biztosítja, hogy a fejlesztőknek ne kelljen másik nyelvet tanulniuk ahhoz, hogy egy elosztott, rendkívül konzisztens adatbázis-motorral dolgozhassanak.
Ebben a cikkben megvizsgáltuk, hogyan különböznek az adatbázis-tervezés alapjai a PostgreSQL, a Cassandra és a MongoDB között. A jövőbeli cikkeinkben olyan fejlett tervezési koncepciókkal fogunk foglalkozni, mint az indexek, tranzakciók, JOIN-ok, TTL-direktívák és JSON-dokumentumok.
Kellemes hétvégét kívánunk, és meghívjuk , amelyre május 14-én kerül sor.
Forrás: will.com