Osnove modeliranja podatkov - PostgreSQL vs. Cassandra vs. MongoDB

Razvijalci aplikacij običajno porabijo veliko časa za ocenjevanje več operativnih baz podatkov, da bi ugotovili, da je ena baza podatkov najbolj primerna za njihove potrebe obremenitve. Te potrebe vključujejo poenostavljeno modeliranje podatkov, transakcijske garancije, uspešnost branja / pisanja, horizontalno skaliranje in toleranco napak. Tradicionalno se ta izbor začne s kategorijami baz podatkov SQL v primerjavi z NoSQL, ker vsaka kategorija predstavlja jasen nabor kompromisov. Visoka učinkovitost v smislu nizke zamude in visoke prepustnosti se običajno obravnava kot nekompromisna zahteva, zato se pričakuje v kateri koli izbrani zbirki podatkov.

Ta objava želi pomagati razvijalcem aplikacij, da razumejo izbiro SQL v primerjavi z NoSQL v kontekstu potreb po modeliranju podatkov v aplikaciji. Kot primere za razlago osnov za modeliranje podatkov, kot so ustvarjanje tabel, vstavljanje podatkov, izvajanje pregledov in brisanje podatkov, uporabljamo bazo podatkov SQL in sicer PostgreSQL ter 2 podatkovni bazi NoSQL, in sicer Cassandra in MongoDB. V naslednjem prispevku bomo zajemali napredne teme, kot so indeksi, transakcije, združevanja, direktive o času do živega (TTL) in modeliranje podatkov o dokumentih na podlagi JSON.

Kako se NoSQL razlikuje od SQL pri modeliranju podatkov?

SQL baze podatkov povečujejo agilnost aplikacij s transakcijskimi garancijami ACID in s svojo zmožnostjo poizvedovanja po podatkih z uporabo JOIN na nepredvidene načine na podlagi obstoječih normaliziranih modelov relacijskih podatkov.

Glede na njihovo monolitno / enojno arhitekturo in uporabo modela podvajanja master-slave za odvečnost tradicionalnih baz podatkov SQL manjkajo dve pomembni zmožnosti - linearna skalabilnost zapisovanja (tj. Samodejno ostrenje na več vozlišč) in samodejna prekinitev izgube / nič. To pomeni, da zaužite količine podatkov ne smejo presegati največjega prepisa zapisa v enem vozlišču. Poleg tega bi bilo treba pričakovati nekaj začasne izgube podatkov ob preklopu (v arhitekturi shranjevanja v skupni rabi nič), ker se nedavne zaveze še ne bi pokazale v podrejeni podrejeni repliki. Zelo težko je doseči nadgradnje ničelnih izpadov v svetu baz podatkov SQL.

NoSQL DB so običajno razporejeni v naravi, kjer se podatki razdelijo ali razdelijo na več vozlišč. Naročajo denormalizacijo, kar pomeni, da je treba vstavljene podatke večkrat kopirati, da služijo točno določenim poizvedbam, ki jih imate v mislih. Splošni cilj je doseči visoko zmogljivost z izrecnim zmanjšanjem števila delcev, ki so dostopni v času branja. Zato trditev, da od NoSQL morate modelirati poizvedbe, medtem ko SQL od vas zahteva, da modelirate svoje podatke.

Osredotočenost NoSQL na doseganje visokih zmogljivosti na porazdeljenem grozdu je navedena kot glavna utemeljitev za več kompromisov pri modeliranju podatkov, ki vključujejo izgubo transakcij ACID, JOIN in dosledne globalne sekundarne indekse.

Splošno mnenje je, da kljub temu, da baze podatkov NoSQL zagotavljajo linearno skalabilnost pisanja in visoko odstopanje napak, izguba transakcijskih garancij naredi neprimerne za kritične podatke.

Naslednja tabela podrobno opisuje, kako se modeliranje NoSQL razlikuje od tistega v SQL.

SQL vs. NoSQL - Razlike pri modeliranju ključnih podatkov

SQL in NoSQL: Zakaj potrebujete oboje?

Večina aplikacij v resničnem svetu z privlačnimi uporabniškimi izkušnjami, kot so Amazon.com, Netflix, Uber in Airbnb, se napaja s pomočjo kompleksne mešanice več delovnih obremenitev. Npr. aplikacija za e-trgovino, kot je Amazon.com, mora shraniti podatke, ki so zelo kritični in so zelo kritični, kot so uporabniki, izdelki, naročila, računi, poleg podatkov o velikem obsegu in manj kritični nalogi, kot so pregledi izdelkov, sporočila službe za pomoč, uporabniška aktivnost, uporabniška priporočila. Seveda se te aplikacije opirajo na vsaj eno bazo SQL poleg vsaj ene baze podatkov NoSQL. V večregionalnih in globalnih razmestitvah podatkovna baza NoSQL deluje tudi kot geo-porazdeljeni predpomnilnik za podatke, shranjene v viru resnice, bazo podatkov SQL, ki teče v enem samem območju.

Kako YugaByte DB združuje SQL in NoSQL v skupnem jedru baze podatkov?

Zasnovan na edinstveni kombinaciji mehanizma za združevanje pomnilnikov, ki je strukturiran v obliki dnevnika, samodejnega ostrenja, podeljene konsenzusne razmnoževanja in porazdeljenih transakcij ACID (navdihnil Google Spanner), YugaByte DB je prva odprtokodna baza podatkov na svetu, ki je hkrati NoSQL (Cassandra & Redis združljiv) in SQL (PostgreSQL združljiv) hkrati. Kot je prikazano v spodnji tabeli, YCQL, združljiv s API-jem Cassandra YugaByte DB, dodaja API-je NoSQL pojem eno-ključnih in več-ključnih ACID transakcij ter globalnih sekundarnih indeksov, s čimer se je začel v dobi Transactional NoSQL. Poleg tega YSQL, YugaByte DB-jev PostgreSQL združljiv API, dodaja pojma linearnega skaliranja pisanja in samodejne odpovedi napak v API-ju SQL in tako ustvari svet distribuiranega SQL-a. Ker je YugaByte DB transakcijski v središču, se lahko zdaj tudi API-ji NoSQL uporabljajo v okviru kritičnih podatkov.

YugaByte DB - SQL in NoSQL v jedru ene baze podatkov

Kot smo že opisali v uvodu YSQL: PostgreSQL združljiv distribucijski SQL API za YugaByte DB, je izbira SQL proti NoSQL v YugaByte DB v celoti odvisna od značilnosti večine delovne obremenitve.

  • Če je večina delovnih obremenitev z večinamičnimi operacijami z JOINS, izberite YSQL z razumevanjem, da so vaši ključi lahko razporejeni po več vozliščih, kar vodi do večje zamude in / ali nižje pretočnosti kot NoSQL.
  • V nasprotnem primeru izberite enega od obeh API-jev NoSQL z razumevanjem, da boste dobili večje prednosti pri uspešnosti, ki izhajajo iz poizvedb, v glavnem iz enega vozlišča hkrati. YugaByte DB lahko služi kot združena operativna baza podatkov za zapletene aplikacije v resničnem svetu, ki imajo običajno več delovnih obremenitev hkrati.

Laboratorij za modeliranje podatkov v naslednjem razdelku temelji na združljivih API-jih PostgreSQL in Cassandra YugaByte v nasprotju s prvotnimi zbirkami podatkov. Ta pristop poudarja preprostost interakcije z dvema različnima API-jem (na dveh različnih pristaniščih) istega sklopa baz podatkov v nasprotju z uporabo popolnoma neodvisnih grozdov dveh različnih baz podatkov.

V naslednjih razdelkih se bomo sprehodili po laboratorijih za modeliranje podatkov, da bi prikazali številne razlike in nekaj skupnih značilnosti med različnimi zbirkami podatkov.

Laboratorij za modeliranje podatkov

Namestite baze podatkov

Glede na osredotočenost na modeliranje podatkov (in ne na kompleksne arhitekture uvajanja) bomo baze podatkov namestili v Dockerjeve vsebnike na naše lokalne stroje in nato z njimi komunicirali z ustreznimi lupinami ukazne vrstice.

YugaByte DB, združljiva baza podatkov PostgreSQL in Cassandra

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
docker potegnite yugabytedb / yugabyte
./yb-docker-ctl ustvarite --enable_postgres

MongoDB

docker run - ime moje-mongo -d mongo: najnovejše

Dostop prek lupine ukazne vrstice

Nato se povežemo z bazami podatkov z uporabo lupin ukazne vrstice za ustrezne API-je.

PostgreSQL

psql je lupina ukazne vrstice za interakcijo s PostgreSQL. Za lažjo uporabo YugaByte DB pošilja različico psql v svojem imeniku bin.

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

Cassandra

cqlsh je lupina ukazne vrstice za interakcijo s Cassandro in njenimi združljivimi bazami podatkov prek CQL (jezik poizvedbe Cassandra). Za lažjo uporabo YugaByte DB pošlje z različico cqlsh v svojem imeniku bin.

Upoštevajte, da CQL močno navdihuje SQL s podobnim pojmom tabel, vrstic, stolpcev in indeksov. Vendar pa kot jezik NoSQL doda poseben niz omejitev, ki jih bomo pregledali med našo serijo blogov.

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

MongoDB

mongo je lupina ukazne vrstice za interakcijo z MongoDB. Najdemo ga v imeniku zabojnikov namestitve MongoDB.

docker exec - to je moj mongo bash
CD zaboj
mongo

Ustvari tabelo

Zdaj lahko z bazo podatkov komuniciramo za različne operacije z lupino ukazne vrstice. Začnimo z ustvarjanjem tabele, ki shranjuje informacije o pesmih, ki so jih objavili izvajalci. Te pesmi so včasih del albuma. Drugi neobvezni atributi pesmi so letnik, cena, zvrst in ocena kritike. Potrebujemo dodatne atribute, ki jih bomo v prihodnosti morda potrebovali v polju 'oznake', ki lahko shrani polstrukturirane podatke kot pare ključ-vrednost.

PostgreSQL

USTVARJITE TABELO Glasba (
    Umetnik VARCHAR (20) NI NULL,
    SongTitle VARCHAR (30) NI NULL,
    AlbumTitle VARCHAR (25),
    Leto INT,
    Cena FLOAT,
    Žanr VARCHAR (10),
    Kritično ocenjevanje FLOAT,
    Oznake TEKST,
    PRIMARNI KLJUČ (izvajalec, SongTitle)
);

Cassandra

Ustvari tabelo v Cassandri je zelo podobno kot v PostgreSQL. Velika razlika je pomanjkanje omejitev integritete (na primer NI NULL), ki je v svetu NoSQL odgovorna za aplikacijo in ne za bazo podatkov. Primarni ključ je sestavljen iz razdelitvenega ključa (stolpec Izvajalec v spodnjem primeru) in niza stolpcev v skupini (stolpec SongTitle v spodnjem primeru). V razdelitvenem ključu je določeno, v katero particijo / delnico naj bo vrstico v stolpcih, v stolpcih združevanja pa je določeno, kako naj bodo organizirani podatki znotraj dane fraze.

CREATE KEYSPACE myapp;
UPORABITE myapp;
USTVARJITE TABELO Glasba (
    TEXT izvajalca,
    TEKST SongTitle,
    AlbumTitle TEXT,
    Leto INT,
    Cena FLOAT,
    Žanr TEKST,
    Kritično ocenjevanje FLOAT,
    Oznake TEKST,
    PRIMARNI KLJUČ (izvajalec, SongTitle)
);

MongoDB

MongoDB organizira podatke v zbirkah podatkov (enakovredno Cassandra Keyspace), ki imajo zbirke (ekvivalentne tabelam) z dokumenti (ekvivalentno vrstici v tabeli). Kot baza podatkov brez sheme v MongoDB ni potrebna predhodna opredelitev sheme. Spodaj prikazan ukaz "uporaba baze podatkov" sproži bazo podatkov prvič, ko jo pokliče, skupaj s spremembo konteksta na novo ustvarjeno bazo podatkov. Tudi zbirk ni treba ustvarjati izrecno, ampak jih ustvarite samodejno, tako da preprosto vstavite prvi dokument v novo zbirko. Upoštevajte, da je privzeta baza podatkov MongoDB preizkusna, zato se vsa operacija na ravni zbiranja, ki se izvede brez navedbe baze podatkov, opravi v tem privzetem kontekstu.

uporabite myNewDatabase;

Pridobite informacije o tabeli

PostgreSQL

\ d Glasba
Tabela "public.music"
    Stolpec | Vrsta | Zbiranje | Izvlečna | Privzeto
-------------- + ----------------------- + ----------- + ---------- + --------
 umetnik | spreminjanje znakov (20) | | ni nično |
 songtitle | spreminjanje znakov (30) | | ni nično |
 albumtitle | spreminjanje znakov (25) | | |
 leto | celo število | | |
 cena | dvojna natančnost | | |
 žanr | spreminjanje znakov (10) | | |
 kritizirati | dvojna natančnost | | |
 oznake | besedilo | | |
Indeksi:
    "music_pkey" PRIMARY KEY, btree (izvajalec, pesmi)

Cassandra

OPISNITE TABELNO GLASBO;
USTVARJITE TABELO myapp.music (
    besedilo izvajalca,
    besedilo pesmi,
    besedilo albuma
    leto int,
    cenovni plovec,
    žanrsko besedilo,
    besedilo oznak,
    PRIMARNI KLJUČ (izvajalec, skladba)
) Z NAVODILO ZA KLUSTIRANJE (songtitle ASC)
    IN default_time_to_live = 0
    IN transakcije = {'omogočeno': 'false'};

MongoDB

uporabite myNewDatabase;
prikaži zbirke;

Vstavite podatke v tabelo

PostgreSQL

VSTAVITE V glasbo
    (Izvajalec, SongTitle, AlbumTitle,
    Leto, Cena, Žanr, Ocenjevanje kritik,
    Oznake)
VREDNOSTI (
    'Nikogar, ki ga poznaš', 'Pokliči me danes', 'Nekoliko znan',
    2015, 2.14, 'Država', 7.8,
    '{"Skladatelji": ["Smith", "Jones", "Davis"], "LengthInSeconds": 214} "
);
VSTAVITE V glasbo
    (Izvajalec, SongTitle, AlbumTitle,
    Cena, žanr, kritična ocena)
VREDNOSTI (
    'Nikogar, ki ga poznaš', 'Moja pasja točka', 'Hej zdaj',
    1.98, 'Država', 8.4
);
VSTAVITE V glasbo
    (Izvajalec, SongTitle, AlbumTitle,
    Cena, žanr)
VREDNOSTI (
    'The Acme Band', 'Pazi, svet', 'Buck začne tukaj',
    0,99, 'Rock'
);
VSTAVITE V glasbo
    (Izvajalec, SongTitle, AlbumTitle,
    Cena, žanr,
    Oznake)
VREDNOSTI (
    'The Acme Band', 'Še vedno zaljubljen', 'Buck začne tukaj',
    2,47, 'Rock',
    '{"radioStationPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotacija": Težek} '
);

Cassandra

Izjave Cassandra INSERT so na videz zelo podobne izjavam PostgreSQL. Vendar pa obstaja ena velika razlika v semantiki. INSERT je dejansko operacija vstavitve v Cassandri, kjer je vrstica posodobljena z najnovejšimi vrednostmi, če vrstica že obstaja.

Enako kot zgoraj navedeni stavki PostgreSQL INSERT.

MongoDB

Čeprav je MongoDB tudi baza podatkov NoSQL, podobna Cassandri, njegovo delovanje vstavljanja nima enakega pomenskega vedenja kot Cassandra. MongoDB insert () nima možnosti vstavitve, zaradi česar je podoben PostgreSQL. Privzeto vedenje vstavka brez oznake _idspecified bo vodilo v nov dokument, dodan v zbirko.

db.music.insert ({
umetnik: "Nikogar, ki ga poznaš",
   songTitle: "Pokliči me danes",
    albumTitle: "Nekoliko znano",
    leto: 2015,
    cena: 2,14,
    žanr: "Država",
    oznake: {
Skladatelji: ["Smith", "Jones", "Davis"],
Dolžina sekunde: 214
}
   }
);
db.music.insert ({
    umetnik: "Nikogar, ki ga poznaš",
    songTitle: "My Dog Spot",
    albumTitle: "Hej zdaj",
    cena: 1,98,
    žanr: "Država",
    ocena kritik: 8.4
   }
);
db.music.insert ({
    umetnik: "The Acme Band",
    songTitle: "Pazi, svet",
    albumTitle: "Buck začne tukaj",
    cena: 0,99,
    žanr: "Rock"
   }
);
db.music.insert ({
    umetnik: "The Acme Band",
    songTitle: "Še vedno zaljubljen",
    albumTitle: "Buck začne tukaj",
    cena: 2,47,
    žanr: "Rock",
    oznake: {
        Predvajanje radia: ["KHCR", "KBQX", "WTNR", "WJJH"],
        tourDates: {
            Seattle: "20150625",
            Cleveland: "20150630"
        },
        vrtenje: "Težek"
}
    }
);

Poizvedovanje po tabeli

Verjetno je najpomembnejša razlika med SQL in NoSQL v smislu poizvedb o modeliranju v uporabi izrazov FROM in WHERE. SQL omogoča, da odlomka FROM vključuje več tabel in da je klavzula WHERE poljubne zapletenosti (vključno z JOIN-ji v tabelah). Vendar pa NoSQL nalaga strogo omejitev na stavku FROM, da je podana samo ena tabela in WHERE, da ima vedno naveden primarni ključ. Razlog za to je, da smo o novi učinkovitosti osredotočili NoSQL, o čemer smo govorili že prej, katerega namen je zmanjšati kakršno koli medsebojno mizo in medsebojno delovanje ključev. Takšna interakcija lahko uvede komunikacijo med vozlišči z visoko zakasnitvijo v odzivni čas, zato se je najbolje izogniti v celoti. Npr. Cassandra zahteva, da operaterji omejijo poizvedbe (samo =, IN, <,>, =>, <= so dovoljeni) na razdelitvenih ključih, razen če poizvedujejo po sekundarnem indeksu (kjer je dovoljen le = operator).

PostgreSQL

Sledijo 3 vrste poizvedb, ki jih lahko brez težav streže baza podatkov SQL.

  • Vrnite vse pesmi izvajalca
  • Vrnite vse skladbe izvajalca, ki se ujemajo s prvim delom naslova
  • Vrnite vse skladbe izvajalca z določeno besedo v naslovu, vendar le, če je cena nižja od 1,00
IZBERI * IZ glasbe
WHERE Artist = 'Nikogar, ki ga poznaš';
IZBERI * IZ glasbe
WHERE Artist = 'Nikogar ne poznate' IN SongTitle Všeč mi je 'Call%';
IZBERI * IZ glasbe
WHERE Artist = 'Nikogar ne poznaš' IN SongTitle Všeč mi je '% Today%'
IN Cena> 1,00;

Cassandra

Od zgoraj naštetih poizvedb PostgreSQL bo samo prva delovala s Cassandra nespremenjenim, saj operater LIKE ni dovoljen v stolpcih, kot je SongTitle. V tem primeru so dovoljeni samo operaterji = in IN.

IZBERI * IZ glasbe
WHERE Artist = 'Nikogar, ki ga poznaš';
IZBERI * IZ glasbe
WHERE Artist = 'Nikogar ne poznaš' IN SongTitle IN ('Call me Today', 'My Dog Spot')
IN Cena> 1,00;

MongoDB

Kot je prikazano v prejšnjih primerih, je glavna metoda za poizvedovanje po MongoDB metoda db.collection.find (). Ta metoda ustreza imenu zbirke (glasba v spodnjem primeru), ki jo je treba izrecno poizvedovati, zato je poizvedovanje po zbirkah izrecno prepovedano.

db.music.find ({
  umetnik: "Nikogar, ki ga poznaš"
 }
);
db.music.find ({
  umetnik: "Nikogar, ki ga poznaš",
  songTitle: / Pokliči /
 }
);

Preberite vse vrstice iz tabele

Branje vseh vrstic je preprosto poseben primer splošnega vzorca poizvedb, ki smo ga opazili prej.

PostgreSQL

IZBERI *
IZ glasbe;

Cassandra

Enako kot zgornji stavek PostgreSQL SELECT.

MongoDB

db.music.find ({});

Spremenite podatke v tabeli

PostgreSQL

PostgreSQL zagotavlja stavek UPDATE za spreminjanje podatkov. Ne dopušča nobene možnosti vstavitve, zato izjava ne bo uspela, če vrstica že ne obstaja v bazi podatkov.

UPDATE Glasba
SET žanr = 'Disco'
WHERE Artist = 'The Acme Band' IN SongTitle = 'Še vedno zaljubljen';

Cassandra

Cassandra ima tudi stavek UPDATE, podoben PostgreSQL. UPDATE tudi isto pomensko semantiko kot v stavku INSERT.

Enako kot zgoraj navedeni stavek PostgreSQL UPDATE.

MongoDB

Operacija MongoDB za posodobitev () lahko v celoti posodobi obstoječi dokument ali posodobi samo določena polja. Privzeto posodobi samo en dokument z izklopljeno semantiko. Posodobitve z več dokumenti in vedenje obnavljanja lahko vklopite tako, da v operaciji nastavite dodatne zastavice. Npr. spodnji primer posodablja žanr določenega izvajalca v pesmih izvajalca.

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

Brisanje podatkov iz tabele

PostgreSQL

IZPUST IZ glasbe
WHERE Artist = 'The Acme Band' IN SongTitle = 'Pazi, svet';

Cassandra

Enako kot zgoraj navedeni stavek PostgreSQL DELETE.

MongoDB

MongoDB ima dve vrsti operacij za obdelavo izbrisov dokumentov - deleteOne () / deleteMany () in remove (). Oba dokumenta izbrišeta, vendar imata različne rezultate vračanja.

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

Odstranite tabelo

PostgreSQL

DROP TABLE Glasba;

Cassandra

Enako kot zgoraj v stavku PostgreSQL DROP TABLE;

MongoDB

db.music.drop ();

Povzetek

Razprava med SQL in NoSQL že več kot desetletje divja. Obstajata dva vidika te razprave: arhitektura jedra baze podatkov (monolitna, transakcijski SQL v primerjavi s porazdeljenim, netraksacijski NoSQL) in pristop modeliranja podatkov (modelirajte svoje podatke v SQL v primerjavi z modeli vašimi poizvedbami v NoSQL).

S porazdeljeno, transakcijsko bazo podatkov, kot je YugaByte DB, lahko del razprave o arhitekturi jedra baze podatkov preprosto počivate. Ko količine podatkov presegajo tisto, kar je mogoče zapisati v eno vozlišče, mora biti popolnoma razporejena arhitektura, ki omogoča linearno skalabilnost pisanja z avtomatskim ostritvijo / ponovnim uravnoteženjem. Poleg tega, kot je opisano v tej objavi iz Googla Cloud, so zdaj splošno sprejete transakcijske, močno dosledne arhitekture, ki zagotavljajo višjo spretnost razvijalca in operacij kot neprevozeče in na koncu dosledne arhitekture.

V razpravi o modeliranju podatkov je pošteno reči, da sta tako SQL kot NoSQL modeliranje podatkov bistvena za vsako kompleksno aplikacijo v resničnem svetu. SQL-model-your-data pristop omogoča razvijalcem, da lažje poskrbijo za spreminjanje poslovnih zahtev, medtem ko pristop NoSQL-model-your-queries omogoča istim razvijalcem, da upravljajo z velikimi količinami podatkov z nizko zamudo in veliko prepustnostjo. Prav to je razlog, zakaj YugaByte DB izvaja tako SQL kot NoSQL API v skupnem jedru, namesto da bi spodbujal, da je en pristop strogo boljši od drugega. Poleg tega z zagotavljanjem združljivosti žic s priljubljenimi jeziki baz podatkov, vključno s PostgreSQL in Cassandra, YugaByte DB zagotavlja, da se razvijalci ne bodo naučili drugega jezika, da bi lahko izkoristili dobro razporejeno jedro baze podatkov.

Ta objava nam je pomagala razumeti, kako se osnove modeliranja podatkov razlikujejo med PostgreSQL, Cassandra in MongoDB. V naslednjih objavah v seriji se bomo podali v napredne koncepte za modeliranje podatkov, kot so indeksi, transakcije, JOIN-ji, direktive TTL in dokumenti JSON.

Kaj je naslednje?

  • Primerjajte YugaByte DB z bazami podatkov, kot so Amazon DynamoDB, Cassandra, MongoDB in Azure Cosmos DB.
  • Začnite z YugaByte DB na macOS, Linux, Docker in Kubernetes.
  • Pišite nam, če želite izvedeti več o licenciranju, cenah ali za načrtovanje tehničnega pregleda.

Prvotno objavljeno na spletnem dnevniku zbirke YugaByte.