ProHoster > Blog > Administrazioa > Datu-basearen diseinuaren oinarriak - PostgreSQL, Cassandra eta MongoDB alderatuz

Datu-basearen diseinuaren oinarriak - PostgreSQL, Cassandra eta MongoDB alderatuz

Kaixo lagunak. Maiatzeko oporraldiaren bigarren zatira abiatu baino lehen, zuekin partekatzen ari gara itzuli dugun materiala erritmoan korronte berri bat abiarazteko asmoz. "DBMS erlazionala".

Datu-basearen diseinuaren oinarriak - PostgreSQL, Cassandra eta MongoDB alderatuz

Aplikazioen garatzaileek denbora asko ematen dute datu-base operatibo anitz alderatzen, aurreikusitako lan-kargari ondoen egokitzen zaiona hautatzeko. Beharren artean datuen eredu sinplifikatua, transakzio-bermeak, irakurketa/idazketa errendimendua, eskala horizontala eta akatsen tolerantzia izan daitezke. Tradizionalki, aukera datu-baseen kategorian hasten da, SQL edo NoSQL, kategoria bakoitzak merkataritza-konpromiso-multzo argi bat aurkezten baitu. Errendimendu handia latentzia baxuari eta errendimendu handiari dagokionez, oro har, truke-off-eskakizun gisa ikusten da eta, beraz, ezinbestekoa da edozein lagin datu-baserako.

Artikulu honen helburua aplikazioen garatzaileei SQL eta NoSQLren artean aukera egokia egiten laguntzea da aplikazioen datuen modelaketaren testuinguruan. SQL datu-base bat aztertuko dugu, hots, PostgreSQL, eta bi NoSQL datu-base, Cassandra eta MongoDB, datu-baseen diseinuaren oinarriak estaltzeko, esate baterako, taulak sortzea, betetzea, taula bateko datuak irakurtzea eta ezabatzea. Hurrengo artikuluan, indizeak, transakzioak, JOIN, TTL zuzentarauak eta JSON oinarritutako datu-baseen diseinua aztertuko ditugu.

Zein da SQL eta NoSQLren arteko aldea?

SQL datu-baseek aplikazioaren malgutasuna areagotzen dute ACID transakzio-bermeen bidez, baita JOIN-ak erabiliz datuak ezusteko moduetan kontsultatzeko gaitasuna ere, dauden datu-base erlazional normalizatuen ereduen gainean.

Nodo bakarreko arkitektura monolitikoa eta erredundantziarako maisu-esklaboen erreplikazio-eredua erabiltzeagatik, SQL datu-base tradizionalek bi ezaugarri garrantzitsu falta dituzte: idazketa linealaren eskalagarritasuna (hau da, nodo anitzetan partizio automatikoa) eta datu-galera automatikoa/zero. Horrek esan nahi du jasotako datu-kopuruak ezin duela gainditu nodo bakar baten idazketa-sarrera maximoa. Gainera, aldi baterako datu-galera batzuk kontuan hartu behar dira akatsen tolerantzian (partekatutako ezer ez den arkitektura batean). Hemen kontuan izan behar duzu azken konpromisoak ez direla oraindik esklabo kopian islatu. Geldialdirik gabeko eguneratzeak ere zailak dira SQL datu-baseetan lortzea.

NoSQL datu-baseak normalean naturan banatzen dira, hau da. horietan, datuak ataletan banatu eta hainbat nodotan banatuta daude. Desnormalizazioa eskatzen dute. Horrek esan nahi du sartutako datuak ere hainbat aldiz kopiatu behar direla bidaltzen dituzun eskaera zehatzei erantzuteko. Helburu orokorra errendimendu handia lortzea da irakurtzeko garaian eskuragarri dauden zati kopurua murriztuz. Horrek esan nahi du NoSQL-k zure kontsultak modelatzea eskatzen dizula, eta SQLk zure datuak modelatzea eskatzen dizula.

NoSQL-k azpimarratzen du banatutako kluster batean errendimendu handia lortzea eta hori da datu-baseen diseinu-konpromiso askoren arrazoi nagusia, besteak beste, ACID transakzioak, JOIN eta bigarren mailako indize global koherenteak galtzea.

NoSQL datu-baseek idazketa-eskalagarritasun lineala eta akatsen tolerantzia handia eskaintzen duten arren, transakzio-bermeak galtzeak datu kritikoetarako desegokiak bihurtzen ditu.

Hurrengo taulak NoSQL-n datuen modelizazioa SQL-tik nola desberdina den erakusten du.

Datu-basearen diseinuaren oinarriak - PostgreSQL, Cassandra eta MongoDB alderatuz

SQL eta NoSQL: zergatik behar dira biak?

Erabiltzaile ugari dituzten benetako aplikazioak, hala nola Amazon.com, Netflix, Uber eta Airbnb, mota askotako zeregin konplexuak egiteaz arduratzen dira. Adibidez, Amazon.com bezalako merkataritza elektronikoko aplikazio batek datu arin eta oso sentikorrak gorde behar ditu, hala nola erabiltzaileei, produktuei, eskaerak, fakturei buruzko informazioa, eta datu astunak baina hain sentikorrak, hala nola produktuen iritziak, laguntza-mezuak, erabiltzaileen jarduerak. , erabiltzaileen iritziak eta gomendioak. Jakina, aplikazio hauek gutxienez SQL datu-base batean oinarritzen dira, gutxienez NoSQL datu-base batekin batera. Eskualde arteko eta mundu mailako sistemetan, NoSQL datu-baseak geo-banatutako cache gisa funtzionatzen du konfiantzazko iturri batean, SQL datu-basean, edozein eskualdetan funtzionatzen duen datuetarako.

Nola konbinatzen ditu YugaByte DB-k SQL eta NoSQL?

Erregistroetara bideratutako biltegiratze motor mistoan, auto-sharding, sharded banatutako adostasunaren erreplikazioa eta ACID banatutako transakzioak (Google Spanner-en inspiratuta), YugaByte DB aldi berean NoSQL (Cassandra & Redis) bateragarria den munduko lehen datu-basea da. ) eta SQL (PostgreSQL). Beheko taulan erakusten den bezala, YCQL, Cassandrarekin bateragarria den YugaByte DB APIak, ACID transakzio bakarreko eta anitzeko transakzioen kontzeptuak eta bigarren mailako indize globalak gehitzen ditu NoSQL API-ra, eta, horrela, NoSQL datu-base transakzionalen aroari hasiera emanez. Horrez gain, YCQL, PostgreSQL-rekin bateragarria den YugaByte DB API batek, idazketa linealaren eskalatze eta hutsegite automatikoaren kontzeptuak gehitzen ditu SQL APIra, banatutako SQL datu-baseak mundura ekarriz. YugaByte DB datu-basea berez transakzionala denez, orain NoSQL APIa datu kritikoen testuinguruan erabil daiteke.

Datu-basearen diseinuaren oinarriak - PostgreSQL, Cassandra eta MongoDB alderatuz

Lehen artikuluan esan bezala "YSQL aurkezten: PostgreSQL bateragarria den SQL API banatua YugaByte DBrako", YugaByte DB-n SQL edo NoSQLren arteko aukeraketa azpiko lan-kargaren ezaugarrien araberakoa da erabat:

  • Zure lan-karga nagusia gako anitzeko JOIN eragiketak badira, YSQL aukeratzerakoan, ulertu zure gakoak hainbat nodotan banatu daitezkeela, eta ondorioz NoSQL baino latentzia handiagoa eta/edo errendimendu txikiagoa izango da.
  • Bestela, aukeratu bi NoSQL APIetako bat, kontuan izanda errendimendu hobea lortuko duzula nodo batetik aldi berean emandako kontsulten ondorioz. YugaByte DB-k datu-base operatibo bakar gisa balio dezake lan-karga anitzak aldi berean kudeatu behar dituzten benetako aplikazio konplexuetarako.

Hurrengo ataleko Datuak modelatzeko laborategia PostgreSQL eta Cassandra bateragarriak diren YugaByte DB datu-baseen APIetan oinarritzen da, jatorrizko datu-baseetan ez bezala. Ikuspegi honek datu-baseen kluster bereko bi API ezberdinekin (bi ataka ezberdinetan) elkarreragiteko erraztasuna azpimarratzen du, bi datu-base ezberdinen kluster guztiz independenteak erabiltzearen aldean.
Hurrengo ataletan, datu-modelaketa laborategiari begiratu bat emango diogu datu-baseen aldea eta ezaugarri komun batzuk azaltzeko.

Datuak modelatzeko laborategia

Datu-basearen instalazioa

Datu-ereduen diseinuan arreta jarrita (inplementazio-arkitektura konplexuak baino), datu-baseak Docker edukiontzietan instalatuko ditugu tokiko makinan eta, ondoren, haiekin elkarreragin egingo dugu dagozkien komando lerroko shell-ak erabiliz.

PostgreSQL eta Cassandra bateragarria, YugaByte DB datu-basea

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

Komando-lerroko sarbidea

Konektatu gaitezen datu-baseetara dagozkien APIetarako komando lerroko shell-a erabiliz.

PostgreSQL

psql PostgreSQL-rekin elkarreragiteko komando-lerroko shell bat da. Erabilera errazteko, YugaByte DB psql-ekin dator bin karpetan.

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

Cassandra

sqlsh komando-lerroko shell bat da Cassandra eta bere datu-base bateragarriak CQL (Cassandra Query Language) bidez elkarreragiteko. Erabilera errazteko, YugaByte DB dator cqlsh katalogoan bin.
Kontuan izan CQL SQL-n inspiratu zela eta taula, errenkada, zutabe eta indizeen antzeko kontzeptuak dituela. Hala ere, NoSQL lengoaia gisa, murrizketa multzo jakin bat gehitzen du, eta horietako gehienak beste artikulu batzuetan ere landuko ditugu.

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

MongoDB

mongo MongoDB-rekin elkarreragiteko komando lerroko shell bat da. MongoDB instalazioaren bin direktorioan aurki daiteke.

docker exec -it my-mongo bash 
cd bin
mongo

Sortu taula bat

Orain datu-basearekin elkarreragin dezakegu komando lerroa erabiliz hainbat eragiketa egiteko. Hasteko, artista ezberdinek idatzitako abestiei buruzko informazioa gordetzen duen taula bat sortzen. Abesti hauek album baten parte izan daitezke. Abestiaren aukerako atributuak ere kaleratze urtea, prezioa, generoa eta balorazioa dira. Etorkizunean beharrezkoak izan daitezkeen atributu gehigarriak kontuan hartu behar ditugu "etiketak" eremuaren bidez. Erdiegituratutako datuak gako-balio bikote gisa gorde ditzake.

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

Cassandra-n taula bat sortzea PostgreSQL-ren oso antzekoa da. Desberdintasun nagusietako bat osotasun-murriztapenik ez izatea da (NOT NULL bezalakoa), baina hau aplikazioaren ardura da, ez NoSQL datu-basearena.. Gako nagusiak partizio-gako batek (Artistaren zutabea beheko adibidean) eta multzokatze-zutabe multzo batek (SongTitle zutabea beheko adibidean) osatzen dute. Partizio-gakoak errenkada zein partizio/zatitan jarri zehazten du, eta multzokatze-zutabeek datuak uneko zatiaren barruan nola antolatu behar diren adierazten dute.

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-k datuak datu-baseetan antolatzen ditu (Database) (Keyspace Cassandraren antzekoa), non Dokumentuak (taula bateko errenkaden antzekoak) dituzten Bildumak (taulen antzekoak) dauden. MongoDB-n, funtsean, ez dago hasierako eskema bat definitu beharrik. Taldea "erabil ezazu datu-basea", behean agertzen dena, datu-basea instantziatzen du lehen deian eta sortu berri den datu-basearen testuingurua aldatzen du. Bildumak ere ez dira esplizituki sortu behar, automatikoki sortzen dira, lehen dokumentua bilduma berri bati gehitzen zaionean. Kontuan izan MongoDB-k proba-datu-base bat erabiltzen duela lehenespenez, beraz, datu-base zehatz bat zehaztu gabe bilketa-mailako edozein eragiketa bertan egingo da lehenespenez. 

use myNewDatabase;

Taula bati buruzko informazioa lortzea
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;

Datuak taula batean sartzea
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

Adierazpen orokorra INSERT Cassandra-n PostgreSQL-ekoaren oso antzekoa da. Hala ere, alde handi bat dago semantikan. Kasandran INSERT operazio bat da benetan UPSERT, non azken balioak gehitzen zaizkion kateari, katea jada existitzen bada.

Datuen sarrera PostgreSQL-ren antzekoa da INSERT arriba,ru

.

MongoDB

MongoDB Cassandra bezalako NoSQL datu-basea bada ere, bere datuak sartzeko eragiketak ez du zerikusirik Cassandraren portaera semantikoarekin. MongoDB-n txertatu () ez dauka aukerarik UPSERT, eta horrek PostgreSQL-ren antzekoa egiten du. Datu lehenetsiak gehitzea gabe _idspecified bildumari dokumentu berri bat gehitzea eragingo du.

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"
}
}
);

Taularen kontsulta

Agian SQL eta NoSQL-ren arteko alderik esanguratsuena kontsultari dagokionez, erabilera da FROM ΠΈ WHERE. SQL-k adierazpenaren ondoren onartzen du FROM hautatu hainbat taula, eta adierazpen bat WHERE edozein konplexutasuna izan daiteke (eragiketak barne JOIN mahaien artean). Hala ere, NoSQL-k muga gogorra ezarri ohi du FROM, eta zehaztutako taula bakarrarekin lan egin, eta barruan WHERE, gako nagusia zehaztu behar da beti. Horrek lehenago hitz egin dugun NoSQL errendimenduaren bultzadarekin lotzen du. Desio honek edozein taula gurutzatu eta gako gurutzatutako elkarrekintzan ahalik eta murrizketa guztiak eragiten ditu. Nodoen arteko komunikazioan atzerapen handia sar dezake eskaera bati erantzuten dionean eta, beraz, hobe da orokorrean saihestea. Adibidez, Cassandra-k kontsultak operadore jakin batzuetara mugatzea eskatzen du (soilik =, IN, <, >, =>, <=) partizio-gakoetan, bigarren indizea eskatzen denean izan ezik (= operadorea bakarrik onartzen da hemen).

PostgreSQL

Jarraian, SQL datu-base batek erraz exekuta daitezkeen hiru kontsulten adibide dira.

  • Erakutsi artistaren abesti guztiak;
  • Bistaratu izenburuaren lehen zatiarekin bat datozen artistaren abesti guztiak;
  • Bistaratu izenburuan hitz jakin bat duten eta 1.00 baino prezio txikiagoa duten artista baten abesti guztiak. 
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

Goian zerrendatutako PostgreSQL kontsultetatik, lehenengoak bakarrik funtzionatuko du aldatu gabe Cassandran, operadoreak geroztik LIKE ezin da aplikatu zutabeak multzokatzeari SongTitle. Kasu honetan, operadoreak bakarrik onartzen dira = ΠΈ 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

Aurreko adibideetan erakusten den bezala, MongoDB-n kontsultak sortzeko metodo nagusia da db.collection.find(). Metodo honek esplizituki biltzen du bildumaren izena (music beheko adibidean), beraz, ez da onartzen hainbat bilduma kontsultatzea.

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

Taula baten errenkada guztiak irakurtzea

Errenkada guztiak irakurtzea lehen aipatu dugun kontsulta ereduaren kasu berezi bat besterik ez da.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Goiko PostgreSQL adibidearen antzekoa.

MongoDB

db.music.find( {} );

Taula bateko datuak editatzea

PostgreSQL

PostgreSQL-k argibideak ematen ditu UPDATE datuak aldatzeko. Ez du aukerarik UPSERT, beraz, adierazpen honek huts egingo du errenkada datu-basean ez badago.

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

Cassandra

Cassandra du UPDATE PostgreSQL-ren antzekoa. UPDATE semantika bera du UPSERT, antzekoa INSERT.

Goiko PostgreSQL adibidearen antzekoa.

MongoDB
eragiketa update () MongoDB-n lehendik dagoen dokumentu bat guztiz egunera dezake edo eremu jakin batzuk soilik eguneratu ditzake. Lehenespenez, semantika desgaituta duen dokumentu bakarra eguneratzen du UPSERT. Freskatu hainbat dokumentu eta antzeko portaera UPSERT Eragiketarako bandera gehigarriak ezarriz aplika daiteke. Beheko adibidean adibidez, artista jakin baten generoa bere abestiaren bidez eguneratzen da.

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

Taula batetik datuak kentzea

PostgreSQL

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

Cassandra

Goiko PostgreSQL adibidearen antzekoa.

MongoDB

MongoDB-k bi eragiketa mota ditu dokumentuak ezabatzeko - deleteOne() /deleteMany() ΠΈ kendu (). Bi motak dokumentuak ezabatzen dituzte baina emaitza desberdinak itzultzen dituzte. 

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

Ezabatu taula bat

PostgreSQL

DROP TABLE Music;

Cassandra

Goiko PostgreSQL adibidearen antzekoa.

MongoDB

db.music.drop();

Ondorioa

SQL eta NoSQLren artean aukeratzearen inguruko eztabaidak 10 urte baino gehiago daramatza. Eztabaida honetan bi alderdi nagusi daude: datu-base-motorren arkitektura (monolitikoa, SQL transakzionala vs banatua, NoSQL ez-transakzionala) eta datu-baseen diseinuaren ikuspegia (zure datuak SQL-n modelatzea vs zure kontsultak NoSQL-en modelatzea).

YugaByte DB bezalako transakzio datu-base banatu batekin, datu-baseen arkitekturaren eztabaida erraz uxatu daiteke. Datu-bolumenak nodo bakarrean idatz daitekeena baino handiagoak diren heinean, idazketa linealaren eskalagarritasuna onartzen duen erabat banatutako arkitektura bat beharrezkoa da zatiketa/berreoreka automatikoarekin.

Gainera, artikuluren batean esaten den bezala Google Cloud,Arkitektura transakzionalak, koherentzia handikoak, gaur egun gehiago erabiltzen dira garapen arintasun hobea emateko transakziozkoak ez diren arkitekturak, azkenean koherenteak baino.

Datu-baseen diseinuari buruzko eztabaidara itzuliz, bidezkoa da esatea bi diseinu ikuspegiak (SQL eta NoSQL) beharrezkoak direla mundu errealeko edozein aplikazio konplexurako. SQLren "datuen modelizazioa" ikuspegiari esker, garatzaileek errazago bete ditzakete negozio-baldintzak, eta NoSQL-ren "kontsulta modelizazioa" ikuspegiari esker, garatzaile horiei datu kopuru handiak latentzia baxuarekin eta errendimendu handian kudeatzeko aukera ematen die. Horregatik YugaByte DB-k SQL eta NoSQL APIak nukleo komun batean eskaintzen ditu, eta ez du planteamenduetako bat defendatzen. Horrez gain, datu-base-lengoai ezagunekin bateragarritasuna eskainiz, PostgreSQL eta Cassandra barne, YugaByte DB-k ziurtatzen du garatzaileek ez dutela beste hizkuntza bat ikasi behar banatutako datu base-motor oso koherente batekin lan egiteko.

Artikulu honetan, datu-baseen diseinuaren oinarriak PostgreSQL, Cassandra eta MongoDB artean nola desberdinak diren aztertu dugu. Hurrengo artikuluetan, diseinu-kontzeptu aurreratuetan murgilduko gara, hala nola indizeak, transakzioak, JOIN, TTL zuzentarauak eta JSON dokumentuak.

Asteburu ona opa dizuegu eta gonbidatzen zaituztegu doako webinarra, maiatzaren 14an egingo dena.

Iturria: www.habr.com

Gehitu iruzkin berria