MongoDB vs. Cassandra: Schreibvorgänge im Planetary Scale

MongoDB und Apache Cassandra verarbeiten beide verteilte Daten in großem Maßstab, verwenden jedoch grundlegend unterschiedliche Architekturen. MongoDB verwendet ein Leader-Follower-Modell (Primary-Secondary-Modell), bei dem Schreibvorgänge an einen einzelnen Primary pro Replica Set gehen. Cassandra verwendet ein leaderloses (Peer-to-Peer-)Modell, bei dem jeder Knoten jeden Schreibvorgang annehmen kann. Dieser architektonische Unterschied bestimmt sämtliche Abwägungen zwischen den beiden Systemen hinsichtlich Leistung, Konsistenz und Betrieb.

In Cassandra sind alle Knoten gleichberechtigte Peers in einer Ringtopologie. Ein Schreibvorgang kann an jeden Knoten (den Koordinator) gesendet werden, der ihn an die N Replikatknoten weiterleitet, die für den Partitionsschlüssel dieser Zeile zuständig sind. Die Anzahl der Knoten, die den Schreibvorgang bestätigen müssen, wird über das Konsistenzniveau konfiguriert (z. B. ONE, QUORUM, ALL). Diese Architektur beseitigt den Engpass eines einzelnen Primary und ermöglicht echte Multi-Master-Schreibvorgänge über mehrere Regionen — jedes Rechenzentrum kann gleichzeitig Schreibvorgänge annehmen.

Cassandra ist für einen extrem hohen Schreibdurchsatz optimiert. Schreibvorgänge werden an ein Commit-Log und eine schnelle In-Memory-Struktur (Memtable) angehängt, bevor sie gesammelt auf die Festplatte (SSTables) geschrieben werden. Durch diesen Append-only-Ansatz stehen Schreibvorgänge auf der Festplatte nie miteinander in Konflikt, und der Durchsatz skaliert linear mit der Anzahl der Knoten. IoT-Plattformen, die Millionen Messwerte pro Sekunde aufnehmen, Ereignisprotokollierungssysteme und Zeitreihen-Workloads mit Schreibraten, die einen einzelnen MongoDB-Primary überlasten würden, sind ideale Einsatzbereiche für Cassandra.

Cassandras Konsistenzniveau lässt sich pro Abfrage anpassen. ONE bedeutet, dass ein Replikat bestätigt (am schnellsten, schwächste Konsistenz). QUORUM bedeutet, dass eine Mehrheit der Replikate bestätigt (ausgewogenes Verhältnis zwischen Latenz und Konsistenz). ALL bedeutet, dass alle Replikate bestätigen (am langsamsten, stärkste Konsistenz). Die entscheidende Formel lautet: Wenn Lesekonsistenz + Schreibkonsistenz > Replikationsfaktor, erhalten Sie starke Konsistenz. Diese Flexibilität ermöglicht es Cassandra, unterschiedliche Workloads innerhalb desselben Clusters unterschiedlich zu bedienen.

Cassandras Datenmodell ist grundsätzlich abfrageorientiert. Sie entwerfen Tabellen so, dass sie bestimmte Abfragen effizient beantworten — eine Ad-hoc-Abfrage-Engine wie in MongoDB gibt es nicht. Tabellen müssen nach einem Partitionsschlüssel partitioniert werden (dieser bestimmt, welcher Knoten die Zeile speichert), und Zeilen innerhalb einer Partition werden nach einem Clustering-Schlüssel sortiert. Sekundärindizes existieren, sind jedoch wesentlich weniger leistungsfähig als die von MongoDB. Komplexe Abfragen (Joins, Aggregationen und Filter über mehrere Felder), die MongoDB mit der Aggregationspipeline verarbeitet, sind in Standard-CQL nicht möglich.

MongoDBs Aggregationspipeline und umfangreiche Abfrageoperatoren ermöglichen Ad-hoc-Abfragen über beliebige Felder. Sie müssen alle Benutzer in Istanbul finden, die in den letzten 30 Tagen ein bestimmtes Produkt gekauft haben? Eine MongoDB-Abfrage mit dem passenden zusammengesetzten Index beantwortet dies direkt. In Cassandra benötigen Sie dafür eine vorab entworfene Tabelle für genau diese Abfrage, müssten die Daten in mehrere Tabellen denormalisieren oder Spark für analytische Abfragen verwenden. MongoDB ist deutlich flexibler, wenn sich Abfrageanforderungen weiterentwickeln.

Cassandras leaderlose Replikation über mehrere Rechenzentren ermöglicht Active-Active-Bereitstellungen: Alle Regionen akzeptieren gleichzeitig Schreibvorgänge. Ein Benutzer in New York schreibt in das US-Rechenzentrum; die Daten desselben Benutzers werden asynchron nach Europa und Asien repliziert. MongoDB unterstützt mehrere Regionen über Lesepräferenzen für Replica Sets und globale Cluster (Atlas), Schreibvorgänge müssen jedoch weiterhin an eine einzelne primäre Region geleitet werden. Für Anwendungen, die Schreibvorgänge aus jeder Region ohne Latenz benötigen, hat Cassandra einen strukturellen Vorteil.

MongoDB mit w: majority bietet starke Konsistenz — sobald ein Schreibvorgang bestätigt wurde, geben alle nachfolgenden Lesevorgänge den neuen Wert zurück. Cassandras Standardkonfiguration bietet eventuelle Konsistenz — ein mit ONE bestätigter Schreibvorgang ist bei Lesevorgängen von anderen Replikaten möglicherweise nicht sofort sichtbar. Anwendungen müssen dies tolerieren oder QUORUM-Lese- und Schreibvorgänge konfigurieren, um starke Konsistenz auf Kosten höherer Latenz zu erreichen. Dies wirkt sich erheblich auf die Komplexität der Anwendung aus.

Beide Systeme erfordern betriebliches Fachwissen, jedoch in unterschiedlichen Bereichen. Mongos Replica-Set-Architektur ist gut etabliert, und Atlas automatisiert nahezu den gesamten Betrieb. Cassandras Ringtopologie erfordert eine sorgfältige Kapazitätsplanung, Tokenverwaltung, Überwachung der Komprimierung und Verwaltung von Tombstones. Löschvorgänge in Cassandra erzeugen Tombstones, die sich ansammeln und die Leseleistung mit der Zeit beeinträchtigen können. Das Löschmodell von MongoDB ist im Betrieb einfacher. Für kleine bis mittelgroße Teams ist der betriebliche Aufwand von MongoDB im Allgemeinen geringer.

Beide Datenbanken werden für IoT- und Zeitreihen-Workloads eingesetzt, allerdings mit unterschiedlichen Ansätzen. Cassandras Zeitreihen-Partitionierung (Partitionierung nach Gerät, Clustering nach Zeit) liefert einen extrem hohen Schreibdurchsatz und effiziente Zeitbereichsabfragen pro Gerät. MongoDBs native Zeitreihen-Collections (seit Version 5.0) schließen durch automatisches Bucketing und spaltenbasierte Speicherung einen großen Teil des Abstands. Bei Schreibraten von mehreren Millionen pro Sekunde über Tausende von Geräten hat Cassandra weiterhin einen Vorteil. Für Workloads unterhalb dieser Größenordnung mit höheren Anforderungen an Abfragen sind MongoDB-Zeitreihen häufig praktischer.

Verwenden Sie Cassandra, wenn der Schreibdurchsatz bei Millionen pro Sekunde liegt, Active-Active-Schreibvorgänge über mehrere Regionen erforderlich sind, das Zugriffsmuster sehr vorhersehbar ist (eine Tabelle pro Abfrage) und die TTLs für die Datenaufbewahrung einfach sind. Verwenden Sie MongoDB, wenn sich Abfragemuster häufig ändern, komplexe Aggregationen und Joins erforderlich sind, Flexibilität bei Dokumenten wichtig ist, das Team klein bis mittelgroß ist oder Sie vollständige ACID-Transaktionen über mehrere Dokumente hinweg benötigen.

In dieser Lektion haben Sie gelernt: Cassandras leaderlose Architektur ermöglicht einen enormen Schreibdurchsatz und echte Active-Active-Schreibvorgänge über mehrere Regionen, die Mongos Primary-Secondary-Modell nicht erreichen kann; Cassandras Abfragemodell ist schema- bzw. tabellenorientiert, während MongoDB umfangreiche Ad-hoc-Abfragen unterstützt; und die Entscheidung zwischen den beiden Systemen hängt von den Anforderungen an die Schreibskalierung, der benötigten Flexibilität bei Abfragen und den betrieblichen Kapazitäten des Teams ab. Als Nächstes vergleichen wir MongoDB mit DynamoDB.