ProHoster > Blog > Administrimi > Bazat e projektimit tĂ« bazave tĂ« dhĂ«nash – krahasimi i PostgreSQL, Cassandra dhe MongoDB

Bazat e projektimit tĂ« bazave tĂ« dhĂ«nash – krahasimi i PostgreSQL, Cassandra dhe MongoDB

Përshëndetje, miq. Para se të nisim pjesën e dytë të festave të majit, po ndajmë me ju një material që e kemi përkthyer në prag të lansimit të një fluksi të ri të kursit «Sistemet e Menaxhimit të të Dhënave Relacionale».

Bazat e projektimit tĂ« bazave tĂ« dhĂ«nash – krahasimi i PostgreSQL, Cassandra dhe MongoDB

Zhvilluesit e aplikacioneve shpenzojnë shumë kohë në krahasimin e disa bazave operuese të dhënash për të zgjedhur atë që i përshtatet më së miri ngarkesës së parashikuar të punës. Kërkesat mund të përfshijnë modelimin e thjeshtuar të të dhënave, garancitë transaksionale, performancën e leximit/shkruarjes, shkallëzimin horizontal dhe disponueshmërinë e qëndrueshme. Tradicionalisht, zgjedhja fillon me kategorinë e bazës së dhënash, SQL ose NoSQL, pasi çdo kategori ofron një set të qartë kompromisesh. Performanca e lartë në terma të vonesës së ulët dhe kapacitetit të lartë zakonisht konsiderohet si një kërkesë pa kompromis dhe prandaj është e nevojshme për çdo bazë të dhënash në mostër.

QĂ«llimi i kĂ«tij artikulli Ă«shtĂ« ndihma pĂ«r zhvilluesit e aplikacioneve tĂ« bĂ«jnĂ« zgjedhjen e duhur mes SQL dhe NoSQL nĂ« kontekstin e modelimit tĂ« tĂ« dhĂ«nave tĂ« aplikacionit. Ne do tĂ« shqyrtojmĂ« njĂ« databazĂ« SQL, konkretisht PostgreSQL dhe dy databaza NoSQL – Cassandra dhe MongoDB, pĂ«r tĂ« folur mbi bazat e projektimit tĂ« databazave, si krijimi i tabelave, mbushja e tyre, leximi i tĂ« dhĂ«nave nga tabela dhe fshirja e tyre. NĂ« artikullin e ardhshĂ«m, ne patjetĂ«r do tĂ« shqyrtojmĂ« indekset, transaksionet, JOIN-at, direktivat TTL dhe projektimin e databazave mbi bazĂ«n e JSON-it.

ÇfarĂ« e ndan SQL nga NoSQL?

Databazat SQL rrisin fleksibilitetin e aplikacioneve përmes garantive transaksionale ACID, si dhe përmes aftësisë së tyre për të pyetur të dhëna përmes JOIN-eve në mënyra të papritura mbi modelet e normalizuara ekzistuese të databazave relacional.

Duke konsideroni arkitekturĂ«n e tyre monolitike/njĂ«-nodale dhe pĂ«rdorimin e modelit tĂ« replikimit master-slave pĂ«r mbiprodhim, databazat tradicionale SQL nuk kanĂ« dy veçori tĂ« rĂ«ndĂ«sishme – shkallĂ«zimin linear tĂ« shkrimit (dmth. ndarjen automatike nĂ« disa nodale) dhe humbjen automatike/zero tĂ« tĂ« dhĂ«nave. Kjo do tĂ« thotĂ« se volumi i tĂ« dhĂ«nave tĂ« marra nuk mund tĂ« tejkalojĂ« kapacitetin maksimal tĂ« shkrimit tĂ« njĂ« nodi. PĂ«r mĂ« tepĂ«r, humbja e tĂ« dhĂ«nave nĂ« njĂ« kohĂ« tĂ« caktuar duhet tĂ« merret parasysh pĂ«r qĂ«ndrueshmĂ«rinĂ« (nĂ« njĂ« arkitekturĂ« pa ndarjen e burimeve). KĂ«tu duhet tĂ« kemi parasysh se komitetet e fundit ende nuk janĂ« reflektuar nĂ« kopjen e nĂ«nshtruar (slave). PĂ«rditĂ«simet pa ndĂ«rprerje gjithashtu janĂ« tĂ« vĂ«shtira pĂ«r t'u arritur nĂ« databazat SQL.

Bazat NoSQL në natyrë janë zakonisht të shpërndara, që do të thotë se të dhënat ndahen në pjesë dhe shpërndahen në disa nyje. Këto kërkojnë denormalizim, që do të thotë se të dhënat e futur duhet të kopjohen disa herë për t'iu përgjigjur kërkesave specifike që dërgoni. Qëllimi kryesor është të arrihet një performancë e lartë duke reduktuar numrin e shardëve në kohën e leximit. Prandaj, NoSQL kërkon që të modeloni kërkesat tuaja, ndërsa SQL kërkon të modeloni të dhënat tuaja.

NoSQL fokusohet në arritjen e një performancë të lartë në një grup të shpërndarë dhe kjo është arsyeja kryesore për shumë kompromis në projektimin e bazave të të dhënave, që përfshijnë humbjen e transaksioneve ACID, JOIN dhe indekse globale të qëndrueshme.

Ka mendime se, megjithëse bazat NoSQL ofrojnë skalabilitet linear në shkrim dhe një qëndrushmëri të lartë, humbja e garancive transaksionale e bën atë të papërshtatshëm për të dhënat kritike.

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

Bazat e projektimit tĂ« bazave tĂ« dhĂ«nash – krahasimi i PostgreSQL, Cassandra dhe MongoDB

SQL dhe NoSQL: Pse nevojiten të dyja?

Aplikacionet reale me një numër të madh përdoruesish, si Amazon.com, Netflix, Uber dhe Airbnb, përballen me ekzekutimin e detyrave të ndryshme dhe komplekse. P.sh., një aplikacion për tregti elektronike si Amazon.com ka nevojë të ruajë të dhëna të lehta dhe me rëndësi të lartë, si informacionin rreth përdoruesve, produkteve, porosive, faturave, së bashku me të dhëna të rënda, por më pak kritike, si rishikimet e produkteve, mesazhet nga shërbimi i mbështetjes, aktiviteti i përdoruesve, komente dhe rekomandime nga përdoruesit. Natyrisht, këto aplikacione mbështeten të paktën në një bazë të dhënash SQL, përveç së paku një baze të dhënash NoSQL. Në sistemet ndër-rajonale dhe globale, një bazë të dhënash NoSQL funksionon si një cache gjeo-distribuese për të dhënat e ruajtura në një burim të besueshëm, një bazë të dhënash SQL që operon në një rajon të vetëm.

Si e kombinon YugaByte DB SQL dhe NoSQL?

E ndërtuar mbi një motor të përzier log-orientuar për ruajtje, auto-shardim, replikim të konsensusit të ndarë, dhe transaksione të shpërndara ACID (të frymëzuara nga Google Spanner), YugaByte DB është databaza e parë në botë me burim të hapur që është njëherazi e kompatibilshme me NoSQL (Cassandra & Redis) dhe SQL (PostgreSQL). Siç tregohet në tabelën më poshtë, YCQL, API YugaByte DB e përputhshme me Cassandra, shton konceptet e transaksioneve ACID me një ose shumë çelësa dhe indekse të dyta globale në API NoSQL, duke hapur kështu një epokë të databazave NoSQL me transaksione. Për më tepër, YCQL, API YugaByte DB e përputhshme me PostgreSQL, shton konceptet e skalimit lineal të të dhënave dhe qëndrueshmërisë automatike në API SQL, duke i paraqitur botës databazat SQL të shpërndara. Duke qenë se databaza YugaByte DB është esencialisht tranzakcionale, API NoSQL tani mund të përdoret në kontekstin e të dhënave kritike.

Bazat e projektimit tĂ« bazave tĂ« dhĂ«nash – krahasimi i PostgreSQL, Cassandra dhe MongoDB

Siç është thënë më parë në artikullin «Introducing YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB», zgjedhja midis SQL ose NoSQL në YugaByte DB varet plotësisht nga karakteristikat e ngarkesës kryesore të punës:

  • NĂ«se ngarkesa kryesore e punĂ«s Ă«shtĂ« operacionet shumĂ«kyçe me JOIN, kur zgjidhni YSQL, kuptoni se çelĂ«sat tuaj mund tĂ« jenĂ« tĂ« shpĂ«rndarĂ« nĂ« disa nyje, duke rezultuar nĂ« vonesa mĂ« tĂ« larta dhe/ose zvogĂ«lim tĂ« kapacitetit nĂ« krahasim me NoSQL.
  • NĂ« tĂ« kundĂ«rt, zgjidhni ndonjĂ« nga dy API-tĂ« NoSQL, duke kujtuar se do tĂ« merrni performancĂ« mĂ« tĂ« lartĂ« nga kĂ«rkesat qĂ« shĂ«rbehen nga njĂ« nyje nĂ« tĂ« njĂ«jtĂ«n kohĂ«. YugaByte DB mund tĂ« shĂ«rbejĂ« si njĂ« bazĂ« tĂ« vetme operative pĂ«r aplikacione tĂ« komplikuara reale, ku nevojitet menaxhimi i disa ngarkesave pune nĂ« tĂ« njĂ«jtĂ«n kohĂ«.

Në thelb të laboratorit të modelimit të të dhënave është baza e të dhënave YugaByte DB, e cila është e pajtueshme me PostgreSQL dhe Cassandra API, në krahasim me bazat origjinale. Ky qasje thekson thjeshtësinë e ndërveprimit me dy API të ndryshme (në dy porte të ndryshme) të të njëjtit klaster të bazave të të dhënave, në krahasim me përdorimin e klastereve krejtësisht të pavarura të dy bazave të ndryshme të të dhënave.
Në seksionet në vazhdim do të njihemi me laboratorin e modelimit të të dhënave për të ilustruar dallimin dhe disa tipare të përbashkëta të bazave të dhënash që po shqyrtojmë.

Laboratori i modelimit të të dhënave

Instalimi i bazave të dhënash

Duke marrë parasysh fokusin në projektimin e modelit të të dhënave (e jo në arkitekturën komplekse të shpërndarjes), ne do të instalojmë bazat e të dhënave në konteinerë Docker në kompjuterin lokal dhe më pas do të bashkëveprojmë me to duke përdorur shell-in e komandave përkatëse.

Përputhshëm me PostgreSQL & Cassandra, baza e të dhënash 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

Qasja përmes shell-it të komandave

Le të lidhemi me bazat e të dhënave përmes shell-it të komandave për API përkatëse.

PostgreSQL

psql — Ă«shtĂ« shell-i i komandave pĂ«r bashkĂ«veprim me PostgreSQL. PĂ«r lehtĂ«si pĂ«rdorimi, YugaByte DB vjen me psql direkt nĂ« dosjen bin.

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

Cassandra

cqlsh — Ă«shtĂ« njĂ« shell komande pĂ«r tĂ« ndĂ«rvepruar me Cassandra dhe bazat e tĂ« dhĂ«nave tĂ« saj tĂ« pĂ«rputhshme nĂ«pĂ«rmjet CQL (gjuha e pyetjeve tĂ« Cassandra). PĂ«r lehtĂ«sinĂ« e pĂ«rdorimit, YugaByte DB vjen me cqlsh nĂ« katalog bin.
Vini re se CQL është frymëzuar nga SQL dhe ka koncepte të ngjashme si tabela, rreshta, kolona dhe indekse. Megjithatë, si një gjuhë NoSQL, ajo shton një grup të caktuar kufizimesh, shumica e të cilave ne do t'i shqyrtojmë edhe në artikuj të tjerë.

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

MongoDB

mongo – Ă«shtĂ« njĂ« shell komande pĂ«r tĂ« ndĂ«rvepruar me MongoDB. Ajo mund tĂ« gjendet nĂ« katalogun bin tĂ« instalimit tĂ« MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Krijimi i një tabele

Tani mund të ndërveprojmë me bazën e të dhënave për të kryer operacione të ndryshme me anë të komandës. Le të fillojmë me krijimin e një tabele që ruan informacion mbi këngët e shkruara nga artistë të ndryshëm. Këngët mund të jenë pjesë e një albumi. Gjithashtu, atributet opsionale për këngën përfshijnë atë të vitit të publikimit, çmimin, zhanrin dhe vlerësimin. Duhet të kemi parasysh atributet shtesë që mund të nevojiten në të ardhmen përmes fushës "tags". Ajo mund të ruajë të dhëna të gjysmë-strukturuara në formën e çifteve çelës-vlerë.

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 tabelĂ«s nĂ« Cassandra Ă«shtĂ« shumĂ« i ngjashĂ«m me PostgreSQL. NjĂ« nga dallimet kryesore Ă«shtĂ« mungesa e kufizimeve tĂ« integritetit (p.sh., NOT NULL), por kjo bie nĂ« pĂ«rgjegjĂ«sinĂ« e aplikacionit dhe jo tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave NoSQL.. ÇelĂ«si primar pĂ«rbĂ«het nga çelĂ«si i pjesĂ«s (kolona Artist nĂ« shembullin mĂ« poshtĂ«) dhe njĂ« grup kolonash tĂ« klasterizimit (kolona SongTitle nĂ« shembullin mĂ« poshtĂ«). ÇelĂ«si i pjesĂ«s pĂ«rcakton se nĂ« cilin pjesĂ«/shard tĂ« vendoset rreshti, ndĂ«rsa kolonat e klasterizimit tregojnĂ« se si duhet tĂ« organizohen tĂ« dhĂ«nat brenda kĂ«tij shard-i.

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ë dhënash (Database) (në mënyrë të ngjashme me Keyspace në Cassandra), ku ka koleksione (Collections) (në mënyrë të ngjashme me tabelat), të cilat përmbajnë dokumente (Documents) (në mënyrë të ngjashme me rreshtat në tavolinë). Në MongoDB në të vërtetë nuk kërkohet përcaktimi i një skeme fillestare. Komanda «use database», e cila më poshtë krijon një instancë të bazës së të dhënave në thirrjen e parë dhe ndryshon kontekstin për bazën e të dhënave të sapo krijuar. As edhe koleksionet nuk nevojitet të krijohen në mënyrë eksplicite, ato krijohen automatikisht thjesht duke shtuar dokumentin e parë në një koleksion të ri. Mbani parasysh se MongoDB përdor bazën e të dhënave të testimit si parazgjedhje, kështu që çdo operacion në nivelin e koleksioneve pa specifikuar një bazë të caktuar do të ekzekutohet atje si parazgjedhje.

përdor myNewDatabase;

Marrja e informacionit mbi tabelën
PostgreSQL

d Music
Tabela "public.music"
    Kolona    |         Lloji          | Renditja | Nullable | Parazgjedhja 
--------------+-----------------------+-----------+----------+--------
 artist       | karakter variues(20) |           | jo null | 
 songtitle    | karakter variues(30) |           | jo null | 
 albumtitle   | karakter variues(25) |           |          | 
 viti         | integer               |           |          | 
 çmimi       | precizion i dyfishtë  |           |          | 
 zhanri       | karakter variues(10) |           |          | 
 vlerësimkritis | precizion i dyfishtë |           |          | 
 etiketat     | tekst                  |           |          | 
Indekset:
    "music_pkey" ÇELSI PRIMAR, btree (artist, songtitle)

Cassandra 

PËRSHKRIM TABELA MUZIKË;
KRIJO TABELË myapp.music (
    artist tekst,
    songtitle tekst,
    albumtitle tekst,
    viti int,
    çmimi float,
    zhanri tekst,
    etiketat tekst,
    ÇELSI PRIMAR (artist, songtitle)
) ME RENDITJEN E KLASAVE SIPAS (songtitle ASC)
    DHE koha_parazgjedhjes = 0
    DHE transaksionet = {'aktivizuar': 'false'};

MongoDB

përdor myNewDatabase;
shiko koleksionet;

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

Përgjithësisht shprehja INSERT në Cassandra duket shumë e ngjashme me atë në PostgreSQL. Megjithatë, ka një ndryshim të madh në semantikë. Në Cassandra INSERT në të vërtetë është një operacion UPSERT, ku në rresht shtohen vlerat e fundit nëse rreshti ekziston tashmë.

Të dhënat hyjnë në mënyrë të ngjashme me PostgreSQL INSERT më sipër

.

MongoDB

Megjithatë, ndonëse MongoDB është një bazë të dhënash NoSQL, si Cassandra, operacioni i saj i hyrjes së të dhënave nuk ka asnjë lidhje me sjelljen semantike në Cassandra. Në MongoDB insert() nuk ka mundësi UPSERT, duke e bërë atë të ngjasë me PostgreSQL. Shtimi i të dhënave është me parazgjedhje pa _idspecified do të çojë në shtimin e një dokumenti të ri në koleksion.

db.music.insert( {
artist: "No One You Know",
songTitle: "MĂ« Kontakt Today",
albumTitle: "Disaçka e Famshme",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "Qeni Im Spot",
albumTitle: "Hej Tani",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Kujdes, Botë",
albumTitle:"Pesha Fillon KĂ«tu",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Akoma NĂ« Dashuri",
albumTitle:"Pesha Fillon KĂ«tu",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Kërkesa e tabelës

Ndoshta, ndryshimi më i rëndësishëm midis SQL dhe NoSQL sa i përket formulimit të kërkesave është përdorimi i formulimeve FROM dhe WHERE. SQL lejon pas shprehjes FROM të zgjedhë disa tabela, dhe shprehja me WHERE mund të jetë çfarëdo kompleksiteti (duke përfshirë operacione JOIN midis tabelave). Sidoqoftë, NoSQL ka tendencë të vendosë një kufizim të fortë mbi FROM, dhe punon vetëm me një tabelë të specifikuar, dhe në WHERE, gjithmonë duhet të jepet çelësi primar. Kjo është për shkak të përpjekjes për të rritur performancën e NoSQL, për të cilën folëm më parë. Kjo përpjekje çon në çdo formë zvogëlimi të ndërveprimit ndërtabelar dhe ndërçelësor. Ajo mund të sjellë vonesa të mëdha në lidhjen ndër-nodale kur përgjigjet në kërkesë dhe, prandaj, është më mirë ta shmangni atë në parim. Për shembull, Cassandra kërkon që kërkesat të kufizohen në operatorë të caktuar (lejohet vetëm =, IN, , =>, <=) në çelësat e pjesëve, përveç rasteve të kërkesës për indeksin dytësor (këtu lejohet vetëm operatori =).

PostgreSQL

Më poshtë do të jepen tri shembuj të pyetjeve që mund të realizohen lehtësisht nga një bazë të dhënash SQL.

  • Shfaq tĂ« gjitha kĂ«ngĂ«t e artistit;
  • 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 artistit qĂ« kanĂ« njĂ« fjalĂ« tĂ« caktuar nĂ« titull dhe kanĂ« njĂ« çmim mĂ« tĂ« ulĂ«t 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 e lartpërmendura, vetëm e para do të funksionojë në Cassandra pa ndryshime, pasi operatori LIKE nuk mund të aplikohet në kolonat e klasterizimit, siç është SongTitle. Në këtë rast, lejohet vetëm operatorët = dhe 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ç u tregua në shembujt e mëparshëm, metoda kryesore për krijimin e pyetjeve në MongoDB është db.collection.find(). Kjo metodë përmban qartë emrin e koleksionit (music në shembullin më poshtë), prandaj pyetjet për disa koleksione janë të ndaluara.

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

Lexo të gjitha rreshtat e tabelës

Leximi të gjitha rreshtave është thjesht një rast i veçantë i atij modeli të kërkesës që diskutuam më parë.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Në mënyrë të ngjashme me shembullin e mësipërm në PostgreSQL.

MongoDB

db.music.find( {} );

Redaktimi i të dhënave në tabelë

PostgreSQL

PostgreSQL ofron një komandë UPDATE për të ndryshuar të dhënat. Ajo nuk ka mundësi UPSERT, prandaj ekzekutimi i kësaj komande do të përfundojë me një gabim, nëse rreshti nuk ekziston më në bazën e të dhënave.

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

Cassandra

Në Cassandra ka UPDATE një ekuivalent me PostgreSQL. UPDATE ka të njëjtin kuptim UPSERT, siç është INSERT.

Në mënyrë të ngjashme me shembullin e mësipërm në PostgreSQL.

MongoDB
Operacioni update() në MongoDB mund të përditësojë plotësisht një dokument ekzistues ose të përditësojë vetëm fusha të caktuara. Në mënyrë standarde, ajo përditëson vetëm një dokument pa semantikën aktive UPSERT. Përditësimi i shumë dokumenteve dhe sjellja e ngjashme UPSERT mund të aplikohet duke vendosur flamuj të tjerë për operacionin. Siç ndodh në shembullin më poshtë, ku përditësohet zhanri i një artisti të caktuar sipas këngës së tij.

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

Shkarkimi i të dhënave nga tabela

PostgreSQL

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

Cassandra

Në mënyrë të ngjashme me shembullin e mësipërm në PostgreSQL.

MongoDB

NĂ« MongoDB ka dy lloje operacionesh pĂ«r tĂ« fshirĂ« dokumente — deleteOne() /deleteMany() dhe remove(). TĂ« dy llojet fshijnĂ« dokumente, por kthejnĂ« rezultate tĂ« ndryshme.

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

Fshirja e tabelës

PostgreSQL

DROP TABLE Music;

Cassandra

Në mënyrë të ngjashme me shembullin e mësipërm në PostgreSQL.

MongoDB

db.music.drop();

PĂ«rfundimi

Kundërshtimet mbi zgjedhjen mes SQL dhe NoSQL janë zhvilluar për më shumë se 10 vjet. Ka dy aspekte kryesore të këtij kundërshtimi: arkitektura bërthamore e bazës së të dhënave (SQL monolitik, transaksional kundër NoSQL të shpërndarë, jotransaksional) dhe qasja në projektimin e bazës së të dhënave (modeli i të dhënave në SQL kundër modelimit të kërkesave tuaja në NoSQL).

Me një bazë të dhënash të shpërndarë dhe transaksionale si YugaByte DB, debatet rreth arkitekturës së bazës së të dhënave mund të shpërndahen lehtë. Ndërsa volumet e të dhënave bëhen më të mëdha se sa mund të regjistrohen në një nyjë, një arkitekturë plotësisht të shpërndarë që mbështet shkallëzueshmërinë lineare të shkrimit me sharding automatik/ribalance, bëhet e nevojshme.

Përveç asaj që është thënë në një nga artikujt Google Cloud, arkitekturat transaksionale, tërësisht të koordinuara tani aplikohen më gjerësisht për të siguruar fleksibilitet më të mirë në zhvillim sesa arkitekturat jo-transaksionale, në fund të fundit të koordinuara.

Duke u kthyer në diskutimin rreth dizajnit të bazave të të dhënave, është e drejtë të thuhet se të dy qasjet e dizajnit (SQL dhe NoSQL) janë thelbësore për çdo aplikacion kompleks në botën reale. Qasja SQL "modelimi i të dhënave" i lejon zhvilluesve të plotësojnë më lehtë kërkesat e ndryshueshme të biznesit, ndërsa qasja NoSQL "modelimi i pyetjeve" u lejon atyre të operojnë me sasi të mëdha të dhënash duke pasur vonesa të ulëta dhe kapacitete të larta. Pikërisht për këtë arsye YugaByte DB siguron SQL dhe NoSQL API në një themel të përbashkët, në vend që të propagandojë një qasje të vetme. Për më tepër, duke ofruar përputhshmëri me gjuhët e njohura të bazave të të dhënave, duke përfshirë PostgreSQL dhe Cassandra, YugaByte DB garanton që zhvilluesit nuk duhet të mësojnë një gjuhë tjetër për të punuar me thelbin e bazës së të dhënave të shpërndara dhe tërësisht të koordinuara.

Në këtë artikull ne shqyrtuam se si ndryshojnë bazat e projektimit të të dhënave në PostgreSQL, Cassandra dhe MongoDB. Në artikujt e ardhshëm do të thellojmë konceptet e avancuara të projektimit, si indekset, transaksionet, JOIN-et, direktivat TTL dhe dokumentet JSON.

Ju urojmë një fundjavë të mrekullueshme dhe ju ftojmë në webinarin falas, i cili do të zhvillohet më 14 maj.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster