Cassandra gegen MongoDB

Ziehen Sie Cassandra oder MongoDB als Datenspeicher für Ihr nächstes Projekt in Betracht? Möchten Sie die beiden Datenbanken vergleichen? Cassandra und MongoDB sind beide „NoSQL“-Datenbanken, aber in Wirklichkeit sind sie sehr unterschiedlich. Sie haben sehr unterschiedliche Stärken und Leistungsversprechen – daher muss jeder Vergleich nuanciert sein. Beginnen wir mit den anfänglichen Anforderungen … Keine dieser Datenbanken ersetzt RDBMS, noch sind sie „ACID“-Datenbanken. Wenn Sie also eine Transaktionsarbeitslast haben, bei der Normalisierung und Konsistenz die Hauptanforderungen sind, wird keine dieser Datenbanken für Sie funktionieren. Sie sind besser dran, bei traditionellen relationalen Datenbanken wie MySQL, PostgreSQL, Oracle usw. zu bleiben. Nachdem wir relationale Datenbanken aus dem Weg geräumt haben, betrachten wir die Hauptunterschiede zwischen Cassandra und MongoDB, die Ihnen bei der Entscheidungsfindung helfen werden. In diesem Beitrag werde ich nicht auf bestimmte Funktionen eingehen, sondern auf einige strategische Unterschiede auf hoher Ebene hinweisen, um Ihnen bei der Auswahl zu helfen.

1. Ausdrucksstarkes Objektmodell

MongoDB unterstützt ein reichhaltiges und ausdrucksstarkes Objektmodell. Objekte können Eigenschaften haben und Objekte können ineinander verschachtelt sein (für mehrere Ebenen). Dieses Modell ist sehr „objektorientiert“ und kann problemlos jede Objektstruktur in Ihrer Domäne darstellen. Sie können auch die Eigenschaft jedes Objekts auf jeder Ebene der Hierarchie indizieren – das ist auffallend leistungsfähig! Cassandra hingegen bietet eine ziemlich traditionelle Tabellenstruktur mit Zeilen und Spalten. Die Daten sind strukturierter und jede Spalte hat einen bestimmten Typ, der während der Erstellung angegeben werden kann.

Urteil:Wenn Ihre problematische Domain ein reichhaltiges Datenmodell benötigt, ist MongoDB-Hosting besser für Sie geeignet.

2. Sekundärindizes

Sekundärindizes sind ein erstklassiges Konstrukt in MongoDB. Dies macht es einfach, jede Eigenschaft eines in MongoDB gespeicherten Objekts zu indizieren, selbst wenn es verschachtelt ist. Dies macht es wirklich einfach, basierend auf diesen sekundären Indizes abzufragen. Cassandra bietet nur oberflächliche Unterstützung für Sekundärindizes. Sekundärindizes sind ebenfalls auf einzelne Spalten und Gleichheitsvergleiche beschränkt. Wenn Sie hauptsächlich mit dem Primärschlüssel abfragen, funktioniert Cassandra gut für Sie.

Urteil:  Wenn Ihre Anwendung sekundäre Indizes und Flexibilität im Abfragemodell benötigt, ist MongoDB besser für Sie geeignet.

3. Hohe Verfügbarkeit

MongoDB unterstützt ein „Single-Master“-Modell. Das bedeutet, dass Sie einen Master-Knoten und eine Reihe von Slave-Knoten haben. Falls der Master ausfällt, wird einer der Slaves zum Master gewählt. Dieser Vorgang erfolgt automatisch, dauert jedoch einige Zeit, normalerweise 10-40 Sekunden. Während dieser Zeit der Wahl des neuen Anführers ist Ihr Replikatsatz ausgefallen und kann keine Schreibvorgänge annehmen. Dies funktioniert für die meisten Anwendungen, hängt aber letztendlich von Ihren Anforderungen ab. Cassandra unterstützt ein „Multiple-Master“-Modell. Der Verlust eines einzelnen Knotens wirkt sich nicht auf die Schreibfähigkeit des Clusters aus – Sie können also eine 100 %ige Betriebszeit für Schreibvorgänge erreichen.

Urteil:Wenn Sie 100 % Verfügbarkeit benötigen, ist Cassandra besser für Sie geeignet.

4. Skalierbarkeit schreiben

MongoDB mit seinem „Single-Master“-Modell kann nur auf der Primärdatenbank schreiben. Die sekundären Server können nur für Lesevorgänge verwendet werden. Wenn Sie also ein Replica-Set mit drei Knoten haben, übernimmt nur der Master Schreibvorgänge und die anderen beiden Knoten werden nur zum Lesen verwendet. Dies schränkt die Schreibskalierbarkeit stark ein. Sie können mehrere Shards bereitstellen, aber im Wesentlichen können nur 1/3 Ihrer Datenknoten Schreibvorgänge annehmen. Cassandra mit seinem „Multiple-Master“-Modell kann auf jedem Server schreiben. Im Wesentlichen ist Ihre Schreibskalierbarkeit durch die Anzahl der Server im Cluster begrenzt. Je mehr Server Sie im Cluster haben, desto besser lässt es sich skalieren.

Urteil:Wenn Schreibskalierbarkeit Ihr Ding ist, ist Cassandra besser für Sie geeignet.

5. Unterstützung der Abfragesprache

Cassandra unterstützt die SQL-ähnliche Abfragesprache CQL. Wenn Sie bereits ein Team von Datenanalysten haben, können diese einen Großteil ihrer SQL-Kenntnisse übertragen, was für große Organisationen sehr wichtig ist. CQL ist jedoch kein vollwertiges ANSI SQL – es hat mehrere Einschränkungen (keine Join-Unterstützung, keine OR-Klauseln) usw. MongoDB hat zu diesem Zeitpunkt keine Unterstützung für eine Abfragesprache. Die Abfragen sind als JSON-Fragmente strukturiert.

Urteil:Wenn Sie Unterstützung in der Abfragesprache benötigen, ist Cassandra die bessere Lösung für Sie.

6. Leistungsbenchmarks

Reden wir über Leistung. An dieser Stelle erwarten Sie wahrscheinlich einen Performance-Benchmark-Vergleich der Datenbanken. Auf Leistungsbenchmarks habe ich bewusst in den Vergleich verzichtet. Bei jedem Vergleich müssen wir sicherstellen, dass wir einen direkten Vergleich anstellen.

1.  Datenbankmodell  - Das Datenbankmodell/Schema der getesteten Anwendung macht einen großen Unterschied. Einige Schemas eignen sich gut für MongoDB und andere gut für Cassandra. Beim Vergleich von Datenbanken ist es daher wichtig, ein Modell zu verwenden, das für beide Datenbanken einigermaßen gut funktioniert.
2.  Eigenschaften laden – Die Eigenschaften der Benchmark-Last sind sehr wichtig. Z.B. Bei schreibintensiven Benchmarks würde ich erwarten, dass Cassandra MongoDB raucht. In leseintensiven Benchmarks sollten MongoDB und Cassandra jedoch eine ähnliche Leistung erbringen.
3. Konsistenzanforderungen - Das ist eine knifflige Frage. Sie müssen sicherstellen, dass die angegebenen Lese-/Schreibkonsistenzanforderungen in beiden Datenbanken identisch sind und nicht auf einen Teilnehmer ausgerichtet sind. Sehr oft werden in einer Reihe von „Marketing“-Benchmarks die Knöpfe so eingestellt, dass sie die andere Seite benachteiligen. Achten Sie also genau auf die Konsistenzeinstellungen.

Eine letzte Sache, die Sie beachten sollten, ist, dass die Benchmark-Last die Leistung Ihrer Anwendung widerspiegeln kann oder nicht. Damit Benchmarks also nützlich sind, ist es sehr wichtig, eine Benchmark-Last zu finden, die die Leistungsmerkmale Ihrer Anwendung widerspiegelt. Hier sind einige Benchmarks, die Sie sich ansehen sollten:
- NoSQL-Leistungsbenchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase

7. Benutzerfreundlichkeit

Wenn Sie diese Frage vor ein paar Jahren gestellt hätten, wäre MongoDB zweifellos der Gewinner. Es ist eine ziemlich einfache Aufgabe, MongoDB zum Laufen zu bringen. In den letzten Jahren hat Cassandra jedoch große Fortschritte in diesem Aspekt des Produkts gemacht. Mit der Einführung von CQL als primäre Schnittstelle für Cassandra ist es noch einen Schritt weiter gegangen – sie haben es Legionen von SQL-Programmierern sehr einfach gemacht, Cassandra sehr einfach zu verwenden.

Urteil:Beide sind ziemlich einfach zu bedienen und hochzufahren.

8. Native Aggregation

MongoDB verfügt über ein integriertes Aggregations-Framework zum Ausführen einer ETL-Pipeline zum Transformieren der in der Datenbank gespeicherten Daten. Dies ist großartig für kleine bis mittlere Jobs, aber wenn Ihre Datenverarbeitungsanforderungen komplizierter werden, wird das Aggregationsframework schwieriger zu debuggen. Cassandra hat kein integriertes Aggregationsframework. Hierfür werden externe Tools wie Hadoop, Spark verwendet.

9. Schemalose Modelle

In MongoDB können Sie festlegen, dass kein Schema für Ihre Dokumente erzwungen wird. Während dies in früheren Versionen die Standardeinstellung war, haben Sie in der neueren Version die Möglichkeit, ein Schema für Ihre Dokumente zu erzwingen. Jedes Dokument in MongoDB kann eine andere Struktur haben und es liegt an Ihrer Anwendung, die Daten zu interpretieren. Während dies für die meisten Anwendungen nicht relevant ist, ist in einigen Fällen die zusätzliche Flexibilität wichtig. Cassandra in den neueren Versionen (mit CQL als Standardsprache) bietet statische Typisierung. Sie müssen den Spaltentyp im Voraus definieren.

Zusammenfassend hier die wichtigsten Unterschiede in Tabellenform:
Wenn Sie die vollständige Infografik anzeigen möchten, besuchen Sie unsere Vergleichsseite zwischen Cassandra und MongoDB.