Hallo freonen. Foardat wy nei it twadde diel fan 'e maaiefakânsje geane, diele wy it materiaal mei jo dat wy hawwe oerset yn ôfwachting fan de lansearring fan in nije stream op it taryf .
Applikaasje-ûntwikkelders besteegje in protte tiid oan it fergelykjen fan meardere operasjonele databases om dejinge te kiezen dy't it bêste wurket foar har bedoelde wurkdruk. Behoeften kinne ferienfâldige gegevensmodellearring, transaksje garânsjes, lês-/skriuwprestaasjes, horizontale skaalfergrutting en fouttolerânsje omfetsje. Tradysjoneel begjint de kar mei de kategory databank, SQL of NoSQL, om't elke kategory in dúdlike set fan ôfwikselingen leveret. Hege prestaasjes yn termen fan lege latency en hege trochslach wurdt algemien sjoen as in eask dy't net kompromittearre wurde kin en is dêrom essinsjeel foar elke databank yn 'e stekproef.
It doel fan dit artikel is om applikaasje-ûntwikkelders te helpen de juste kar te meitsjen tusken SQL en NoSQL yn 'e kontekst fan modeling fan applikaasjegegevens. Wy sille sjen nei ien SQL-database, nammentlik PostgreSQL, en twa NoSQL-databases, Cassandra en MongoDB, om de basis fan database-ûntwerp te dekken, lykas it meitsjen fan tabellen, it befolkjen fan se, it lêzen fan gegevens fan in tabel, en it wiskjen fan se. Yn it folgjende artikel sille wy perfoarst sjen nei yndeksen, transaksjes, JOIN's, TTL-rjochtlinen, en database-ûntwerp basearre op JSON.
Wat is it ferskil tusken SQL en NoSQL?
SQL-databases fergrutsje de fleksibiliteit fan tapassing troch ACID-transaksjonele garânsjes, lykas har fermogen om gegevens te freegjen mei JOIN's op ûnferwachte manieren boppe op besteande normalisearre relationele databankmodellen.
Sjoen har monolityske / ienknooppuntarsjitektuer en it brûken fan in master-slave-replikaasjemodel foar redundânsje, ûntbrekke tradisjonele SQL-databases twa wichtige funksjes - lineêre skriuwskaalberens (dus automatyske splitsing oer meardere knooppunten) en automatysk / nul gegevensferlies. Dit betsjut dat de hoemannichte gegevens ûntfongen net mear wêze kinne as de maksimale skriuwferfier fan in inkele knooppunt. Derneist moat wat tydlik ferlies fan gegevens rekken holden wurde foar fouttolerânsje (yn in net-dielde arsjitektuer). Hjir moatte jo yn 't sin hâlde dat resinte commits noch net werjûn binne yn' e slavekopy. Gjin downtime-updates binne ek lestich te berikken yn SQL-databases.
NoSQL-databases wurde typysk ferspraat yn 'e natuer, d.w.s. yn harren, de gegevens wurdt ferdield yn seksjes en ferdield oer ferskate knopen. Se hawwe denormalisaasje nedich. Dit betsjut dat de ynfierde gegevens ek ferskate kearen kopiearre wurde moatte om te reagearjen op de spesifike oanfragen dy't jo stjoere. It algemiene doel is om hege prestaasjes te krijen troch it ferminderjen fan it oantal shards beskikber op lêstiid. Dit ymplisearret dat NoSQL fereasket dat jo jo queries modellearje, wylst SQL jo fereasket om jo gegevens te modellearjen.
NoSQL rjochtet him op it berikken fan hege prestaasjes yn in ferspraat kluster en dit is de ûnderlizzende rationale foar in protte databankûntwerp tradeoffs dy't ACID transaksjeferlies, JOIN's en konsekwinte wrâldwide sekundêre yndeksen omfetsje.
D'r is in miening dat hoewol NoSQL-databases lineêre skriuwskaalberens en hege fouttolerânsje leverje, it ferlies fan transaksjonele garânsjes makket se net geskikt foar krityske gegevens.
De folgjende tabel lit sjen hoe't gegevensmodellering yn NoSQL ferskilt fan SQL.
SQL en NoSQL: Wêrom binne beide nedich?
Real-life applikaasjes mei in grut oantal brûkers, lykas Amazon.com, Netflix, Uber en Airbnb, binne ferantwurdlik foar it útfieren fan komplekse taken fan ferskate soarten. Bygelyks, in e-commerce-applikaasje lykas Amazon.com moat ljochtgewicht, heul gefoelige gegevens opslaan lykas ynformaasje oer brûkers, produkten, oarders, faktueren, tegearre mei swiere, mar minder gefoelige gegevens lykas produktresinsjes, stipeberjochten. , brûkersaktiviteit , brûker resinsjes en oanbefellings. Natuerlik fertrouwe dizze applikaasjes op op syn minst ien SQL-database tegearre mei op syn minst ien NoSQL-database. Yn ynterregionale en wrâldwide systemen wurket NoSQL-database as in geo-ferspraat cache foar gegevens opslein yn in fertroude boarne, SQL-database, opereare yn ien regio.
Hoe kombinearret YugaByte DB SQL en NoSQL?
Boud op in log-rjochte mingde opslachmotor, auto-sharding, sharded ferdielde konsensusreplikaasje, en ACID-ferdielde transaksjes (ynspirearre troch Google Spanner), YugaByte DB is de earste iepen boarne-database fan 'e wrâld dy't tagelyk NoSQL (Cassandra & Redis) kompatibel is. ) en SQL (PostgreSQL). Lykas werjûn yn 'e tabel hjirûnder, foeget YCQL, in YugaByte DB API kompatibel mei Cassandra, de konsepten fan single- en multi-key ACID-transaksjes en globale sekundêre yndeksen ta oan' e NoSQL API, wêrtroch it tiidrek fan transaksjonele NoSQL-databases ynliedt. Derneist foeget YCQL, in YugaByte DB API kompatibel mei PostgreSQL, de konsepten fan lineêre skriuwskaalfergrutting en automatyske failover ta oan de SQL API, en bringt ferspraat SQL-databases nei de wrâld. Om't de YugaByte DB-database ynherint transaksjoneel is, kin de NoSQL API no brûkt wurde yn 'e kontekst fan krityske gegevens.
Lykas earder oanjûn yn it artikel , de kar tusken SQL of NoSQL yn YugaByte DB hinget folslein ôf fan 'e skaaimerken fan' e ûnderlizzende wurkdruk:
- As jo primêre wurkdruk is multi-key JOIN operaasjes, dan as jo kieze YSQL, wês bewust dat jo kaaien kinne wurde ferspraat oer meardere knopen, resultearret yn hegere latency en / of legere trochstreaming dan NoSQL.
- Kies oars ien fan 'e twa NoSQL API's, hâld yn gedachten dat jo bettere prestaasjes krije as gefolch fan fragen dy't fan ien knooppunt tagelyk wurde betsjinne. YugaByte DB kin tsjinje as ien operasjonele databank foar echte komplekse applikaasjes dy't moatte beheare meardere workloads tagelyk.
It datamodelleringslab yn 'e folgjende seksje is basearre op de PostgreSQL- en Cassandra-kompatibele YugaByte DB-database API's, yn tsjinstelling ta de orizjinele databases. Dizze oanpak beklammet it gemak fan ynteraksje mei twa ferskillende API's (op twa ferskillende havens) fan deselde databankkluster, yn tsjinstelling ta it brûken fan folslein ûnôfhinklike klusters fan twa ferskillende databases.
Yn 'e folgjende seksjes sille wy it Data Modeling Lab besjen om it ferskil en guon fan' e mienskiplikheden fan 'e oanbelangjende databases te yllustrearjen.
Data Modeling Lab
Ynstallaasje fan databases
Sjoen de fokus op gegevensmodelûntwerp (ynstee fan komplekse ynset-arsjitektueren), sille wy de databases yn Docker-konteners op 'e lokale masine ynstallearje en dan mei har ynteraksje mei har respektivelike kommandorigel-shells.
PostgreSQL & Cassandra kompatibel, YugaByte DB databank
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:latestKommandorigel tagong
Litte wy ferbine mei de databases mei de kommandorigel-shell foar de respektivelike API's.
PostgreSQL
is in kommandorigel shell foar ynteraksje mei PostgreSQL. Foar gemak fan gebrûk komt YugaByte DB mei psql direkt yn 'e bin-map.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
is in kommandorigel shell foar ynteraksje mei Cassandra en har kompatibele databases fia CQL (Cassandra Query Language). Foar gemak fan gebrûk komt YugaByte DB mei cqlsh yn 'e katalogus bin.
Tink derom dat CQL waard ynspirearre troch SQL en hat ferlykbere konsepten fan tabellen, rigen, kolommen en yndeksen. As NoSQL-taal foeget it lykwols in bepaalde set beheiningen ta, wêrfan wy de measte ek sille dekke yn oare artikels.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
is in kommandorigel shell foar ynteraksje mei MongoDB. It kin fûn wurde yn 'e bin-map fan' e MongoDB-ynstallaasje.
docker exec -it my-mongo bash
cd bin
mongoMeitsje in tabel
No kinne wy ynteraksje mei de databank om ferskate operaasjes út te fieren mei de kommandorigel. Litte wy begjinne mei it meitsjen fan in tabel dy't ynformaasje opslacht oer ferskes skreaun troch ferskate artysten. Dizze ferskes kinne diel útmeitsje fan in album. Ek opsjonele attributen foar it ferske binne release jier, priis, sjenre en wurdearring. Wy moatte rekken hâlde mei ekstra attributen dy't mooglik nedich wêze yn 'e takomst fia it "tags" fjild. It kin semi-strukturearre gegevens opslaan as kaai-wearde-pearen.
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
It meitsjen fan in tabel yn Cassandra is heul gelyk oan PostgreSQL. Ien fan 'e wichtichste ferskillen is it gebrek oan yntegriteitsbeperkingen (bgl. NOT NULL), mar dit is de ferantwurdlikens fan 'e applikaasje, net de NoSQL-database. De primêre kaai bestiet út in partysjekaai (Artystkolom yn it foarbyld hjirûnder) en in set fan klusterkolommen (SongTitle-kolom yn it foarbyld hjirûnder). De partysjekaai bepaalt yn hokker partition / shard de rige yn te setten, en de klusterkolommen jouwe oan hoe't de gegevens moatte wurde organisearre binnen de aktuele shard.
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 organisearret gegevens yn databases (Database) (lykas Keyspace yn Cassandra), wêr't kolleksjes binne (Samlingen) (lykas tabellen) dy't dokuminten befetsje (Dokuminten) (lykas rigen yn in tabel). Yn MongoDB is yn prinsipe gjin earste skema-definysje nedich. Ploech "gebrûk databank", werjûn hjirûnder, instantiates de databank op de earste oprop en feroaret de kontekst foar de nij oanmakke databank. Sels kolleksjes hoege net eksplisyt oanmakke te wurden, se wurde automatysk oanmakke, krekt as it earste dokumint oan in nije kolleksje tafoege wurdt. Tink derom dat MongoDB standert in testdatabase brûkt, sadat elke operaasje op samlingnivo sûnder in spesifyk databank te spesifisearjen standert dêryn wurdt útfierd.
use myNewDatabase;Krij ynformaasje oer in tabel
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;It ynfieren fan gegevens yn in tabel
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
Yn it algemien, de útdrukking INSERT yn Cassandra liket heul op dat yn PostgreSQL. D'r is lykwols ien grut ferskil yn semantyk. Yn Cassandra INSERT is eins in operaasje UPSERT, wêr't de lêste wearden wurde tafoege oan 'e tekenrige, as de tekenrige al bestiet.
Gegevens ynfier is fergelykber mei PostgreSQL
INSERThegere
.
MongoDB
Sels hoewol MongoDB in NoSQL-database is lykas Cassandra, hat har gegevensynfieroperaasje neat te meitsjen mei Cassandra's semantyske gedrach. Yn MongoDB hat gjin kâns UPSERT, wat it fergelykber makket mei PostgreSQL. It tafoegjen fan standertgegevens sûnder _idspecified sil resultearje yn in nij dokumint wurdt tafoege oan de kolleksje.
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"
}
}
);
Tabelfraach
Miskien is it meast wichtige ferskil tusken SQL en NoSQL yn termen fan query-konstruksje de brûkte taal FROM и WHERE. SQL jout na útdrukking FROM selektearje meardere tabellen, en in útdrukking mei WHERE kin fan elke kompleksiteit wêze (ynklusyf operaasjes JOIN tusken tabellen). NoSQL hat lykwols de neiging om in hurde limyt op te lizzen FROM, en wurkje allinnich mei ien oantsjutte tabel, en yn WHERE, moat de primêre kaai altyd oantsjutte wurde. Dit is te tankjen oan 'e winsk om de prestaasjes fan NoSQL te ferbetterjen, wêr't wy earder oer praat hawwe. Dizze winsk liedt ta elke mooglike reduksje fan elke krúsljepper en krúskaai-ynteraksje. It kin in grutte fertraging ynfiere yn kommunikaasje tusken knooppunten by it reagearjen op in fersyk en wurdt dêrom yn prinsipe it bêste foarkommen. Bygelyks, Cassandra fereasket dat fersiken wurde beheind ta bepaalde operators (allinich tastien =, IN, <, >, =>, <=) op partition-kaaien, útsein by it opfreegjen fan in sekundêre yndeks (allinich de = operator is hjir tastien).
PostgreSQL
De folgjende binne trije foarbylden fan fragen dy't maklik kinne wurde útfierd troch in SQL-database.
- Lit alle ferskes fan in artyst sjen;
- Lit alle ferskes fan de artyst sjen dy't oerienkomme mei it earste diel fan 'e titel;
- Lit alle ferskes fan in artyst sjen dy't in bepaald wurd yn har titel hawwe en in priis hawwe fan minder dan 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
Fan 'e hjirboppe neamde PostgreSQL-fragen sil allinich de earste net feroare wurde yn Cassandra, om't de operator LIKE kin net tapast wurde op clustering kolommen lykas SongTitle. Yn dit gefal binne allinich operators tastien = и 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
Lykas werjûn yn 'e foarige foarbylden, is de wichtichste metoade foar it meitsjen fan queries yn MongoDB . Dizze metoade befettet eksplisyt de namme fan 'e kolleksje (music yn it foarbyld hjirûnder), sadat it opfreegjen fan meardere kolleksjes net tastien is.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Lês alle rigen fan in tabel
It lêzen fan alle rigen is gewoan in spesjaal gefal fan it querypatroan dat wy earder besprutsen hawwe.
PostgreSQL
SELECT *
FROM Music;Cassandra
Fergelykber mei it PostgreSQL-foarbyld hjirboppe.
MongoDB
db.music.find( {} );Gegevens bewurkje yn in tabel
PostgreSQL
PostgreSQL jout in ferklearring UPDATE om gegevens te feroarjen. Se hat gjin kânsen UPSERT, dus dizze ferklearring sil mislearje as de rige net mear yn 'e databank is.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandra hat UPDATE fergelykber mei PostgreSQL. UPDATE hat deselde semantyk UPSERT,lyk INSERT.
Fergelykber mei it PostgreSQL-foarbyld hjirboppe.
MongoDB
Operaasje yn MongoDB kin it in besteande dokumint folslein bywurkje of allinich bepaalde fjilden bywurkje. Standert bywurket it mar ien dokumint mei semantyk útskeakele UPSERT. Ferfarskje meardere dokuminten en ferlykber gedrach UPSERT kin tapast wurde troch it ynstellen fan ekstra flaggen foar de operaasje. Bygelyks, yn it foarbyld hjirûnder, wurdt it sjenre fan in bepaalde artyst bywurke troch syn ferske.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);It fuortsmiten fan gegevens út in tabel
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Fergelykber mei it PostgreSQL-foarbyld hjirboppe.
MongoDB
MongoDB hat twa soarten operaasjes foar it wiskjen fan dokuminten - и . Beide typen wiskje dokuminten, mar jouwe ferskillende resultaten.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
It wiskjen fan in tabel
PostgreSQL
DROP TABLE Music;Cassandra
Fergelykber mei it PostgreSQL-foarbyld hjirboppe.
MongoDB
db.music.drop();konklúzje
It debat oer de kar tusken SQL en NoSQL hat mear dan 10 jier razen. D'r binne twa haadaspekten foar dit debat: de arsjitektuer fan 'e databankmotor (monolitikum, transaksje-SQL vs. ferdield, net-transaksjeel NoSQL) en de oanpak fan databankûntwerp (datamodellearjen yn SQL vs. modelearjen fan jo queries yn NoSQL).
Mei in ferspraat transaksjonele databank lykas YugaByte DB, kin it debat oer databankarsjitektuer maklik wurde ferdwûn. As gegevensvoluminten grutter wurde as wat kin wurde skreaun nei in inkele knooppunt, wurdt in folslein ferdielde arsjitektuer dy't lineêre skriuwskalberens stipet mei automatyske sharding / rebalancing nedich.
Neist wat waard sein yn ien fan 'e artikels , Transactional, sterk konsekwint arsjitektueren wurde no mear wiidferspraat oannommen om te foarsjen bettere ûntwikkeling fleksibiliteit as net-transactional, úteinlik konsekwint arsjitektuer.
Werom nei de diskusje oer databankûntwerp, is it earlik te sizzen dat beide ûntwerpbenaderingen (SQL en NoSQL) nedich binne foar elke komplekse echte applikaasje. De oanpak fan "gegevensmodellering" fan SQL lit ûntwikkelders makliker foldwaan oan feroarjende saaklike easken, wylst de oanpak fan "querymodellering" fan NoSQL dizze deselde ûntwikkelders grutte hoemannichten gegevens mei lege latency en hege trochput kinne omgean. It is om dizze reden dat YugaByte DB SQL- en NoSQL APIs yn in mienskiplike kearn leveret, en pleitet net ien fan 'e oanpak. Derneist, troch kompatibiliteit te leverjen mei populêre databanktalen, ynklusyf PostgreSQL en Cassandra, soarget YugaByte DB dat ûntwikkelders gjin oare taal hoege te learen om te wurkjen mei in ferspraat sterk konsistinte databankmotor.
Yn dit artikel seagen wy hoe't de fûneminten fan database-ûntwerp ferskille tusken PostgreSQL, Cassandra en MongoDB. Yn takomstige artikels sille wy dûke yn avansearre ûntwerpkonsepten lykas yndeksen, transaksjes, JOIN's, TTL-rjochtlinen en JSON-dokuminten.
Wy winskje dy in moai wykein en noegje dy út , dat plakfynt op 14 maaie.
Boarne: www.habr.com