763 Stimmen

MongoDB vs. Cassandra

Ich überlege, was die beste Migrationsoption sein könnte.

Derzeit verwende ich ein Sharded-MySQL (horizontale Partition), wobei die meisten meiner Daten in JSON-Blobs gespeichert sind. Ich habe keine komplexen SQL-Abfragen (bereits weg migriert, da ich meine Datenbank partitioniert).

Im Moment sieht es so aus, als ob sowohl MongoDB als auch Cassandra in Frage kommen würden. Meine Situation:

  • Viele Lesevorgänge in jeder Abfrage, weniger regelmäßige Schreibvorgänge
  • Keine Sorge um "massive" Skalierbarkeit
  • Einfache Einrichtung, Wartung und Code sind wichtiger
  • Minimierung der Hardware-/Serverkosten

5 Stimmen

Eine offizielle Leistungsvergleichsstatistik ist verfügbar. Cassandra vs. MongoDB vs. HBase

1 Stimmen

>Viele Lesevorgänge in jeder Abfrage, weniger regelmäßige Schreibvorgänge => Suchen Sie nach CQRS (trennen Sie Ihre Lesevorgänge von Ihren Schreibvorgängen, wahrscheinlich ohne Event-Sourcing, aber prüfen Sie, ob Sie Ihr Lesemodell asynchron aktualisieren können sync kann auch funktionieren es hängt von Ihren Anwendungsfällen ab)

4 Stimmen

Das ist wirklich eine gute Frage. Ich frage mich, ob es eine aktualisierte Version davon gibt? Diese hier ist schon sehr alt

602voto

Michael Punkte 8416

Viele Lesevorgänge in jeder Abfrage, weniger regelmäßige Schreibvorgänge

Beide Datenbanken sind gut für Lesevorgänge geeignet, bei denen der heiße Datensatz in den Speicher passt. Beide legen auch Wert auf verbindungslose Datenmodelle (und fördern stattdessen die Denormalisierung), und beide bieten Indizes auf Dokumente o Zeilen obwohl die Indizes von MongoDB derzeit flexibler sind.

Die Speicher-Engine von Cassandra ermöglicht Schreibvorgänge in konstanter Zeit, egal wie groß Ihr Datensatz wird. In MongoDB sind Schreibvorgänge problematischer, was zum Teil an der B-Tree-basierten Speichermaschine liegt, vor allem aber an der Multigranularitätssicherung es tut.

Für Analysen bietet MongoDB eine benutzerdefinierte Map/Reduce-Implementierung; Cassandra bietet native Hadoop-Unterstützung, auch für Bienenstock (ein SQL-Data-Warehouse auf der Grundlage von Hadoop map/reduce) und Schwein (eine Hadoop-spezifische Analysesprache, die nach Ansicht vieler besser für Map/Reduce-Workloads geeignet ist als SQL). Cassandra unterstützt auch die Verwendung von Funke .

Keine Sorge um "massive" Skalierbarkeit

Wenn Sie nur einen einzigen Server benötigen, ist MongoDB wahrscheinlich die bessere Wahl. Für diejenigen, die sich mehr Gedanken über die Skalierung machen, ist die Architektur von Cassandra, die keinen einzigen Fehlerpunkt aufweist, einfacher einzurichten und zuverlässiger. (Auch die globale Schreibsperre von MongoDB ist tendenziell problematischer.) Cassandra bietet außerdem viel mehr Kontrolle über die Replikation, einschließlich der Unterstützung für mehrere Rechenzentren.

Einfache Einrichtung, Wartung und Code sind wichtiger

Beide sind trivial einzurichten, mit vernünftigen Standardeinstellungen für einen einzelnen Server. Cassandra ist in einer Konfiguration mit mehreren Servern einfacher einzurichten, da es keine Knoten mit speziellen Rollen gibt, um die man sich kümmern muss.

Wenn Sie derzeit JSON-Blobs verwenden, ist MongoDB eine wahnsinnig gute Lösung für Ihren Anwendungsfall, da es BSON zum Speichern der Daten verwendet. Sie werden reichhaltigere und besser abfragbare Daten haben, als Sie es in Ihrer derzeitigen Datenbank hätten. Das wäre der größte Gewinn für Mongo.

148voto

Richard K. Punkte 2024

Ich habe MongoDB ausgiebig genutzt (in den letzten 6 Monaten), um ein hierarchisches Datenverwaltungssystem aufzubauen, und ich kann mich sowohl für die Einfachheit der Einrichtung (installieren, ausführen, verwenden!) als auch für die Geschwindigkeit verbürgen. Solange man sorgfältig über Indizes nachdenkt, kann man mit der Geschwindigkeit absolut zufrieden sein.

Ich gehe davon aus, dass Cassandra aufgrund seiner Verwendung bei Großprojekten wie Twitter über bessere Skalierungsfunktionen verfügt, obwohl das MongoDB-Team daran arbeitet, hier gleichzuziehen. Ich sollte darauf hinweisen, dass ich Cassandra nicht über die Testphase hinaus verwendet habe, daher kann ich nicht für die Details sprechen.

Als wir NoSQL-Datenbanken untersuchten, war für mich die Abfrage das Entscheidende - Cassandra ist im Grunde nur ein riesiger Key/Value-Speicher, und die Abfrage ist etwas umständlich (zumindest im Vergleich zu MongoDB), so dass man aus Leistungsgründen ziemlich viele Daten als eine Art manuellen Index duplizieren muss. MongoDB hingegen verwendet ein "Query by Example"-Modell.

Nehmen wir an, Sie haben eine Collection (MongoDB-Umgangssprache für das Äquivalent zu einer RDMS-Tabelle), die Benutzer enthält. MongoDB speichert Datensätze als Dokumente, die im Grunde binäre JSON-Objekte sind. z. B:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

Wenn Sie alle Benutzer mit dem Namen Smith finden möchten, die über Admin-Rechte verfügen, erstellen Sie einfach ein neues Dokument (in der Verwaltungskonsole mit Javascript oder in der Produktionsumgebung mit der Sprache Ihrer Wahl):

{
   LastName: "Smith",
   Groups: "Admin"
}

...und führen Sie dann die Abfrage aus. Das war's schon. Es gibt zusätzliche Operatoren für Vergleiche, RegEx-Filterung usw., aber es ist alles ziemlich einfach, und die Wiki-basierte Dokumentation ist ziemlich gut.

122voto

Jason Grant Taylor Punkte 1219

Warum zwischen einer herkömmlichen Datenbank und einem NoSQL-Datenspeicher wählen? Verwenden Sie beides! Das Problem bei NoSQL-Lösungen (abgesehen von der anfänglichen Lernkurve) ist das Fehlen von Transaktionen - Sie führen alle Aktualisierungen in MySQL durch und lassen MySQL einen NoSQL-Datenspeicher für Lesevorgänge befüllen - Sie profitieren dann von den Stärken jeder Technologie. Das erhöht zwar die Komplexität, aber Sie haben ja schon die MySQL-Seite - fügen Sie einfach MongoDB, Cassandra usw. hinzu.

NoSQL-Datenspeicher skalieren in der Regel weitaus besser als herkömmliche DBs bei ansonsten gleichen Spezifikationen - es gibt einen Grund, warum Facebook, Twitter, Google und die meisten Start-ups NoSQL-Lösungen verwenden. Es sind nicht nur Geeks, die sich an neuer Technologie berauschen.

60voto

Kostja Punkte 1577

Ich werde wahrscheinlich ein Außenseiter sein, aber ich denke, Sie sollten bei MySQL bleiben. Sie haben kein wirkliches Problem beschrieben, das Sie lösen müssen, und MySQL/InnoDB ist ein ausgezeichnetes Speicher-Backend, sogar für Blob/Json-Daten.

Es ist ein gängiger Trick unter Web-Ingenieuren, dass sie versuchen, mehr NoSQL zu verwenden, sobald sie feststellen, dass nicht alle Funktionen eines RDBMS genutzt werden. Dies allein ist jedoch kein guter Grund, da NoSQL-Datenbanken in den meisten Fällen eher schlechte Daten-Engines haben (das, was MySQL eine Storage Engine nennt).

Wenn Sie nicht zu dieser Sorte gehören, dann geben Sie bitte an, was das ist fehlt in MySQL und die Sie in einer anderen Datenbank suchen (z. B. Auto-Sharding, automatisches Failover, Multi-Master-Replikation, eine schwächere Datenkonsistenzgarantie im Cluster, die sich durch einen höheren Schreibdurchsatz auszahlt usw.).

20voto

dalton Punkte 3596

Ich habe Cassandra nicht benutzt, aber ich habe MongoDB benutzt und finde es großartig.

Wenn Sie eine einfache Einrichtung wünschen, ist dies die richtige Lösung: Entpacken Sie einfach MongoDB und starten Sie den Mongod-Daemon, und das war's ... er läuft.

Natürlich ist das nur ein Anfang, aber für den Anfang ist es einfach.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X