ProHoster > Blog > administratë > Bazat e dizajnit të bazës së të dhënave - Krahasimi i PostgreSQL, Cassandra dhe MongoDB

Bazat e dizajnit të bazës së të dhënave - Krahasimi i PostgreSQL, Cassandra dhe MongoDB

Përshëndetje miq. Përpara nisjes për në pjesën e dytë të festave të majit, ndajmë me ju materialin që përkthyem në pritje të nisjes së një transmetimi të ri në kurs. "DBMS relacionale".

Bazat e dizajnit të bazës së të dhënave - Krahasimi i PostgreSQL, Cassandra dhe MongoDB

Zhvilluesit e aplikacioneve shpenzojnë shumë kohë duke krahasuar bazat e të dhënave të shumta operacionale për të zgjedhur atë që i përshtatet më mirë ngarkesës së synuar të punës. Nevojat mund të përfshijnë modelimin e thjeshtuar të të dhënave, garancitë e transaksioneve, performancën e leximit/shkrimit, shkallëzimin horizontal dhe tolerancën ndaj gabimeve. Tradicionalisht, zgjedhja fillon me kategorinë e bazës së të dhënave, SQL ose NoSQL, pasi secila kategori paraqet një grup të qartë kompromisesh. Performanca e lartë për sa i përket vonesës së ulët dhe xhiros së lartë përgjithësisht shihet si një kërkesë jo-shkëmbimi dhe për këtë arsye është thelbësore për çdo bazë të dhënash të mostrës.

Qëllimi i këtij artikulli është të ndihmojë zhvilluesit e aplikacioneve të bëjnë zgjedhjen e duhur midis SQL dhe NoSQL në kontekstin e modelimit të të dhënave të aplikacionit. Ne do të shikojmë një bazë të dhënash SQL, përkatësisht PostgreSQL, dhe dy baza të të dhënave NoSQL, Cassandra dhe MongoDB, për të mbuluar bazat e dizajnit të bazës së të dhënave, si krijimi i tabelave, plotësimi i tyre, leximi i të dhënave nga një tabelë dhe fshirja e tyre. Në artikullin vijues, do të jemi të sigurt që të shikojmë indekset, transaksionet, JOIN-et, direktivat TTL dhe dizajnin e bazës së të dhënave të bazuar në JSON.

Cili është ndryshimi midis SQL dhe NoSQL?

Bazat e të dhënave SQL rrisin fleksibilitetin e aplikacionit përmes garancive transaksionale ACID, si dhe aftësinë e tyre për të kërkuar të dhëna duke përdorur JOIN në mënyra të papritura në krye të modeleve ekzistuese të të dhënave relacionale të normalizuara.

Duke pasur parasysh arkitekturën e tyre monolitike/me një nyje dhe përdorimin e një modeli të replikimit master-slave për tepricë, bazave të të dhënave tradicionale SQL u mungojnë dy veçori të rëndësishme - shkallëzueshmëria lineare e shkrimit (d.m.th. ndarje automatike nëpër nyje të shumta) dhe humbja automatike/zero e të dhënave. Kjo do të thotë që sasia e të dhënave të marra nuk mund të kalojë xhiron maksimale të shkrimit të një nyje të vetme. Përveç kësaj, disa humbje të përkohshme të të dhënave duhet të merren parasysh në tolerancën e gabimeve (në një arkitekturë të përbashkët-asgjë). Këtu duhet të keni parasysh se kryerjet e fundit nuk janë pasqyruar ende në kopjen skllav. Përditësimet pa ndërprerje janë gjithashtu të vështira për t'u arritur në bazat e të dhënave SQL.

Bazat e të dhënave NoSQL zakonisht shpërndahen nga natyra, d.m.th. në to, të dhënat ndahen në seksione dhe shpërndahen nëpër disa nyje. Ata kërkojnë denormalizim. Kjo do të thotë që të dhënat e futura duhet gjithashtu të kopjohen disa herë për t'iu përgjigjur kërkesave specifike që dërgoni. Qëllimi i përgjithshëm është të përftoni performancë të lartë duke reduktuar numrin e copave të disponueshme gjatë leximeve. Kjo nënkupton që NoSQL kërkon që ju të modeloni pyetjet tuaja, ndërsa SQL kërkon që ju të modeloni të dhënat tuaja.

NoSQL fokusohet në arritjen e performancës së lartë në një grupim të shpërndarë dhe ky është arsyetimi themelor për shumë kompromiset e dizajnit të bazës së të dhënave që përfshijnë humbjen e transaksioneve ACID, JOIN-at dhe indekset dytësore të qëndrueshme globale.

Ekziston një argument se ndërsa bazat e të dhënave NoSQL ofrojnë shkallëzim linear të shkrimit dhe tolerancë të lartë ndaj gabimeve, humbja e garancive transaksionale i bën ato të papërshtatshme për të dhëna kritike për misionin.

Tabela e mëposhtme tregon se si modelimi i të dhënave në NoSQL ndryshon nga SQL.

Bazat e dizajnit të bazës së të dhënave - Krahasimi i PostgreSQL, Cassandra dhe MongoDB

SQL dhe NoSQL: Pse nevojiten të dyja?

Aplikacionet e botës reale me një numër të madh përdoruesish, si Amazon.com, Netflix, Uber dhe Airbnb, kanë për detyrë të kryejnë detyra komplekse dhe shumëplanëshe. Për shembull, një aplikacion e-commerce si Amazon.com duhet të ruajë të dhëna të lehta, me rëndësi të lartë, si informacionet e përdoruesit, produktet, porositë, faturat, së bashku me të dhëna të rënda, më pak të ndjeshme si rishikimet e produkteve, mesazhet mbështetëse, aktivitetin e përdoruesit, komentet dhe rekomandimet e përdoruesve. Natyrisht, këto aplikacione mbështeten në të paktën një bazë të dhënash SQL së bashku me të paktën një bazë të dhënash NoSQL. Në sistemet ndër-rajonale dhe globale, një bazë të dhënash NoSQL funksionon si një memorie e shpërndarë gjeo-shpërndarë për të dhënat e ruajtura në një bazë të dhënash SQL me burim të besuar që funksionon në një rajon të vetëm.

Si kombinon YugaByte DB SQL dhe NoSQL?

E ndërtuar mbi një motor ruajtjeje të përzier të orientuar nga regjistrat, ndarjen automatike, riprodhimin e konsensusit të shpërndarë të copëtuar dhe transaksionet e shpërndara ACID (frymëzuar nga Google Spanner), YugaByte DB është baza e të dhënave e parë me burim të hapur në botë që është njëkohësisht e pajtueshme me NoSQL (Cassandra & Redis) dhe SQL (PostgreSQL). Siç tregohet në tabelën më poshtë, YCQL, YugaByte DB API i pajtueshëm me Cassandra, shton konceptet e transaksioneve ACID me një dhe shumë çelës dhe indekset dytësore globale në API-në NoSQL, duke sjellë kështu epokën e bazave të të dhënave NoSQL transaksionale. Për më tepër, YCQL, YugaByte DB API i pajtueshëm me PostgreSQL, shton konceptet e shkallëzimit linear të shkrimit dhe tolerancës automatike të gabimeve në SQL API, duke sjellë bazat e të dhënave të shpërndara SQL në botë. Për shkak se YugaByte DB ka natyrë transaksionale, API NoSQL tani mund të përdoret në kontekstin e të dhënave kritike për misionin.

Bazat e dizajnit të bazës së të dhënave - Krahasimi i PostgreSQL, Cassandra dhe MongoDB

Siç u tha më parë në artikull "Prezantimi i YSQL: Një API SQL e shpërndarë e pajtueshme me PostgreSQL për YugaByte DB", zgjedhja midis SQL ose NoSQL në YugaByte DB varet tërësisht nga karakteristikat e ngarkesës themelore të punës:

  • Nëse ngarkesa juaj kryesore e punës janë operacionet JOIN me shumë çelësa, atëherë kur zgjidhni YSQL, kuptoni se çelësat tuaj mund të shpërndahen nëpër nyje të shumta, duke rezultuar në vonesë më të lartë dhe/ose xhiros më të ulët se NoSQL.
  • Përndryshe, zgjidhni njërën nga dy API-të NoSQL, duke pasur parasysh se do të merrni performancë më të mirë si rezultat i pyetjeve të ofruara nga një nyje në të njëjtën kohë. YugaByte DB mund të shërbejë si një bazë të dhënash e vetme operacionale për aplikacione komplekse të botës reale që duhet të menaxhojnë ngarkesa të shumta pune njëkohësisht.

Laboratori i modelimit të të dhënave në seksionin tjetër bazohet në bazat e të dhënave YugaByte DB të pajtueshme me PostgreSQL dhe Cassandra API, në krahasim me bazat e të dhënave vendase. Kjo qasje thekson lehtësinë e ndërveprimit me dy API të ndryshme (në dy porte të ndryshme) të të njëjtit grup bazë të dhënash, në krahasim me përdorimin e grupimeve krejtësisht të pavarura të dy bazave të të dhënave të ndryshme.
Në seksionet e mëposhtme, ne do t'i hedhim një vështrim laboratorit të modelimit të të dhënave për të ilustruar ndryshimet dhe disa nga të përbashkëtat e bazave të të dhënave të mbuluara.

Laboratori i Modelimit të të Dhënave

Instalimi i bazës së të dhënave

Duke pasur parasysh theksin në hartimin e modelit të të dhënave (në vend të arkitekturave komplekse të vendosjes), ne do të instalojmë bazat e të dhënave në kontejnerët Docker në makinën lokale dhe më pas do të ndërveprojmë me to duke përdorur predhat përkatëse të linjës së komandës.

Baza e të dhënave YugaByte DB e pajtueshme me PostgreSQL & Cassandra

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

Qasja në linjën e komandës

Le të lidhemi me bazat e të dhënave duke përdorur guaskën e linjës së komandës për API-të përkatëse.

PostgreSQL

psql është një guaskë e linjës komanduese për ndërveprim me PostgreSQL. Për lehtësinë e përdorimit, YugaByte DB vjen me psql pikërisht në dosjen e koshit.

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

Cassandra

cqlsh është një guaskë e linjës komanduese për ndërveprim me Cassandra dhe bazat e të dhënave të saj të pajtueshme nëpërmjet CQL (Cassandra Query Language). Për lehtësinë e përdorimit, YugaByte DB vjen me cqlsh në katalog bin.
Vini re se CQL u frymëzua nga SQL dhe ka koncepte të ngjashme të tabelave, rreshtave, kolonave dhe indekseve. Sidoqoftë, si gjuhë NoSQL, ajo shton një grup të caktuar kufizimesh, shumicën e të cilave do t'i trajtojmë edhe në artikuj të tjerë.

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

MongoDB

Mongo është një guaskë e linjës komanduese për ndërveprim me MongoDB. Mund të gjendet në drejtorinë e koshit të instalimit MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Krijo një tabelë

Tani ne mund të ndërveprojmë me bazën e të dhënave për të kryer operacione të ndryshme duke përdorur vijën e komandës. Le të fillojmë duke krijuar një tabelë që ruan informacione për këngët e shkruara nga artistë të ndryshëm. Këto këngë mund të jenë pjesë e një albumi. Gjithashtu atributet opsionale për një këngë janë viti i publikimit, çmimi, zhanri dhe vlerësimi. Ne duhet të llogarisim për atributet shtesë që mund të nevojiten në të ardhmen përmes fushës "tags". Mund të ruajë të dhëna gjysmë të strukturuara në formën e çifteve të vlerave kyçe.

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

Krijimi i një tabele në Cassandra është shumë i ngjashëm me PostgreSQL. Një nga ndryshimet kryesore është mungesa e kufizimeve të integritetit (p.sh. NOT NULL), por kjo është përgjegjësi e aplikacionit, jo e bazës së të dhënave NoSQL. Çelësi kryesor përbëhet nga një çelës ndarjeje (kolona Artist në shembullin më poshtë) dhe një grup kolonash grupimi (kolona SongTitle në shembullin më poshtë). Çelësi i ndarjes përcakton se në cilën ndarje/pjesë duhet të vendoset rreshti, dhe kolonat e grupimit tregojnë se si duhet të organizohen të dhënat brenda pjesës aktuale.

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 organizon të dhënat në baza të të dhënave (Baza e të dhënave) (e ngjashme me Keyspace në Cassandra), ku ka Koleksione (të ngjashme me tabelat) që përmbajnë Dokumente (të ngjashme me rreshtat në një tabelë). Në MongoDB, në thelb nuk ka nevojë të përcaktohet një skemë fillestare. Ekipi "përdor bazën e të dhënave", i paraqitur më poshtë, instancon bazën e të dhënave në thirrjen e parë dhe ndryshon kontekstin për bazën e të dhënave të krijuar rishtazi. Edhe koleksionet nuk kanë nevojë të krijohen në mënyrë eksplicite; ato krijohen automatikisht, thjesht kur shtoni dokumentin e parë në një koleksion të ri. Vini re se MongoDB përdor bazën e të dhënave të testimit si parazgjedhje, kështu që çdo operacion në nivel koleksioni pa specifikuar një bazë të dhënash specifike do të ekzekutohet në të si parazgjedhje. 

use myNewDatabase;

Marrja e informacionit për një 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;

Futja e të dhënave në një 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

Shprehja e përgjithshme INSERT në Cassandra duket shumë e ngjashme me atë në PostgreSQL. Sidoqoftë, ekziston një ndryshim i madh në semantikë. Në Kasandra INSERT në fakt është një operacion UPSERT, ku vlerat e fundit i shtohen rreshtit nëse rreshti tashmë ekziston.

Futja e të dhënave është e ngjashme me PostgreSQL INSERT sipër

.

MongoDB

Edhe pse MongoDB është një bazë të dhënash NoSQL si Cassandra, operacioni i futjes së tij nuk ka asgjë të përbashkët me sjelljen semantike të Cassandra. Në MongoDB fut () nuk ka mundësi UPSERT, gjë që e bën atë të ngjashëm me PostgreSQL. Shtimi i të dhënave të paracaktuar pa _idspecified do të bëjë që një dokument i ri të shtohet në koleksion.

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"
}
}
);

Pyetja e tabelës

Ndoshta ndryshimi më domethënës midis SQL dhe NoSQL për sa i përket ndërtimit të pyetjeve është gjuha e përdorur FROM и WHERE. SQL lejon pas shprehjes FROM zgjidhni tabela të shumta dhe shprehni me WHERE mund të jetë i çdo kompleksiteti (përfshirë operacionet JOIN ndërmjet tabelave). Sidoqoftë, NoSQL tenton të vendosë një kufizim të rëndë FROM, dhe punoni vetëm me një tabelë të specifikuar, dhe në WHERE, çelësi primar duhet të specifikohet gjithmonë. Kjo lidhet me shtytjen e performancës NoSQL për të cilën folëm më parë. Kjo dëshirë çon në çdo reduktim të mundshëm në çdo ndërveprim ndër-tabelor dhe ndër-kyç. Mund të sjellë një vonesë të madhe në komunikimin ndërmjet nyjeve kur i përgjigjet një kërkese dhe për këtë arsye është më mirë të shmanget në përgjithësi. Për shembull, Cassandra kërkon që pyetjet të kufizohen në disa operatorë (vetëm =, IN, <, >, =>, <=) në çelësat e ndarjes, përveç kur kërkohet një indeks dytësor (vetëm operatori = lejohet këtu).

PostgreSQL

Më poshtë janë tre shembuj të pyetjeve që mund të ekzekutohen lehtësisht nga një bazë të dhënash SQL.

  • Shfaq të gjitha këngët e një artisti;
  • Shfaq të gjitha këngët e artistit që përputhen me pjesën e parë të titullit;
  • Shfaq të gjitha këngët e një artisti që kanë një fjalë të caktuar në titull dhe kanë një çmim më të vogël se 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

Nga pyetjet PostgreSQL të listuara më sipër, vetëm i pari do të funksionojë i pandryshuar në Cassandra, pasi operatori LIKE nuk mund të aplikohet në kolonat e grupimit si p.sh SongTitle. Në këtë rast, lejohen vetëm operatorët = и 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

Siç tregohet në shembujt e mëparshëm, metoda kryesore për krijimin e pyetjeve në MongoDB është db.collection.find(). Kjo metodë përmban në mënyrë eksplicite emrin e koleksionit (music në shembullin e mëposhtëm), kështu që pyetja për koleksione të shumta është e ndaluar.

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

Leximi i të gjitha rreshtave të një tabele

Leximi i të gjitha rreshtave është thjesht një rast i veçantë i modelit të pyetjes që shikuam më herët.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Ngjashëm me shembullin PostgreSQL më sipër.

MongoDB

db.music.find( {} );

Redaktimi i të dhënave në një tabelë

PostgreSQL

PostgreSQL ofron udhëzime UPDATE për të ndryshuar të dhënat. Ajo nuk ka mundësi UPSERT, kështu që kjo deklaratë do të dështojë nëse rreshti nuk është më në bazën e të dhënave.

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

Cassandra

Kasandra ka UPDATE të ngjashme me PostgreSQL. UPDATE ka të njëjtën semantikë UPSERT, i ngjashëm INSERT.

Ngjashëm me shembullin PostgreSQL më sipër.

MongoDB
Operacion azhurnoj () në MongoDB mund të përditësojë plotësisht një dokument ekzistues ose të përditësojë vetëm disa fusha. Si parazgjedhje, ai përditëson vetëm një dokument me semantikë të çaktivizuar UPSERT. Përditësimi i dokumenteve të shumta dhe sjellje të ngjashme UPSERT mund të aplikohet duke vendosur flamuj shtesë për operacionin. Për shembull, në shembullin më poshtë, zhanri i një artisti specifik përditësohet bazuar në këngën e tij.

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

Heqja e të dhënave nga një tabelë

PostgreSQL

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

Cassandra

Ngjashëm me shembullin PostgreSQL më sipër.

MongoDB

MongoDB ka dy lloje operacionesh për të fshirë dokumentet - fshijOne() /deleteMany() и hiq (). Të dy llojet fshijnë dokumentet, por kthejnë rezultate të ndryshme. 

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

Fshirja e një tabele

PostgreSQL

DROP TABLE Music;

Cassandra

Ngjashëm me shembullin PostgreSQL më sipër.

MongoDB

db.music.drop();

Përfundim

Debati për zgjedhjen midis SQL dhe NoSQL ka qenë i ndezur për më shumë se 10 vjet. Ekzistojnë dy aspekte kryesore të këtij debati: arkitektura e motorit të bazës së të dhënave (monolitike, transaksionale SQL kundër NoSQL e shpërndarë, jo-transaksionale) dhe qasja e dizajnit të bazës së të dhënave (modelimi i të dhënave tuaja në SQL kundrejt modelimit të pyetjeve tuaja në NoSQL).

Me një bazë të dhënash transaksionale të shpërndara si YugaByte DB, debati rreth arkitekturës së bazës së të dhënave mund të pushohet lehtësisht. Ndërsa vëllimet e të dhënave bëhen më të mëdha se ato që mund të shkruhen në një nyje të vetme, bëhet e nevojshme një arkitekturë plotësisht e shpërndarë që mbështet shkallëzueshmërinë lineare të shkrimit me ndarje/ribalancim automatik.

Përveç kësaj, siç thuhet në një nga artikujt Google CloudArkitekturat transakcionale, shumë të qëndrueshme tani përdoren më shumë për të ofruar shkathtësi më të mirë zhvillimi sesa arkitekturat jo-transaksionale, përfundimisht të qëndrueshme.

Duke iu rikthyer diskutimit të projektimit të bazës së të dhënave, është e drejtë të thuhet se të dyja qasjet e projektimit (SQL dhe NoSQL) janë të nevojshme për çdo aplikim kompleks të botës reale. Qasja e "modelimit të të dhënave" SQL i lejon zhvilluesit të përmbushin më lehtë kërkesat në ndryshim të biznesit, ndërsa qasja NoSQL "modelimi i pyetjeve" lejon të njëjtët zhvillues të operojnë në vëllime të mëdha të dhënash me vonesë të ulët dhe xhiro të lartë. Është për këtë arsye që YugaByte DB ofron SQL dhe NoSQL API në një bërthamë të përbashkët, në vend që të promovojë një nga qasjet. Për më tepër, duke ofruar përputhshmëri me gjuhët e njohura të bazës së të dhënave, duke përfshirë PostgreSQL dhe Cassandra, YugaByte DB siguron që zhvilluesit nuk duhet të mësojnë një gjuhë tjetër për të punuar me një motor bazë të dhënash të shpërndarë dhe shumë të qëndrueshëm.

Në këtë artikull, ne shikuam se si ndryshojnë bazat e dizajnit të bazës së të dhënave midis PostgreSQL, Cassandra dhe MongoDB. Në artikujt e ardhshëm, ne do të zhytemi në konceptet e avancuara të dizajnit si indekset, transaksionet, JOIN-et, direktivat TTL dhe dokumentet JSON.

Ju urojmë një pushim të mbarë të fundjavës dhe ju ftojmë webinar falas, e cila do të zhvillohet më 14 maj.

Burimi: www.habr.com

Shto një koment