Grundlagen des Datenbankdesigns - PostgreSQL-, Cassandra- und MongoDB-Vergleich

Hallo Freunde. Bevor wir in den zweiten Teil der Mai-Ferien aufbrechen, teilen wir Ihnen das Material mit, das wir am Vorabend des Starts eines neuen Streams mit der Rate von „Relational DBMS“ ü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 einer Datenbankkategorie, SQL oder NoSQL, da jede Kategorie eine klare Reihe von Kompromissen bietet. Eine hohe Leistung in Bezug auf niedrige Latenz und hohen Durchsatz wird normalerweise als Kompromissanforderung angesehen und ist daher für jede Datenbank in der Stichprobe erforderlich.

Der Zweck dieses Artikels besteht darin, Anwendungsentwicklern dabei zu helfen, im Kontext der Modellierung von Anwendungsdaten die richtige Wahl zwischen SQL und NoSQL zu treffen. Wir werden uns eine SQL-Datenbank ansehen, nämlich PostgreSQL und zwei NoSQL-Datenbanken - Cassandra und MongoDB -, um über die Grundlagen des Datenbankdesigns zu sprechen, z. B. das Erstellen, Auffüllen von Tabellen, Lesen von Daten aus der Tabelle und Löschen von Tabellen. Im nächsten Artikel werden wir uns definitiv mit Indizes, Transaktionen, JOINs, TTL-Direktiven und dem JSON-basierten Datenbankdesign befassen.

Was ist der Unterschied zwischen SQL und NoSQL?

SQL-Datenbanken erhöhen die Anwendungsflexibilität durch ACID-Transaktionsgarantien sowie ihre Fähigkeit, Daten mithilfe von JOINs auf unerwartete Weise zusätzlich zu vorhandenen normalisierten relationalen Datenbankmodellen abzufragen.

Aufgrund ihrer monolithischen Architektur / Einzelknotenarchitektur und der Verwendung eines Master-Slave-Replikationsmodells für Redundanz weisen herkömmliche SQL-Datenbanken keine zwei wichtigen Merkmale auf - lineare Skalierbarkeit des Datensatzes (d. H. Automatische Aufteilung in mehrere Knoten) und automatischer Datenverlust / Null. Dies bedeutet, dass die empfangene Datenmenge den maximalen Schreibdurchsatz eines Knotens nicht überschreiten darf. Darüber hinaus sollte ein vorübergehender Datenverlust bei der Fehlertoleranz berücksichtigt werden (in einer Architektur ohne gemeinsame Nutzung von Ressourcen). Hier müssen Sie berücksichtigen, dass die letzten Commits noch nicht in der Slave-Kopie berücksichtigt wurden. Updates ohne Ausfallzeiten sind auch in SQL-Datenbanken schwer zu erreichen.

NoSQL-Datenbanken werden typischerweise von Natur aus verteilt, d.h. In ihnen werden Daten in Abschnitte unterteilt und auf mehrere Knoten verteilt. Sie erfordern eine Denormalisierung. Dies bedeutet, dass die eingegebenen Daten auch mehrmals kopiert werden müssen, um auf bestimmte von Ihnen gesendete Anfragen zu antworten. Das übergeordnete Ziel besteht darin, eine hohe Leistung zu erzielen, indem die Anzahl der beim Lesen verfügbaren Shards verringert wird. Es folgt der Aussage, dass Sie in NoSQL Ihre Abfragen modellieren müssen, während Sie in SQL Ihre Daten modellieren müssen.

NoSQL konzentriert sich auf die Erzielung einer hohen Leistung in einem verteilten Cluster. Dies ist der Hauptgrund für viele Kompromisse beim Datenbankdesign, zu denen Transaktionsverlust-ACIDs, JOINs und konsistente globale Sekundärindizes gehören.

Es wird angenommen, dass NoSQL-Datenbanken zwar eine lineare Schreibskalierbarkeit und eine hohe Fehlertoleranz bieten, der Verlust von Transaktionsgarantien sie jedoch für geschäftskritische 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 führen komplexe, vielfach sortierte Aufgaben aus. Beispielsweise muss eine E-Commerce-Anwendung wie Amazon.com leichte, hochkritische Daten wie Informationen zu Benutzern, Produkten, Bestellungen, Rechnungen sowie schwere, aber weniger sensible Daten wie Produktbewertungen und Supportnachrichten speichern , Benutzeraktivität, Benutzerbewertungen und Empfehlungen. Natürlich basieren diese Anwendungen auf mindestens einer SQL-Datenbank zusammen mit mindestens einer NoSQL-Datenbank. In interregionalen und globalen Systemen fungiert die NoSQL-Datenbank als geoverteilter Cache für Daten, die in einer vertrauenswürdigen Quelle, einer SQL-Datenbank, gespeichert sind und in einer bestimmten Region ausgeführt werden.

Wie kombiniert YugaByte DB SQL und NoSQL?

YugaByte DB basiert auf einer protokollorientierten Mixed-Storage-Engine, automatischem Sharding, Sharding verteilter Konsensreplikation und verteilten ACID-Transaktionen (inspiriert von Google Spanner) und ist die erste Open-Source-Datenbank der Welt, die gleichzeitig mit NoSQL (Cassandra & Redis) kompatibel ist ) und SQL (PostgreSQL). Wie in der folgenden Tabelle gezeigt, fügt YSQL, die Cassandra-kompatible YugaByte DB-API, den NoSQL-APIs die Konzepte von ACID-Transaktionen mit einem und mehreren Schlüsseln und globalen Sekundärindizes hinzu und eröffnet damit die Ära der transaktionalen NoSQL-Datenbanken. Darüber hinaus erweitert YSQL, eine PostgreSQL-kompatible YugaByte DB-API, die SQL-API um den Begriff der linearen Schreibskalierung und der automatischen Fehlertoleranz und führt verteilte SQL-Datenbanken in die Welt ein. Da es sich bei der YugaByte DB-Datenbank im Wesentlichen um eine Transaktionsdatenbank handelt, kann die NoSQL-API jetzt im Kontext geschäftskritischer Daten verwendet werden.



Wie bereits im Artikel „Einführung in YSQL: Eine PostgreSQL-kompatible verteilte SQL-API für YugaByte DB“ erwähnt , hängt die Wahl zwischen SQL oder NoSQL in YugaByte DB vollständig von den Merkmalen der Hauptarbeitslast ab:

• Wenn die Hauptauslastung Mehrschlüsseloperationen mit JOINs sind, sollten Sie bei der Auswahl von YSQL verstehen, dass Ihre Schlüssel auf mehrere Knoten verteilt werden können, was zu einer höheren Verzögerung und / oder einem geringeren Durchsatz als in NoSQL führt.
• Wählen Sie andernfalls eine der beiden NoSQL-APIs aus, und berücksichtigen Sie dabei, dass Sie eine bessere Leistung erzielen, wenn Abfragen von jeweils einem Knoten ausgeführt werden. YugaByte DB kann als einzelne Betriebsdatenbank für sehr komplexe Anwendungen dienen, in denen Sie mehrere Workloads gleichzeitig verwalten müssen.

Das Datenmodellierungslabor im nächsten Abschnitt basiert im Gegensatz zu den Quelldatenbanken auf YugaByte DB-Datenbanken, die mit PostgreSQL und Cassandra API kompatibel sind. Dieser Ansatz betont die einfache Interaktion mit zwei verschiedenen APIs (an zwei verschiedenen Ports) desselben Datenbankclusters, im Gegensatz zur Verwendung völlig unabhängiger Cluster aus zwei verschiedenen Datenbanken.

In den folgenden Abschnitten werden wir uns mit dem Datenmodellierungslabor treffen, um die Unterschiede und einige gemeinsame Merkmale der betreffenden Datenbanken zu veranschaulichen.

Datenmodellierungslabor

Datenbankinstallation

Angesichts des Schwerpunkts auf dem Entwerfen eines Datenmodells (anstelle komplexer Bereitstellungsarchitekturen) werden wir die Datenbanken in Docker-Containern auf dem lokalen Computer installieren und dann mit ihnen über die entsprechenden Befehlszeilen-Shells interagieren.

Kompatibel mit PostgreSQL & Cassandra, 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_postgres 

Mongodb

 docker run --name my-mongo -d mongo:latest 

Befehlszeilenzugriff

Stellen Sie über die Befehlszeilen-Shell für die entsprechenden APIs eine Verbindung zu den Datenbanken her.

PostgreSQL

psql ist eine Befehlszeilen-Shell für die Interaktion mit PostgreSQL. Zur Vereinfachung der Verwendung wird YugaByte DB mit psql direkt im Ordner bin geliefert.

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

Cassandra

cqlsh ist eine Befehlszeilen-Shell für die Interaktion mit Cassandra und seinen kompatiblen Datenbanken über CQL (Cassandra Query Language). Zur Vereinfachung der Verwendung enthält YugaByte DB cqlsh im bin .

Beachten Sie, dass CQL von SQL inspiriert wurde und ähnliche Konzepte wie Tabellen, Zeilen, Spalten und Indizes hat. Als NoSQL-Sprache werden jedoch bestimmte Einschränkungen hinzugefügt, von denen die meisten auch in anderen Artikeln behandelt werden.

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

Mongodb

mongo 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 mongo 

Tabellenerstellung

Jetzt können wir mit der Datenbank interagieren, um verschiedene Operationen über die Befehlszeile auszuführen. Beginnen wir mit der Erstellung einer Tabelle, in der Informationen zu Songs gespeichert sind, die von verschiedenen Künstlern geschrieben wurden. Diese Songs können Teil eines Albums sein. Auch optionale Attribute für den Song - Erscheinungsjahr, Preis, Genre und Bewertung. Wir müssen zusätzliche Attribute berücksichtigen, die möglicherweise in Zukunft über das Feld "Tags" 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) ); 

Cassandra

Das Erstellen einer Tabelle in Cassandra ist PostgreSQL sehr ähnlich. Einer der Hauptunterschiede ist das Fehlen von Integritätsbeschränkungen (z. B. NICHT NULL). Dies liegt jedoch in der Verantwortung der Anwendung und nicht der NoSQL-Datenbank . Der Primärschlüssel besteht aus einem Abschnittsschlüssel (Artist-Spalte im folgenden Beispiel) und einer Reihe von Clustering-Spalten (SongTitle-Spalte im folgenden Beispiel). Der Partitionsschlüssel bestimmt, in welcher Partition / in welchem ​​Shard die Zeile platziert 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 die Daten in Datenbanken (Database) (ähnlich wie Keyspace in Cassandra), in denen Sammlungen (Collections) (ähnlich wie Tabellen) vorhanden sind, die Dokumente (Documents) enthalten (ähnlich wie Zeilen in einer Tabelle). MongoDB erfordert grundsätzlich nicht die Definition des ursprünglichen Schemas. Der unten gezeigte Befehl "Datenbank verwenden" erstellt beim ersten Aufruf eine Instanz der Datenbank und ändert den Kontext für die neu erstellte Datenbank. Auch Sammlungen müssen nicht explizit erstellt werden, sondern werden automatisch erstellt, einfach wenn Sie das erste Dokument zu einer neuen Sammlung hinzufügen. Beachten Sie, dass MongoDB standardmäßig die Testdatenbank verwendet. Daher wird standardmäßig jede Operation auf Sammlungsebene ohne Angabe einer bestimmten Datenbank ausgeführt.

 use myNewDatabase; 

Abrufen von PostgreSQL-Tabelleninformationen

 \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; 

Daten in eine PostgreSQL-Tabelle posten

 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

Im Allgemeinen sieht der INSERT Ausdruck in Cassandra dem in PostgreSQL sehr ähnlich. Es gibt jedoch einen großen Unterschied in der Semantik. In Cassandra ist INSERT eine UPSERT Operation, bei der die letzten Werte zur Zeichenfolge hinzugefügt werden, falls die Zeichenfolge bereits vorhanden ist.

Die Dateneingabe ähnelt der obigen INSERT von PostgreSQL INSERT

Mongodb

Obwohl MongoDB wie Cassandra eine NoSQL-Datenbank ist, hat ihre Einfügeoperation nichts mit semantischem Verhalten in Cassandra zu tun. In MongoDB verfügt insert () nicht über UPSERT Funktionen, UPSERT es wie PostgreSQL aussieht. Durch Hinzufügen von Standarddaten ohne _idspecified wird der Sammlung ein neues Dokument _idspecified .

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 im Hinblick auf das Abfragedesign ist die Verwendung der FROM und WHERE Anweisungen. Mit SQL können Sie mehrere Tabellen nach einer FROM auswählen, und eine WHERE kann beliebig komplex sein (einschließlich JOIN Operationen zwischen Tabellen). NoSQL neigt jedoch dazu, FROM strikt einzuschränken und nur mit einer angegebenen Tabelle zu arbeiten. 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 jeder möglichen Reduzierung einer tabellen- und schlüsselübergreifenden Interaktion. Dies kann zu einer großen Verzögerung der Kommunikation zwischen Knoten führen, wenn auf eine Anfrage geantwortet wird, und wird daher im Prinzip am besten vermieden. Cassandra verlangt beispielsweise, dass Abfragen auf bestimmte Operatoren (nur =, IN, <, >, =>, <= sind zulässig) für Partitionsschlüssel beschränkt sind, außer wenn ein Sekundärindex angefordert wird (hier ist nur der Operator = zulässig).

PostgreSQL

Im Folgenden werden drei Beispiele für Abfragen aufgeführt, die von einer SQL-Datenbank problemlos ausgeführt werden können.

• Drucken Sie alle Songs des Künstlers;
• Drucken Sie alle Songs des Künstlers, die dem ersten Teil des Namens entsprechen.
• Listen Sie alle Songs des Künstlers auf, 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; 

Cassandra

Von den oben genannten PostgreSQL-Abfragen funktioniert nur die erste in Cassandra unverändert, da die LIKE Anweisung nicht auf Clustering-Spalten wie SongTitle . In diesem Fall sind nur Operatoren = und IN zulässig.

 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 db.collection.find () . Diese Methode enthält explizit den Namen der Sammlung ( music im folgenden Beispiel), sodass die Anforderung mehrerer Sammlungen verboten ist.

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

Lesen Sie alle Tabellenzeilen

Das Lesen aller Zeilen ist nur ein Sonderfall der zuvor untersuchten Abfragevorlage.

PostgreSQL

 SELECT * FROM Music; 

Cassandra

Ähnlich wie im obigen Beispiel in PostgreSQL.

Mongodb

 db.music.find( {} ); 

Bearbeiten von Daten in einer Tabelle

PostgreSQL

PostgreSQL bietet eine UPDATE zum Ändern von Daten. Es verfügt nicht über UPSERT Funktionen, daher UPSERT die Ausführung dieser Anweisung fehl, wenn sich die Zeile nicht mehr in der Datenbank befindet.

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

Cassandra

Cassandra hat ein UPDATE ähnlich wie PostgreSQL. UPDATE hat dieselbe UPSERT Semantik UPSERT INSERT .

Ähnlich wie im obigen Beispiel in PostgreSQL.

Mongodb
Die update () -Operation in MongoDB kann ein vorhandenes Dokument vollständig aktualisieren oder nur bestimmte Felder aktualisieren. Standardmäßig wird nur ein Dokument mit UPSERT Semantik aktualisiert. Das Aktualisieren mehrerer Dokumente und das Verhalten ähnlich wie bei UPSERT können angewendet werden, indem zusätzliche Flags für den Vorgang gesetzt werden. Im folgenden Beispiel wird beispielsweise das Genre eines bestimmten Künstlers durch sein Lied 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'; 

Cassandra

Ähnlich wie im obigen Beispiel in PostgreSQL.

Mongodb

MongoDB bietet zwei Arten von Vorgängen zum Löschen von Dokumenten: deleteOne () / deleteMany () und remove () . Beide Typen löschen Dokumente, geben jedoch unterschiedliche Ergebnisse zurück.

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

Tabelle löschen

PostgreSQL

 DROP TABLE Music; 

Cassandra

Ähnlich wie im obigen Beispiel in PostgreSQL.

Mongodb

 db.music.drop(); 

Fazit

Die Debatte über die Wahl zwischen SQL und NoSQL tobt seit über 10 Jahren. Es gibt zwei Hauptaspekte dieser Debatte: die Architektur des Datenbankmoduls (monolithisches, transaktionales SQL im Vergleich zu verteiltem, nicht transaktionalem NoSQL) und den Ansatz für das Datenbankdesign (Datenmodellierung in SQL im Vergleich zur Modellierung Ihrer Abfragen in NoSQL).

Mit einer verteilten Transaktionsdatenbank wie YugaByte DB kann die Debatte über die Datenbankarchitektur leicht zerstreut werden. Wenn das Datenvolumen größer wird als das, was auf einen einzelnen Knoten geschrieben werden kann, ist eine vollständig verteilte Architektur erforderlich, die die lineare Skalierbarkeit von Aufzeichnungen mit automatischem Sharding / Neuausgleich unterstützt.

Zusätzlich zu einem Artikel in einem Google Cloud- Artikel werden transaktionsorientierte, streng konsistente Architekturen heute häufiger verwendet, 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 erforderlich sind. Der SQL-Ansatz „Datenmodellierung“ ermöglicht es Entwicklern, sich ändernde Geschäftsanforderungen einfacher zu erfüllen, während der NoSQL-Ansatz „Datenmodellierung“ 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 Kernel bereit, anstatt einen der Ansätze zu fördern. Durch die Kompatibilität mit gängigen Datenbanksprachen wie PostgreSQL und Cassandra stellt YugaByte DB außerdem sicher, dass Entwickler keine andere Sprache lernen müssen, um mit einer verteilten, streng konsistenten Datenbank-Engine zu arbeiten.

In diesem Artikel haben wir herausgefunden, wie sich die Grundlagen des Datenbankdesigns in PostgreSQL, Cassandra und MongoDB unterscheiden. In den folgenden Artikeln werden wir uns mit fortgeschrittenen Designkonzepten wie Indizes, Transaktionen, JOINs, TTL-Direktiven und JSON-Dokumenten befassen.

Wir wünschen Ihnen einen schönen Aufenthalt für den Rest des Wochenendes und laden Sie zu einem kostenlosen Webinar ein , das am 14. Mai stattfinden wird.