Andmete modelleerimise põhitõed - PostgreSQL vs. Cassandra vs. MongoDB

Rakenduse arendajad kulutavad tavaliselt palju operatiivsete andmebaaside hindamisele palju aega, et leida üks andmebaas, mis sobib kõige paremini nende töökoormuse vajadustega. Need vajadused hõlmavad andmete lihtsustatud modelleerimist, tehingutagatisi, lugemise ja kirjutamise jõudlust, horisontaalset skaleerimist ja tõrketaluvust. Traditsiooniliselt algab see valik SQL vs. NoSQL andmebaasi kategooriatest, kuna iga kategooria pakub selget kompromissi. Kõrget jõudlust väikese latentsuse ja suure läbilaskevõime osas käsitletakse tavaliselt kompromissitu nõudena ja seetõttu oodatakse seda kõigis valitud andmebaasides.

Selle postituse eesmärk on aidata rakenduste arendajatel mõista SQL-i ja NoSQL-i valikut rakenduse andmete modelleerimise vajaduste kontekstis. Kasutame näitena ühte SQL-andmebaasi, nimelt PostgreSQL, ja 2 NoSQL-i andmebaasi, nimelt Cassandra ja MongoDB, et selgitada andmete modelleerimise põhitõdesid, näiteks tabelite loomine, andmete sisestamine, skaneerimine ja andmete kustutamine. Jätkuprogrammis käsitleme edasijõudnuteid teemasid nagu indeksid, tehingud, liitumised, TTL-direktiivid ja JSON-põhised dokumentide andmete modelleerimine.

Kuidas NoSQL erineb SQL-ist andmemudelis?

SQL-andmebaasid suurendavad rakenduste paindlikkust ACID-i tehingutagatiste kaudu, samuti tänu nende võimalusele olemasolevate normaliseeritud relatsiooniliste andmemudelite kõrval andmeid päringuid kasutades JOIN-e ette näha.

Arvestades nende monoliitset / ühe sõlme ülesehitust ja ülem-alluv replikatsioonimudeli kasutamist koondamiseks, puuduvad traditsioonilistes SQL-andmebaasides kaks olulist võimalust - lineaarne kirjutamisskaalaritus (s.o automaatne varjutamine mitme sõlme vahel) ja automaatne / null-andmete kadumise tõrkeotsing. See tähendab, et sissevõetud andmemahud ei tohi ületada ühe sõlme maksimumkirjutusvõimet. Lisaks tuleks tõrkesiirde korral (jagatud mitte midagi salvestava arhitektuuri korral) oodata ajutist andmete kaotust, arvestades, et hiljutised lubadused poleks veel orja replikatsioonis ilmnenud. Null-seisakuid on ka SQL-andmebaasimaailmas raske saavutada.

NoSQL DB-sid levitatakse tavaliselt looduses, kus andmed jaotatakse või hajutatakse mitme sõlme vahel. Nad volitavad denormaliseerimist, mis tähendab, et sisestatud andmeid tuleb ka mitu korda kopeerida, et pakkuda teile konkreetseid päringuid. Üldine eesmärk on saada kõrge jõudlus, vähendades selgesõnaliselt lugemisaja jooksul kasutatavate kildude arvu. Siit tuleneb väide, et NoSQL nõuab, et te modereeriksite oma päringuid, samal ajal kui SQL nõuab, et te modelleeriksite oma andmeid.

NoSQL keskendub hajutatud klastri suure jõudlusega saavutamisele kui peamisele põhjendusele mitmete andmete modelleerimisega seotud kompromisside puhul, mis hõlmavad ACID-tehingute, JOIN-ide ja järjepidevate globaalsete sekundaarsete indeksite kaotamist.

Üldine arusaam on, et kuigi NoSQL andmebaasid pakuvad lineaarset kirjutamisskaalaritust ja kõrget tõrketaluvust, muudab tehingutagatiste kaotamine need kõlbmatuks missioonikriitiliste andmete jaoks.

Järgmises tabelis kirjeldatakse, kuidas NoSQL-i andmete modelleerimine erineb SQL-i modelleerimisest.

SQL vs NoSQL - peamised andmete modelleerimise erinevused

SQL ja NoSQL: miks vajate mõlemat?

Enamikku pärismaailma kaasahaaravate kasutajakogemustega rakendusi, näiteks Amazon.com, Netflix, Uber ja Airbnb, toidavad sisemiselt keerulised segud, mis koosnevad mitmest töökoormusest. Näit. selline e-kaubanduse rakendus nagu Amazon.com peab salvestama väikesemahulisi ja ülimalt missioonikriitilisi andmeid (nt kasutajad, tooted, tellimused, arved) suuremahuliste ja vähem missioonikriitiliste andmete kõrval, näiteks tooteülevaated, kasutajatoe teated, kasutaja tegevus, kasutaja soovitused. Loomulikult toetuvad need rakendused vähemalt ühele SQL-andmebaasile vähemalt ühe NoSQL-i andmebaasi kõrval. Mitme regiooni ja globaalse juurutamise korral toimib NoSQL andmebaas ka tõeallikas talletatud andmete geograafiliselt jaotatud vahemäluna - SQL andmebaas töötab ühes piirkonnas.

Kuidas YugaByte DB SQL-i ja NoSQL-i ühisesse andmebaasi tuuma kokku viib?

YugaByte DB, mis on üles ehitatud unikaalsele logistruktureeritud ühilduvmäluseadme, automaatse varjundi, jaotusepõhise hajutatud konsensuse replikatsiooni ja hajutatud ACID-tehingute (inspireeritud Google Spannerist) abil, on YugaByte DB maailmas esimene avatud lähtekoodiga andmebaas, mis on ühtlasi NoSQL (Cassandra ja Redis ühilduv) ja SQL (ühildub PostgreSQL-iga). Nagu on näidatud allolevas tabelis, lisab YCQL, YugaByte DB Cassandra ühilduv API, NoSQL API-desse ühe võtme ja mitme võtmega ACID-tehingute ning globaalsete sekundaarsete indeksite mõiste, viies sisse tehingulise NoSQL-i ajastul. Lisaks lisab YSQL, YugaByte DB PostgreSQL-iga ühilduv API SQL API-le lineaarse kirjutamiskaala ja automaatse tõrketaluvuse mõisted, tuues sellega esile hajutatud SQL-i maailma. Kuna YugaByte DB on tehingute keskmes, saab nüüd isegi NoSQL API-sid kasutada missioonikriitiliste andmete kontekstis.

YugaByte DB - SQL ja NoSQL ühes andmebaasisüdamikus

Nagu eelnevalt kirjeldati jaotises YSQLi tutvustamine: PostgreSQL-iga ühilduv hajutatud SQL API YugaByte DB jaoks, sõltub SQL versiooni NoSQL valik YugaByte DB-s täielikult suurema osa töökoormuse omadustest.

  • Kui suurem osa töökoormusest on JOINS-iga mitme võtmega toimingud, siis valige YSQL, mõeldes sellele, et teie võtmed võivad olla jaotatud mitme sõlme vahel, mis viib suurema latentsuse ja / või madalama läbilaskevõimega kui NoSQL.
  • Muul juhul valige üks neist kahest NoSQL API-st, mõeldes, et saate paremaid jõudluse eeliseid, kui päringuid teenindatakse peamiselt ühest sõlmest korraga. YugaByte DB võib toimida ühtse operatiivse andmebaasina keerukates reaalmaailma rakendustes, mille haldamiseks on tavaliselt korraga mitu töökoormust.

Järgmises jaotises sisalduv andmete modelleerimise labor põhineb YugaByte DB PostgreSQL ja Cassandra ühilduvatel API-l, mitte originaalsetel andmebaasidel. See lähenemisviis rõhutab sama andmebaasi klastri kahe erineva API-ga (kahel erineval pordil) suhtlemise lihtsust, mitte aga kahe erineva andmebaasi täiesti sõltumatute klastrite kasutamist.

Järgmistes jaotistes tutvume andmete modelleerimisega laboris, et illustreerida paljusid erinevusi ja mõningaid sarnasusi erinevate andmebaaside vahel.

Andmete modelleerimise labor

Installige andmebaasid

Arvestades keskendumist andmete modelleerimisele (ja mitte keerukatele juurutusarhitektuuridele), installime andmebaasid Dockeri konteineritesse meie kohalikesse masinatesse ja suhtleme seejärel nende vastavate käsuridade abil.

YugaByte DB, PostgreSQL ja Cassandra ühilduv andmebaas

mkdir ~ / yugabyte && cd ~ / yugabyte
vidin https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
doki tõmmake yugabytedb / yugabyte
./yb-docker-ctl luua - aktiveerida_postitus

MongoDB

doki käivitamine - nimeta minu-mongo -d mongo: viimane

Juurdepääs käsuridade abil

Järgmisena ühendume andmebaasidega, kasutades vastavate API-de käsuribasid.

PostgreSQL

psql on PostgreSQL-iga suhtlemiseks käsurida. Kasutamise lihtsustamiseks edastatakse YugaByte DB prügikasti kataloogis psql-i versiooniga.

doki täitja yb-postgres-n1 / kodu / yugabyte / postgres / bin / psql -p 5433 -U postgres

Cassandra

cqlsh on käsurida, mis võimaldab Cassandra ja selle ühilduvate andmebaasidega suhelda CQL-i (Cassandra Query Language) kaudu. Kasutamise hõlbustamiseks tarnitakse YugaByte DB prügikasti kataloogis cqlsh-i versiooniga.

Pange tähele, et CQL on suuresti inspireeritud SQL-ist, sarnase mõistega tabelid, read, veerud ja indeksid. NoSQL-i keelena lisab see siiski konkreetse komplekti piiranguid, millest enamiku vaatame läbi oma blogisarja jooksul.

doki käivitaja yb-tserver-n1 / kodu / yugabyte / bin / cqlsh

MongoDB

mongo on käsuribal MongoDB-ga suhtlemiseks. Selle võib leida MongoDB installi prügikataloogist.

doki käivitaja - minu mongo bash
CD-prügikast
mongo

Loo tabel

Nüüd saame käsuribi abil andmebaasiga suhelda mitmesuguste toimingute jaoks. Alustame tabeli loomisega, kuhu salvestatakse teave artistide avaldatud lugude kohta. Need laulud on mõnikord albumi osa. Laulu muud valikulised atribuudid on välja antud aasta, hinna, žanri ja kriitiku hinnangu järgi. Me vajame kontot täiendavate atribuutide jaoks, mida meil tulevikus võib vaja minna välja „sildid” kaudu, mis võib salvestada poolstruktureeritud andmeid võtme-väärtuse paaridena.

PostgreSQL

CREATE TABLE Music (
    Kunstnik VARCHAR (20) EI NULL,
    SongTitle VARCHAR (30) EI OLE NULL,
    Albumi pealkiri VARCHAR (25),
    Aasta INT,
    Hind FLOAT,
    Žanr VARCHAR (10),
    Kriitiline HÕLMASTUS,
    Sildid TEXT,
    ESIMENE VÕTM (esitaja, SongTitle)
);

Cassandra

Cassandras tabeli loomine sarnaneb PostgreSQL-iga. Üks suur erinevus on terviklikkuspiirangute puudumine (näiteks MITTE NULL), mille eest vastutab rakendus, mitte NoSQL-i andmebaas. Primaarvõti koosneb partitsiooniklahvist (allpool toodud näite veerg Artist) ja rühmitusveergude komplektist (SongTitle veerg allpool toodud näites). Partitsiooniklahv määrab, millisesse sektsiooni / varjundisse rida paigutada ja klastriveerud määravad, kuidas antud kihi sees olevad andmed peaksid olema korraldatud.

CREATE KEYSPACE myapp;
KASUTA myapp;
CREATE TABLE Music (
    Esitaja TEXT,
    SongTitle TEXT,
    Albumi pealkiri TEXT,
    Aasta INT,
    Hind FLOAT,
    Žanr TEKST,
    Kriitiline HÕLMASTUS,
    Sildid TEXT,
    ESIMENE VÕTM (esitaja, SongTitle)
);

MongoDB

MongoDB korraldab andmeid andmebaasides (samaväärne Cassandra Keyspace'iga), kus on kogud (samaväärsed tabelitega), millel on dokumendid (sama kui tabeli rida). Kuna skeemideta andmebaas, pole MongoDB-s skeemi enne tähtaega määratleda. Allpool näidatud käsk „kasuta andmebaasi” kohestab andmebaasi juba esimest korda ja koos konteksti muutmisega vastloodud andmebaasiks. Isegi kogud ei pea olema selgesõnalised, vaid luuakse automaatselt automaatselt, sisestades lihtsalt esimese dokumendi uude kollektsiooni. Pange tähele, et MongoDB vaikeandmebaas on test, nii et kõik andmebaasi täpsustamata kogumistaseme toimingud tehakse selles vaikekontekstis.

kasutage myNewDatabase;

Hankige teavet tabeli kohta

PostgreSQL

\ d Muusika
Tabel "public.music"
    Veerg | Tüüp | Kogumine | Nullitav | Vaikimisi
-------------- + ----------------------- + ----------- + ---------- + --------
 kunstnik | märk varieeruv (20) | | mitte olematu |
 laulupealkiri | tähemärki varieeruv (30) | | mitte olematu |
 albumi pealkiri | tähemärk varieeruv (25) | | |
 aasta | täisarv | | |
 hind | kahekordne täpsus | | |
 žanr | tähemärki varieeruv (10) | | |
 kriitika | kahekordne täpsus | | |
 sildid | tekst | | |
Indeksid:
    "music_pkey" PRIMARY KEY, btree (esitaja, loo pealkiri)

Cassandra

KIRJELDA TABELI MUUSIKAT;
LOE TABEL myapp.music (
    esitaja tekst,
    laulu pealkirja tekst,
    albumi pealkirja tekst,
    aasta keskmine,
    hind ujuk,
    žanritekst,
    sildistab teksti,
    PRIMARY KEY (esitaja, laulu pealkiri)
) KLASTEERIMISKORRALDUSEGA (loo pealkiri ASC)
    JA default_time_to_live = 0
    JA tehingud = {'lubatud': 'vale'};

MongoDB

kasutage myNewDatabase;
näitusekollektsioonid;

Sisestage andmed tabelisse

PostgreSQL

INSERT INTO Music
    (Artist, SongTitle, AlbumTitle,
    Aasta, hind, žanr, kriitiline hindamine,
    Sildid)
VÄÄRTUSED(
    "Keegi, keda te ei tunne", "Helistage mulle täna", "Mõnevõrra kuulus",
    2015, 2,14, „Riik”, 7,8,
    '{"Heliloojad": ["Smith", "Jones", "Davis"], "LengthInSeconds": 214} "
);
INSERT INTO Music
    (Artist, SongTitle, AlbumTitle,
    Hind, žanr, kriitiline hindamine)
VÄÄRTUSED(
    "Keegi, keda te ei tunne", "Minu koer on kohapeal", "Hei nüüd",
    1,98, 'Riik', 8,4
);
INSERT INTO Music
    (Artist, SongTitle, AlbumTitle,
    Hind, žanr)
VÄÄRTUSED(
    "The Acme Band", "Vaadake välja, maailm", "The Buck Starts Here",
    0,99, 'rokk'
);
INSERT INTO Music
    (Artist, SongTitle, AlbumTitle,
    Hind, žanr,
    Sildid)
VÄÄRTUSED(
    "The Acme Band", "endiselt armunud", "The Buck Starts Here",
    2.47, 'Rock',
    '{"radioStationPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotatsioon": Raske} ”
);

Cassandra

Cassandra INSERT väljavõtted näevad välja väga sarnased PostgreSQL-iga üldiselt. Siiski on semantikas üks suur erinevus. INSERT on tegelikult ülesjuhtimisoperatsioon Cassandras, kus rida värskendatakse uusimate väärtustega juhul, kui rida on juba olemas.

Sama mis ülaltoodud PostgreSQL INSERT avaldused.

MongoDB

Ehkki MongoDB on ka Cassandraga sarnane NoSQL-andmebaas, pole selle sisestusoperatsioonil sama semantilist käitumist kui Cassandral. MongoDB insertil () pole üleslülitusvõimalust, mis muudab selle sarnaseks PostgreSQL-iga. Sisestamise vaikekäitumine, millel pole _ids täpsustatud, toob uue kollektsiooni dokumendi lisamise.

db.music.insert ({
kunstnik: "Keegi, keda sa ei tunne",
   songTitle: "Helista mulle täna",
    albumTitle: "mõnevõrra kuulus",
    aasta: 2015,
    hind: 2,14,
    žanr: "Riik",
    sildid: {
Heliloojad: ["Smith", "Jones", "Davis"],
Pikkus sekundites: 214
}
   }
);
db.music.insert ({
    kunstnik: "Keegi, keda sa ei tunne",
    songTitle: "Minu koer kohapeal",
    albumTitle: "Hey Now",
    hind: 1,98,
    žanr: "Riik",
    kritiseerimine: 8.4
   }
);
db.music.insert ({
    kunstnik: "The Acme Band",
    songTitle: "Vaadake välja, maailm",
    albumTitle: "Buck algab siit",
    hind: 0,99,
    žanr: "Rock"
   }
);
db.music.insert ({
    kunstnik: "The Acme Band",
    songTitle: "Veel armunud",
    albumTitle: "Buck algab siit",
    hind: 2,47,
    žanr: "Rock",
    sildid: {
        radioStationPlaying: ["KHCR", "KBQX", "WTNR", "WJJH"],
        tourDates: {
            Seattle: "20150625",
            Cleveland: "20150630"
        },
        rotatsioon: "raske"
}
    }
);

Tabeli päring

Vaieldamatult kõige olulisem erinevus SQL-i ja NoSQL-i vahel päringute modelleerimisel on klauslite FROM ja WHERE kasutamine. SQL lubab FROM-klauselil lisada mitu tabelit ja WHERE-lause olla suvalise keerukusega (sealhulgas JOIN-id tabelite vahel). NoSQL kipub aga FROM-i klauslile kehtestama kõva piirangu, kui on määratud ainult üks tabel ja WHERE-klausel, et primaarvõti oleks alati täpsustatud. Selle põhjuseks on NoSQL kõrge jõudlusega keskendumine, millest me varem arutlesime, mille eesmärk on vähendada igasugust risttabelit ja võtmetevahelist interaktsiooni. Selline interaktsioon võib päringu reageerimise aja sisse viia kõrge latentsusega sõlmedevahelise suhtluse ja seetõttu on seda kõige parem vältida. Näit. Cassandra nõuab, et operaatorid piiraksid päringuid (lubatud on ainult =, IN, <,>, =>, <=) partitsiooniklahvidel, välja arvatud sekundaarindeksi pärimisel (kus lubatud on ainult = operaator).

PostgreSQL

Järgnevalt on toodud 3 tüüpi päringuid, mida saab SQL-andmebaasi abil hõlpsalt teenindada.

  • Tagastage kõik artisti laulud
  • Tagastage kõik artisti lood, mis vastavad pealkirja esimesele osale
  • Tagastage kõik artisti laulud, pealkirjas on konkreetne sõna, kuid ainult siis, kui hind on alla 1,00
VALI * muusikast
KUS kunstnik = 'Keegi, keda sa ei tunne';
VALI * muusikast
KUS Artist = 'Keegi ei tunne sind' ja SongTitle LIKE 'Call%';
VALI * muusikast
KUS Artist = 'Keegi, keda te ei tunne' JA SongTitle LIKE '% Täna%%'
JA hind> 1,00;

Cassandra

Ülalloetletud PostgreSQL-i päringutest töötab Cassandraga modifitseerimata ainult esimene, kuna operaator LIKE pole sellistel klasterveergudel nagu SongTitle lubatud. Sel juhul on lubatud ainult = ja IN operaatorid.

VALI * muusikast
KUS kunstnik = 'Keegi, keda sa ei tunne';
VALI * muusikast
KUS Artist = 'Keegi ei tunne teid' ja SongTitle IN ('Helistage mulle täna', 'Minu koer')
JA hind> 1,00;

MongoDB

Nagu eelmistes näidetes näidatud, on MongoDB-st päringu esmane meetod db.collection.find (). Seda meetodit kvalifitseeritakse kollektsiooni nime järgi (muusika alltoodud näites), et selle järele tuleb esitada väga selgesõnaline päring, nii et kogu kogu päringute tegemine on sõnaselgelt keelatud.

db.music.find ({
  kunstnik: "Keegi, keda sa ei tunne"
 }
);
db.music.find ({
  kunstnik: "Keegi, keda sa ei tunne",
  songTitle: / Helista /
 }
);

Loe kõiki ridu tabelist

Kõigi ridade lugemine on lihtsalt üldine pärimusmustri erijuhtum, mida me varem täheldasime.

PostgreSQL

VALI *
Muusikast;

Cassandra

Sama nagu ülaltoodud avaldus PostgreSQL SELECT.

MongoDB

db.music.find ({});

Andmete muutmine tabelis

PostgreSQL

PostgreSQL pakub andmete muutmiseks UPDATE-avaldust. See ei luba ühtegi üleslülitusvõimalust, nii et avaldus ebaõnnestub, kui rida pole andmebaasis juba olemas.

UPDATE muusika
SET-žanr = 'disko'
KUS Artist = 'The Acme Band' ja SongTitle = 'Ikka armunud';

Cassandra

Cassandral on ka PostgreSQL-iga sarnane UPDATE-avaldus. UPDATE ka sama ülespoole semantika kui INSERT avalduses.

Sama nagu ülaltoodud avaldus PostgreSQL UPDATE.

MongoDB

MongoDB värskenduse () toiminguga saab olemasolevat dokumenti täielikult värskendada või värskendada ainult konkreetseid välju. Vaikimisi värskendab see ainult ühte dokumenti, mille ülaosa semantika on välja lülitatud. Mitme dokumendi värskendused ja üleslaadimise käitumine saab sisse lülitada, määrates toimingule täiendavad lipud. Näit. allolevas näites värskendatakse konkreetse artisti žanrit kõigi esitaja lugude lõikes.

db.music.update (
  {"artist": "The Acme Band"},
  {
    $ komplekt: {
      "žanr": "disko"
    }
  },
  {"multi": true, "upsert": true}
);

Kustutage andmed tabelist

PostgreSQL

Kustuta muusikast
KUS Artist = 'The Acme Band' ja SongTitle = 'Vaadake välja, maailm';

Cassandra

Sama nagu ülaltoodud avaldus PostgreSQL DELETE.

MongoDB

MongoDB-l on dokumentide kustutamisega tegelemiseks kahte tüüpi toiminguid - deleteOne () / deleteMany () ja remove (). Mõlemad kustutavad dokumendi (dokumendid), kuid tagastamise tulemused on erinevad.

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

Eemaldage tabel

PostgreSQL

DROP TABLE Muusika;

Cassandra

Sama nagu ülaltoodud avaldus PostgreSQL DROP TABLE;

MongoDB

db.music.drop ();

Kokkuvõte

Arutelud SQL vs NoSQL üle on kippunud juba kümme aastat. Sellel arutelul on 2 aspekti: andmebaasi tuumiarhitektuur (monoliitne, tehinguline SQL vs hajutatud, mittetehinguline NoSQL) ja andmete modelleerimise lähenemisviis (modelleerige oma andmed SQL-is ja modelleerige oma päringud NoSQL-is).

Hajutatud tehinguandmebaasi (näiteks YugaByte DB) abil saab andmebaasi tuumiarhitektuuri osa hõlpsasti puhata. Kuna andmemahud kasvavad kaugemale sellest, mida saab kirjutada ühte sõlme, muutub hädavajalikuks täielikult jaotatud arhitektuur, mis võimaldab lineaarset kirjutamisskaalaritust automaatse varjundiga / uuesti tasakaalustamisega. Lisaks, nagu kirjeldatakse selles Google Cloudi postituses, aktsepteeritakse laialdaselt ka tehingulisi, tugevalt järjepidevaid arhitektuure, et pakkuda suuremat arendaja ja operatsioonide paindlikkust kui mittetehingulised, lõpuks järjepidevad arhitektuurid.

Tulles andmete modelleerimise arutelule, on õiglane öelda, et nii SQL kui ka NoSQL andmete modelleerimise lähenemisviisid on mis tahes keeruka reaalmaailma rakenduse jaoks hädavajalikud. SQL-i mudel - teie andmed - lähenemisviis võimaldab arendajatel hõlpsamini rahuldada muutuvaid ärinõudeid, samas kui NoSQL-i mudel-teie päringud võimaldab samadel arendajatel hallata suuri andmemahtusid väikese latentsusaja ja suure läbilaskevõimega. Just see on põhjus, miks YugaByte DB rakendab ühisesse tuuma nii SQL kui ka NoSQL API, selle asemel, et reklaamida seda, et üks lähenemisviis on teisest parem. Lisaks tagab YugaByte DB, tagades traadi ühilduvuse populaarsete andmebaasikeeltega, sealhulgas PostgreSQL ja Cassandra, et arendajad ei õpi teist keelt, et saada kasu hajutatud kindla järjepidevusega andmebaasi tuumast.

See postitus aitas meil mõista, kuidas andmete modelleerimise põhitõed erinevad PostgreSQL, Cassandra ja MongoDB vahel. Sarja järgmistes postitustes sukeldume täpsematesse andmete modelleerimise kontseptsioonidesse nagu indeksid, tehingud, JOINid, TTL direktiivid ja JSON-dokumendid.

Mis järgmiseks?

  • Võrrelge YugaByte DB andmebaasidega nagu Amazon DynamoDB, Cassandra, MongoDB ja Azure Cosmos DB.
  • Alustage YugaByte DB-ga MacOS-is, Linuxis, Dockeris ja Kuberneteses.
  • Litsentsimise, hinnakujunduse või tehnilise ülevaate kavandamise kohta lisateabe saamiseks võtke meiega ühendust.

Algselt avaldati YugaByte andmebaasi ajaveebis.