YugaByte-Rezension: Cassandra und Redis im Planetenmaßstab

Während meiner Jahrzehnte als Entwickler von Datenbankanwendungen hätte ich mir in meinen wildesten Träumen nie vorgestellt, dass ich jemals Zugang zu einer verteilten Transaktionsdatenbank im Planetenmaßstab haben würde, geschweige denn, dass ich viele davon vergleichen würde. Mit Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise und zuletzt YugaByte DB, die alle in der Produktion verfügbar sind, ist dieser einmalige Wunschtraum nun ganz real.

Im Allgemeinen bietet Google Cloud Spanner eine skalierbare, verteilte, stark konsistente SQL-Datenbank als Dienst, der etwa 2.000 Schreibvorgänge pro Sekunde und 10.000 Lesevorgänge pro Sekunde pro Knoten mit einer mittleren Latenz von etwa fünf Millisekunden verarbeiten kann. Um Lesevorgänge zu beschleunigen, für die keine absolut aktuellen Daten erforderlich sind, können Sie Spanner um veraltete Lesevorgänge bitten, da Zeitreisen abgefragt werden. Spanner verwendet einen Google-Dialekt von SQL und läuft nur auf der Google Cloud Platform.

CockroachDB ist eine Spanner-ähnliche Open-Source-SQL-Datenbank, die das PostgreSQL-Drahtprotokoll und den PostgreSQL-SQL-Dialekt unterstützt. CockroachDB basiert auf RocksDB, einem Open-Source-Transaktions- und konsistenten Schlüsselwertspeicher. Wie Spanner unterstützt es Zeitreise-Abfragen. CockroachDB kann in jeder Cloud, in Docker-Containern mit oder ohne Orchestrierung oder auf Linux-Servern oder VMs ausgeführt werden. Die Unternehmensversion von CockroachDB bietet Geopartitionierung, rollenbasierte Zugriffssteuerung und Unterstützung.

Azure Cosmos DB ist eine global verteilte, horizontal partitionierte Multimodell-Datenbank als Service. Es bietet vier Datenmodelle (Schlüsselwert, Spaltenfamilie, Dokument und Diagramm) und fünf einstellbare Konsistenzstufen (starke, begrenzte Stalenität, Sitzung, konsistentes Präfix und eventuell). Es bietet fünf API-Sets: SQL (Dialekt), MongoDB-kompatibel, Azure Table-kompatibel, Graph (Gremlin) und Apache Cassandra-kompatibel. Es wird nur in der Microsoft Azure-Cloud ausgeführt.

Neo4j ist eine skalierbare und überlebensfähige Diagrammdatenbank, die die Abfragesprache Cypher verwendet. Sie können die Open-Source-Version ohne Cluster unter Windows, MacOS und Linux, in Docker-Containern und in VMs installieren. Neo4j Enterprise unterstützt Hochverfügbarkeits- und Kausalcluster. Kausale Cluster ermöglichen asynchron aktualisierte Cluster von Lesereplikaten, um eine hohe Leistung für geografisch verteilte Bereitstellungen zu ermöglichen.

Geben Sie Yugabyte DB ein

YugaByte DB, das Thema dieser Überprüfung, ist eine Open-Source-Transaktionsdatenbank mit hoher Leistung für Anwendungen im Planetenmaßstab, die drei API-Sätze unterstützt: YCQL, kompatibel mit Apache Cassandra Query Language (CQL); YEDIS, kompatibel mit Redis; und PostgreSQL (derzeit unvollständig und in der Beta). YugaWare ist die Orchestrierungsschicht für YugaByte DB Enterprise Edition. Mit YugaWare können verteilte Cluster in Amazon Web Services, der Google Cloud Platform und (voraussichtlich im vierten Quartal 2018) Microsoft Azure schnell hochgefahren und heruntergefahren werden. YugaByte DB implementiert die Multiversion Concurrency Control (MVCC), unterstützt jedoch noch keine Zeitreise-Abfragen.

YugaByte DB basiert auf einer erweiterten Verzweigung des RocksDB-Schlüsselwertspeichers. YugaByte DB 1.0 wurde im Mai 2018 ausgeliefert.

Zwei der Schlüsseltechnologien, die verwendet werden, um verteilte Transaktionsdatenbanken konsistent und schnell zu machen, sind Clusterkonsensalgorithmen und Knotensynchronisation. Google Cloud Spanner und Azure Cosmos DB verwenden beide den von Leslie Lamport vorgeschlagenen Paxos-Konsensalgorithmus. CockroachDB und YugaByte DB verwenden den von Diego Ongaro und John Ousterhout vorgeschlagenen Raft-Konsensalgorithmus.

Google Cloud Spanner verwendet die proprietäre TrueTime-API von Google, die auf GPS und Atomuhren basiert. Azure Cosmos DB, CockroachDB und YugaByte DB verwenden HLC-Zeitstempel (Hybrid Logic Clock) und NTP-Taktsynchronisation (Network Time Protocol).

YugaByte Designziele

Die Gründer von YugaByte - Kannan Muthukkaruppan, Karthik Ranganathan und Mikhail Bautin - waren Apache HBase-Committer, frühe Ingenieure von Apache Cassandra und die Entwickler der NoSQL-Plattform von Facebook (unterstützt von Apache HBase). Ihr Ziel für YugaByte DB war ein verteilter Datenbankserver, der sich philosophisch zwischen Azure Cosmos DB und Google Cloud Spanner befindet. Das heißt, sie wollten die Multimodell- und Hochleistungsattribute von Cosmos DB mit den ACID-Transaktionen und der globalen Konsistenz von Spanner kombinieren. Eine andere Möglichkeit, ihr Ziel zu beschreiben, besteht darin, dass YugaByte DB gleichzeitig transaktional, leistungsstark und planetarisch sein soll.

Sie teilten den Prozess in fünf Schritte auf, deren Bau jeweils etwa sechs Monate dauerte. Der erste Schritt bestand darin, eine stark konsistente Version von RocksDB, einem in C ++ geschriebenen Hochleistungs-Schlüsselwertspeicher, zu erstellen, indem das Raft-Konsensprotokoll hinzugefügt, Sharding und Lastausgleich durchgeführt und Transaktionsprotokollierung sowie Sicherungen zu bestimmten Zeitpunkten entfernt wurden. und Wiederherstellung, die in einer höheren Schicht implementiert werden musste.

Der nächste Schritt bestand darin, eine protokollstrukturierte Schlüssel-zu-Dokument-Speicher-Engine zu erstellen, die nicht primitive und verschachtelte Typen wie Zeilen, Karten, Sammlungen und JSON hinzufügt. Anschließend fügten sie eine steckbare API-Schicht wie Azure Cosmos DB hinzu, die Cassandra-kompatible und Redis-kompatible APIs implementierte und eine PostgreSQL-kompatible SQL-API auf einen späteren Zeitpunkt verschob. Dann kamen erweiterte Abfragesprachen.

YugaByte Cloud Query Language (YCQL) erweitert die Cassandra-API um Unterstützung für verteilte Transaktionen, stark konsistente Sekundärindizes und JSON. YugaByte Dictionary Service (YEDIS) ist eine Redis-kompatible API mit zusätzlichen Funktionen für integrierte Persistenz, Auto-Sharding und lineare Skalierbarkeit. YEDIS ermöglicht optional zeitlinienkonsistente Lesevorgänge mit geringer Latenz vom nächsten Rechenzentrum, während starke Schreibvorgänge die globale Konsistenz gewährleisten. YEDIS enthält auch einen neuen Zeitreihendatentyp.

Schließlich fügt YugaByte DB Enterprise mit Version 1.0 eine Ebene hinzu, um Bereitstellungen in Produktionsqualität über mehrere Regionen und mehrere Clouds hinweg zu koordinieren, zu sichern und zu überwachen und verteilte Sicherungen auf einem konfigurierbaren Endpunkt wie Amazon S3 zu speichern. Die PostgreSQL-Unterstützung bleibt unvollständig und befindet sich auf Beta-Test-Ebene.

Verteilte ACID-Transaktionen 

Lassen Sie mich versuchen, die Art und Weise, wie YugaByte verteilte ACID-Transaktionen durchführt, zusammenzufassen, da die Gefahr besteht, dass der Prozess vollständig vereinfacht wird. ACID (steht für Atomizität, Konsistenz, Isolation und Haltbarkeit) wurde früher als eine Eigenschaft betrachtet, die auf SQL-Datenbanken beschränkt war.

Angenommen, Sie senden eine YCQL-Abfrage mit Aktualisierungen innerhalb einer Transaktion, z. B. eine gepaarte Belastung und Gutschrift, die beide abgebrochen werden müssen, wenn eine fehlschlägt, um die Konsistenz einer Finanzdatenbank aufrechtzuerhalten. YugaByte DB akzeptiert die Transaktion in einem zustandslosen Transaktionsmanager, von dem einer auf jedem Knoten im Cluster ausgeführt wird. Der Transaktionsmanager versucht dann, die Transaktion auf dem Tablet-Server, der die meisten Daten besitzt, auf die die Transaktion zugreift, zu Leistungszwecken zu planen.

Der Transaktionsmanager fügt der Transaktionsstatustabelle einen Transaktionseintrag mit einer eindeutigen ID hinzu. Anschließend werden vorläufige Datensätze auf alle Tablets geschrieben, die für die Schlüssel verantwortlich sind, die die Transaktion zu ändern versucht. Bei Konflikten wird eine der widersprüchlichen Transaktionen zurückgesetzt.

Sobald alle vorläufigen Datensätze erfolgreich geschrieben wurden, fordert der Transaktionsmanager das Transaktionsstatustablett auf, alle vorläufigen Datensätze durch reguläre Datensätze zu ersetzen, indem der Zeitstempel des Eintrags "Transaktion festgeschrieben" in seinem Floßprotokoll verwendet wird. Schließlich sendet das Transaktionsstatus-Tablet Bereinigungsanforderungen an jedes der Tablets, die an der Transaktion teilgenommen haben.

Um die Leistung zu verbessern, speichert YugaByte Informationen für laufende Transaktionen aggressiv zwischen, implementiert feinkörnige Sperren und verwendet hybride Time Leader-Leases, um zu verhindern, dass Kunden veraltete Werte von alten Führungskräften lesen. Einzeilige ACID-Transaktionen sind so optimiert, dass sie geringe Latenzen aufweisen, wenn kein widersprüchlicher Vorgang vorliegt. Verteilte ACID-Transaktionen gewährleisten die Korrektheit auf Kosten höherer Latenzen.

YCQL, YEDIS und PostgreSQL

YugaByte enthält eine nahezu vollständige Implementierung von CQL sowie einige Erweiterungen. Eine enorme Verbesserung gegenüber Cassandra ist, dass YugaByte stark konsistent ist, während Cassandra letztendlich konsistent ist. Die anderen Verbesserungen betreffen verteilte Transaktionen, stark konsistente Sekundärindizes und JSON. YugaByte übertrifft Cassandra bei jeder Operation, mit Ausnahme von Kurzstrecken-Scans, zumindest teilweise aufgrund seiner starken Konsistenz, die einen einzelnen Lesevorgang anstelle des in Cassandra erforderlichen Quorum-Lesevorgangs ermöglicht.

Cassandra unterstützt vier primitive Datentypen, die in YugaByte noch nicht unterstützt werden: Datum, Uhrzeit, Tupel und Varint. YugaByte hat auch einige Einschränkungen für Ausdrücke. 

Bei der Implementierung von Redis durch YugaByte fehlt der Listendatentyp, es wird jedoch ein Zeitreihendatentyp hinzugefügt. Es bietet integrierte Persistenz, Auto-Sharding und lineare Skalierbarkeit sowie die Möglichkeit, für eine geringe Latenz aus dem nächstgelegenen Rechenzentrum zu lesen.

Die PostgreSQL-Implementierung von YugaByte ist nicht sehr weit fortgeschritten. Im Moment fehlen UPDATE- und DELETE-Anweisungen, Ausdrücke, und der SELECT-Anweisung fehlt eine Join-Klausel.

Installation und Test von YugaByte

Sie können die Open-Source-Datenbank YugaByte aus dem Quellcode, aus Tarballs unter MacOS, Centos 7 und Ubuntu 16.04 oder höher sowie aus Docker-Images unter Docker oder Kubernetes installieren. Anschließend können Sie Cluster erstellen und die drei Abfrage-APIs sowie einige Beispiel-Workload-Generatoren testen.

Ich habe mich für die Installation von YugaByte DB Enterprise auf der Google Cloud Platform entschieden. Obwohl mehr manuelle Schritte erforderlich waren, als ich gerne hätte, konnte ich meine Installation und Tests an einem einzigen Nachmittag durchführen, nachdem ich meinen Enterprise Edition-Lizenzschlüssel erhalten hatte.

Nachdem die YugaWare-Instanz auf einer Instanz mit vier CPUs in Google Cloud ausgeführt wurde, habe ich Google Cloud Platform als Cloud-Anbieter für meinen Datenbankcluster konfiguriert.

Dann habe ich einen Drei-Knoten-Cluster mit acht CPU-Instanzen in der Region US-Ost erstellt.

Ich habe Lasttests sowohl mit der CQL- als auch mit der Redis-API durchgeführt.

Ich konnte sowohl die CQL- als auch die Redis-Daten über die Befehlszeile abfragen.

Ich habe auch einen Cluster mit drei Knoten in verschiedenen Regionen auf der ganzen Welt erstellt (siehe unten). Die Erstellung dauerte länger (ca. 45 Minuten) und hatte erwartungsgemäß eine viel höhere Schreiblatenz. Die Lichtgeschwindigkeit kann man leider nicht umgehen.

YugaByte kostet

Der Preis für eine YugaByte DB Enterprise Edition-Lizenz mit drei Knoten beginnt bei 40.000 USD pro Jahr. Darüber hinaus müssen Sie die Kosten der Server berücksichtigen. Für einen Cluster mit drei Knoten auf der Google Cloud Platform mit VM-Instanzen mit acht CPUs liegen diese Kosten im Bereich von 800 bis 900 US-Dollar pro Monat plus Netzwerkverkehr, möglicherweise 11.000 US-Dollar pro Jahr.

Meine eigenen Kosten für einen Testnachmittag betrugen 0,38 USD für die Instanzen und 0,01 USD für den Interzonenausgang. Das Löschen von Datenbankclustern von der YugaByte DB Enterprise-Schnittstelle war einfach, und nachdem ich die VM-Instanz gestoppt hatte, auf der die Administrations- und Orchestrierungsschnittstelle ausgeführt wurde, fielen keine erheblichen Kosten mehr an.

Schneller, besser, verteilt

Insgesamt hat sich YugaByte DB wie angekündigt entwickelt. Zu diesem Zeitpunkt in seiner Entwicklung ist es als schnelleres, besseres, verteiltes Redis und Cassandra nützlich. Es sollte schließlich auch ein besseres PostgreSQL sein, obwohl dies meiner Erfahrung nach lange dauert (Jahre statt Monate), insbesondere wenn Sie versuchen, relationale Verknüpfungen zu optimieren.

YugaByte DB konkurriert noch nicht mit Google Cloud Spanner, CockroachDB oder der SQL-Schnittstelle zu Azure Cosmos DB, da keine ausgefeilte SQL-Schnittstelle vorhanden ist. Es konkurriert noch nicht mit Neo4j oder der Grafikschnittstelle zu Cosmos DB, da die Grafikdatenbank nicht unterstützt wird. Es konkurriert mit Redis, Cassandra und der Cassandra-kompatiblen Schnittstelle zu Cosmos DB.

Sollten Sie YugaByte DB selbst ausprobieren? Wenn Sie eine verteilte Version von Redis oder Cassandra benötigen oder MongoDB für ein global verteiltes Szenario ersetzen müssen, dann ja. YugaByte DB kann auch verwendet werden, um eine einzelne Datenbank für mehrere Zwecke zu standardisieren, z. B. um eine Cassandra-Datenbank mit Redis-Caching zu kombinieren, wie es der YugaByte-Kunde Narvar getan hat. YugaByte DB fügt Cassandra außerdem leistungsstarke Sekundärindizes und einen JSON-Typ hinzu, wodurch die Nützlichkeit als Transaktionsdatenbank erhöht wird.

Ob Sie die Open Source- oder Enterprise-Version von YugaByte DB möchten, hängt von Ihrem Budget ab. Im Großen und Ganzen möchten Sie als Startup wahrscheinlich die Open Source-Version. Wenn Sie ein etabliertes globales Unternehmen mit vielen Transaktionsdatenbankanwendungen sind, insbesondere wenn Sie Cluster häufig nach oben und unten skalieren müssen, können Sie von den zusätzlichen Funktionen in der Unternehmensversion profitieren.