Grundlagen der Datenmodellierung - PostgreSQL vs. Cassandra vs. MongoDB

Anwendungsentwickler verbringen in der Regel viel Zeit mit der Evaluierung mehrerer operativer Datenbanken, um diejenige Datenbank zu finden, die für ihre Arbeitslastanforderungen am besten geeignet ist. Diese Anforderungen umfassen eine vereinfachte Datenmodellierung, Transaktionsgarantien, Lese- / Schreibleistung, horizontale Skalierung und Fehlertoleranz. Traditionell beginnt diese Auswahl mit den SQL- und NoSQL-Datenbankkategorien, da jede Kategorie eine Reihe von Kompromissen aufweist. Hohe Leistung in Bezug auf niedrige Latenz und hohen Durchsatz wird normalerweise als nicht kompromittierbare Anforderung behandelt und wird daher in jeder ausgewählten Datenbank erwartet.

Dieser Beitrag soll Anwendungsentwicklern helfen, die Wahl zwischen SQL und NoSQL im Kontext der Datenmodellierungsanforderungen einer Anwendung zu verstehen. Wir verwenden eine SQL-Datenbank, nämlich PostgreSQL, und zwei NoSQL-Datenbanken, nämlich Cassandra und MongoDB, als Beispiele, um die Grundlagen der Datenmodellierung wie das Erstellen von Tabellen, das Einfügen von Daten, das Durchführen von Scans und das Löschen von Daten zu erläutern. In einem anschließenden Beitrag werden erweiterte Themen wie Indizes, Transaktionen, Verknüpfungen, TTL-Anweisungen (Time-to-Live) und JSON-basierte Modellierung von Dokumentdaten behandelt.

Wie unterscheidet sich NoSQL von SQL in der Datenmodellierung?

SQL-Datenbanken erhöhen die Flexibilität von Anwendungen durch ACID-Transaktionsgarantien sowie durch die Möglichkeit, Daten mithilfe von JOINs auf unvorhergesehene Weise zusätzlich zu vorhandenen normalisierten relationalen Datenmodellen abzufragen.

In Anbetracht ihrer monolithischen / Einzelknoten-Architektur und der Verwendung eines Master-Slave-Replikationsmodells für Redundanz fehlen traditionellen SQL-Datenbanken zwei wichtige Funktionen: lineare Schreibskalierbarkeit (d. H. Automatisches Sharding über mehrere Knoten hinweg) und automatisches Failover ohne Datenverlust. Dies bedeutet, dass das aufgenommene Datenvolumen den maximalen Schreibdurchsatz eines einzelnen Knotens nicht überschreiten kann. Darüber hinaus ist bei einem Failover (auf Shared-Nothing-Speicherarchitekturen) mit einem vorübergehenden Datenverlust zu rechnen, da die letzten Festschreibungen noch nicht auf dem Slave-Replikat angezeigt wurden. Auch in der SQL-Datenbankwelt sind Upgrades ohne Ausfallzeiten nur sehr schwer möglich.

NoSQL-DBs sind in der Regel in der Natur verteilt, in der Daten auf mehrere Knoten aufgeteilt oder aufgeteilt werden. Sie schreiben eine Denormalisierung vor, was bedeutet, dass eingefügte Daten auch mehrmals kopiert werden müssen, um die spezifischen Fragen zu beantworten, die Sie haben. Das übergeordnete Ziel besteht darin, eine hohe Leistung zu erzielen, indem die Anzahl der Shards, auf die während der Lesezeit zugegriffen wird, explizit verringert wird. Daher die Aussage, dass Sie bei NoSQL Ihre Abfragen modellieren müssen, während Sie bei SQL Ihre Daten modellieren müssen.

Der Fokus von NoSQL auf die Erzielung einer hohen Leistung in einem verteilten Cluster wird als Hauptgrund für mehrere Kompromisse bei der Datenmodellierung angegeben, zu denen der Verlust von ACID-Transaktionen, JOINs und konsistenten globalen Sekundärindizes gehören.

Allgemein wird davon ausgegangen, dass NoSQL-Datenbanken zwar eine lineare Schreibskalierbarkeit und eine hohe Fehlertoleranz bieten, jedoch aufgrund des Verlusts von Transaktionsgarantien nicht für geschäftskritische Daten geeignet sind.

In der folgenden Tabelle wird erläutert, wie sich die NoSQL-Datenmodellierung von der von SQL unterscheidet.

SQL vs. NoSQL - Unterschiede bei der Modellierung von Schlüsseldaten

SQL & NoSQL: Warum brauchen Sie beides?

Die meisten realen Anwendungen mit ansprechenden Benutzererfahrungen wie Amazon.com, Netflix, Uber und Airbnb werden intern von einer komplexen Mischung aus mehreren Workloads unterstützt. Z.B. In einer E-Commerce-Anwendung wie Amazon.com müssen sehr geschäftskritische Daten mit geringem Volumen wie Benutzer, Produkte, Bestellungen, Rechnungen sowie weniger geschäftskritische Daten mit hohem Volumen wie Produktbewertungen, Helpdesk-Nachrichten gespeichert werden. Benutzeraktivität, Benutzerempfehlungen. Natürlich setzen diese Anwendungen neben mindestens einer NoSQL-Datenbank mindestens eine SQL-Datenbank ein. In Bereitstellungen mit mehreren Regionen und weltweit fungiert die NoSQL-Datenbank auch als geoverteilter Cache für die Daten, die in der Quelle der Wahrheit gespeichert sind, wobei die SQL-Datenbank in einer einzelnen Region ausgeführt wird.

Wie bringt YugaByte DB SQL und NoSQL auf einem gemeinsamen Datenbankkern zusammen?

YugaByte DB ist die weltweit erste Open-Source-Datenbank, die sowohl NoSQL (Cassandra & Redis) als auch NoSQL (Cassandra & Redis) ist kompatibel) und SQL (PostgreSQL kompatibel) gleichzeitig. Wie in der folgenden Tabelle gezeigt, fügt YCQL, die Cassandra-kompatible API von YugaByte DB, den NoSQL-APIs die Begriffe Einzelschlüssel- und Mehrschlüssel-ACID-Transaktionen und globale Sekundärindizes hinzu und läutet damit die Ära von Transactional NoSQL ein. Darüber hinaus erweitert YSQL, die PostgreSQL-kompatible API von YugaByte DB, eine SQL-API um die Begriffe lineare Schreibskalierung und automatische Fehlertoleranz. Da YugaByte DB das Kernstück der Transaktion ist, können jetzt auch die NoSQL-APIs im Kontext unternehmenskritischer Daten verwendet werden.

YugaByte DB - SQL & NoSQL auf einem einzigen Datenbankkern

Wie bereits unter Einführung in YSQL: Eine PostgreSQL-kompatible verteilte SQL-API für YugaByte DB beschrieben, hängt die Auswahl von SQL im Vergleich zu NoSQL in YugaByte DB vollständig von den Merkmalen der meisten Workloads ab.

  • Handelt es sich bei der Mehrzahl der Workloads um Multi-Key-Vorgänge mit JOINS, wählen Sie YSQL mit dem Verständnis, dass Ihre Schlüssel auf mehrere Knoten verteilt sein können, was zu einer höheren Latenz und / oder einem geringeren Durchsatz als NoSQL führt.
  • Wählen Sie andernfalls eine der beiden NoSQL-APIs aus, mit der Gewissheit, dass Sie einen höheren Leistungsvorteil erzielen, wenn Abfragen hauptsächlich von jeweils einem Knoten aus bearbeitet werden. YugaByte DB kann als einheitliche Betriebsdatenbank für komplexe reale Apps dienen, für die in der Regel mehrere Workloads gleichzeitig verwaltet werden müssen.

Das Datenmodellierungslabor im nächsten Abschnitt basiert auf den PostgreSQL- und Cassandra-kompatiblen APIs von YugaByte DB im Gegensatz zu den Originaldatenbanken. Dieser Ansatz unterstreicht die Einfachheit der 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 nächsten Abschnitten werden wir anhand eines praktischen Datenmodellierungslabors viele der Unterschiede und einige Gemeinsamkeiten zwischen verschiedenen Datenbanken veranschaulichen.

Data Modeling Lab

Datenbanken installieren

Angesichts des Fokus auf die Datenmodellierung (und nicht auf komplexe Bereitstellungsarchitekturen) werden wir die Datenbanken in Docker-Containern auf unseren lokalen Computern installieren und dann mithilfe der jeweiligen Befehlszeilen-Shells mit ihnen interagieren.

YugaByte DB, eine PostgreSQL & Cassandra-kompatible Datenbank

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
Docker ziehen yugabytedb / yugabyte
./yb-docker-ctl erstelle --enable_postgres

MongoDB

docker run --name mein-mongo -d mongo: spätestens

Zugriff über die Befehlszeilen-Shell

Als Nächstes stellen wir mithilfe der Befehlszeilen-Shells für die jeweiligen APIs eine Verbindung zu den Datenbanken her.

PostgreSQL

psql ist eine Kommandozeilen-Shell für die Interaktion mit PostgreSQL. Zur Vereinfachung der Verwendung wird YugaByte DB mit einer Version von psql im bin-Verzeichnis ausgeliefert.

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

Kassandra

cqlsh ist eine Befehlszeilen-Shell für die Interaktion mit Cassandra und seinen kompatiblen Datenbanken über CQL (Cassandra Query Language). Zur Vereinfachung der Verwendung wird YugaByte DB mit einer Version von cqlsh im bin-Verzeichnis ausgeliefert.

Beachten Sie, dass CQL stark von SQL inspiriert ist und eine ähnliche Vorstellung von Tabellen, Zeilen, Spalten und Indizes hat. Als NoSQL-Sprache werden jedoch bestimmte Einschränkungen hinzugefügt, auf die wir in unserer Blog-Reihe zum größten Teil eingehen werden.

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

MongoDB

Mongo ist eine Kommandozeilen-Shell für die Interaktion mit MongoDB. Es befindet sich im bin-Verzeichnis einer MongoDB-Installation.

Docker Exec -it My-Mongo Bash
cd bin
Mongo

Erstellen Sie eine Tabelle

Über die Befehlszeilen-Shell können wir jetzt mit der Datenbank für verschiedene Vorgänge interagieren. Beginnen wir mit der Erstellung einer Tabelle, in der Informationen zu Titeln gespeichert werden, die von Künstlern veröffentlicht wurden. Diese Songs sind manchmal Teil eines Albums. Die anderen optionalen Attribute eines Songs sind das Erscheinungsjahr, der Preis, das Genre und die Kritikerbewertung. Wir müssen zusätzliche Attribute berücksichtigen, die wir in Zukunft möglicherweise über ein Feld "Tags" benötigen, in dem halbstrukturierte Daten als Schlüssel-Wert-Paare gespeichert werden können.

PostgreSQL

TABELLE ERSTELLEN Musik (
    Künstler VARCHAR (20) NICHT NULL,
    SongTitle VARCHAR (30) NICHT NULL,
    AlbumTitle VARCHAR (25),
    Jahr INT,
    Preis FLOAT,
    Genre VARCHAR (10),
    CriticRating FLOAT Früher
    Tags TEXT,
    PRIMARY KEY (Künstler, SongTitle)
);

Kassandra

Das Erstellen einer Tabelle in Cassandra ist dem von PostgreSQL sehr ähnlich. Ein großer Unterschied ist das Fehlen von Integritätsbeschränkungen (wie NOT NULL), die in der NoSQL-Welt in der Verantwortung der Anwendung und nicht der Datenbank liegen. Der Primärschlüssel besteht aus dem Partitionsschlüssel (die Artist-Spalte im folgenden Beispiel) und einer Reihe von Cluster-Spalten (die 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 in einem bestimmten Shard organisiert werden sollen.

CREATE KEYSPACE myapp;
USE myapp;
TABELLE ERSTELLEN Musik (
    Künstler TEXT,
    SongTitle TEXT,
    AlbumTitle TEXT,
    Jahr INT,
    Preis FLOAT,
    Genre TEXT,
    CriticRating FLOAT Früher
    Tags TEXT,
    PRIMARY KEY (Künstler, SongTitle)
);

MongoDB

MongoDB organisiert Daten in Datenbanken (entspricht Cassandra Keyspace) mit Sammlungen (entspricht Tabellen), die Dokumente (entspricht einer Zeile in einer Tabelle) enthalten. Als "schemenlose" Datenbank ist in MongoDB die vorherige Definition des Schemas nicht erforderlich. Der unten gezeigte Befehl "use database" instanziiert eine Datenbank beim allerersten Aufrufen zusammen mit der Änderung des Kontexts für die neu erstellte Datenbank. Auch Sammlungen müssen nicht explizit erstellt werden, sondern werden automatisch erstellt, indem einfach das erste Dokument in eine neue Sammlung eingefügt wird. Beachten Sie, dass die Standarddatenbank von MongoDB ein Test ist, sodass alle Vorgänge auf Sammlungsebene, die ohne Angabe der Datenbank ausgeführt werden, in diesem Standardkontext ausgeführt werden.

benutze myNewDatabase;

Informationen zu einer Tabelle abrufen

PostgreSQL

\ d Musik
Tabelle "public.music"
    Spalte | Typ | Kollation | Nullable | Standard
-------------- + ----------------------- + ----------- + ---------- + --------
 Künstler | Zeichen variieren (20) | | nicht null |
 songtitle | Zeichen variieren (30) | | nicht null |
 Albumtitel | Zeichen variieren (25) | | |
 jahr | ganze Zahl | | |
 Preis | doppelte Präzision | | |
 Genre | Zeichen variieren (10) | | |
 kritisieren doppelte Präzision | | |
 tags | text | | |
Indizes:
    "music_pkey" PRIMARY KEY, btree (Interpret, Songtitel)

Kassandra

TISCHMUSIK BESCHREIBEN;
CREATE TABLE myapp.music (
    künstler text
    songtitle text
    Albumtiteltext,
    jahr int,
    Preisschwankung,
    genretext,
    etikettiert text,
    PRIMARY KEY (Künstler, Songtitel)
) MIT CLUSTERING ORDER BY (Songtitel ASC)
    AND default_time_to_live = 0
    AND-Transaktionen = {'aktiviert': 'falsch'};

MongoDB

benutze myNewDatabase;
Kollektionen zeigen;

Daten in eine Tabelle einfügen

PostgreSQL

INSERT IN Musik
    (Artist, SongTitle, AlbumTitle,
    Jahr, Preis, Genre, Kritiker,
    Stichworte)
WERTE(
    "Niemand, den du kennst", "Nenn mich heute", "Etwas berühmt",
    2015, 2.14, "Land", 7.8,
    '{"Komponisten": ["Smith", "Jones", "Davis"], "LengthInSeconds": 214}'
);
INSERT IN Musik
    (Artist, SongTitle, AlbumTitle,
    Preis, Genre, Bewertung)
WERTE(
    "Niemand, den du kennst", "My Dog Spot", "Hey Now",
    1,98, "Land", 8,4
);
INSERT IN Musik
    (Artist, SongTitle, AlbumTitle,
    Preis, Genre)
WERTE(
    "The Acme Band", "Look Out, World", "Der Dollar fängt hier an",
    0,99, 'Rock'
);
INSERT IN Musik
    (Artist, SongTitle, AlbumTitle,
    Preis, Genre,
    Stichworte)
WERTE(
    "The Acme Band", "Immer noch verliebt", "The Buck Starts Here",
    2.47, "Rock",
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Schwer}'
);

Kassandra

Die INSERT-Anweisungen von Cassandra sehen denen von PostgreSQL im Allgemeinen sehr ähnlich. Es gibt jedoch einen großen Unterschied in der Semantik. INSERT ist eine Upsert-Operation in Cassandra, bei der die Zeile mit den neuesten Werten aktualisiert wird, falls die Zeile bereits vorhanden ist.

Entspricht den obigen PostgreSQL INSERT-Anweisungen.

MongoDB

Auch wenn MongoDB eine ähnliche NoSQL-Datenbank wie Cassandra ist, weist seine Einfügeoperation nicht dasselbe semantische Verhalten wie Cassandra auf. MongoDB insert () hat keine Upsert-Möglichkeit, was es ähnlich wie PostgreSQL macht. Das Standardverhalten beim Einfügen ohne _idspecified führt dazu, dass der Sammlung ein neues Dokument hinzugefügt wird.

db.music.insert ({
Künstler: "Niemand den du kennst",
   songTitle: "Call Me Today",
    albumTitle: "Somewhat Famous",
    Jahr: 2015,
    Preis: 2,14,
    Genre: "Country",
    Stichworte: {
Komponisten: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
   }
);
db.music.insert ({
    Künstler: "Niemand den du kennst",
    songTitle: "My Dog Spot",
    albumTitle: "Hey Now",
    Preis: 1,98,
    Genre: "Country",
    criticalBewertung: 8.4
   }
);
db.music.insert ({
    Künstler: "The Acme Band",
    songTitle: "Look Out, World",
    albumTitle: "The Buck Starts Here",
    Preis: 0,99,
    Genre: "Rock"
   }
);
db.music.insert ({
    Künstler: "The Acme Band",
    songTitle: "Still In Love",
    albumTitle: "The Buck Starts Here",
    Preis: 2,47,
    Genre: "Rock",
    Stichworte: {
        Wiedergabe von Radiosendern: ["KHCR", "KBQX", "WTNR", "WJJH"],
        Tourdaten: {
            Seattle: "20150625",
            Cleveland: 20150630
        },
        Drehung: "Schwer"
}
    }
);

Eine Tabelle abfragen

Der wohl bedeutendste Unterschied zwischen SQL und NoSQL in Bezug auf Modellierungsabfragen liegt in der Verwendung der FROM- und WHERE-Klauseln. SQL ermöglicht es der FROM-Klausel, mehrere Tabellen einzuschließen, und der WHERE-Klausel, willkürlich komplex zu sein (einschließlich tabellenübergreifender JOINs). NoSQL neigt jedoch dazu, die FROM-Klausel stark einzuschränken, damit nur eine Tabelle angegeben wird, und die WHERE-Klausel, damit immer der Primärschlüssel angegeben wird. Dies ist auf den bereits erwähnten hohen Leistungsfokus von NoSQL zurückzuführen, der darauf abzielt, die Interaktion zwischen Tabellen und Schlüsseln zu reduzieren. Eine solche Interaktion kann eine knotenübergreifende Kommunikation mit hoher Latenz in die Antwortzeit der Abfrage einführen und wird daher am besten vollständig vermieden. Z.B. Cassandra verlangt, dass Abfragen von Operatoren (nur =, IN, <,>, =>, <= sind zulässig) auf Partitionsschlüssel beschränkt werden, außer wenn ein sekundärer Index abgefragt wird (wobei nur = Operator zulässig ist).

PostgreSQL

Es folgen 3 Arten von Abfragen, die von einer SQL-Datenbank problemlos bedient werden können.

  • Geben Sie alle Songs eines Künstlers zurück
  • Geben Sie alle Songs eines Künstlers zurück, die dem ersten Teil des Titels entsprechen
  • Geben Sie alle Songs eines Künstlers mit einem bestimmten Wort im Titel zurück, jedoch nur, wenn der Preis unter 1,00 liegt
SELECT * FROM Music
WO Künstler = 'Niemand den du kennst';
SELECT * FROM Music
WHERE Artist = 'Niemand, den du kennst' UND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist = 'Niemand, den du kennst' UND SongTitel LIKE '% Today%'
UND Preis> 1,00;

Kassandra

Von den oben aufgeführten PostgreSQL-Abfragen funktioniert nur die erste mit Cassandra unverändert, da der LIKE-Operator für Clustering-Spalten wie SongTitle nicht zulässig ist. In diesem Fall sind nur die Operatoren = und IN zulässig.

SELECT * FROM Music
WO Künstler = 'Niemand den du kennst';
SELECT * FROM Music
WHERE Artist = "Niemand, den du kennst" UND SongTitle IN ("Call Me Today", "My Dog Spot")
UND Preis> 1,00;

MongoDB

Wie in den vorherigen Beispielen gezeigt, ist die primäre Methode zum Abfragen von MongoDB die Methode db.collection.find (). Diese Methode ist durch den Sammlungsnamen (Musik im folgenden Beispiel) gekennzeichnet, der sehr explizit abgefragt werden soll, sodass das Abfragen über Sammlungen hinweg explizit nicht zulässig ist.

db.music.find ({
  Künstler: "Niemand den du kennst"
 }
);
db.music.find ({
  Künstler: "Niemand den du kennst",
  songTitle: / Call /
 }
);

Lesen Sie alle Zeilen aus einer Tabelle

Das Lesen aller Zeilen ist lediglich ein Sonderfall des zuvor beobachteten generischen Abfragemusters.

PostgreSQL

WÄHLEN *
FROM Music;

Kassandra

Entspricht der obigen PostgreSQL SELECT-Anweisung.

MongoDB

db.music.find ({});

Daten in einer Tabelle ändern

PostgreSQL

PostgreSQL bietet die UPDATE-Anweisung zum Ändern von Daten. Es erlaubt keine Upsert-Möglichkeit, sodass die Anweisung fehlschlägt, wenn die Zeile noch nicht in der Datenbank vorhanden ist.

UPDATE Musik
SET Genre = 'Disco'
WO Artist = 'The Acme Band' UND SongTitle = 'Still In Love';

Kassandra

Cassandra hat auch eine UPDATE-Anweisung ähnlich wie PostgreSQL. UPDATE hat auch die gleiche Upsert-Semantik wie die INSERT-Anweisung.

Entspricht der obigen PostgreSQL UPDATE-Anweisung.

MongoDB

Die update () - Operation von MongoDB kann ein vorhandenes Dokument vollständig oder nur bestimmte Felder aktualisieren. Standardmäßig wird nur ein Dokument mit deaktivierter Upsert-Semantik aktualisiert. Aktualisierungen mehrerer Dokumente und Upsert-Verhalten können aktiviert werden, indem zusätzliche Flags für den Vorgang festgelegt werden. Z.B. Das folgende Beispiel aktualisiert das Genre eines bestimmten Interpreten in allen Titeln des Interpreten.

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

Daten aus einer Tabelle löschen

PostgreSQL

AUS Musik LÖSCHEN
WO Artist = 'The Acme Band' UND SongTitle = 'Look Out, World';

Kassandra

Entspricht der obigen PostgreSQL DELETE-Anweisung.

MongoDB

MongoDB hat zwei Arten von Operationen, um das Löschen von Dokumenten zu handhaben - deleteOne () / deleteMany () und remove (). Beide löschen Dokumente, haben aber unterschiedliche Rückgabeergebnisse.

db.music.deleteMany ({
        Künstler: "The Acme Band"
    }
);

Entfernen Sie einen Tisch

PostgreSQL

TROPFENTISCH Musik;

Kassandra

Entspricht der obigen PostgreSQL DROP TABLE-Anweisung.

MongoDB

db.music.drop ();

Zusammenfassung

Die Debatte zwischen SQL und NoSQL tobt seit über einem Jahrzehnt. Es gibt zwei Aspekte dieser Debatte: die Datenbankkernarchitektur (monolithisches, transaktionales SQL vs. verteiltes, nicht transaktionales NoSQL) und den Datenmodellierungsansatz (Modellieren Sie Ihre Daten in SQL vs. Modellieren Sie Ihre Abfragen in NoSQL).

Mit einer verteilten Transaktionsdatenbank wie YugaByte DB kann der Kern der Datenbankarchitektur, der Teil der Debatte ist, einfach zur Ruhe gebracht werden. Da das Datenvolumen über das hinausgeht, was in einen einzelnen Knoten geschrieben werden kann, ist eine vollständig verteilte Architektur, die eine lineare Schreibskalierbarkeit mit automatischem Sharding / Re-Balancing ermöglicht, ein Muss. Wie in diesem Beitrag von Google Cloud beschrieben, sind transaktionale, stark konsistente Architekturen mittlerweile weit verbreitet, um eine höhere Agilität für Entwickler und Betrieb zu gewährleisten als nicht transaktionale, eventuell konsistente Architekturen.

In Bezug auf die Datenmodellierungsdebatte ist zu sagen, dass sowohl der SQL- als auch der NoSQL-Datenmodellierungsansatz für jede komplexe reale Anwendung von wesentlicher Bedeutung sind. Dank des SQL-Modell-für-Ihre-Daten-Ansatzes können die Entwickler leichter auf sich ändernde Geschäftsanforderungen reagieren, während der NoSQL-Modell-für-Ihre-Abfragen-Ansatz es denselben Entwicklern ermöglicht, große Datenmengen mit geringer Latenz und hohem Durchsatz zu verwalten. Dies ist genau der Grund, warum YugaByte DB sowohl SQL- als auch NoSQL-APIs auf dem gemeinsamen Kern implementiert, anstatt dafür zu werben, dass ein Ansatz strikt besser ist als der andere. Durch die Gewährleistung der Kompatibilität mit gängigen Datenbanksprachen wie PostgreSQL und Cassandra stellt YugaByte DB außerdem sicher, dass Entwickler keine andere Sprache lernen, um vom verteilten, stark konsistenten Datenbankkern zu profitieren.

Dieser Beitrag hat uns geholfen zu verstehen, wie sich die Grundlagen der Datenmodellierung zwischen PostgreSQL, Cassandra und MongoDB unterscheiden. In den nächsten Beiträgen der Reihe werden wir uns mit fortgeschrittenen Datenmodellierungskonzepten wie Indizes, Transaktionen, JOINs, TTL-Direktiven und JSON-Dokumenten befassen.

Was kommt als nächstes?

  • Vergleichen Sie YugaByte DB mit Datenbanken wie Amazon DynamoDB, Cassandra, MongoDB und Azure Cosmos DB.
  • Starten Sie mit YugaByte DB unter macOS, Linux, Docker und Kubernetes.
  • Kontaktieren Sie uns, um mehr über Lizenzen, Preise oder einen technischen Überblick zu erfahren.

Ursprünglich im YugaByte Database Blog veröffentlicht.