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

Hallo, Freunde. Vor dem Beginn der zweiten Mai-Feiertagswoche teilen wir mit euch ein Material, das wir im Vorfeld des Starts eines neuen Kurses übersetzt haben. „Relationale DBMS“.

Entwickler verbringen viel Zeit damit, verschiedene relationale Datenbanken zu vergleichen, um diejenige auszuwählen, die am besten für die geplante Arbeitslast geeignet ist. Die Anforderungen können einfaches Datenmodellieren, transaktionale Garantien, Lese-/Schreibleistung, horizontale Skalierbarkeit und Ausfallsicherheit umfassen. Traditionell beginnt die Auswahl mit der Datenbankkategorie, SQL oder NoSQL, da jede Kategorie einen klaren Satz von Kompromissen bietet. Eine hohe Leistung im Hinblick auf niedrige Latenz und hohe Bandbreite wird in der Regel als nicht verhandelbar betrachtet, und ist daher für jede Datenbank in der Auswahl erforderlich.

Ziel dieses Artikels ist es, Entwicklern zu helfen, die richtige Wahl zwischen SQL und NoSQL im Kontext der Datenmodellierung ihres Anwendungs 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. das Erstellen von Tabellen, das Befüllen dieser Tabellen, das Auslesen von Daten und das Löschen von Daten. In unserem nächsten Artikel werden wir auf Indizes, Transaktionen, JOINs, TTL-Anweisungen und die Gestaltung von Datenbanken auf der Grundlage von JSON eingehen.

Was ist der Unterschied zwischen SQL und NoSQL?

SQL-Datenbanken erhöhen die Flexibilität von Anwendungen durch transaktionale ACID-Garantien sowie durch die Fähigkeit, Daten auf unerwartete Weise mit JOINs über bestehende normalisierte Modelle relationaler Datenbanken abzufragen.

Angesichts ihrer monolithischen/einzelknoten Architektur und der Verwendung des Master-Slave-Replikationsmodells zur Redundanz haben traditionelle SQL-Datenbanken zwei wichtige Eigenschaften nicht – die lineare Skalierbarkeit der Schreibvorgänge (d.h. die automatische Verteilung auf mehrere Knoten) und die automatische/null Datenverlustgarantie. Das bedeutet, dass das Volumen der empfangenen Daten nicht die maximale Schreibkapazität eines Knotens überschreiten kann. Darüber hinaus sollte ein gewisser zeitlicher Datenverlust bei der Fehlertoleranz (in einer Architektur ohne Ressourcenaufteilung) berücksichtigt werden. Dabei ist zu beachten, dass aktuelle Commits noch nicht in der Slave-Kopie reflektiert sind. Aktualisierungen ohne Ausfallzeiten sind ebenfalls in SQL-Datenbanken schwer zu erreichen.

NoSQL-Datenbanken sind naturgemäß in der Regel verteilt, d.h. die Daten werden in Abschnitte aufgeteilt und auf mehrere Knoten verteilt. Sie erfordern eine Denormalisierung. Das bedeutet, dass die eingegebenen Daten mehrere Male kopiert werden müssen, um auf die spezifischen Anfragen zu antworten, die Sie senden. Das übergeordnete Ziel besteht darin, eine hohe Leistung zu erzielen, indem die Anzahl der Shards, die während des Lesens verfügbar sind, verringert wird. Daraus folgt die Behauptung, dass NoSQL von Ihnen verlangt, Ihre Abfragen zu modellieren, während SQL von Ihnen verlangt, Ihre Daten zu modellieren.

NoSQL konzentriert sich auf die Erreichung einer hohen Leistung in einem verteilten Cluster, und dies ist die Hauptbegründung für viele Kompromisse im Datenbankdesign, die den Verlust von ACID-Transaktionsgarantien, JOINs und konsistenten globalen Sekundärindizes umfassen.

Es gibt die Meinung, dass, obwohl NoSQL-Datenbanken eine lineare Schreibskalierbarkeit und hohe Fehlertoleranz bieten, der Verlust von Transaktionsgarantien sie ungeeignet für kritische Daten macht.

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

SQL und NoSQL: Warum beide benötigt werden?

In realen Anwendungen mit einer großen Anzahl von Nutzern, wie Amazon.com, Netflix, Uber und Airbnb, laufen komplexe und unterschiedliche Aufgaben ab. Zum Beispiel benötigt eine E-Commerce-Anwendung wie Amazon.com leichte, hochkritische Daten, wie Informationen über Nutzer, Produkte, Bestellungen, Rechnungen, zusammen mit schwereren, aber weniger sensiblen Daten, wie Produktbewertungen, Supportnachrichten, Nutzeraktivitäten, Feedback und Empfehlungen von Nutzern. Natürlich verlassen sich diese Anwendungen mindestens auf eine SQL-Datenbank neben mindestens einer NoSQL-Datenbank. In interregionalen und globalen Systemen fungiert die NoSQL-Datenbank als geografisch verteilte Cache für Daten, die in einer vertrauenswürdigen Quelle, einer SQL-Datenbank, die in einem bestimmten Gebiet arbeitet, gespeichert sind.

Wie vereint YugaByte DB SQL und NoSQL?

YugaByte DB, die auf einer logorientierten gemischten Engine für Speicherung, Auto-Sharding, sharding-basierter verteilten Konsensreplikation und verteilten ACID-Transaktionen (inspiriert von Google Spanner) basiert, ist die weltweit erste Open-Source-Datenbank, die sowohl mit NoSQL (Cassandra & Redis) als auch mit SQL (PostgreSQL) kompatibel ist. Wie in der untenstehenden Tabelle dargestellt, fügt YCQL, die Cassandra-kompatible API von YugaByte DB, Konzepte für ACID-Transaktionen mit einem und mehreren Schlüsseln sowie globale sekundäre Indizes in die NoSQL-API ein, wodurch eine Ära von transaktionalen NoSQL-Datenbanken eröffnet wird. Darüber hinaus fügt YCQL, die PostgreSQL-kompatible API von YugaByte DB, Konzepte für lineares Schreiber-Skalieren und automatische Fehlertoleranz zur SQL-API hinzu und präsentiert die Welt verteilte SQL-Datenbanken. Da die YugaByte DB von Natur aus transaktional ist, kann die NoSQL-API nun im Kontext kritischer Daten verwendet werden.

Wie bereits in dem Artikel „Introducing YSQL: A PostgreSQL Compatible Distributed SQL API for 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 zugrunde liegende Arbeitslast mehrschlüsselige JOIN-Operationen umfasst, sollten Sie bei der Wahl von YSQL beachten, dass Ihre Schlüsseldaten über mehrere Knoten verteilt sein können, was zu höheren Latenzen und/oder einer verminderten Bandbreite im Vergleich zu NoSQL führen kann.
Andernfalls wählen Sie eine der beiden NoSQL-APIs, wobei Sie beachten, dass Sie eine bessere Leistung bei Anfragen erhalten, die von einem Knoten zur selben Zeit verarbeitet werden. YugaByte DB kann als zentrale Datenbank für realistische komplexe Anwendungen dienen, in denen mehrere Arbeitslasten gleichzeitig verwaltet werden müssen.

Das Datenmodellierungslabor im nächsten Abschnitt basiert auf den mit PostgreSQL und Cassandra kompatiblen APIs von YugaByte DB, im Gegensatz zu den ursprünglichen Datenbanken. Dieser Ansatz betont die Einfachheit der Interaktion mit zwei verschiedenen APIs (auf zwei unterschiedlichen Ports) eines und desselben Datenbankclusters im Gegensatz zur Verwendung völlig unabhängiger Cluster von zwei verschiedenen Datenbanken.
In den folgenden Abschnitten werden wir das Datenmodellierungslabor kennenlernen, um die Unterschiede und einige Gemeinsamkeiten der betrachteten Datenbanken zu illustrieren.

Datenmodellierungslabor

Datenbankinstallation

Angesichts des Schwerpunkts auf der Gestaltung des Datenmodells (nicht auf komplexen Bereitstellungsarchitekturen) werden wir die Datenbanken in Docker-Containern auf dem lokalen Computer installieren und dann mit ihnen über die entsprechende Kommandozeile interagieren.

Mit PostgreSQL & Cassandra kompatible 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

Lasst uns auf die Datenbanken zugreifen, mithilfe der Kommandozeile für die entsprechenden APIs.

PostgreSQL

psql — ist eine Kommandozeile zur Interaktion mit PostgreSQL. Zur Vereinfachung wird YugaByte DB mit psql direkt im bin-Ordner geliefert.

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

Cassandra

cqlsh — ist eine Kommandozeile zur Interaktion mit Cassandra und ihren kompatiblen Datenbanken über CQL (Cassandra Query Language). Zu Ihrer Bequemlichkeit wird YugaByte DB mit cqlsh im Verzeichnis bin.
Bitte beachten Sie, dass CQL von SQL inspiriert wurde und ähnliche Konzepte für Tabellen, Zeilen, Spalten und Indizes hat. Als NoSQL-Sprache fügt es jedoch eine bestimmte Menge an Einschränkungen hinzu, von denen die meisten auch in anderen Artikeln behandelt werden.

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

MongoDB

mongo – dies ist eine Befehlszeilenoberfläche zur Interaktion mit MongoDB. Sie finden sie im Bin-Verzeichnis der MongoDB-Installation.

docker exec -it my-mongo bash 
cd bin
mongo

Tabelle erstellen

Jetzt können wir mit der Datenbank interagieren, um verschiedene Operationen über die Befehlszeile durchzuführen. Lassen Sie uns mit der Erstellung einer Tabelle beginnen, die Informationen über Songs speichert, die von verschiedenen Künstlern geschrieben wurden. Diese Songs können Teil eines Albums sein. Außerdem gibt es optionale Attribute für den Song – Erscheinungsjahr, Preis, Genre und Bewertung. Wir müssen zusätzliche Attribute berücksichtigen, die in Zukunft benötigt werden könnten, über das Feld „Tags“. Es kann halbstukturierte 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ätsbedingungen (z.B. NOT NULL), aber dies liegt in der Verantwortung der Anwendung und nicht der NoSQL-Datenbank.. Der Primärschlüssel besteht aus dem Partitionsschlüssel (Spalte Artist im folgenden Beispiel) und einer Reihe von Cluster-Spalten (Spalte SongTitle im folgenden Beispiel). Der Partitionsschlüssel bestimmt, in welche Partition/Shard die Zeile eingefügt werden soll, und die Cluster-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 (Database) (ähnlich wie Keyspace in Cassandra), wo es Sammlungen (Collections) (ähnlich wie Tabellen) gibt, in denen Dokumente (Documents) (ähnlich wie Zeilen in einer Tabelle) liegen. In MongoDB ist grundsätzlich keine ursprüngliche Schema-Definition erforderlich. Der Befehl „use database“, der unten angezeigt wird, erstellt eine Instanz der Datenbank beim ersten Aufruf und ändert den Kontext für die neu erstellte Datenbank. Selbst Sammlungen müssen nicht explizit erstellt werden, sie werden automatisch erstellt, einfach durch das Hinzufügen des ersten Dokuments zu einer neuen Sammlung. Beachten Sie, dass MongoDB standardmäßig eine Testdatenbank verwendet; daher wird jede Sammlungsebene-Operation ohne Angabe einer bestimmten Datenbank standardmäßig in dieser durchgeführt.

use myNewDatabase;

Informationen über die Tabelle abrufen
PostgreSQL

d Musik
Tabelle "public.music"
    Spalte     |         Typ           | Kollation | Nullable | Standard 
--------------+-----------------------+-----------+----------+--------
 Künstler     | Zeichenfolge variabel(20) |           | nicht null | 
 Liedtitel    | Zeichenfolge variabel(30) |           | nicht null | 
 Albentitel   | Zeichenfolge variabel(25) |           |          | 
 Jahr         | Ganzzahl              |           |          | 
 Preis        | doppelte Genauigkeit   |           |          | 
 Genre        | Zeichenfolge variabel(10) |           |          | 
 Kritikerbewertung | doppelte Genauigkeit |           |          | 
 Tags         | Text                  |           |          | 
Indizes:
    "music_pkey" PRIMÄRSCHLÜSSEL, btree (Künstler, Liedtitel)

Cassandra

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

MongoDB

verwende meineNeueDatenbank;
zeige Sammlungen;

Daten in die Tabelle einfügen
PostgreSQL

EINFÜGEN IN Musik 
    (Künstler, Liedtitel, Albentitel, 
    Jahr, Preis, Genre, Kritikerbewertung, 
    Tags)
WERT(EINEN (
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Komponisten": ["Smith", "Jones", "Davis"],"LängeInSekunden": 214}'
);
EINFÜGEN IN Musik 
    (Künstler, Liedtitel, Albentitel, 
    Preis, Genre, Kritikerbewertung)
WERT(EINEN (
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
EINFÜGEN IN Musik 
    (Künstler, Liedtitel, Albentitel, 
    Preis, Genre)
WERT(EINEN (
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
EINFÜGEN IN Musik 
    (Künstler, Liedtitel, Albentitel, 
    Preis, Genre, 
    Tags)
WERT(EINEN (
    '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 Ausdruck INSERT in Cassandra dem in PostgreSQL sehr ähnlich. Es gibt jedoch einen großen Unterschied in der Semantik. In Cassandra INSERT ist tatsächlich eine Operation UPSERT, bei der die letzten Werte zur Zeile hinzugefügt werden, falls die Zeile bereits existiert.

Die Dateneingabe erfolgt ähnlich wie in PostgreSQL INSERT über

MongoDB

Obwohl MongoDB eine NoSQL-Datenbank ist, ähnlich wie Cassandra, hat seine Dateneingabeoperation nichts mit dem semantischen Verhalten in Cassandra zu tun. In MongoDB insert() hat keine Möglichkeiten UPSERT, was es ähnlich wie PostgreSQL macht. Das Hinzufügen von Daten ohne _idspecified führt zum Hinzufügen eines neuen Dokuments zur Sammlung.

db.music.insert( { artist: "Niemand, den Sie kennen", songTitle: "Rufen Sie mich heute an", albumTitle: "Etwas Berühmt", year: 2015, price: 2.14, genre: "Country", tags: { Composers: ["Smith", "Jones", "Davis"], LengthInSeconds: 214 } } ); db.music.insert( { artist: "Niemand, den Sie kennen", songTitle: "Mein Hund Spot", albumTitle: "Hey jetzt", price: 1.98, genre: "Country", criticRating: 8.4 } ); db.music.insert( { artist: "Die Acme-Band", songTitle: "Achtung, Welt", albumTitle:"Der Buck beginnt hier", price: 0.99, genre: "Rock" } ); db.music.insert( { artist: "Die Acme-Band", songTitle: "Immer noch verliebt", albumTitle:"Der Buck beginnt hier", price: 2.47, genre: "Rock", tags: { radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"], tourDates: { Seattle: "20150625", Cleveland: "20150630" }, rotation: "Heavy" } } );

Abfrage der Tabelle

Der möglicherweise signifikanteste Unterschied zwischen SQL und NoSQL im Hinblick auf die Abfrageerstellung besteht in der Verwendung von Formulierungen FROM und WHERE. SQL erlaubt nach dem Ausdruck FROM das Auswählen mehrerer Tabellen, und ein Ausdruck mit WHERE kann beliebig komplex sein (einschließlich Operationen JOIN zwischen Tabellen). NoSQL hingegen neigt dazu, strenge Einschränkungen auf FROMzu legen, und arbeitet nur mit einer angegebenen Tabelle, während in WHERE, der primäre Schlüssel muss immer angegeben werden. Dies ist auf das Bestreben zurückzuführen, die Leistung von NoSQL zu steigern, über das wir zuvor gesprochen haben. Dieses Bestreben führt dazu, dass jegliche Cross-Tabellen- und Cross-Key-Interaktionen minimiert werden. Dies kann zu erheblichen Verzögerungen in der Knotenumgebung bei der Beantwortung von Anfragen führen, weshalb es im Prinzip am besten vermieden werden sollte. Zum Beispiel erfordert Cassandra, dass Anfragen auf bestimmte Operatoren beschränkt sind (nur erlaubt sind =, IN, , =>, <=) über Partition-Schlüsseln, es sei denn, es handelt sich um eine Sekundärindex-Abfrage (hier ist nur der Operator = erlaubt).

PostgreSQL

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

Alle Songs des Künstlers anzeigen;
Alle Songs des Künstlers anzeigen, die mit dem Anfang des Titels übereinstimmen;
Alle Songs des Künstlers anzeigen, 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 Abfragen wird nur die erste in Cassandra ohne Änderungen funktionieren, da der Operator LIKE nicht auf Clusterschlüsselspalten wie SongTitle. In diesem Fall sind nur die Operatoren zulässig = 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 zum Erstellen von Abfragen in MongoDB in db.collection.find(). Diese Methode enthält ausdrücklich den Namen der Sammlung (music im folgenden Beispiel), weshalb eine Abfrage über mehrere Sammlungen nicht erlaubt ist.

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

Alle Zeilen der Tabelle lesen

Das Lesen aller Zeilen ist einfach ein Spezialfall des Abfrage-Templates, das wir zuvor betrachtet haben.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB

db.music.find( {} );

Daten in der Tabelle bearbeiten

PostgreSQL

PostgreSQL stellt die Anweisung UPDATE zum Ändern von Daten bereit. Diese hat keine Fähigkeiten UPSERT, weshalb die Ausführung dieser Anweisung mit einem Fehler enden würde, wenn die Zeilen nicht mehr in der Datenbank vorhanden sind.

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

Cassandra

In Cassandra gibt es UPDATE eine vergleichbare Funktion wie in PostgreSQL. UPDATE hat die gleiche Semantik UPSERT, ähnlich INSERT.

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB
Operation update() In MongoDB kann ein vorhandenes Dokument vollständig aktualisiert oder nur bestimmte Felder aktualisiert werden. Standardmäßig wird nur ein Dokument mit deaktivierter Semantik aktualisiert. UPSERT. Die Aktualisierung mehrerer Dokumente und das Verhalten sind ähnlich. UPSERT Das kann durch das Setzen zusätzlicher Flags für die Operation erreicht werden. Wie im folgenden Beispiel die Aktualisierung des Genres eines bestimmten Künstlers anhand seines Liedes erfolgt.

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

Tabelle löschen

PostgreSQL

DROP TABLE Music;

Cassandra

Entsprechend dem obigen Beispiel in PostgreSQL.

MongoDB

db.music.drop();

Fazit

Die Debatte über die Wahl zwischen SQL und NoSQL tobt bereits seit mehr als 10 Jahren. Es gibt zwei Hauptaspekte dieser Debatte: die Architektur des Datenbankkerns (monolithisches, transaktionales SQL gegen verteiltes, nicht-transaktionales NoSQL) und den Ansatz zum Datenbankdesign (Datenmodellierung in SQL gegen Modellierung Ihrer Anfragen in NoSQL).

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

Zusätzlich zu dem, was in einem der Artikel gesagt wurde Google Cloud, werden transaktionale, strikt konsistente Architekturen jetzt breiter eingesetzt, um mehr Flexibilität in der Entwicklung zu gewährleisten als nicht-transaktionale, letztendlich konsistente Architekturen.

Wenn wir das Design von Datenbanken betrachten, ist es fair zu sagen, dass beide Ansätze (SQL und NoSQL) für jede komplexe reale Anwendung notwendig sind. Der SQL-Ansatz „Datenmodellierung“ ermöglicht es Entwicklern, sich leichter an die sich ändernden Geschäftsanforderungen anzupassen, während der NoSQL-Ansatz „Abfragemodellierung“ es denselben Entwicklern ermöglicht, mit großen Datenmengen bei geringer Latenz und hoher Bandbreite zu arbeiten. Aus diesem Grund bietet YugaByte DB sowohl SQL- als auch NoSQL-APIs im gemeinsamen Kern an und propagiert nicht einen der Ansätze. Darüber hinaus gewährleistet YugaByte DB durch die Kompatibilität mit beliebten Datenbanksprachen, einschließlich PostgreSQL und Cassandra, dass die Entwickler keine andere Sprache lernen müssen, um mit dem verteilten strengen konsistenten Datenbankkern zu arbeiten.

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

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

Quelle: habr.com