Apache Cassandra vs. MongoDB

Apache Cassandra und MongoDB sind weit verbreitete NoSQL-Datenbanken, die zum Speichern und Verwalten großer Datenmengen entwickelt wurden.

Die Beliebtheit dieser beiden Datenbanksysteme ist zum Teil auf ihre hohe Skalierbarkeit und Verfügbarkeit zurückzuführen. Beide sind ebenfalls seit weit über einem Jahrzehnt im Einsatz: Cassandra wurde 2008 als Open-Source-Projekt veröffentlicht; die Veröffentlichung von MongoDB erfolgte ein Jahr später.

Trotz der Ähnlichkeiten unterscheiden sich Apache Cassandra und MongoDB in Bezug auf ihre Datenmodelle, ihre Architektur und andere Komponenten erheblich. Diese grundlegenden Unterschiede wirken sich auf ihre Leistung in Bezug auf wichtige Merkmale aus und können beeinflussen, für welche Datenverwaltungsanwendungsfälle sie am besten geeignet sind.

Bevor Sie Apache Cassandra und MongoDB vergleichen, ist es hilfreich, ein Verständnis für NoSQL-Datenbanken zu entwickeln.

NoSQL-Datenbanken, auch als „not only SQL“- oder „Non-SQL“-Datenbanken bezeichnet, sind verteilte Datenbanken. Das bedeutet, dass die darin enthaltenen Informationen eine Replikation auf verschiedene Knoten (einzelne Server, die Daten speichern) erfahren. Diese verteilte Architektur unterstützt hohe Verfügbarkeit und Langlebigkeit; wenn ein oder mehrere Knoten offline gehen, kann der Rest der Datenbank fortfahren.

Vor allem aber sind NoSQL-Datenbanken darauf ausgelegt, Daten außerhalb der traditionellen Strukturen relationaler Datenbankmanagementsysteme (RDBMS) zu speichern und abzufragen. Anstatt sich an eine strenge tabellarische Struktur zu halten, die bei traditionellen relationalen Datenbanken üblich ist, erfordert das nicht-relationale Datenbankdesign kein festes Schema. Dies ermöglicht eine schnelle Skalierbarkeit zur Verwaltung großer Datensätze, einschließlich strukturierter, halbstrukturierter und unstrukturierter Datensätze.

(Es ist wichtig zu beachten, dass die Skalierbarkeit, die in NoSQL-Datenbanken, einschließlich Cassandra und MongoDB, geschätzt wird, horizontale Skalierbarkeit oder „Scaling-out“ ist. Bei der horizontalen Skalierbarkeit können Workloads auf die Server verteilt werden, im Gegensatz zur vertikalen Skalierbarkeit oder „Scaling-up“, die mit SQL-Datenbanken verbunden ist und das Hinzufügen von Speicher zur vorhandenen Hardware erfordert.)

Aufgrund ihrer Leistung, Skalierbarkeit und Flexibilität haben sich NoSQL-Datenbanken als erste Wahl für die Unterstützung von Big-Data-Anwendungen und Echtzeit-Workloads erwiesen. Zu den weiteren beliebten NoSQL-Datenbanken zählen neben Apache Cassandra und MongoDB auch DynamoDB (bereitgestellt von AWS), Redis und CouchDB.

Obwohl beide nur wenige Jahre nach der Jahrtausendwende entstanden, unterscheiden sich Apache Cassandra und MongoDB in ihrer Entstehung.

Apache Cassandra geht auf Facebook zurück, etwa 2007, als Ingenieure nach einem System suchten, das Daten für die wachsende Messaging-Plattform des Unternehmens speichern konnte. Durch die Kombination etablierter NoSQL-Datenbankmodelle schufen sie ein System mit effizienten Datenstrukturen und schließlich Konsistenz – in dem Aktualisierungen so lange weitergegeben werden, bis alle Replikate im Laufe der Zeit übereinstimmen. Die Ingenieure veröffentlichten Cassandra als Open-Source-Projekt im Jahr 2008. Ein Jahr später übernahm die Apache Software Foundation die Leitung. 

MongoDB wurde 2007 als Teil eines Platform-as-a-Service-Projekts des Unternehmens 10Gen ins Leben gerufen. Das Unternehmen konzentrierte sich auf MongoDB – der Name ist ein Spiel mit dem Wort „umfangreich“ – und entwickelte es als dokumentenorientierte Datenbank, die schnell funktioniert und einfach zu bedienen ist. ¹

10Gen, das schließlich seinen Namen in MongoDB Inc. änderte, veröffentlichte MongoDB 2009 als Open-Source-Projekt. Die neuesten Versionen von MongoDB werden jedoch unter der Server Side Public License v1 veröffentlicht.

Die grundlegenden Unterschiede zwischen Apache Cassandra und MongoDB wirken sich auf ihre Leistung und ideale Anwendungsfälle aus. Die wichtigsten Elemente:

• Datenmodelle
• Architektur und Speicher
• Abfragen und andere Sprachen

NoSQL-Datenbanken basieren auf einer von vier Arten von Datenmodellen:

• Dokumentenmodell: Daten werden als strukturierte Dokumente gespeichert, in der Regel in JSON (JavaScript Object Notation) oder BSON (Binary JSON).
• Modell mit breiten Spalten: Die Daten werden in Tabellen mit schmalen Spalten gespeichert, was bedeutet, dass jede Zeile in einer Tabelle eine unterschiedliche Anzahl von Spalten haben kann.
• Schlüssel-Wert-Modell: Daten werden als Schlüssel-Wert-Paare gespeichert (Kennzeichnung oder Markierung, die mit bestimmten Werten gepaart sind).
• Graphenmodell: Daten werden als Knoten und Edges gespeichert, die Entitäten und Beziehungen darstellen.

Das Datenmodell von Cassandra ist ein Wide-Column-Modell, das auch als Wide-Column-Speicher bezeichnet wird. Jede Zeile in einer Cassandra-Tabelle verfügt über eine Sammlung von Spalten und einen eindeutigen Partitionsschlüssel, der zur Verteilung von Daten auf Knoten und Rechenzentren verwendet wird. Zeilen werden durch Primärschlüssel identifiziert, die aus Partitionsschlüsseln und optional aus Clusterschlüsseln bestehen können (Spalten, die Zeilen innerhalb einer Partition oder einer verwandten Gruppe eindeutig identifizieren können).

Dieser Ansatz ist flexibler als der von relationalen Datenbanken, bei denen der Speicherplatz einer festgelegten Anzahl von Spalten zugewiesen wird. Durch das Datenmodell von Cassandra führt die Verwendung von Spalten nur bei Bedarf zu einer effizienteren Speicherung und schnelleren Abfragen. ²

Im Gegensatz dazu verwendet MongoDB ein Dokumentmodell. Daten werden hauptsächlich als BSON gespeichert, eine von MongoDB entwickelte binäre Darstellung von JSON.

BSON hilft dabei, die Hindernisse zu überwinden, die der Standard JSON für Datenbanken mit sich brachte: Unterstützung begrenzter Datentypen, keine feste Länge für Objekte (was die Geschwindigkeit des Traversierens verlangsamt) und das Fehlen von Metadaten (was die Dokumentenabruf verlangsamt). BSON wurde entwickelt, um Geschwindigkeit und Effizienz durch die Kodierung von Format- und Längeninformationen zu optimieren. Es unterstützt auch einige nicht-native JSON-Datentypen, wie z.B. Datumsangaben und binäre Daten. ³

Als NoSQL-Datenbanken unterstützen sowohl Apache Cassandra als auch MongoDB verteilte Systeme mit Datenspeicher über mehrere Rechenressourcen, um Ausfallzeit zu minimieren. Aber wie bei ihren Datenmodellen unterscheidet sich auch die dieser Verteilung zugrunde liegende Architektur grundlegend.

Apache Cassandra basiert auf einer Peer-to-Peer-Architektur. Jeder Knoten in einem Cassandra-Cluster ist gleich, es gibt keine Abhängigkeit von einem Master-Knoten. Wenn Daten in einen Cluster eingefügt werden, wird eine Hash-Funktion auf den Partitionsschlüssel der Zeile angewendet und die Ausgabe wird verwendet, um Daten bestimmten Knoten zuzuweisen. Die Daten werden auch auf andere Knoten kopiert.

Der Replikationsfaktor einer Cassandra-Datenspeicher beschreibt die Anzahl der Kopien der Daten, die in der Datenbank gespeichert sind. Die Speicher-Engine von Cassandra verwendet einen schrittweisen Ablauf (oder Schreibpfad), der aus einem Commit-Protokoll, einer In-Memory-Tabelle (memtable) und sortierten String-Tabellen-Dateien (SSTable) besteht.

Im Gegensatz zu Cassandra verwendet MongoDB ein primäres/sekundäres Modell für seine verteilte Architektur. In MongoDB besteht ein Replikatsatz (eine Gruppe von Instanzen) aus einem primären Knoten, der alle Schreiboperationen (Datenergänzungen oder -änderungen) abwickelt, und sekundären Knoten, die Daten im primären Knoten wiedergeben.

Große Datensätze in MongoDB können auch durch einen Prozess, der als Sharding bekannt ist, auf mehrere Maschinen verteilt werden. Die Informationen werden in Sharding-Cluster unterteilt – mehrere Replikatgruppen und ein Router, der Abfragen von Anwendungen an die Replikatgruppen überträgt – um die Kapazität des Systems zur Verarbeitung von Datenanforderungen zu verbessern.

Die Datenbanken verwenden auch unterschiedliche Indizierungsmethoden. In Apache Cassandra ist der primäre Index der Partitionsschlüssel, obwohl die Cassandra-Dokumentation die speichergebundene Indizierung (die Funktionen für Nicht-Partitionsspalten enthält) als für den meisten Anwendungsfall angemessen anführt. ⁴ Cassandra verfügt auch über Sekundärindizes, bei denen es sich um lokale Indizes handelt, die in Tabellen gespeichert sind, die von den indizierten Werten getrennt sind. MongoDB unterstützt mehrere verschiedene Indextypen für verschiedene Anwendungsfälle, einschließlich Geodatenindizes, Multikey-Indizes und Textindizes.

Per Definition verwenden NoSQL-Datenbanken keine Structured Query Language (SQL), die standardisierte Programmiersprache für relationale Datenbanken. Sowohl Apache Cassandra als auch MongoDB haben jedoch ihre eigenen Abfragesprachen.

Cassandra verwendet eine angepasste Version von SQL namens Cassandra Query Language (CQL). Obwohl CQL in hohem Maße SQL ähnelt, gibt es wesentliche Unterschiede zwischen den beiden. Beispielsweise funktioniert SQL mit standardisierten Tabellen, während CQL für nicht-standardisierte Cassandra-Daten, die mit Partitionsschlüsseln ausgerichtet sind, konzipiert ist. Darüber hinaus ist SQL für Transaktionen optimiert, während CQL für Echtzeitabfragen und Schreibvorgänge mit hohem Volumen konzipiert ist.

MongoDB verwendet MongoDB Query Language (MQL). MQL wurde für die Abfrage von Dokumentenmodellen entwickelt und hat dieselbe Syntax wie Dokumente - eine größere Abweichung von SQL als Cassandra Query Language. MQL wird dafür angepriesen, dass es eine Reihe von Abfragen und Datenbearbeitungsfunktionen ermöglicht, darunter komplexe Abfragen, Aggregationspipelines und Abfragen von Geodaten ⁵

Zusätzlich zu den jeweiligen Abfragesprachen unterscheiden sich die Datenbanken in der Programmierunterstützung. MongoDB bietet offizielle Treiber für über ein Dutzend Programmiersprachen wie Java, Python, Ruby und Node.js. Diese und andere Sprachen sind auch mit Cassandra kompatibel, aber die Treiber werden größtenteils von Drittanbietern angeboten.

Die fundamentalen Unterschiede zwischen Apache Cassandra und MongoDB führen zu einigen Abweichungen in den Leistungsmerkmalen. Diese Variationen können auch durch das CAP-Theorem erklärt werden.

CAP ist eine Abkürzung für drei gewünschte Merkmale verteilter Systeme: Konsistenz (alle Clients sehen zur gleichen Zeit dieselben Daten), Verfügbarkeit (jeder Client, der eine Datenanforderung stellt, erhält eine Antwort, auch wenn ein oder mehrere Knoten ausgefallen sind) und Partitionstoleranz (ein Cluster von Knoten funktioniert auch dann weiter, wenn die Kommunikation zwischen zwei oder mehr Knoten unterbrochen ist).

Das CAP-Theorem besagt, dass ein verteiltes System nur zwei der drei gewünschten Merkmale erfüllen kann. Apache Cassandra wird im Allgemeinen als „AP“-Datenbank kategorisiert und bietet eine hohe Leistung vor allem in Bezug auf Verfügbarkeit und Partitionstoleranz.

Mittlerweile ist MongoDB als „CP“-Datenbank bekannt und zeichnet sich durch Partitionstoleranz und Konsistenz aus. Aber für beide Datenbanken gibt es auch Maßnahmen zur Verbesserung der Leistung bei vermeintlich beeinträchtigten Merkmalen – also der Konsistenz für Cassandra und der Verfügbarkeit für MongoDB.

Schauen wir uns die drei gewünschten Eigenschaften genauer an.

Cassandra unterstützt Hochverfügbarkeit, weil es als dezentrales System mit Daten, die auf mehrere Knoten repliziert werden, eine hohe Fehlertoleranz und keine Funktion eines einzelnen Ausfallpunkts bietet. Wenn ein Knoten Ausfallzeit hat, können andere mit Kopien derselben Daten eine Datenanfrage erfüllen. Darüber hinaus ermöglicht die Replikation von Daten in Rechenzentren auf der ganzen Welt eine geringe Latenz für lokale Benutzer.

Da die Architektur von MongoDB auf einem Primär-/Sekundärmodell basiert, kann es zu einem Single Point of Failure kommen, wenn ein primärer Knoten ausfällt. Das Failover von MongoDB gilt jedoch als stabil: Bei den sogenannten Replikatsatzwahlen wählen die zu einem Replikatsatz gehörenden Knoten einen neuen primären Knoten aus, der den nicht verfügbaren primären Knoten ersetzt. Dieser Prozess ermöglicht es MongoDB, auch hohe Verfügbarkeit zu bieten, wenn auch mit einer kurzen Verzögerung – die Leistung wird erst nach Auswahl des neuen Knotens wieder aufgenommen.

MongoDB bietet von Natur aus eine hohe Konsistenz, da alle Clients in eine Single-Source-of-Truth (SSOT) schreiben – jede Replikatgruppe kann nur einen Knoten haben, der alle Schreiboperationen empfängt. Im Gegensatz dazu bietet Apache Cassandra eine letztendliche Konsistenz: Clients können jederzeit auf beliebige Knoten schreiben, und Unstimmigkeiten werden dann so schnell wie möglich ausgeglichen.

Cassandra ermöglicht es Benutzern auch, die Einheitlichkeit zu optimieren (und gleichzeitig die Verfügbarkeit zu priorisieren), was als optimierbare Konsistenz bekannt ist. Benutzer können eine Konsistenzstufe auswählen, die festlegt, wie viele Replikate einen Lese- oder Schreibvorgang bestätigen müssen, bevor sie ihn der Client-Anwendung bestätigen. Bei höherer Konsistenz müssen mehr Replikate mit Bestätigungen reagieren, was jedoch auch die Latenzzeit erhöht und die Verfügbarkeit verringert.

Sowohl Apache Cassandra als auch MongoDB bieten Partitionstoleranz, da beide so konzipiert sind, dass sie fortfahren, wenn es zu einer Kommunikationsunterbrechung in einem Teil des Systems kommt.

In Apache Cassandra bleiben Knoten auch bei Kommunikationsproblemen verfügbar, aber einige Knoten liefern möglicherweise nicht die aktuellsten Datenversionen (als Antwort auf Datenanfragen), bis die Aufteilung behoben ist. In MongoDB ist die Verfügbarkeit eingeschränkt, um die Datenkonsistenz zu gewährleisten, während die Partition adressiert wird.

Apache Cassandra wird häufig für global verteilte, schreibintensive Workloads mit hohem Durchsatz empfohlen, bei denen Verfügbarkeit und Skalierbarkeit kritisch sind, wie z. B. Streaming und Unterhaltung. Streaming-Dienste wie Netflix verwenden beispielsweise Cassandra, um globale Benutzeraktivitäten zu verarbeiten.

MongoDB eignet sich ideal für dokumentenzentrierte Anwendungsfälle mit flexiblen Schemata, die von der Agilität der Entwickler und einer hohen Einheitlichkeit profitieren. Unternehmen verlassen sich bei der Unterstützung ihrer Content-Management-Systeme häufig auf MongoDB, da MongoDB eine Vielzahl von Content-Assets speichert und bereitstellt.

Trotz der Unterschiede zwischen den beiden Datenbanken können sichdie Anwendungsfälle für Apache Cassandra und die Anwendungsfälle für MongoDB überschneiden. Fallstudien zu jeder Datenbank belegen deren Effektivität für Anwendungendes Internets der Dinge (IoT), E-Commerce und mehr.