🥇Grundlagen des Datenbankdesigns – Vergleich von PostgreSQL, Cassandra und MongoDB

Guten Tag, Freunde. Bevor wir in die zweite Phase der Maifeiertage gehen, möchten wir Ihnen Materialien zur Verfügung stellen, die wir im Vorfeld des Starts eines neuen Kurses übersetzt haben. „Relationale DBMS“.

Anwendungsentwickler verbringen viel Zeit damit, verschiedene relationale Datenbanken zu vergleichen, um diejenige auszuwählen, die am besten zur geplanten Arbeitslast passt. Die Anforderungen können unter anderem die Vereinfachung der Datenmodellierung, transaktionale Garantien, Lese-/Schreibleistungen, horizontale Skalierbarkeit und Ausfallsicherheit umfassen. Traditionell beginnt die Auswahl mit der Datenbankkategorie, SQL oder NoSQL, da jede Kategorie ein klares Set an Kompromissen bietet. Hohe Leistung in Bezug auf niedrige Latenz und hohe Bandbreite wird normalerweise als kompromissloses Erfordernis angesehen und ist daher für jede Datenbank in der Auswahl notwendig.

Ziel dieses Artikels ist es, Anwendungsentwicklern zu helfen, die richtige Wahl zwischen SQL und NoSQL im Kontext der Datenmodellierung für Anwendungen zu treffen. Wir werden eine SQL-Datenbank, nämlich PostgreSQL, sowie zwei NoSQL-Datenbanken – Cassandra und MongoDB – betrachten, um die Grundlagen des Datenbankdesigns zu erläutern, wie z. B. die Erstellung von Tabellen, das Befüllen dieser Tabellen, das Lesen von Daten aus Tabellen und deren Löschung. Im nächsten Artikel werden wir unbedingt Indizes, Transaktionen, JOINs, TTL-Direktiven und das Datenbankdesign auf JSON-Basis behandeln.

Was unterscheidet SQL von NoSQL?

SQL-Datenbanken erhöhen die Flexibilität von Anwendungen durch die transaktionssicheren ACID-Garantien sowie durch ihre Fähigkeit, Daten überraschend durch JOINs über bestehende normalisierte Modelle relationaler Datenbanken abzurufen.

Angesichts ihrer monolithischen/einzelknoten Architektur und der Nutzung des Master-Slave-Replikationsmodells zur Redundanz verfügen traditionelle SQL-Datenbanken nicht über zwei wesentliche Eigenschaften – die lineare Schreibskalierbarkeit (d.h. die automatische Aufteilung auf mehrere Knoten) und die automatische/null Datenverlust. Das bedeutet, dass das Volumen der empfangenen Daten die maximale Schreibkapazität eines Knotens nicht überschreiten kann. Darüber hinaus muss bei der Fehlertoleranz (in einer Architektur ohne Ressourcenaufteilung) eine gewisse zeitliche Datenverlust berücksichtigt werden. Hierbei ist zu beachten, dass kürzliche Commits noch nicht in der untergeordneten (Slave) Kopie reflektiert sind. Updates ohne Ausfallzeiten sind in SQL-Datenbanken ebenfalls schwer zu erreichen.

NoSQL-Datenbanken sind typischerweise von Natur aus verteilt, was bedeutet, dass die Daten in Sektionen aufgeteilt und über mehrere Knoten verteilt werden. Sie erfordern eine Denormalisierung. Das bedeutet, dass eingegebene Daten auch mehrfach kopiert werden müssen, um auf spezifische Abfragen zu reagieren, die Sie senden. Das übergeordnete Ziel ist es, eine hohe Leistung zu erzielen, indem die Anzahl der Shards während des Lesens minimiert wird. Daher ist das Argument, dass NoSQL von Ihnen verlangt, Ihre Abfragen zu modellieren, während SQL von Ihnen verlangt, Ihre Daten zu modellieren.

NoSQL konzentriert sich darauf, hohe Leistung in einem verteilten Cluster zu erreichen, und dies ist das Hauptargument für zahlreiche Designkompromisse bei Datenbanken, die den Verlust von ACID-Transaktionen, Joins und konsistente globale sekundäre Indizes einschließen.

Es wird oft gesagt, dass, obwohl NoSQL-Datenbanken eine lineare Skalierbarkeit beim Schreiben und eine hohe Fehlertoleranz bieten, der Verlust von Transaktionsgarantien sie für kritische Daten ungeeignet macht.

Die folgende Tabelle zeigt, wie sich das Datenmodellieren in NoSQL von SQL unterscheidet.

SQL und NoSQL: Warum brauchen wir beide?

Echte Anwendungen mit einer großen Anzahl von Benutzern, wie Amazon.com, Netflix, Uber und Airbnb, erfordern die Verarbeitung komplexer, heterogener Aufgaben. Zum Beispiel benötigt eine E-Commerce-Anwendung wie Amazon.com die Speicherung leichter, hochkritischer Daten wie Benutzerinformationen, Produktdetails, Bestellungen und Rechnungen, zusammen mit schwereren, aber weniger sensiblen Daten wie Produktbewertungen, Supportanfragen, Benutzeraktivitäten, Feedback und Empfehlungen. Natürlich stützen sich diese Anwendungen auf mindestens eine SQL-Datenbank zusammen mit mindestens einer NoSQL-Datenbank. In interregionalen und globalen Systemen fungiert die NoSQL-Datenbank als geo-verteilte Cache für Daten, die in einer vertrauenswürdigen Quelle, der SQL-Datenbank, die in einer bestimmten Region betrieben wird, gespeichert sind.

Wie kombiniert YugaByte DB SQL und NoSQL?

YugaByte DB ist die weltweit erste Open-Source-Datenbank, die einen log-orientierten hybriden Speicher-Engine verwendet und gleichzeitig mit NoSQL (Cassandra & Redis) und SQL (PostgreSQL) kompatibel ist. Sie unterstützt Auto-Sharding, sharding-basierte verteilte Konsensus-Replikation und verteilte ACID-Transaktionen, inspiriert von Google Spanner. Wie aus der folgenden Tabelle ersichtlich, führt YCQL, die mit Cassandra kompatible API von YugaByte DB, Konzepte für ein- und mehrschlüsselige ACID-Transaktionen sowie globale sekundäre Indizes in die NoSQL-API ein und eröffnet damit das Zeitalter der transaktionalen NoSQL-Datenbanken. Darüber hinaus führt YCQL, die mit PostgreSQL kompatible API von YugaByte DB, Konzepte für lineares Schreib-Skalieren und automatische Fehlertoleranz in die SQL-API ein und präsentiert der Welt verteilte SQL-Datenbanken. Da die YugaByte DB intrinsisch transaktional ist, kann die NoSQL-API nun im Kontext kritischer Daten verwendet werden.

Wie zuvor in dem Artikel „Introducing YSQL: Eine PostgreSQL-kompatible verteilte SQL-API für YugaByte DB“, hängt die Wahl zwischen SQL oder NoSQL in YugaByte DB vollständig von den Eigenschaften der zugrunde liegenden Arbeitslast ab:

Wenn die Hauptlast aus mehrschichtigen JOIN-Operationen besteht, sollten Sie bei der Auswahl von YSQL verstehen, dass Ihre Schlüssel auf mehrere Knoten verteilt sein können, was zu höheren Latenzen und/oder einer verringerten Bandbreite im Vergleich zu NoSQL führen kann.
Andernfalls wählen Sie eine der beiden NoSQL-APIs, wobei Sie bedenken sollten, dass Sie eine höhere Leistung bei Anfragen erzielen, die von einem Knoten gleichzeitig bedient werden. YugaByte DB kann als umfassende Datenbank für reale komplexe Anwendungen dienen, bei denen mehrere Arbeitslasten gleichzeitig verwaltet werden müssen.

Die Basis des Datenmodellierungslabors im nächsten Abschnitt bilden die mit PostgreSQL und Cassandra kompatiblen APIs der YugaByte DB-Datenbanken, im Gegensatz zu den Ausgangsdatenbanken. Dieser Ansatz hebt die Einfachheit der Interaktion mit zwei verschiedenen APIs (über zwei verschiedene Ports) des gleichen Datenbankclusters hervor, im Gegensatz zur Verwendung vollständig unabhängiger Cluster von zwei verschiedenen Datenbanken.
In den folgenden Abschnitten werden wir das Datenmodellierungs-Labor kennenlernen, um die Unterschiede und einige Gemeinsamkeiten der betrachteten Datenbanken zu veranschaulichen.

Datenmodellierungs-Labor

Datenbankinstallation

Da der Fokus auf dem Entwurf des Datenmodells liegt (und nicht auf komplexen Bereitstellungsarchitekturen), werden wir die Datenbanken in Docker-Containern auf unserem lokalen Computer einrichten und dann mit den entsprechenden Kommandozeilen-Schnittstellen interagieren.

Kompatibel mit PostgreSQL & Cassandra, die YugaByte DB

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

Zugriff über die Kommandozeile

Lassen Sie uns eine Verbindung zu den Datenbanken herstellen, indem wir die Kommandozeilen-Schnittstelle für die jeweiligen APIs verwenden.

PostgreSQL

. Angenommen, wir müssen in die Shell von — dies ist die Kommandozeilen-Schnittstelle zur Interaktion mit PostgreSQL. Zur Erleichterung bringt YugaByte DB psql direkt im bin-Ordner mit.

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

Cassandra,

cqlsh — ist eine Kommandozeilen-Shell, die zur Interaktion mit Cassandra und ihren kompatiblen Datenbanken über CQL (Cassandra Query Language) verwendet wird. Um die Benutzerfreundlichkeit zu erhöhen, wird YugaByte DB mit cqlsh im Verzeichnis bin.
Bitte beachten Sie, dass CQL von SQL inspiriert wurde und ähnliche Konzepte wie Tabellen, Zeilen, Spalten und Indizes aufweist. Da es sich jedoch um eine NoSQL-Sprache handelt, fügt es eine spezifische Reihe von Einschränkungen hinzu, von denen wir die meisten auch in anderen Artikeln behandeln werden.

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

MongoDB

mongo – ist eine Kommandozeilen-Shell zur Interaktion mit MongoDB. Sie befindet sich im bin-Verzeichnis der MongoDB-Installation.

docker exec -it my-mongo bash 
cd bin
mongo

Tabelle erstellen

Jetzt können wir über die Befehlszeile mit der Datenbank interagieren, um verschiedene Operationen durchzuführen. Lassen Sie uns mit der Erstellung einer Tabelle beginnen, die Informationen über Songs von verschiedenen Künstlern speichert. Diese Songs können Teil eines Albums sein. Zudem gibt es optionale Attribute für den Song – Erscheinungsjahr, Preis, Genre und Bewertung. Wir müssen zusätzliche Attribute in Betracht ziehen, die in Zukunft benötigt werden könnten, über das Feld „Tags“. Dieses kann semi-strukturierte Daten in Form von Schlüssel-Wert-Paaren 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,

Die Erstellung einer Tabelle in Cassandra ähnelt sehr der in PostgreSQL. Einer der Hauptunterschiede ist das Fehlen von Integritätsconstraints (z. B. NOT NULL), jedoch liegt dies in der Verantwortung der Anwendung und nicht der NoSQL-Datenbank.. Der Primärschlüssel besteht aus dem Partition Key (Spalte Artist im folgenden Beispiel) und einer Gruppe von Clustering-Spalten (Spalte SongTitle im folgenden Beispiel). Der Partition Key bestimmt, in welche Partition/Shard die Zeile platziert werden soll, während die Clustering-Spalten angeben, wie die Daten innerhalb des aktuellen Shards organisiert sein 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 (Database) (vergleichbar mit Keyspace in Cassandra), die Sammlungen (Collections) (vergleichbar mit Tabellen) enthalten, in denen Dokumente (Documents) (vergleichbar mit Zeilen in einer Tabelle) gespeichert sind. In MongoDB ist prinzipiell keine Ausgangsschema-Definition erforderlich. Der Befehl „use database“, die unten angezeigt wird, erstellt eine Datenbankinstanz beim ersten Aufruf und ändert den Kontext für die neu erstellte Datenbank. Sogar Sammlungen müssen nicht explizit erstellt werden; sie werden automatisch erstellt, sobald das erste Dokument in eine neue Sammlung hinzugefügt wird. Beachten Sie, dass MongoDB standardmäßig die Testdatenbank verwendet. Daher wird jede Sammlungsebene-Operation ohne Angabe einer spezifischen Datenbank standardmäßig in dieser ausgeführt.

verwende meineNeueDatenbank;

Informationen zur Tabelle abrufen
PostgreSQL

d Musik
Tabelle "public.music"
    Spalte   |         Typ          | Sortierung | Nullable | Standard 
-------------+---------------------+-----------+----------+--------
 Künstler    | Zeichenkette (20)    |           | nicht null | 
 Titel       | Zeichenkette (30)    |           | nicht null | 
 Albumtitel  | Zeichenkette (25)    |           |          | 
 Jahr        | ganze Zahl          |           |          | 
 Preis       | doppelte Genauigkeit |           |          | 
 Genre       | Zeichenkette (10)    |           |          | 
 Kritikerbewertung | doppelte Genauigkeit |           |          | 
 Tags        | Text                |           |          | 
Indizes:
    "music_pkey" PRIMÄRSCHLÜSSEL, btree (Künstler, Titel)

Cassandra,

BESCHREIBE TABELLE MUSIK;
ERSTELLE TABELLE myapp.music (
    Künstler Text,
    Titel Text,
    Albumtitel Text,
    Jahr int,
    Preis float,
    Genre Text,
    Tags Text,
    PRIMÄRSCHLÜSSEL (Künstler, Titel)
) MIT CLUSTERING-ORDER BY (Titel ASC)
    UND standard_time_to_live = 0
    UND Transaktionen = {'aktiviert': 'falsch'};

MongoDB

verwende meineNeueDatenbank;
zeige Sammlungen an;

Daten in die Tabelle einfügen
PostgreSQL

INSERT INTO Music 
    (Künstler, Songtitel, Albumtitel, 
    Jahr, Preis, Genre, Kritikerbewertung, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2,14, 'Country', 7,8,
    '{"Komponisten": ["Smith", "Jones", "Davis"],"LängeInSekunden": 214}'
);
INSERT INTO Music 
    (Künstler, Songtitel, Albumtitel, 
    Preis, Genre, Kritikerbewertung)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1,98, 'Country', 8,4
);
INSERT INTO Music 
    (Künstler, Songtitel, Albumtitel, 
    Preis, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0,99, 'Rock'
);
INSERT INTO Music 
    (Künstler, Songtitel, Albumtitel, 
    Preis, 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 ist der Ausdruck INSERT in Cassandra sehr ähnlich wie das entsprechende in PostgreSQL. Es gibt jedoch einen wesentlichen Unterschied in der Semantik. In Cassandra INSERT ist es tatsächlich eine Operation UPSERT, bei der die neuesten Werte zur Zeile hinzugefügt werden, falls die Zeile bereits existiert.

Die Eingabe von Daten erfolgt ähnlich wie in PostgreSQL. INSERT oben

MongoDB

Obwohl MongoDB eine NoSQL-Datenbank ist, ähnlich wie Cassandra, hat ihre Datenoperation nichts mit dem semantischen Verhalten von Cassandra gemein. In MongoDB insert() hat keine Möglichkeiten UPSERT, was es PostgreSQL ähnlich macht. Daten werden standardmäßig ohne _idspecified hinzugefügt führt zur Hinzufügung eines neuen Dokuments zur Sammlung.

db.music.insert( { Künstler: "No One You Know", Titel: "Call Me Today", Album: "Somewhat Famous", Jahr: 2015, Preis: 2,14, Genre: "Country", Tags: { Komponisten: ["Smith", "Jones", "Davis"], LängeInSekunden: 214 } } ); db.music.insert( { Künstler: "No One You Know", Titel: "My Dog Spot", Album: "Hey Now", Preis: 1,98, Genre: "Country", Kritikerwertung: 8,4 } ); db.music.insert( { Künstler: "The Acme Band", Titel: "Look Out, World", Album:"The Buck Starts Here", Preis: 0,99, Genre: "Rock" } ); db.music.insert( { Künstler: "The Acme Band", Titel: "Still In Love", Album:"The Buck Starts Here", Preis: 2,47, Genre: "Rock", Tags: { RadioStationenDieSpielen:["KHCR", "KBQX", "WTNR", "WJJH"], Tourdaten: { Seattle: "20150625", Cleveland: "20150630" }, Rotation: "Heavy" } } );

Tabellenabfrage

Möglicherweise liegt der bedeutendste Unterschied zwischen SQL und NoSQL im Hinblick auf die Abfrageerstellung in der Verwendung von Formulierungen FROM und WHERE. SQL ermöglicht nach dem Ausdruck FROM mehrere Tabellen auszuwählen, während der Ausdruck mit WHERE beliebig komplex sein kann (einschließlich Operationen JOIN zwischen den Tabellen). NoSQL hingegen neigt dazu, strenge Einschränkungen aufzuerlegen, FROMund arbeitet nur mit einer angegebenen Tabelle, während in WHEREimmer der Primärschlüssel angegeben werden muss. Dies liegt am Bestreben, die Leistung von NoSQL zu steigern, über das wir zuvor gesprochen haben. Dieses Bestreben führt zu einer drastischen Reduzierung jeglicher Tabellen- und schlüsselübergreifenden Interaktionen. Dies kann zu einer erheblichen Verzögerung in der Knotenkommunikation bei der Beantwortung von Anfragen führen und sollte daher im Prinzip möglichst vermieden werden. Zum Beispiel verlangt Cassandra, dass Abfragen auf bestimmte Operatoren beschränkt sind (nur) =, IN, , =>, <=) bei Partitionsschlüsseln, mit Ausnahme von Anfragen für sekundäre Indizes (hier ist nur der Operator = erlaubt).

PostgreSQL

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

Alle Lieder des Künstlers anzeigen;
Alle Lieder des Künstlers anzeigen, die mit dem ersten Teil des Titels übereinstimmen;
Alle Lieder des Künstlers anzeigen, die ein bestimmtes Wort im Titel enthalten 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 Abfragen wird nur die erste in Cassandra ohne Änderungen funktionieren, da der Operator LIKE nicht auf Cluster-Spalten wie SongTitle. In diesem Fall sind nur die Operatoren erlaubt, = und 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, besteht die Hauptmethode zur Erstellung von Abfragen in MongoDB aus db.collection.find(). Diese Methode enthält den Namen der Sammlung ausdrücklich (music im folgenden Beispiel), daher ist eine Abfrage über mehrere Sammlungen nicht erlaubt.

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

Alle Zeilen der Tabelle auslesen

Das Lesen aller Zeilen ist einfach ein spezieller Fall des Abfrageformats, das wir zuvor betrachtet haben.

PostgreSQL

SELECT * 
FROM Music;

Cassandra,

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB

db.music.find( {} );

Daten in einer Tabelle bearbeiten

PostgreSQL

PostgreSQL bietet eine Anweisung UPDATE zum Ändern von Daten. Sie hat keine Fähigkeiten UPSERT, weshalb die Ausführung dieser Anweisung fehlerhaft ist, 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';

Cassandra,

In Cassandra gibt es UPDATE ein entsprechendes Pendant zu PostgreSQL. UPDATE hat die gleiche Semantik UPSERT, ähnlich wie INSERT.

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB
Operation update() in MongoDB kann ein bestehendes Dokument vollständig aktualisieren oder nur bestimmte Felder ändern. Standardmäßig wird nur ein Dokument mit deaktivierter Semantik aktualisiert UPSERT. Die Aktualisierung mehrerer Dokumente und das Verhalten sind ähnlich UPSERT , können erreicht werden, indem zusätzliche Flags für die Operation gesetzt werden. Im folgenden Beispiel wird das Genre eines bestimmten Künstlers anhand seines Songs aktualisiert.

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

Daten aus einer Tabelle löschen

PostgreSQL

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

Cassandra,

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB

In MongoDB gibt es zwei Arten von Operationen zum Löschen von Dokumenten — deleteOne() /deleteMany() und remove(). Beide Typen löschen Dokumente, liefern jedoch unterschiedliche Ergebnisse.

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

Löschen einer Tabelle

PostgreSQL

DROP TABLE Music;

Cassandra,

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB

db.music.drop();

Fazit

Die Debatten über die Wahl zwischen SQL und NoSQL toben seit über 10 Jahren. Es gibt zwei Hauptaspekte dieser Debatte: die Architektur des Datenbankkerns (monolithisches, transaktionales SQL versus verteiltes, nicht-transaktionales NoSQL) und den Ansatz zur Datenbankgestaltung (Datenmodellierung in SQL versus Modellierung Ihrer Abfragen in NoSQL).

Mit einer verteilten transaktionalen Datenbank wie YugaByte DB können die Debatten über die Datenbankarchitektur leicht ausgeräumt werden. Während die Datenmengen größer werden als das, was auf einem einzelnen Knoten gespeichert werden kann, wird eine vollständig verteilte Architektur, die lineare Schreibskalierbarkeit mit automatischem Sharding/Umschichtung unterstützt, unerlässlich.

Neben dem, was in einem der Artikel gesagt wurde Google Cloud, transaktionale, streng konsistente Architekturen werden nun breiter eingesetzt, um eine bessere Flexibilität in der Entwicklung zu gewährleisten als nicht-transaktionale, letztendlich konsistente Architekturen.

Zurück zur Diskussion über das Design von Datenbanken ist es fair zu sagen, dass beide Designansätze (SQL und NoSQL) für jede komplexe reale Anwendung notwendig sind. Der SQL-Ansatz des "Datenmodellierens" ermöglicht es Entwicklern, sich besser an sich ändernde Geschäftsanforderungen anzupassen, während der NoSQL-Ansatz des "Abfragemodellierens" denselben Entwicklern ermöglicht, große Datenmengen mit geringer Latenz und hoher Bandbreite zu bearbeiten. Aus diesem Grund bietet YugaByte DB sowohl SQL- als auch NoSQL-APIs im gemeinsamen Kern an, anstatt eine der beiden Ansätze zu bevorzugen. Darüber hinaus gewährleistet die Kompatibilität mit gängigen Datenbanksystemen wie PostgreSQL und Cassandra, dass Entwickler keine andere Sprache lernen müssen, um mit dem verteilten, streng konsistenten Datenbankkern zu arbeiten.

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

Wir wünschen Ihnen ein schönes restliches Wochenende und laden Sie ein zu einem kostenlosen Webinar, das bereits am 14. Mai stattfinden wird.

Quelle: habr.com

Datenbankdesign-Grundlagen – Vergleich von PostgreSQL, Cassandra und MongoDB

Juri Gagarin