Hei ystävät. Ennen lähtöä toukokuun lomien toiselle osalle jaamme kanssasi materiaalin, jonka olemme kääntäneet odottaessamme uuden streamin käynnistämistä .
Sovelluskehittäjät käyttävät paljon aikaa useiden toiminnallisten tietokantojen vertaamiseen valitakseen niistä, jotka sopivat parhaiten suunniteltuun työmäärään. Tarpeita voivat olla yksinkertaistettu tietojen mallinnus, tapahtumatakaukset, luku-/kirjoitussuorituskyky, vaakasuuntainen skaalaus ja vikasietoisuus. Perinteisesti valinta alkaa tietokantakategorialla, SQL:llä tai NoSQL:llä, koska jokaisessa kategoriassa on selkeät kompromissit. Korkea suorituskyky alhaisen viiveen ja suuren suorituskyvyn osalta nähdään yleensä ei-vaihtovaatimuksena, ja siksi se on olennainen kaikissa näytetietokannassa.
Tämän artikkelin tarkoituksena on auttaa sovelluskehittäjiä tekemään oikea valinta SQL:n ja NoSQL:n välillä sovellustietojen mallinnuksen yhteydessä. Tarkastelemme yhtä SQL-tietokantaa, nimittäin PostgreSQL-tietokantaa, ja kahta NoSQL-tietokantaa, Cassandraa ja MongoDB:tä, kattaaksemme tietokannan suunnittelun perusteet, kuten taulukoiden luomisen, täyttämisen, tietojen lukemisen taulukosta ja sen poistamisen. Seuraavassa artikkelissa tarkastelemme varmasti indeksejä, tapahtumia, JOINeja, TTL-käskyjä ja JSON-pohjaista tietokannan suunnittelua.
Mitä eroa on SQL:llä ja NoSQL:llä?
SQL-tietokannat lisäävät sovellusten joustavuutta ACID-tapahtumien takuiden avulla sekä niiden kykyä kysellä tietoja JOIN-koodien avulla odottamattomilla tavoilla olemassa olevien normalisoitujen relaatiotietokantamallien lisäksi.
Perinteisistä SQL-tietokannoista puuttuu kaksi tärkeää ominaisuutta monoliittisen/yksisolmun arkkitehtuuri ja isäntä-orja-replikointimallin ansiosta - lineaarinen kirjoitusskaalautuvuus (eli automaattinen jakaminen useisiin solmuihin) ja automaattinen/nolla datahäviö. Tämä tarkoittaa, että vastaanotetun tiedon määrä ei voi ylittää yksittäisen solmun suurinta kirjoituskapasiteettia. Lisäksi on otettava huomioon jokin tilapäinen tietojen menetys vikasietoisuuden vuoksi (ei-jaetussa arkkitehtuurissa). Tässä sinun on pidettävä mielessä, että viimeaikaiset sitoumukset eivät ole vielä näkyneet orjakopiossa. Myöskään seisokkipäivityksiä on vaikea saavuttaa SQL-tietokannassa.
NoSQL-tietokannat ovat tyypillisesti hajautettuja luonnossa, ts. niissä data on jaettu osiin ja jaettu useisiin solmuihin. Ne vaativat denormalisointia. Tämä tarkoittaa, että syötetyt tiedot on myös kopioitava useita kertoja, jotta voit vastata lähettämiisi pyyntöihin. Yleisenä tavoitteena on saada korkea suorituskyky vähentämällä lukuaikana käytettävissä olevien sirpaleiden määrää. Tämä tarkoittaa, että NoSQL vaatii sinua mallintamaan kyselysi, kun taas SQL vaatii sinua mallintamaan tietosi.
NoSQL korostaa korkean suorituskyvyn saavuttamista hajautetussa klusterissa, ja tämä on tärkein syy monille tietokannan suunnittelun kompromisseille, joihin kuuluu ACID-tapahtumien, JOIN-toimintojen ja johdonmukaisten globaalien toissijaisten indeksien menettäminen.
On olemassa mielipide, että vaikka NoSQL-tietokannat tarjoavat lineaarisen kirjoitusskaalautuvuuden ja korkean vikasietokyvyn, transaktiotakuiden menetys tekee niistä sopimattomia kriittisille tiedoille.
Seuraava taulukko näyttää, kuinka NoSQL:n tietojen mallinnus eroaa SQL:stä.
SQL ja NoSQL: Miksi molempia tarvitaan?
Tosielämän sovellukset, joissa on paljon käyttäjiä, kuten Amazon.com, Netflix, Uber ja Airbnb, vastaavat erilaisten monimutkaisten tehtävien suorittamisesta. Esimerkiksi Amazon.comin kaltaisen verkkokauppasovelluksen on tallennettava kevyitä, erittäin arkaluontoisia tietoja, kuten tietoja käyttäjistä, tuotteista, tilauksista, laskuista, sekä raskaita mutta vähemmän arkaluonteisia tietoja, kuten tuotearvioita, tukiviestejä. , käyttäjien arvosteluja ja suosituksia. Luonnollisesti nämä sovellukset käyttävät vähintään yhtä SQL-tietokantaa ja vähintään yhtä NoSQL-tietokantaa. Alueidenvälisissä ja globaaleissa järjestelmissä NoSQL-tietokanta toimii maantieteellisesti hajautettuna välimuistina luotettavaan lähteeseen, SQL-tietokantaan, tallennetuille tiedoille, jotka toimivat millä tahansa alueella.
Kuinka YugaByte DB yhdistää SQL:n ja NoSQL:n?
YugaByte DB on rakennettu lokisuuntautuneeseen sekatallennusmoottoriin, automaattiseen jakamiseen, hajautettuun hajautettuun konsensusreplikointiin ja ACID-hajautettuihin tapahtumiin (Google Spannerin inspiroima), ja se on maailman ensimmäinen avoimen lähdekoodin tietokanta, joka on samanaikaisesti NoSQL (Cassandra & Redis) -yhteensopiva. ) ja SQL (PostgreSQL). Kuten alla olevasta taulukosta näkyy, YCQL, Cassandra-yhteensopiva YugaByte DB -sovellusliittymä, lisää yhden ja usean avaimen ACID-tapahtumien ja globaalien toissijaisten indeksien käsitteet NoSQL-sovellusliittymään, mikä avaa tapahtumakohtaisten NoSQL-tietokantojen aikakauden. Lisäksi YCQL, PostgreSQL:n kanssa yhteensopiva YugaByte DB API, lisää lineaarisen kirjoitusskaalauksen ja automaattisen vikasietoisuuden käsitteet SQL API:hen tuoden hajautetut SQL-tietokannat maailmalle. Koska YugaByte DB -tietokanta on luonnostaan transaktiopohjainen, NoSQL API:ta voidaan nyt käyttää kriittisten tietojen yhteydessä.
Kuten artikkelissa aiemmin todettiin , valinta SQL:n tai NoSQL:n välillä YugaByte DB:ssä riippuu täysin taustalla olevan työkuorman ominaisuuksista:
- Jos ensisijainen työkuormasi ovat usean avaimen JOIN-toiminnot, YSQL:ää valitessasi ota huomioon, että avaimesi voivat olla hajallaan useiden solmujen kesken, mikä johtaa korkeampaan latenssiin ja/tai pienempään suorituskykyyn kuin NoSQL.
- Muussa tapauksessa valitse jompikumpi kahdesta NoSQL-sovellusliittymästä pitäen mielessä, että saat paremman suorituskyvyn yhdestä solmusta kerrallaan toimitettujen kyselyjen ansiosta. YugaByte DB voi toimia yhtenä toimivana tietokantana todellisille monimutkaisille sovelluksille, joiden on hallittava useita työkuormia samanaikaisesti.
Seuraavan osan tietojen mallinnuslaboratorio perustuu PostgreSQL- ja Cassandra-yhteensopiviin YugaByte DB -tietokantasovellusliittymiin, toisin kuin alkuperäiset tietokannat. Tämä lähestymistapa korostaa saman tietokantaklusterin kahden eri API:n (kahdessa eri portissa) vuorovaikutuksen helppoutta, toisin kuin kahden eri tietokannan täysin itsenäisten klustereiden käyttäminen.
Seuraavissa osioissa tarkastellaan Data Modeling Labia havainnollistaaksemme kyseisten tietokantojen eroja ja joitain yhteisiä piirteitä.
Datan mallinnuslaboratorio
Tietokantojen asentaminen
Koska painopiste on tietomallien suunnittelussa (monimutkaisten käyttöönottoarkkitehtuurien sijaan), asennamme tietokannat Docker-säilöihin paikalliselle koneelle ja olemme sitten vuorovaikutuksessa niiden kanssa käyttämällä vastaavia komentorivin kuoria.
PostgreSQL- ja Cassandra-yhteensopiva, YugaByte DB -tietokanta
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_postgresMongoDB
docker run --name my-mongo -d mongo:latestPääsy komentoriville
Muodostetaan yhteys tietokantoihin vastaavien sovellusliittymien komentoriviltä.
PostgreSQL
on komentorivin kuori vuorovaikutukseen PostgreSQL:n kanssa. Käytön helpottamiseksi YugaByte DB:n mukana tulee psql suoraan bin-kansiossa.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
on komentorivin kuori vuorovaikutukseen Cassandran ja sen yhteensopivien tietokantojen kanssa CQL:n (Cassandra Query Language) kautta. YugaByte DB:n mukana tulee käytön helppous cqlsh luettelossa bin.
Huomaa, että CQL on saanut inspiraationsa SQL:stä ja siinä on samanlaiset taulukot, rivit, sarakkeet ja indeksit. NoSQL-kielenä se kuitenkin lisää tietyn joukon rajoituksia, joista useimmat käsittelemme myös muissa artikkeleissa.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
on komentorivin kuori vuorovaikutukseen MongoDB:n kanssa. Se löytyy MongoDB-asennuksen bin-hakemistosta.
docker exec -it my-mongo bash
cd bin
mongoLuo taulukko
Nyt voimme olla vuorovaikutuksessa tietokannan kanssa suorittaaksemme erilaisia toimintoja komentorivin avulla. Aloitetaan luomalla taulukko, joka tallentaa tietoa eri artistien kirjoittamista kappaleista. Nämä kappaleet voivat olla osa albumia. Myös kappaleen valinnaisia määritteitä ovat julkaisuvuosi, hinta, genre ja luokitus. Meidän on otettava huomioon lisäattribuutit, joita voidaan tarvita tulevaisuudessa "tunnisteet"-kentän kautta. Se voi tallentaa puolistrukturoitua dataa avain-arvo-pareina.
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
Taulukon luominen Cassandrassa on hyvin samanlaista kuin PostgreSQL. Yksi tärkeimmistä eroista on eheysrajoitusten puuttuminen (kuten NOT NULL), mutta tämä on sovelluksen, ei NoSQL-tietokannan, vastuulla.. Ensisijainen avain koostuu osioavaimesta (Artist-sarake alla olevassa esimerkissä) ja joukosta klusterisarakkeita (SongTitle-sarake alla olevassa esimerkissä). Osioavain määrittää, mihin osioon/sirpaleeseen rivi asetetaan, ja klusterisarakkeet osoittavat, kuinka tiedot tulee järjestää nykyisessä sirpaleessa.
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 järjestää tiedot tietokantoiksi (Database) (samanlainen kuin Keyspace Cassandrassa), joissa on kokoelmia (kokoelmia) (kuten taulukoita), jotka sisältävät asiakirjoja (Documents) (samanlaiset kuin taulukon rivit). MongoDB:ssä ei periaatteessa vaadita skeeman alkumäärittelyä. Tiimi "käytä tietokantaa", joka näkyy alla, instantoi tietokannan ensimmäisessä kutsussa ja muuttaa juuri luodun tietokannan kontekstia. Edes kokoelmia ei tarvitse luoda erikseen, ne luodaan automaattisesti, juuri kun ensimmäinen dokumentti lisätään uuteen kokoelmaan. Huomaa, että MongoDB käyttää oletusarvoisesti testitietokantaa, joten kaikki kokoelmatason toiminnot ilman tiettyä tietokantaa suoritetaan oletuksena siinä.
use myNewDatabase;Tietojen saaminen pöydästä
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;Tietojen syöttäminen taulukkoon
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
Yleensä ilmaisu INSERT Cassandrassa näyttää hyvin samanlaiselta kuin PostgreSQL:ssä. Semantiikassa on kuitenkin yksi suuri ero. Cassandrassa INSERT on itse asiassa operaatio UPSERT, jossa riville lisätään viimeiset arvot, jos rivi on jo olemassa.
Tiedonsyöttö on samanlainen kuin PostgreSQL
INSERTedellä
.
MongoDB
Vaikka MongoDB on NoSQL-tietokanta, kuten Cassandra, sen lisäystoiminnolla ei ole mitään yhteistä Cassandran semanttisen käyttäytymisen kanssa. MongoDB:ssä ei ole mahdollisuutta UPSERT, mikä tekee siitä samanlaisen kuin PostgreSQL. Oletustietojen lisääminen ilman _idspecified johtaa uuden asiakirjan lisäämiseen kokoelmaan.
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"
}
}
);
Taulukkokysely
Ehkä merkittävin ero SQL:n ja NoSQL:n välillä kyselyn kannalta on sen käyttö FROM и WHERE. SQL sallii lausekkeen jälkeen FROM valitse useita taulukoita ja lauseke WHERE voivat olla mitä tahansa monimutkaisia (mukaan lukien toiminnot JOIN taulukoiden välissä). NoSQL:llä on kuitenkin taipumus asettaa kovat rajat FROM, ja työskentele vain yhden määritetyn taulukon kanssa ja sisään WHERE, ensisijainen avain on aina määritettävä. Tämä johtuu halusta parantaa NoSQL:n suorituskykyä, josta puhuimme aiemmin. Tämä toive johtaa kaikkiin mahdollisiin välilehtien ja avainten välisten vuorovaikutusten vähentämiseen. Se voi aiheuttaa suuren viiveen solmujen välisessä viestinnässä, kun vastataan pyyntöön, ja siksi sitä on periaatteessa parasta välttää. Esimerkiksi Cassandra vaatii pyyntöjen rajoittamista tiettyihin operaattoreihin (vain sallittu =, IN, <, >, =>, <=).
PostgreSQL
Alla on kolme esimerkkiä kyselyistä, jotka voidaan helposti suorittaa SQL-tietokannan avulla.
- Näytä kaikki esittäjän kappaleet;
- Näytä kaikki esittäjän kappaleet, jotka vastaavat nimen ensimmäistä osaa;
- Näytä kaikki esittäjän kappaleet, joiden nimessä on tietty sana ja joiden hinta on alle 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
Yllä luetelluista PostgreSQL-kyselyistä vain ensimmäinen toimii Cassandrassa ilman muutoksia, koska käsky LIKE ei voida soveltaa klusterisarakkeisiin, kuten SongTitle. Tässä tapauksessa vain operaattorit ovat sallittuja = и 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
Kuten edellisissä esimerkeissä näkyy, tärkein menetelmä kyselyjen luomiseksi MongoDB:ssä on . Tämä menetelmä sisältää eksplisiittisesti kokoelman nimen (music alla olevassa esimerkissä), joten useiden kokoelmien kyselyä ei sallita.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Taulukon kaikkien rivien lukeminen
Kaikkien rivien lukeminen on yksinkertaisesti aiemmin tarkastelemamme kyselymallin erikoistapaus.
PostgreSQL
SELECT *
FROM Music;Cassandra
Samanlainen kuin yllä oleva PostgreSQL-esimerkki.
MongoDB
db.music.find( {} );Tietojen muokkaaminen taulukossa
PostgreSQL
PostgreSQL tarjoaa lausunnon UPDATE muuttaaksesi tietoja. Hänellä ei ole mahdollisuutta UPSERT, joten tämä lausunto epäonnistuu, jos rivi ei ole enää tietokannassa.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandralla on UPDATE samanlainen kuin PostgreSQL. UPDATE on sama semantiikka UPSERT, samanlainen INSERT.
Samanlainen kuin yllä oleva PostgreSQL-esimerkki.
MongoDB
Toiminta MongoDB:ssä voi päivittää olemassa olevan asiakirjan kokonaan tai päivittää vain tietyt kentät. Oletuksena se päivittää vain yhden asiakirjan, jonka semantiikka on poistettu käytöstä UPSERT. Päivitä useita asiakirjoja ja muuta vastaavaa toimintaa UPSERT voidaan käyttää asettamalla lisälippuja toiminnolle. Kuten esimerkiksi alla olevassa esimerkissä, hänen kappaleensa päivittää tietyn artistin genren.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Tietojen poistaminen taulukosta
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Samanlainen kuin yllä oleva PostgreSQL-esimerkki.
MongoDB
MongoDB:ssä on kahdenlaisia toimenpiteitä asiakirjojen poistamiseen − и . Molemmat tyypit poistavat asiakirjoja, mutta palauttavat erilaisia tuloksia.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Taulukon poistaminen
PostgreSQL
DROP TABLE Music;Cassandra
Samanlainen kuin yllä oleva PostgreSQL-esimerkki.
MongoDB
db.music.drop();Johtopäätös
Keskustelua SQL:n ja NoSQL:n välisestä valinnasta on käyty yli 10 vuoden ajan. Tässä keskustelussa on kaksi pääasiallista näkökohtaa: tietokantamoottorin arkkitehtuuri (monoliittinen, tapahtumaan perustuva SQL vs. hajautettu, ei-transaktioon perustuva NoSQL) ja lähestymistapa tietokannan suunnitteluun (tietomallinnus SQL:ssä vs. kyselyjesi mallintaminen NoSQL:ssä).
Hajautetun tapahtumatietokannan, kuten YugaByte DB:n, avulla tietokanta-arkkitehtuurikeskustelu voidaan helposti hälventää. Kun tietomäärät kasvavat suurempia kuin yhteen solmuun voidaan kirjoittaa, täysin hajautettu arkkitehtuuri, joka tukee lineaarista kirjoitusskaalautuvuutta automaattisella sharing/rebalancingilla, tulee välttämättömäksi.
Sen lisäksi, mitä yhdessä artikkelissa sanottiin , transaktioihin perustuvia, vahvasti johdonmukaisia arkkitehtuureja on nyt otettu laajemmin käyttöön paremman kehitysjoustavuuden takaamiseksi kuin ei-transaktioihin perustuvat, lopulta johdonmukaiset arkkitehtuurit.
Palatakseni keskusteluun tietokannan suunnittelusta, on reilua sanoa, että molemmat suunnittelulähestymistavat (SQL ja NoSQL) ovat välttämättömiä missä tahansa monimutkaisessa reaalimaailmassa. SQL-tietomallinnuksen avulla kehittäjät voivat vastata muuttuviin liiketoimintavaatimuksiin helpommin, kun taas NoSQL:n "kyselymallinnuksen" avulla samat kehittäjät voivat käyttää suuria tietomääriä alhaisella viiveellä ja suurella suorituskyvyllä. Tästä syystä YugaByte DB tarjoaa SQL- ja NoSQL-sovellusliittymiä yhteisessä ytimessä, eikä se suosittele mitään näistä lähestymistavoista. Lisäksi YugaByte DB tarjoaa yhteensopivuuden suosittujen tietokantakielten kanssa, mukaan lukien PostgreSQL ja Cassandra, ja se varmistaa, että kehittäjien ei tarvitse opetella toista kieltä voidakseen työskennellä hajautetun, vahvasti yhtenäisen tietokantamoottorin kanssa.
Tässä artikkelissa tarkastelimme, kuinka tietokannan suunnittelun perusteet eroavat PostgreSQL:n, Cassandran ja MongoDB:n välillä. Seuraavissa artikkeleissa sukeltamme edistyneisiin suunnittelukonsepteihin, kuten indekseihin, tapahtumiin, JOIN:iin, TTL-käskyihin ja JSON-dokumentteihin.
Toivotamme sinulle hyvää viikonloppua ja kutsumme sinut mukaan joka järjestetään 14. toukokuuta.
Lähde: will.com