Bazat e modelimit të të dhënave - PostgreSQL vs Cassandra vs MongoDB

Zhvilluesit e aplikacionit zakonisht kalojnë kohë të konsiderueshme duke vlerësuar bazat e të dhënave të shumta operacionale për të gjetur se një bazë e të dhënave që është më e përshtatshme për nevojat e tyre për ngarkesën e punës. Këto nevoja përfshijnë modelimin e thjeshtuar të të dhënave, garancitë e transaksionit, performancën e leximit / shkrimit, shkallëzimin horizontal dhe tolerancën e gabimeve. Tradicionalisht, kjo përzgjedhje fillon me kategoritë e bazës së të dhënave SQL vs NoSQL sepse secila kategori paraqet një grup të qartë të veprimeve tregtare. Performanca e lartë për sa i përket latencës së ulët dhe rrjedhës së lartë zakonisht trajtohet si një kërkesë jo-kompromentuese dhe prandaj pritet në çdo bazë të dhënash të zgjedhur.

Ky post synon të ndihmojë zhvilluesit e aplikacioneve të kuptojnë zgjedhjen e SQL vs NoSQL në kontekstin e nevojave të modelimit të të dhënave të një aplikacioni. Ne përdorim një bazë të dhënash SQL, përkatësisht PostgreSQL, dhe 2 bazat e të dhënave NoSQL, përkatësisht Cassandra dhe MongoDB, si shembuj për të shpjeguar bazat e modelimit të të dhënave si krijimi i tabelave, futja e të dhënave, kryerja e skanimeve dhe fshirja e të dhënave. Në një postim vijues, ne do të mbulojmë tema të avancuara siç janë indekset, transaksionet, anëtarësimet, direktivat për kohë për të jetuar (TTL) dhe modelimin e të dhënave të dokumenteve me bazë JSON.

Si ndryshon NoSQL nga SQL në modelimin e të dhënave?

Baza e të dhënave SQL rrisin shkathtësinë e aplikimit përmes garancive të transaksionit ACID, si dhe me aftësinë e tyre për të kërkuar të dhëna duke përdorur JOIN në mënyra të paparashikuara në krye të modeleve ekzistuese të normalizuara të marrëdhënieve.

Duke pasur parasysh arkitekturën e tyre monolit / një-nyje dhe përdorimin e një modeli të përsëritur të skllevërve master për tepricë, bazës së të dhënave tradicionale të SQL mungojnë dy aftësi të rëndësishme - shkallëzimi linear i shkrimit (d.m.th. sharing automatik nëpër nyje të shumta) dhe humbje automatike / zero-humbje e të dhënave. Kjo do të thotë që vëllimet e të dhënave të gëlltitura nuk mund të tejkalojnë rrjedhën maksimale të shkrimit të një nyje të vetme. Për më tepër, disa humbje të përkohshme të të dhënave duhet të priten në humbje (në arkitekturat e asgjëve të përbashkëta të ruajtjes) duke pasur parasysh se angazhimet e fundit nuk do të shfaqeshin ende në kopjen e skllevërve. Përditësimet zero joproduktive janë gjithashtu shumë të vështira për t'u arritur në botën e të dhënave SQL.

DB-të e NoSQL zakonisht shpërndahen në natyrë ku të dhënat ndahen ose copëzohen nëpër nyje të shumta. Ata mandatojnë denormalizimin që do të thotë të dhëna të futura gjithashtu duhet të kopjohen shumë herë për të shërbyer pyetjeve specifike që keni në mendje. Qëllimi kryesor është nxjerrja e performancës së lartë duke zvogëluar në mënyrë të qartë numrin e shkurreve të arrihen gjatë kohës së leximit. Prandaj deklarata që NoSQL kërkon që ju të modeloni pyetjet tuaja ndërsa SQL kërkon që ju të modeloni të dhënat tuaja.

Përqendrimi i NoSQL në arritjen e performancës së lartë në një grup të shpërndarë deklarohet si arsyeja kryesore për kompromise të shumta për modelimin e të dhënave që përfshijnë humbjen e transaksioneve ACID, JOIN dhe indekset e qëndrueshme globale dytësore.

Perceptimi i përgjithshëm është se edhe pse bazat e të dhënave NoSQL sigurojnë shkallëzim linear të shkrimit dhe një tolerancë të lartë të 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 detajon se si modelimi i të dhënave NoSQL ndryshon nga ai i SQL.

SQL vs NoSQL - Dallimet kryesore të modelimit të të dhënave

SQL & NoSQL: Pse ju duhen të dy?

Shumica e aplikacioneve në botë reale me përvojat e përdoruesve tërheqës si Amazon.com, Netflix, Uber dhe Airbnb mundësohen nga brenda nga një përzierje komplekse e ngarkesave të shumta të punës. P.sh. një aplikim i tregtisë elektronike si Amazon.com duhet të ruajë të dhëna me kritikë të ulët për vëllim, me shumë kritikë, siç janë përdoruesit, produktet, porositë, faturat krahas të dhënave me kritere të vëllimit të lartë, me më pak mision, siç janë rishikimet e produktit, porositë e ndihmës, veprimtaria e përdoruesit, rekomandimet e përdoruesit. 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ë vendosjet me shumë rajone dhe globale, baza e të dhënave NoSQL vepron gjithashtu si një cache e shpërndarë gjeo për të dhënat e ruajtura në burimin e së vërtetës, bazën e të dhënave SQL që funksionon në një rajon të vetëm.

Si YugaByte DB bashkon SQL & NoSQL në një bazë të dhënash të përbashkët?

Ndërtuar në një kombinim unik të motorit të ruajtjes së bashkimit të log-strukturuar, auto-shading, kopjimit të shpërndarë të konsensusit të shpërndarë për çdo copë dhe shpërndarë transaksione ACID (frymëzuar nga Google Spanner), YugaByte DB është baza e parë e të dhënave me burim të hapur në botë që është edhe NoSQL (Cassandra & Redis kompatibil) dhe SQL (PostgreSQL i pajtueshëm) në të njëjtën kohë. Siç tregohet në tabelën më poshtë, YCQL, API i pajtueshëm Cassandra i YugaByte DB, shton nocionin e transaksioneve ACID me një çelës dhe shumë-çelës dhe indekseve dytësore globale në API të NoSQL duke përdorur kështu në epokën e transaksioneve NoSQL. Për më tepër, YSQL, API i pajtueshëm PostgreSQL i YugaByte DB, shton nocionet e shkallëzimit linear të shkrimit dhe tolerancës automatike ndaj gabimeve në një API SQL duke sjellë kështu botën e SQL të Shpërndarë. Meqenëse YugaByte DB është transaksionale në thelb, madje API-të e NoSQL tani mund të përdoren në kontekstin e të dhënave kritike për misionin.

YugaByte DB - SQL & NoSQL në një bazë të dhënash të vetme

Siç përshkruhet më parë në Paraqitjen e YSQL: Një SQL API shpërndarë e pajtueshme PostgreSQL për YugaByte DB, zgjedhja e SQL kundrejt NoSQL në YugaByte DB varet tërësisht nga karakteristikat e ngarkesës me shumicë.

  • Nëse ngarkesa me shumicë është operacione me shumë çelësa me JOINS, atëherë zgjedhni YSQL me të kuptuarit se çelësat tuaj mund të shpërndahen nëpër nyje të shumta që çojnë në latencë më të lartë dhe / ose xhiros më të ulët se NoSQL.
  • Përndryshe, zgjedhni njërën nga dy API-të e NoSQL me të kuptuarit se do të merrni përfitime më të larta të performancës që vijnë nga pyetjet që shërbehen kryesisht nga një nyje në një kohë. YugaByte DB mund të shërbejë si bazë e të dhënave operative të unifikuar për aplikacione komplekse në botë reale që zakonisht kanë ngarkesa të shumta pune për të menaxhuar në të njëjtën kohë.

Laboratori i modelimit të të dhënave në seksionin tjetër bazohet në API të pajtueshme të YugaByte DB, PostgreSQL dhe Cassandra, në krahasim me bazat e të dhënave origjinale. Kjo qasje nënvizon thjeshtësinë e bashkëveprimit me dy API të ndryshme (në dy porte të ndryshme) të të njëjtit grup të bazës së të dhënave në krahasim me përdorimin e grupimeve plotësisht të pavarur të dy bazave të të dhënave të ndryshme.

Në seksionet e ardhshme do të shohim në laborator një modelim të të dhënave për të ilustruar shumë nga ndryshimet dhe disa bashkësi midis bazave të të dhënave të ndryshme.

Laboratori i Modelimit të të Dhënave

Instaloni bazat e të dhënave

Duke pasur parasysh përqendrimin në modelimin e të dhënave (dhe jo në arkitekturat e vendosjes komplekse), ne do të instalojmë bazat e të dhënave në kontejnerët Docker në makinat tona lokale dhe më pas do të bashkëveprojmë me ta duke përdorur predhat e tyre përkatëse të linjës komanduese.

YugaByte DB, një bazë të dhënash e përputhshme PostgreSQL & Cassandra

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
docker tërheq yugabytedb / yugabyte
./yb-docker-ctl krijoj --enable_postgres

MongoDB

docker run - Emri im-mongo -d mongo: i fundit

Qasja duke përdorur Shellin e Komandës Line

Tjetra le të lidhemi me bazat e të dhënave duke përdorur predha të linjës komanduese për API-të përkatëse.

PostgreSQL

psql është një guaskë e linjës komanduese për bashkëveprimin me PostgreSQL. Për lehtësinë e përdorimit, YugaByte DB dërgon me një version psql në direktorinë e saj.

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 bashkëveprimin me Cassandra dhe bazat e të dhënave të saj të pajtueshme përmes CQL (Cassandra Language Query Language). Për lehtësinë e përdorimit, YugaByte DB dërgon me një version të cqlsh në direktorinë e saj.

Vini re se CQL është frymëzuar shumë nga SQL me nocion të ngjashëm të tabelave, rreshtave, kolonave dhe indekseve. Sidoqoftë, si gjuhë NoSQL, shton një grup specifik kufizimesh, shumica e të cilave do t'i rishikojmë gjatë serive tona të blogut.

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

MongoDB

mongo është një guaskë e linjës komanduese për bashkëveprimin me MongoDB. Mund të gjendet në direktorinë e koshave të një instalimi MongoDB.

docker exec -it bash my-mongo
kosh cd
Mongo

Krijoni një Tabelë

Tani mund të bashkëveprojmë me bazën e të dhënave për operacione të ndryshme duke përdorur shellin e linjës komanduese. Le të fillojmë me krijimin e një tryeze që ruan informacione rreth këngëve të publikuara nga artistë. Këto këngë ndonjëherë janë pjesë e një albumi. Tiparet e tjera opsionale të një kënge janë viti i lëshuar, çmimi, zhanri dhe vlerësimi i kritikës. Ne kemi nevojë për llogari të atributeve shtesë që mund të na duhen në të ardhmen përmes një fushe ‘etiketash’ që mund të ruajnë të dhënat gjysmë të strukturuara si çifte me vlerë kyçe.

PostgreSQL

Krijoni TABEL Muzikë (
    Artist VARCHAR (20) NUK NUMULR,
    SongTitle VARCHAR (30) NUK NUMR,
    AlbumTitle VARCHAR (25),
    Viti INT,
    Pricemimi FLOAT,
    Zhanër VARCHAR (10),
    Kritika RRETH,
    Etiketa TEXT,
    KEY PARIMAR (Artist, SongTitle)
);

Cassandra

Krijoni tabelë në Cassandra është shumë e ngjashme me atë të PostgreSQL. Një ndryshim i madh është mungesa e kufizimeve të integritetit (siç është NUK NULL) që është përgjegjësi e aplikacionit dhe jo e bazës së të dhënave në botën e NoSQL. Keyelësi kryesor është i përbërë nga çelësi i ndarjes (kolona e Artistit në shembullin më poshtë) dhe një grup kolonash grumbullimi (kolona SongTitle në shembullin më poshtë). Kyçi i ndarjes përcakton se cilën ndarje / shard për të vendosur rreshtin dhe kolonat grumbulluese specifikojnë se si duhet të organizohen të dhënat brenda një shardi të caktuar.

KRIJON KEYSPACE myapp;
PERDORIM myapp;
Krijoni TABEL Muzikë (
    Teksti artistik,
    TEKTI SongTitle,
    AlbumTitle TEXT,
    Viti INT,
    Pricemimi FLOAT,
    Teksti i zhanrit,
    Kritika RRETH,
    Etiketa TEXT,
    KEY PARIMAR (Artist, SongTitle)
);

MongoDB

MongoDB organizon të dhëna në bazat e të dhënave (ekuivalente me Cassandra Keyspace) që kanë Koleksione (ekuivalente me Tabelat) që kanë Dokumente (ekuivalente me një Rresht në Tabelë). Si një bazë të dhënash "skemaliteti", përkufizimi i skemës para kohe nuk është i nevojshëm në MongoDB. Komanda "përdorim bazën e të dhënave", e treguar më poshtë, krijon një databazë që herën e parë që thirret së bashku me ndryshimin e kontekstit në bazën e të dhënave të krijuar rishtas. Edhe koleksionet nuk kanë nevojë të krijohen në mënyrë eksplicite por përkundrazi janë krijuar automatikisht duke futur thjesht dokumentin e parë në një koleksion të ri. Vini re se baza e të dhënave parazgjedhore e MongoDB është provë, kështu që çdo operacion i nivelit të grumbullimit të bërë pa specifikuar bazën e të dhënave do të bëhet në këtë kontekst të paracaktuar.

përdorni myNewDatabase;

Merrni informacione rreth një tabele

PostgreSQL

Muzikë
Tabela "public.music"
    Kolona | Lloji | Përbërja | E pavlefshme | Default
-------------- + ----------------------- + ----------- + ---------- + --------
 artisti | karakteri që ndryshon (20) | | jo nul |
 kënga e këngëve | karakteri që ndryshon (30) | | jo nul |
 titulli i albumit | karakteri që ndryshon (25) | | |
 viti | numër i plotë | | |
 çmimi | saktësi të dyfishtë | | |
 zhanër | karakteri që ndryshon (10) | | |
 duke kritikuar | saktësi të dyfishtë | | |
 etiketat | teksti | | |
indekset:
    "music_pkey" KEY PARAJ, btree (artist, titulli i këngës)

Cassandra

TABELA MUZIKE DESKRIBE;
KRIJONI TABELIN myapp.music (
    teksti artistik,
    teksti i këngës,
    teksti i titullit të albumit,
    vit int,
    çmimi noton,
    teksti zhanër,
    etiketime teksti,
    KEY PARIMAR (artist, titull kënge)
) ME RREGULLIMIN E RRITJES NGA (Këngë këngësh ASC)
    AND default_time_to_live = 0
    AND transaksioneve = {'aktivizuar': 'false'};

MongoDB

përdorni myNewDatabase;
tregojnë koleksione;

Vendosni të dhënat në një Tabelë

PostgreSQL

INSERT NO Muzikë
    (Artist, SongTitle, AlbumTitle,
    Viti, Pricemimi, Zhanri, Vlerësimi i Kritikës,
    Tags)
VLERAT (
    No Askush nuk e dini ’, 'Më thërrisni sot’, Som Disi të famshëm ’,
    2015, 2.14, 'Vendi', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"], "LengthInSeconds": 214'
);
INSERT NO Muzikë
    (Artist, SongTitle, AlbumTitle,
    Pricemimi, Zhanri, CriticRating)
VLERAT (
    'Askush nuk e dini ju "," Spot My Dog "," Hej Tani ",
    1.98, 'Vendi', 8.4
);
INSERT NO Muzikë
    (Artist, SongTitle, AlbumTitle,
    Pricemimi, Zhanri)
VLERAT (
    "The Acme Band", "Look Out, World", "The Buck Fillon Here",
    0,99, 'Rock'
);
INSERT NO Muzikë
    (Artist, SongTitle, AlbumTitle,
    Pricemimi, Zhanri,
    Tags)
VLERAT (
    "The Acme Band", "Ende In Love", "The Buck Fillon Here",
    2.47, 'Rock',
    '{"radioStationsPlaying": [["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotacioni": Heavy} '
);

Cassandra

Deklaratat e Cassandra INSERT duken shumë të ngjashme me atë të PostgreSQL në përgjithësi. Sidoqoftë, ekziston një ndryshim i madh në semantikë. INSERT është në të vërtetë një operacion i ngritur në Cassandra ku rreshti azhurnohet me vlerat e fundit në rast se rreshti tashmë ekziston.

Njësoj si deklaratat e PostgreSQL INSERT më lart.

MongoDB

Edhe pse MongoDB është gjithashtu një bazë e të dhënave NoSQL e ngjashme me Cassandra, funksionimi i futjes së saj nuk ka të njëjtën sjellje semantike si Cassandra. Futja MongoDB () nuk ka mundësi të vendosë që e bën atë të ngjashme me PostgreSQL. Sjellja e paracaktuar e futjes pa _ specifikuar do të çojë në një dokument të ri të shtuar në koleksion.

db.music.insert ({
artisti: "Askush nuk e njeh",
   këngaTitle: "Call Me Today",
    albumTitle: "Disi i Famshëm",
    viti: 2015,
    çmimi: 2.14,
    zhanër: "Vendi",
    etiketat: {
Kompozitorët: ["Smith", "Jones", "Davis"],
GjatësiaS sekondave: 214
}
   }
);
db.music.insert ({
    artisti: "Askush nuk e njeh",
    këngëTitle: "Spot My Dog",
    albumTitle: "Hej Tani",
    çmimi: 1.98,
    zhanër: "Vendi",
    kritikimi: 8.4
   }
);
db.music.insert ({
    artisti: "The Acme Band",
    këngaTitle: "Shiko, Bota",
    albumTitle: "The Buck Fillon Këtu",
    çmimi: 0,99,
    zhanër: "Rock"
   }
);
db.music.insert ({
    artisti: "The Acme Band",
    këngaTitle: "Ende In Love",
    albumTitle: "The Buck Fillon Këtu",
    çmimi: 2.47,
    zhanër: "Rock",
    etiketat: {
        radioStationsPlayer: ["KHCR", "KBQX", "WTNR", "WJJH"],
        Datat e udhëtimit: {
            Seattle: "20150625",
            Cleveland: "20150630"
        }
        rrotullimi: "I rëndë"
}
    }
);

Pyetni një tabelë

Me sa duket, ndryshimi më domethënës midis SQL dhe NoSQL përsa i përket pyetjeve të modelimit është në përdorimin e klauzolave ​​FROM dhe WHERE. SQL lejon Klauzolën NGA të përfshijë tabela të shumta dhe KUSHTI KUAJ të jetë me komplekse arbitrare (përfshirë P JORBASHKT nëpër tabela). Sidoqoftë, NoSQL tenton të vendosë një kufizim të fortë në klauzolën NGA të ketë vetëm një tabelë të specifikuar dhe Klauzola KU JU të ketë gjithmonë çelësin parësor të specifikuar. Kjo për shkak të fokusit të lartë të performancës së NoSQL që kemi diskutuar më herët që synon të zvogëlojë çdo ndërveprim ndër-tryezë dhe ndër-kyç. Një ndërveprim i tillë mund të prezantojë një komunikim ndër-nyje latente të lartë në kohën e përgjigjes së pyetjes dhe kështu shmanget më së miri krejt. P.sh. Cassandra kërkon që pyetjet të kufizohen nga operatorët (vetëm =, IN, <,>, =>, <= lejohen) në çelësat e ndarjes, përveç kur kërkohet një indeks dytësor (kur lejohet vetëm = operatori).

PostgreSQL

Më poshtë janë 3 llojet e pyetjeve që mund të shërbehen lehtësisht nga një bazë e të dhënave SQL.

  • Kthejeni të gjitha këngët nga një artist
  • Kthejeni të gjitha këngët nga një artist, duke përputhur pjesën e parë të titullit
  • Kthejeni të gjitha këngët nga një artist, me një fjalë të veçantë në titull, por vetëm nëse çmimi është më i vogël se 1.00
SELECT * NGA Muzikë
KU JU Artist = 'Askush nuk e dini';
SELECT * NGA Muzikë
KU JU Artist = 'Askush nuk e dini' DHE Këngën e këngës LIKE 'Thirrje%';
SELECT * NGA Muzikë
KU JU Artist = 'Askush nuk e dini' DHE Këngën e këngës LIKE '% Sot%'
DHE Pricemimi> 1.00;

Cassandra

Nga pyetjet e PostgreSQL të renditura më lart, vetëm e para do të punojë me Cassandra të pandryshuar pasi operatori LIKE nuk lejohet të kolonat grumbulluese siç është SongTitle. Vetëm operatorët = dhe IN lejohen në këtë rast.

SELECT * NGA Muzikë
KU JU Artist = 'Askush nuk e dini';
SELECT * NGA Muzikë
KU KUJTUAR Artist = 'Askush nuk e dini' DHE SongTitle IN ('Call Me Today', 'Spot My Dog')
DHE Pricemimi> 1.00;

MongoDB

Siç tregohet në shembujt e mëparshëm, metoda kryesore për të pyetur MongoDB është metoda db.collection.find (). Kjo metodë është cilësuar nga emri i koleksionit (muzika në shembullin e mëposhtëm) për t'u pyetur shumë qartë, kështu që kërkimi nëpër koleksione nuk lejohet në mënyrë të qartë.

db.music.find ({
  artisti: "Askush nuk e dini"
 }
);
db.music.find ({
  artisti: "Askush nuk e njeh",
  këngëTitle: / Thirrni /
 }
);

Lexoni të gjitha rreshtat nga një tabelë

Leximi i të gjitha rreshtave është thjesht një rast i veçantë i modelit të pyetës së përgjithshme që kemi vërejtur më herët.

PostgreSQL

SELECT *
NGA Muzika;

Cassandra

Njësoj si deklarata e SELECT PostgreSQL më lart.

MongoDB

db.music.find ({});

Modifikoni të dhënat në një Tabelë

PostgreSQL

PostgreSQL siguron deklaratën UPDATE për modifikimin e të dhënave. Ai nuk lejon ndonjë mundësi të mbrojtur, kështu që deklarata do të dështojë nëse rreshti nuk ekziston në bazën e të dhënave tashmë.

UPDATE Muzikë
Zhanri SET = 'Disco'
KUSH Artist = 'The Acme Band' AND SongTitle = 'Ende In Love';

Cassandra

Cassandra gjithashtu ka një deklaratë UPDATE të ngjashme me PostgreSQL. UPDATE gjithashtu njëjtë pohojnë semantikën si ajo e deklaratës INSERT.

Njësoj me deklaratën e UPDATE PostgreSQL më lart.

MongoDB

Operacioni () i azhurnimit i MongoDB mund të azhurnojë plotësisht një dokument ekzistues ose mund të aktualizojë vetëm fusha specifike. Si parazgjedhje, ai aktualizon vetëm një dokument me semantikën e përmbysur. Përditësimet me shumë dokumente dhe sjellja e përmbytjes mund të aktivizohen duke vendosur flamuj shtesë në operacion. P.sh. shembulli më poshtë azhurnon zhanrin e një artisti specifik në të gjithë këngët e artistit.

db.music.update (
  {"artist": "The Acme Band",
  {
    $ vendosur: {
      "zhanër": "Disco"
    }
  }
  {"multi": e vërtetë, "upsert": true
);

Fshini të dhënat nga një tabelë

PostgreSQL

DELETE NGA Muzikë
KU JU Artist = 'The Acme Band' AND SongTitle = 'Shikoni, Botë';

Cassandra

Njësoj si deklarata e PostgreSQL DELETE më lart.

MongoDB

MongoDB ka dy lloje të operacioneve për të trajtuar fshirjet e dokumenteve - fshini një () / fshiniMany () dhe hiqni (). Të dy fshijnë dokumentin (et) por kanë rezultate të ndryshme kthimi.

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

Hiq një tabelë

PostgreSQL

DROP TABLE Muzikë;

Cassandra

Njësoj si deklarata e mësipërme e Tabelës PostgreSQL DROP;

MongoDB

db.music.drop ();

përmbledhje

Debati SQL vs NoSQL është duke u ndezur për një dekadë tani. Ekzistojnë 2 aspekte të këtij debati: arkitektura bazë e të dhënave (monolitike, SQL transaksionale e shpërndarë, NoSQL jo-transaksionale) dhe qasja e modelimit të të dhënave (modeloni të dhënat tuaja në SQL vs. modeloni pyetjet tuaja në NoSQL).

Me një bazë të dhënash të shpërndarë, transaksionale, siç është YugaByte DB, pjesa kryesore e arkitekturës së bazës së të dhënave mund të vihet në qetësi. Ndërsa vëllimet e të dhënave rriten përtej asaj që mund të shkruhet në një nyje të vetme, një arkitekturë plotësisht e shpërndarë që mundëson shkallëzimin linear të shkrimit me copëzim / ribalancim automatik bëhet e domosdoshme. Për më tepër, siç përshkruhet në këtë postim nga Google Cloud, arkitekturat transaksionale, të qëndrueshme tani pranohen gjerësisht për të ofruar aftësi zhvilluese dhe zhvillimesh më të larta se arkitektura jo-transaksionale, përfundimisht të qëndrueshme.

Duke ardhur në debatin për modelimin e të dhënave, është e drejtë të thuhet se të dyja qasjet e modelimit të të dhënave SQL dhe NoSQL janë thelbësore për çdo aplikim kompleks të botës reale. Qasja e modelit tuaj të të dhënave të SQL lejon zhvilluesit të kujdesen për të ndryshuar më lehtë kërkesat e biznesit ndërsa qasja e modelit-pyetjeve tuaja të NoSQL u lejon të njëjtëve zhvillues që të menaxhojnë vëllime të mëdha të të dhënave me latente të ulët dhe xhiros të lartë. Kjo është pikërisht arsyeja pse YugaByte DB zbaton të dy API-të SQL dhe NoSQL në thelbin e përbashkët, në vend që të promovojë që njëra qasje të jetë rreptësisht më e mirë se tjetra. Për më tepër, duke siguruar pajtueshmëri teli me gjuhët e të dhënave të njohura, përfshirë PostgreSQL dhe Cassandra, YugaByte DB siguron që zhvilluesit nuk kanë mësuar një gjuhë tjetër në mënyrë që të përfitojnë nga thelbi i shpërndarë fort i qëndrueshëm i bazës së të dhënave.

Ky post na ndihmoi të kuptojmë se si bazat e modelimit të të dhënave ndryshojnë midis PostgreSQL, Cassandra dhe MongoDB. Në postimet e rradhës në seri, ne do të zhyten në koncepte të modelimit të përparuar të modelimit të të dhënave siç janë indekset, transaksionet, JOIN, direktivat TTL dhe dokumentet JSON.

Ç'pritet më tej?

  • Krahasoni YugaByte DB me bazat e të dhënave si Amazon DynamoDB, Cassandra, MongoDB dhe Azure Cosmos DB.
  • Filloni me YugaByte DB në macOS, Linux, Docker dhe Kubernetes.
  • Kontaktoni me ne për të mësuar më shumë rreth licencimit, çmimeve ose për të planifikuar një përmbledhje teknike.

Botuar fillimisht në Blog Databaza e JugaByte.