Hallo Freunde. Bevor wir in die zweite Hälfte der Maiferien aufbrechen, teilen wir mit Ihnen das Material, das wir im Vorgriff auf den Start eines neuen Streams zum Tarif übersetzt haben .
Anwendungsentwickler verbringen viel Zeit damit, mehrere Betriebsdatenbanken zu vergleichen, um diejenige auszuwählen, die für ihre beabsichtigte Arbeitslast am besten geeignet ist. Zu den Anforderungen können eine vereinfachte Datenmodellierung, Transaktionsgarantien, Lese-/Schreibleistung, horizontale Skalierung und Fehlertoleranz gehören. Traditionell beginnt die Auswahl mit der Kategorie Datenbank, SQL oder NoSQL, da jede Kategorie klare Kompromisse bietet. Eine hohe Leistung im Sinne einer geringen Latenz und eines hohen Durchsatzes wird allgemein als eine Anforderung angesehen, die keine Kompromisse eingehen darf und daher für jede Datenbank in der Stichprobe unerlässlich ist.
Der Zweck dieses Artikels besteht darin, Anwendungsentwicklern dabei zu helfen, im Kontext der Anwendungsdatenmodellierung die richtige Wahl zwischen SQL und NoSQL zu treffen. Wir werden uns eine SQL-Datenbank, nämlich PostgreSQL, und zwei NoSQL-Datenbanken, Cassandra und MongoDB, ansehen, um die Grundlagen des Datenbankdesigns zu behandeln, wie z. B. das Erstellen von Tabellen, deren Befüllung, das Lesen von Daten aus einer Tabelle und deren Löschen. Im nächsten Artikel werden wir uns auf jeden Fall mit Indizes, Transaktionen, JOINs, TTL-Anweisungen und Datenbankdesign auf Basis von JSON befassen.
Was ist der Unterschied zwischen SQL und NoSQL?
SQL-Datenbanken erhöhen die Anwendungsflexibilität durch ACID-Transaktionsgarantien sowie durch ihre Fähigkeit, Daten mithilfe von JOINs auf unerwartete Weise zusätzlich zu bestehenden normalisierten relationalen Datenbankmodellen abzufragen.
Aufgrund ihrer monolithischen/Einzelknoten-Architektur und der Verwendung eines Master-Slave-Replikationsmodells für Redundanz fehlen herkömmlichen SQL-Datenbanken zwei wichtige Merkmale: lineare Schreibskalierbarkeit (d. h. automatische Aufteilung auf mehrere Knoten) und automatischer/kein Datenverlust. Dies bedeutet, dass die empfangene Datenmenge den maximalen Schreibdurchsatz eines einzelnen Knotens nicht überschreiten kann. Darüber hinaus muss für die Fehlertoleranz ein gewisser vorübergehender Datenverlust berücksichtigt werden (in einer nicht gemeinsam genutzten Architektur). Dabei ist zu beachten, dass sich die letzten Commits noch nicht in der Slave-Kopie widerspiegeln. Auch bei SQL-Datenbanken ist es schwierig, Aktualisierungen ohne Ausfallzeiten zu erreichen.
NoSQL-Datenbanken sind typischerweise verteilter Natur, d. h. Dabei werden die Daten in Abschnitte unterteilt und auf mehrere Knoten verteilt. Sie erfordern eine Denormalisierung. Das bedeutet, dass die eingegebenen Daten auch mehrfach kopiert werden müssen, um auf die konkreten Anfragen, die Sie senden, reagieren zu können. Das übergeordnete Ziel besteht darin, eine hohe Leistung zu erzielen, indem die Anzahl der zum Lesezeitpunkt verfügbaren Shards reduziert wird. Dies bedeutet, dass Sie bei NoSQL Ihre Abfragen modellieren müssen, während Sie bei SQL Ihre Daten modellieren müssen.
NoSQL legt Wert darauf, eine hohe Leistung in einem verteilten Cluster zu erreichen. Dies ist der Hauptgrund für viele Kompromisse beim Datenbankdesign, zu denen der Verlust von ACID-Transaktionen, JOINs und konsistenten globalen Sekundärindizes gehört.
Es besteht die Meinung, dass NoSQL-Datenbanken zwar eine lineare Schreibskalierbarkeit und eine hohe Fehlertoleranz bieten, der Verlust von Transaktionsgarantien sie jedoch für kritische Daten ungeeignet macht.
Die folgende Tabelle zeigt, wie sich die Datenmodellierung in NoSQL von SQL unterscheidet.
SQL und NoSQL: Warum werden beide benötigt?
Reale Anwendungen mit einer großen Anzahl von Benutzern, wie Amazon.com, Netflix, Uber und Airbnb, sind für die Ausführung komplexer Aufgaben unterschiedlicher Art verantwortlich. Beispielsweise muss eine E-Commerce-Anwendung wie Amazon.com leichte, hochsensible Daten wie Informationen über Benutzer, Produkte, Bestellungen, Rechnungen sowie umfangreiche, aber weniger sensible Daten wie Produktbewertungen, Supportnachrichten und Benutzeraktivitäten speichern , Benutzerbewertungen und Empfehlungen. Natürlich basieren diese Anwendungen auf mindestens einer SQL-Datenbank und mindestens einer NoSQL-Datenbank. In interregionalen und globalen Systemen fungiert die NoSQL-Datenbank als geografisch verteilter Cache für Daten, die in einer vertrauenswürdigen Quelle, einer SQL-Datenbank, gespeichert sind, die in einer beliebigen Region betrieben wird.
Wie kombiniert YugaByte DB SQL und NoSQL?
YugaByte DB basiert auf einer protokollorientierten gemischten Speicher-Engine, automatischem Sharding, verteilter Shard-Konsensreplikation und verteilten ACID-Transaktionen (inspiriert von Google Spanner) und ist die weltweit erste Open-Source-Datenbank, die gleichzeitig mit NoSQL (Cassandra und Redis) kompatibel ist. ) und SQL (PostgreSQL). Wie in der folgenden Tabelle gezeigt, fügt YCQL, eine mit Cassandra kompatible YugaByte DB-API, der NoSQL-API die Konzepte von Single- und Multi-Key-ACID-Transaktionen und globalen Sekundärindizes hinzu und läutet damit die Ära der transaktionalen NoSQL-Datenbanken ein. Darüber hinaus fügt YCQL, eine mit PostgreSQL kompatible YugaByte DB-API, die Konzepte der linearen Schreibskalierung und des automatischen Failovers zur SQL-API hinzu und bringt so verteilte SQL-Datenbanken auf die Welt. Da die YugaByte DB-Datenbank von Natur aus transaktional ist, kann die NoSQL-API jetzt im Kontext kritischer Daten verwendet werden.
Wie bereits im Artikel erwähnt Die Wahl zwischen SQL oder NoSQL in YugaByte DB hängt vollständig von den Eigenschaften der zugrunde liegenden Arbeitslast ab:
- Wenn Ihre primäre Arbeitslast aus JOIN-Vorgängen mit mehreren Schlüsseln besteht, sollten Sie bei der Auswahl von YSQL bedenken, dass Ihre Schlüssel möglicherweise auf mehrere Knoten verteilt sind, was zu einer höheren Latenz und/oder einem geringeren Durchsatz als bei NoSQL führt.
- Andernfalls wählen Sie eine der beiden NoSQL-APIs. Beachten Sie dabei, dass Sie eine bessere Leistung erzielen, wenn Abfragen jeweils von einem Knoten aus bedient werden. YugaByte DB kann als einzelne Betriebsdatenbank für wirklich komplexe Anwendungen dienen, die mehrere Workloads gleichzeitig verwalten müssen.
Das Datenmodellierungslabor im nächsten Abschnitt basiert im Gegensatz zu den Originaldatenbanken auf den PostgreSQL- und Cassandra-kompatiblen YugaByte DB-Datenbank-APIs. Dieser Ansatz betont die einfache Interaktion mit zwei unterschiedlichen APIs (an zwei unterschiedlichen Ports) desselben Datenbankclusters, im Gegensatz zur Verwendung völlig unabhängiger Cluster zweier unterschiedlicher Datenbanken.
In den folgenden Abschnitten werfen wir einen Blick auf das Data Modeling Lab, um die Unterschiede und einige Gemeinsamkeiten der betreffenden Datenbanken zu veranschaulichen.
Datenmodellierungslabor
Datenbanken installieren
Da wir uns auf das Design von Datenmodellen konzentrieren (und nicht auf komplexe Bereitstellungsarchitekturen), werden wir die Datenbanken in Docker-Containern auf dem lokalen Computer installieren und dann über ihre jeweiligen Befehlszeilen-Shells mit ihnen interagieren.
PostgreSQL- und Cassandra-kompatibel, YugaByte DB-Datenbank
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:latestBefehlszeilenzugriff
Stellen wir über die Befehlszeilen-Shell für die jeweiligen APIs eine Verbindung zu den Datenbanken her.
PostgreSQL
ist eine Befehlszeilen-Shell für die Interaktion mit PostgreSQL. Zur Vereinfachung der Verwendung enthält YugaByte DB psql direkt im Bin-Ordner.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresKassandra
ist eine Befehlszeilen-Shell für die Interaktion mit Cassandra und seinen kompatiblen Datenbanken über CQL (Cassandra Query Language). Zur Benutzerfreundlichkeit ist YugaByte DB im Lieferumfang enthalten cqlsh im Katalog bin.
Beachten Sie, dass CQL von SQL inspiriert wurde und ähnliche Konzepte für Tabellen, Zeilen, Spalten und Indizes aufweist. Als NoSQL-Sprache bringt sie jedoch eine Reihe von Einschränkungen mit sich, von denen wir die meisten auch in anderen Artikeln behandeln werden.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
ist eine Befehlszeilen-Shell für die Interaktion mit MongoDB. Es befindet sich im bin-Verzeichnis der MongoDB-Installation.
docker exec -it my-mongo bash
cd bin
mongoErstellen Sie eine Tabelle
Jetzt können wir mit der Datenbank interagieren, um über die Befehlszeile verschiedene Vorgänge auszuführen. Beginnen wir mit der Erstellung einer Tabelle, in der Informationen zu Liedern verschiedener Künstler gespeichert sind. Diese Lieder können Teil eines Albums sein. Weitere optionale Attribute für den Song sind Erscheinungsjahr, Preis, Genre und Bewertung. Über das Feld „Tags“ müssen wir zusätzliche Attribute berücksichtigen, die in Zukunft möglicherweise benötigt werden. Es kann halbstrukturierte Daten als Schlüssel-Wert-Paare speichern.
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)
); Kassandra
Das Erstellen einer Tabelle in Cassandra ist PostgreSQL sehr ähnlich. Einer der Hauptunterschiede ist das Fehlen von Integritätsbeschränkungen (wie NOT NULL), aber dafür ist die Anwendung verantwortlich, nicht die NoSQL-Datenbank.. Der Primärschlüssel besteht aus einem Partitionsschlüssel (Spalte „Artist“ im Beispiel unten) und einer Reihe von Clustering-Spalten (Spalte „SongTitle“ im Beispiel unten). Der Partitionsschlüssel bestimmt, in welche Partition/Shard die Zeile eingefügt werden soll, und die Clustering-Spalten geben an, wie die Daten innerhalb des aktuellen Shards organisiert werden sollen.
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 organisiert Daten in Datenbanken (Datenbank) (ähnlich Keyspace in Cassandra), in denen es Sammlungen (Sammlungen) (ähnlich Tabellen) gibt, die Dokumente (Dokumente) enthalten (ähnlich Zeilen in einer Tabelle). In MongoDB ist grundsätzlich keine anfängliche Schemadefinition erforderlich. Team „Datenbank verwenden“, wie unten gezeigt, instanziiert die Datenbank beim ersten Aufruf und ändert den Kontext für die neu erstellte Datenbank. Auch Sammlungen müssen nicht explizit erstellt werden, sie werden automatisch erstellt, sobald das erste Dokument zu einer neuen Sammlung hinzugefügt wird. Beachten Sie, dass MongoDB standardmäßig eine Testdatenbank verwendet, sodass alle Vorgänge auf Sammlungsebene ohne Angabe einer bestimmten Datenbank standardmäßig darin ausgeführt werden.
use myNewDatabase;Informationen zu einer Tabelle abrufen
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)Kassandra
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;Daten in eine Tabelle eingeben
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}'
);Kassandra
Im Allgemeinen der Ausdruck INSERT in Cassandra sieht dem in PostgreSQL sehr ähnlich. Es gibt jedoch einen großen Unterschied in der Semantik. In Kassandra INSERT ist eigentlich eine Operation UPSERT, wobei die neuesten Werte zur Zeichenfolge hinzugefügt werden, falls die Zeichenfolge bereits vorhanden ist.
Die Dateneingabe ähnelt PostgreSQL
INSERToben
.
MongoDB
Obwohl MongoDB wie Cassandra eine NoSQL-Datenbank ist, hat seine Dateneingabeoperation nichts mit dem semantischen Verhalten von Cassandra zu tun. In MongoDB hat keine Chance UPSERT, wodurch es PostgreSQL ähnelt. Standarddaten hinzufügen ohne _idspecified führt dazu, dass der Sammlung ein neues Dokument hinzugefügt wird.
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"
}
}
);
Tabellenabfrage
Der vielleicht bedeutendste Unterschied zwischen SQL und NoSQL in Bezug auf die Abfrage ist die Verwendung von FROM и WHERE. SQL erlaubt Nachausdrücke FROM Wählen Sie mehrere Tabellen und einen Ausdruck mit aus WHERE kann beliebig komplex sein (einschließlich Operationen). JOIN zwischen Tischen). Allerdings tendiert NoSQL dazu, eine harte Grenze festzulegen FROM, und arbeiten mit nur einer angegebenen Tabelle und in WHERE, muss immer der Primärschlüssel angegeben werden. Dies ist auf den Wunsch zurückzuführen, die Leistung von NoSQL zu verbessern, über den wir bereits gesprochen haben. Dieser Wunsch führt zu einer größtmöglichen Reduzierung jeglicher Kreuztabellen- und Kreuztasteninteraktion. Dies kann zu einer großen Verzögerung bei der Kommunikation zwischen Knoten bei der Beantwortung einer Anfrage führen und sollte daher grundsätzlich vermieden werden. Cassandra erfordert beispielsweise, dass Anfragen auf bestimmte Operatoren beschränkt werden (nur zulässig). =, IN, <, >, =>, <=) auf Partitionsschlüsseln, außer bei der Abfrage eines Sekundärindex (hier ist nur der =-Operator zulässig).
PostgreSQL
Im Folgenden finden Sie drei Beispiele für Abfragen, die problemlos von einer SQL-Datenbank ausgeführt werden können.
- Alle Songs des Künstlers anzeigen;
- Alle Songs des Künstlers anzeigen, die zum ersten Teil des Titels passen;
- Zeigt alle Songs des Künstlers an, die ein bestimmtes Wort im Titel haben und einen Preis von weniger als 1.00 haben.
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;Kassandra
Von den oben aufgeführten PostgreSQL-Abfragen funktioniert nur die erste in Cassandra unverändert, da die Anweisung LIKE kann nicht auf Clustering-Spalten angewendet werden, z SongTitle. In diesem Fall sind nur Operatoren zulässig = и 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
Wie in den vorherigen Beispielen gezeigt, ist die Hauptmethode zum Erstellen von Abfragen in MongoDB . Diese Methode enthält explizit den Namen der Sammlung (music im Beispiel unten), daher ist die Abfrage mehrerer Sammlungen nicht zulässig.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Alle Zeilen einer Tabelle lesen
Das Lesen aller Zeilen ist nur ein Sonderfall des zuvor besprochenen Abfragemusters.
PostgreSQL
SELECT *
FROM Music;Kassandra
Ähnlich dem obigen PostgreSQL-Beispiel.
MongoDB
db.music.find( {} );Bearbeiten von Daten in einer Tabelle
PostgreSQL
PostgreSQL stellt eine Anweisung bereit UPDATE Daten ändern. Sie hat keine Chance UPSERT, daher schlägt diese Anweisung fehl, wenn die Zeile nicht mehr in der Datenbank vorhanden ist.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Kassandra
Cassandra hat UPDATE ähnlich wie PostgreSQL. UPDATE hat die gleiche Semantik UPSERT, wie INSERT.
Ähnlich dem obigen PostgreSQL-Beispiel.
MongoDB
Betrieb In MongoDB kann es ein vorhandenes Dokument vollständig aktualisieren oder nur bestimmte Felder aktualisieren. Standardmäßig wird nur ein Dokument mit deaktivierter Semantik aktualisiert UPSERT. Mehrere Dokumente aktualisieren und ähnliches Verhalten UPSERT kann angewendet werden, indem zusätzliche Flags für den Vorgang gesetzt werden. Wie zum Beispiel im folgenden Beispiel wird das Genre eines bestimmten Künstlers durch seinen Song aktualisiert.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Daten aus einer Tabelle entfernen
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Kassandra
Ähnlich dem obigen PostgreSQL-Beispiel.
MongoDB
MongoDB verfügt über zwei Arten von Operationen zum Löschen von Dokumenten: и . Beide Typen löschen Dokumente, liefern jedoch unterschiedliche Ergebnisse.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Eine Tabelle löschen
PostgreSQL
DROP TABLE Music;Kassandra
Ähnlich dem obigen PostgreSQL-Beispiel.
MongoDB
db.music.drop();Abschluss
Die Debatte über die Wahl zwischen SQL und NoSQL tobt seit über 10 Jahren. Bei dieser Debatte gibt es zwei Hauptaspekte: die Architektur der Datenbank-Engine (monolithisches, transaktionales SQL vs. verteiltes, nicht-transaktionales NoSQL) und den Ansatz zum Datenbankdesign (Datenmodellierung in SQL vs. Modellierung Ihrer Abfragen in NoSQL).
Mit einer verteilten Transaktionsdatenbank wie YugaByte DB kann die Debatte über die Datenbankarchitektur leicht ausgeräumt werden. Da die Datenmengen größer werden, als auf einen einzelnen Knoten geschrieben werden kann, wird eine vollständig verteilte Architektur erforderlich, die lineare Schreibskalierbarkeit mit automatischem Sharding/Rebalancing unterstützt.
Zusätzlich zu dem, was in einem der Artikel gesagt wurde Transaktionale, stark konsistente Architekturen werden mittlerweile häufiger eingesetzt, um eine bessere Entwicklungsflexibilität zu bieten als nicht-transaktionale, letztendlich konsistente Architekturen.
Zurück zur Diskussion des Datenbankdesigns: Man kann mit Recht sagen, dass beide Designansätze (SQL und NoSQL) für jede komplexe reale Anwendung notwendig sind. Der „Datenmodellierungs“-Ansatz von SQL ermöglicht es Entwicklern, sich ändernden Geschäftsanforderungen leichter gerecht zu werden, während der „Abfragemodellierungs“-Ansatz von NoSQL es denselben Entwicklern ermöglicht, große Datenmengen mit geringer Latenz und hohem Durchsatz zu verarbeiten. Aus diesem Grund stellt YugaByte DB SQL- und NoSQL-APIs in einem gemeinsamen Kern bereit und befürwortet keinen der Ansätze. Darüber hinaus stellt YugaByte DB durch die Kompatibilität mit gängigen Datenbanksprachen, einschließlich PostgreSQL und Cassandra, sicher, dass Entwickler keine weitere Sprache erlernen müssen, um mit einer verteilten, stark konsistenten Datenbank-Engine zu arbeiten.
In diesem Artikel haben wir untersucht, wie sich die Datenbankdesigngrundlagen zwischen PostgreSQL, Cassandra und MongoDB unterscheiden. In den folgenden Artikeln befassen wir uns mit fortgeschrittenen Designkonzepten wie Indizes, Transaktionen, JOINs, TTL-Anweisungen und JSON-Dokumenten.
Wir wünschen Ihnen ein tolles Wochenende und laden Sie herzlich dazu ein die am 14. Mai stattfinden wird.
Source: habr.com