ProHoster > Blog > Administratioun > Datebank Design Fundamentals - Vergläicht PostgreSQL, Cassandra a MongoDB

Datebank Design Fundamentals - Vergläicht PostgreSQL, Cassandra a MongoDB

Moien, Frënn. Ier Dir op den zweeten Deel vun der Mee Vakanz fort geet, deele mir Iech d'Material dat mir iwwersat hunn an Erwaardung op de Start vun engem neie Stream um Cours "Relational DBMS".

Datebank Design Fundamentals - Vergläicht PostgreSQL, Cassandra a MongoDB

Applikatioun Entwéckler verbréngen vill Zäit fir verschidde operationell Datenbanken ze vergläichen fir deen ze wielen deen am Beschten déi geplangten Aarbechtslaascht passt. Bedierfnesser kënne vereinfacht Datemodelléierung, Transaktiounsgarantien, Lies- / Schreifleistung, horizontale Skaléieren a Feelertoleranz enthalen. Traditionell fänkt d'Wiel mat der Datebankkategorie un, SQL oder NoSQL, well all Kategorie e klore Set vu Ofwäichunge presentéiert. Héich Leeschtung a punkto gerénger latency an héijen Duerchgang gëtt allgemeng als net-trade-off Ufuerderung ugesinn an ass dofir wesentlech fir all Probe-Datebank.

Den Zweck vun dësem Artikel ass d'Applikatioun Entwéckler ze hëllefen déi richteg Wiel tëscht SQL an NoSQL am Kontext vun der Applikatiounsdatenmodelléierung ze maachen. Mir kucken op eng SQL Datebank, nämlech PostgreSQL, an zwou NoSQL Datenbanken, Cassandra a MongoDB, fir d'Basis vum Datebankdesign ze decken, sou wéi Tabellen erstellen, se populéieren, Daten aus enger Tabell liesen an se läschen. Am nächsten Artikel wäerte mir sécher sinn Indexen, Transaktiounen, JOINs, TTL Direktiven, an JSON-baséiert Datebankdesign ze kucken.

Wat ass den Ënnerscheed tëscht SQL an NoSQL?

SQL Datenbanken erhéijen d'Applikatiounsflexibilitéit duerch ACID Transaktiounsgarantien, souwéi hir Fäegkeet fir Daten ze froen mat JOINs op onerwaarte Weeër uewen op existent normaliséierter relational Datebankmodeller.

Wéinst hirer monolithescher / eenzeger Node Architektur an der Notzung vun engem Master-Sklave Replikatiounsmodell fir Redundanz, fehlen traditionell SQL Datenbanken zwee wichteg Features - linear Schreif Skalierbarkeet (dh automatesch Partitionéierung iwwer verschidde Noden) an automatesch / Null Dateverloscht. Dëst bedeit datt d'Quantitéit vun den empfangenen Donnéeën net de maximale Schreifduerchgang vun engem eenzegen Node kann iwwerschreiden. Zousätzlech, muss e puer temporärer Dateverloscht a Feeler Toleranz berücksichtegt ginn (an enger gemeinsamer-näischt Architektur). Hei musst Dir am Kapp behalen datt rezent Verpflichtungen nach net an der Sklave Kopie reflektéiert goufen. Net-Downtime Updates sinn och schwéier an SQL Datenbanken z'erreechen.

NoSQL Datenbanken ginn normalerweis vun Natur verdeelt, d.h. an hinnen, Daten sinn an Sektiounen ënnerdeelt an iwwer e puer Wirbelen verdeelt. Si erfuerderen Denormaliséierung. Dëst bedeit datt déi aginn Donnéeën och e puer Mol musse kopéiert ginn fir op déi spezifesch Ufroen ze reagéieren déi Dir schéckt. D'allgemeng Zil ass eng héich Leeschtung ze kréien duerch d'Reduktioun vun der Zuel vun Shards verfügbar während Liesen. Dëst implizéiert datt NoSQL Iech erfuerdert Är Ufroen ze modelléieren, während SQL erfuerdert datt Dir Är Donnéeën modelléiert.

NoSQL konzentréiert sech op d'Erreeche vun héijer Leeschtung an engem verdeelte Stärekoup an dëst ass d'Basisdaten Begrënnung fir vill Datebank Design Tradeoffs déi ACID Transaktiounsverloscht, JOINs, a konsequent global sekundär Indizes enthalen.

Et gëtt en Argument datt wärend NoSQL Datenbanken linear Schreif Skalierbarkeet an héich Feeler Toleranz ubidden, de Verloscht vun Transaktiounsgarantien mécht se net gëeegent fir missionskritesch Donnéeën.

Déi folgend Tabell weist wéi Datenmodelléierung an NoSQL sech vun SQL ënnerscheet.

Datebank Design Fundamentals - Vergläicht PostgreSQL, Cassandra a MongoDB

SQL an NoSQL: Firwat si béid gebraucht?

Real-Welt Uwendungen mat grousser Zuel vu Benotzer, wéi Amazon.com, Netflix, Uber, an Airbnb, sinn opgefuerdert komplex, villsäiteg Aufgaben auszeféieren. Zum Beispill, eng E-Commerce Applikatioun wéi Amazon.com muss liicht, héichkritesch Donnéeën wéi Benotzerinformatioun, Produkter, Bestellungen, Rechnungen, zesumme mat schwéieren, manner sensiblen Donnéeën wéi Produktbewertungen, Supportmeldungen, Benotzeraktivitéit, Benotzer Kritik a Recommandatiounen. Natierlech vertrauen dës Uwendungen op d'mannst eng SQL Datebank zesumme mat op d'mannst eng NoSQL Datebank. A cross-regional a global Systemer funktionéiert eng NoSQL Datebank als geo-verdeelt Cache fir Daten, déi an enger vertrauter Quell SQL-Datebank an enger eenzeger Regioun lafen.

Wéi kombinéiert YugaByte DB SQL an NoSQL?

Gebaut op engem logorientéierte gemëschte Späichermotor, Auto-Sharding, sharded verdeelt Konsens Replikatioun an ACID verdeelt Transaktiounen (inspiréiert vu Google Spanner), YugaByte DB ass déi éischt Open Source Datebank vun der Welt déi gläichzäiteg kompatibel ass mat NoSQL (Cassandra & Redis) an SQL (PostgreSQL). Wéi an der Tabell hei ënnendrënner, YCQL, de YugaByte DB API kompatibel mat Cassandra, füügt d'Konzepter vun eenzelen a Multi-Schlëssel ACID Transaktiounen a global sekundär Indexen un d'NoSQL API un, an doduerch d'Ära vun der Transaktiouns NoSQL Datenbanken. Zousätzlech, YCQL, de YugaByte DB API kompatibel mat PostgreSQL, füügt d'Konzepter vun der linearer Schreifskaléierung an der automatescher Feelertoleranz op d'SQL API bäi, bréngt verdeelt SQL-Datenbanken op d'Welt. Well YugaByte DB transaktiounsfäeg ass, kann d'NoSQL API elo am Kontext vu missionskriteschen Donnéeën benotzt ginn.

Datebank Design Fundamentals - Vergläicht PostgreSQL, Cassandra a MongoDB

Wéi virdrun am Artikel gesot "Aféierung YSQL: A PostgreSQL kompatibel verdeelt SQL API fir YugaByte DB", d'Wiel tëscht SQL oder NoSQL an YugaByte DB hänkt ganz vun de Charakteristike vun der Basisdaten Aarbechtslaascht of:

  • Wann Är primär Aarbechtsbelaaschtung Multi-Schlëssel JOIN Operatiounen ass, da wann Dir YSQL auswielt, verstitt datt Är Schlësselen iwwer verschidde Wirbelen verdeelt kënne ginn, wat zu enger méi héijer Latenz an / oder méi nidderegen Duerchsatz resultéiert wéi NoSQL.
  • Soss, wielt entweder vun den zwee NoSQL APIen, bedenkt datt Dir besser Leeschtung kritt als Resultat vun Ufroen, déi vun engem Node gläichzäiteg zerwéiert ginn. YugaByte DB kann als eenzeg operationell Datebank fir real-Welt, komplex Uwendungen déngen, déi gläichzäiteg verschidde Aarbechtslaascht musse managen.

Den Datemodelléierungslabo an der nächster Sektioun baséiert op PostgreSQL a Cassandra API kompatiblen YugaByte DB Datenbanken, am Géigesaz zu gebierteg Datenbanken. Dës Approche betount d'Liichtegkeet vun der Interaktioun mat zwee verschiddenen APIen (op zwee verschiddene Ports) vum selwechte Datebankcluster, am Géigesaz zu komplett onofhängege Cluster vun zwou verschiddenen Datenbanken.
An de folgende Sektioune kucke mir den Datemodelléierungslabo fir d'Ënnerscheeder an e puer vun de Gemeinsamkeeten vun den iwwerdeckten Datenbanken ze illustréieren.

Datemodelléierungslaboratoire

Datebank Installatioun

Gitt de Schwéierpunkt op Datemodelldesign (anstatt komplex Deploymentarchitekturen), wäerte mir Datenbanken an Docker Container op der lokaler Maschinn installéieren an dann mat hinnen interagéieren andeems se hir jeweileg Kommandozeil Shells benotzen.

PostgreSQL & Cassandra kompatibel YugaByte DB Datebank

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

Kommando Linn Zougang

Loosst eis mat den Datenbanken verbannen mat der Kommandozeil Shell fir déi entspriechend APIen.

PostgreSQL

psql ass eng Command Line Shell fir mat PostgreSQL ze interagéieren. Fir einfach ze benotzen, kënnt YugaByte DB mat psql direkt am Bin Dossier.

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

Cassandra

cqlsch ass eng Kommandozeil Shell fir Interaktioun mat Cassandra a seng kompatiblen Datenbanken iwwer CQL (Cassandra Query Language). Fir einfach ze benotzen, kënnt YugaByte DB mat cqlsh am Katalog bin.
Notéiert datt CQL vun SQL inspiréiert gouf an ähnlech Konzepter vun Dëscher, Reihen, Kolonnen an Indexen huet. Wéi och ëmmer, als NoSQL Sprooch füügt et e gewësse Set vu Beschränkungen un, déi meescht vun deenen mir och an aneren Artikelen ofdecken.

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

MongoDB

mongo ass eng Kommandozeil Shell fir mat MongoDB ze interagéieren. Et kann am bin Verzeechnes vun der MongoDB Installatioun fonnt ginn.

docker exec -it my-mongo bash 
cd bin
mongo

Schafen en Dësch

Elo kënne mir mat der Datebank interagéieren fir verschidde Operatiounen mat der Kommandozeil auszeféieren. Loosst eis ufänken mat engem Dësch ze kreéieren deen Informatioun iwwer Lidder späichert vu verschiddene Kënschtler. Dës Lidder kënnen Deel vun engem Album sinn. Och fakultativ Attributer fir e Lidd sinn d'Joer vun der Verëffentlechung, Präis, Genre a Bewäertung. Mir mussen zousätzlech Attributer berücksichtegen, déi an Zukunft duerch de Feld "Tags" gebraucht kënne ginn. Et kann semi-strukturéiert Donnéeën a Form vun Schlëssel-Wäert Pairen späicheren.

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

En Dësch an Cassandra erstellen ass ganz ähnlech wéi PostgreSQL. Ee vun den Haaptunterschiede ass de Mangel un Integritéitsbeschränkungen (zB NET NULL), awer dëst ass d'Verantwortung vun der Applikatioun, net d'NoSQL Datebank. De primäre Schlëssel besteet aus engem Partitionsschlëssel (d'Kënschtler Kolonn am Beispill hei ënnen) an eng Rei vu Clustering Kolonnen (d'SongTitle Kolonn am Beispill hei ënnen). De Partitionsschlëssel bestëmmt op wéi eng Partition / Shard d'Zeil soll plazéiert ginn, an d'Clustering Kolonnen weisen wéi d'Donnéeën am aktuellen Shard solle organiséiert ginn.

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 organiséiert Daten an Datenbanken (Datebase) (ähnlech wéi Keyspace zu Cassandra), wou et Sammlungen sinn (ähnlech wéi Dëscher) déi Dokumenter enthalen (ähnlech wéi Reihen an enger Tabell). Am MongoDB ass et am Fong kee Besoin fir en initial Schema ze definéieren. Equipe "Datebank benotzen", hei ënnendrënner ugewisen, instantiéiert d'Datebank um éischten Uruff an ännert de Kontext fir déi nei erstallt Datebank. Och Sammlungen mussen net explizit erstallt ginn, si ginn automatesch erstallt, einfach wann Dir dat éischt Dokument an eng nei Sammlung bäidréit. Notéiert datt MongoDB d'Testdatenbank als Standard benotzt, sou datt all Sammlungsniveau Operatioun ouni eng spezifesch Datebank ze spezifizéieren als Standard drop leeft. 

use myNewDatabase;

Kréien Informatiounen iwwert en Dësch
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;

Gitt Daten an eng Tabell
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

Allgemeng Ausdrock INSERT an Cassandra gesäit ganz ähnlech aus wéi am PostgreSQL. Wéi och ëmmer, et gëtt e groussen Ënnerscheed an der Semantik. An der Cassandra INSERT ass eigentlech eng Operatioun UPSERT, wou déi lescht Wäerter an d'Zeil bäigefüügt ginn wann d'Zeil scho existéiert.

Dateentrée ass ähnlech wéi PostgreSQL INSERT méi héich

.

MongoDB

Och wann MongoDB eng NoSQL Datebank wéi Cassandra ass, huet seng Insertiounsoperatioun näischt gemeinsam mam semantesche Verhalen vu Cassandra. An MongoDB asetzen () huet keng Méiglechkeeten UPSERT, wat et ähnlech wéi PostgreSQL mécht. Dobäizemaachen Standarddaten ouni _idspecified wäert en neit Dokument an d'Kollektioun bäidroen.

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

Dësch Query

Vläicht ass de bedeitendsten Ënnerscheed tëscht SQL an NoSQL a punkto Ufrokonstruktioun d'Sprooch déi benotzt gëtt FROM и WHERE. SQL erlaabt no Ausdrock FROM wielt MÉI Dëscher, an Ausdrock mat WHERE kann vun all Komplexitéit sinn (inklusiv Operatiounen JOIN tëscht Dëscher). Wéi och ëmmer, NoSQL tendéiert eng schwéier Limitatioun op FROM, a schafft nëmme mat engem spezifizéierten Dësch, an an WHERE, muss de primäre Schlëssel ëmmer spezifizéiert ginn. Dëst verbënnt mat der NoSQL Performance Push, iwwer déi mir virdru geschwat hunn. Dëse Wonsch féiert zu all méiglech Reduktioun vun all Kräiz-Tabulär a Kräiz-Schlëssel Interaktioun. Et kann e grousst Verspéidung an der Inter-Node Kommunikatioun aféieren wann Dir op eng Ufro reagéiert an ass dofir am Beschten allgemeng vermeit. Zum Beispill erfuerdert d'Cassandra Ufroe fir verschidde Betreiber limitéiert ze sinn (nëmmen =, IN, <, >, =>, <=) op Partitionsschlësselen, ausser wann Dir e sekundären Index ufrot (nëmmen den = Bedreiwer ass hei erlaabt).

PostgreSQL

Drënner sinn dräi Beispiller vu Ufroen déi einfach vun enger SQL Datebank ausgefouert kënne ginn.

  • Weist all Lidder vun engem Kënschtler;
  • Weist all Lidder vum Kënschtler déi mam éischten Deel vum Titel passen;
  • Weist all Lidder vun engem Kënschtler déi e bestëmmt Wuert am Titel hunn an e Präis manner wéi 1.00 hunn. 
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

Vun de PostgreSQL Ufroen uewen opgezielt, funktionnéiert nëmmen déi éischt onverännert an Cassandra, well de Bedreiwer LIKE kann net op Clustering Sailen applizéiert ginn wéi z SongTitle. An dësem Fall sinn nëmmen Opérateuren erlaabt = и 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

Wéi an de fréiere Beispiller gewisen, ass d'Haaptmethod fir Ufroen an MongoDB ze kreéieren db.collection.find(). Dës Method enthält explizit den Numm vun der Sammlung (music am Beispill hei ënnen), sou datt et verbueden ass fir verschidde Sammlungen ze froen.

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

Liesen all Zeile vun engem Dësch

All Zeilen liesen ass einfach e spezielle Fall vum Ufromuster dat mir virdru gekuckt hunn.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Ähnlech wéi de PostgreSQL Beispill hei uewen.

MongoDB

db.music.find( {} );

Änneren Daten an enger Tabell

PostgreSQL

PostgreSQL bitt Instruktiounen UPDATE Donnéeën ze änneren. Si huet keng Méiglechkeeten UPSERT, also wäert dës Ausso versoen wann d'Zeil net méi an der Datebank ass.

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

Cassandra

Cassandra huet UPDATE ähnlech wéi PostgreSQL. UPDATE huet déi selwecht Semantik UPSERT, ähnlech INSERT.

Ähnlech wéi de PostgreSQL Beispill hei uewen.

MongoDB
Operatioun aktualiséieren () an MongoDB kann en existent Dokument komplett aktualiséieren oder nëmme bestëmmte Felder aktualiséieren. Par défaut aktualiséiert et nëmmen een Dokument mat Semantik behënnert UPSERT. MÉI Dokumenter aktualiséieren an ähnlecht Verhalen UPSERT kann applizéiert ginn andeems Dir zousätzlech Fändelen fir d'Operatioun setzt. Zum Beispill, am Beispill hei ënnen, gëtt de Genre vun engem spezifesche Kënschtler op Basis vu sengem Lidd aktualiséiert.

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

Ewechzehuelen Daten aus engem Dësch

PostgreSQL

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

Cassandra

Ähnlech wéi de PostgreSQL Beispill hei uewen.

MongoDB

MongoDB huet zwou Aarte vu Operatiounen fir Dokumenter ze läschen - läschenOne() /deleteMany() и ewechhuelen (). Béid Zorte läschen Dokumenter awer ginn aner Resultater zréck. 

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

En Dësch läschen

PostgreSQL

DROP TABLE Music;

Cassandra

Ähnlech wéi de PostgreSQL Beispill hei uewen.

MongoDB

db.music.drop();

Konklusioun

D'Debatt iwwer d'Wiel tëscht SQL an NoSQL ass zënter méi wéi 10 Joer rëselt. Et ginn zwee Haaptaspekter zu dëser Debatt: Datebankmotorarchitektur (monolithesch, transaktionell SQL vs verdeelt, net-transaktionell NoSQL) an Datebankdesign Approche (Modelleréieren Är Donnéeën an SQL vs Modelléiere vun Ären Ufroen an NoSQL).

Mat enger verdeeler Transaktiounsdatenbank wéi YugaByte DB, kann d'Debatt iwwer d'Datebankarchitektur ganz einfach gesat ginn. Wéi Datenvolumen méi grouss ginn wéi dat wat an engem eenzegen Node geschriwwe ka ginn, gëtt eng voll verdeelt Architektur déi linear Schreifskalierbarkeet mat automatescher Scherpung / Rebalancing ënnerstëtzt.

Ausserdeem, wéi et an engem vun den Artikelen steet Google CloudTransaktionell, staark konsequent Architekturen ginn elo méi benotzt fir besser Entwécklungsbeweeglechkeet ze bidden wéi net-transaktionell, schliisslech konsequent Architekturen.

Zréck op d'Datebankdesign Diskussioun, et ass fair ze soen datt béid Design Approche (SQL an NoSQL) fir all komplex real-Welt Applikatioun noutwendeg sinn. D'SQL "Datemodelléierung" Approche erlaabt d'Entwéckler méi einfach verännert Geschäftsbedéngungen z'erreechen, während d'NoSQL "Query Modeling" Approche erlaabt déiselwecht Entwéckler op grousse Volumen vun Daten mat gerénger latency an héijen Duerchsatz ze bedreiwen. Et ass aus dësem Grond datt YugaByte DB SQL an NoSQL APIen an engem gemeinsame Kär ubitt, anstatt eng vun den Approchen ze förderen. Zousätzlech, andeems Dir Kompatibilitéit mat populäre Datebanksproochen ubitt, dorënner PostgreSQL a Cassandra, suergt YugaByte DB datt d'Entwéckler keng aner Sprooch musse léieren fir mat engem verdeelen, héich konsequent Datebankmotor ze schaffen.

An dësem Artikel hu mir gekuckt wéi Datebank Design Fundamenter tëscht PostgreSQL, Cassandra a MongoDB ënnerscheeden. An zukünfteg Artikelen dauchte mir an fortgeschratt Designkonzepter wéi Indizes, Transaktiounen, JOINs, TTL Direktiven, an JSON Dokumenter.

Mir wënschen Iech e schéine Rescht vum Weekend an invitéieren Iech op fräi webinar, déi de 14. Mee stattfënnt.

Source: will.com

Setzt e Commentaire