it-swarm.com.de

MongoDB vs. Cassandra

Ich prüfe, welche Migrationsoption die beste ist.

Derzeit bin ich auf einer Sharded-MySQL-Partition (horizontale Partition), wobei die meisten meiner Daten in JSON-Blobs gespeichert sind. Ich habe keine komplexen SQL-Abfragen (nach der Partitionierung meiner Datenbank bereits migriert).

Im Moment scheinen sowohl MongoDB als auch Cassandra wahrscheinliche Optionen zu sein. Meine Situation:

  • Viele Lesevorgänge in jeder Abfrage, weniger regelmäßige Schreibvorgänge
  • Keine Sorge um "massive" Skalierbarkeit
  • Mehr Sorge um einfache Einrichtung, Wartung und Code
  • Minimieren Sie die Hardware-/Serverkosten
719
ming yeow

Viele Lesevorgänge in jeder Abfrage, weniger reguläre Schreibvorgänge

Beide Datenbanken bieten eine gute Leistung bei Lesevorgängen, bei denen der Hot Data Set in den Arbeitsspeicher passt. Beide unterstreichen auch Datenmodelle ohne Verknüpfungen (und fördern stattdessen die Denormalisierung), und beide bieten Indizes für Dokumente oder Zeilen , obwohl die Indizes von MongoDB derzeit flexibler sind.

Die Speicher-Engine von Cassandra bietet Schreibvorgänge mit konstanter Zeit, unabhängig davon, wie groß Ihr Datensatz ist. Schreibvorgänge sind in MongoDB problematischer, zum Teil aufgrund der B-Tree-basierten Speicher-Engine, zum Teil aber auch aufgrund des Multi-Granularity-Locking .

Für die Analyse stellt MongoDB eine benutzerdefinierte Map/Reduce-Implementierung bereit. Cassandra bietet native Hadoop-Unterstützung, einschließlich Hive (ein auf Hadoop-Map/Reduce aufgebautes SQL-Data-Warehouse) und Pig (eine Hadoop-spezifische Analysesprache) Viele denken, dass es besser für die Zuordnung/Reduzierung von Arbeitslasten als für SQL geeignet ist. Cassandra unterstützt auch die Verwendung von Spark .

Keine Sorge um "massive" Skalierbarkeit

Wenn Sie sich einen einzelnen Server ansehen, ist MongoDB wahrscheinlich besser geeignet. Für diejenigen, die sich mehr mit Skalierung beschäftigen, ist die No-Single-Point-of-Failure-Architektur von Cassandra einfacher einzurichten und zuverlässiger. (Die globale Schreibsperre von MongoDB kann auch schmerzhafter werden.) Cassandra bietet außerdem eine viel bessere Kontrolle über die Funktionsweise Ihrer Replikation, einschließlich der Unterstützung mehrerer Rechenzentren.

Mehr Bedenken hinsichtlich einfacher Einrichtung, Wartung und Code

Beide sind einfach einzurichten, mit angemessenen Standardeinstellungen für einen einzelnen Server. Cassandra ist in einer Konfiguration mit mehreren Servern einfacher einzurichten, da keine Knoten mit speziellen Rollen zu befürchten sind.

Wenn Sie derzeit JSON-Blobs verwenden, passt MongoDB wahnsinnig gut zu Ihrem Anwendungsfall, da es BSON zum Speichern der Daten verwendet. Sie können umfangreichere und abfragbarere Daten haben als in Ihrer aktuellen Datenbank. Dies wäre der bedeutendste Sieg für Mongo.

569
Michael

Ich habe MongoDB intensiv genutzt (in den letzten 6 Monaten), ein hierarchisches Datenverwaltungssystem aufgebaut und kann sowohl für die einfache Einrichtung (Installation, Ausführung, Verwendung!) Als auch für die Geschwindigkeit bürgen. Solange Sie sorgfältig über Indizes nachdenken, kann sie absolut schnell mitschreien.

Ich stelle fest, dass Cassandra aufgrund ihrer Verwendung in großen Projekten wie Twitter eine bessere Skalierungsfunktionalität aufweist, obwohl das MongoDB-Team dort an der Parität arbeitet. Ich sollte darauf hinweisen, dass ich Cassandra nicht über das Stadium des Probelaufs hinaus verwendet habe, daher kann ich nicht für Details sprechen.

Als wir die NoSQL-Datenbanken bewerteten, war der eigentliche Swinger für mich das Abfragen - Cassandra ist im Grunde nur ein riesiger Schlüssel-/Wertspeicher, und das Abfragen ist etwas umständlich (zumindest im Vergleich zu MongoDB) Leistung Sie müssten ziemlich viele Daten als eine Art manueller Index duplizieren. MongoDB verwendet dagegen ein "Query by Example" -Modell.

Nehmen wir beispielsweise an, Sie haben eine Collection (MongoDB als Entsprechung zu einer RDMS-Tabelle), die Benutzer enthält. MongoDB speichert Datensätze als Dokumente, die im Grunde genommen binäre JSON-Objekte sind. z.B:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "[email protected]",
   Groups: ["Admin", "User", "SuperUser"]
}

Wenn Sie alle Benutzer mit Administratorrechten namens Smith suchen möchten, erstellen Sie einfach ein neues Dokument (an der Administratorkonsole mit Javascript oder in der Produktion in der Sprache Ihrer Wahl):

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

... und dann die Abfrage ausführen. Das ist es. Es gibt zusätzliche Operatoren für Vergleiche, RegEx-Filter usw., aber es ist alles ziemlich einfach und die Wiki-basierte Dokumentation ist ziemlich gut.

143
Richard K.

Warum zwischen einer herkömmlichen Datenbank und einem NoSQL-Datenspeicher wählen? Verwende beide! Das Problem bei NoSQL-Lösungen (über die anfängliche Lernkurve hinaus) ist das Fehlen von Transaktionen - Sie führen alle Aktualisierungen von MySQL durch und lassen MySQL einen NoSQL-Datenspeicher zum Lesen füllen - Sie profitieren dann von den Stärken der jeweiligen Technologie. Dies erhöht die Komplexität, aber Sie haben bereits die MySQL-Seite - fügen Sie einfach MongoDB, Cassandra usw. zum Mix hinzu.

NoSQL-Datenspeicher skalieren im Allgemeinen viel besser als eine herkömmliche Datenbank für dieselben anderen Spezifikationen - es gibt einen Grund, warum Facebook, Twitter, Google und die meisten Start-ups NoSQL-Lösungen verwenden. Es sind nicht nur Freaks, die sich für neue Technologien begeistern.

113

Ich werde wahrscheinlich ein merkwürdiger Mann sein, aber ich denke, Sie müssen bei MySQL bleiben. Sie haben kein echtes Problem beschrieben, das Sie lösen müssen, und MySQL/InnoDB ist ein hervorragendes Speicher-Back-End, selbst für Blob-/Json-Daten.

Es gibt unter Webingenieuren einen Trick, mehr NoSQL zu verwenden, sobald erkannt wird, dass nicht alle Funktionen eines RDBMS verwendet werden. Dies allein ist kein guter Grund, da NoSQL-Datenbanken in den meisten Fällen eher schlechte Daten-Engines aufweisen (was MySQL als Speicher-Engine bezeichnet).

Wenn Sie nicht von dieser Art sind, geben Sie bitte an, was fehlt in MySQL ist und was Sie in einer anderen Datenbank suchen (z. B. Auto-Sharding, automatisches Failover, Multi-Master-Replikation) , eine schwächere Datenkonsistenzgarantie im Cluster, die sich bei höherem Schreibdurchsatz usw. auszahlt.

58
Kostja

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

Wenn Sie nach einem einfachen Setup suchen, dann ist dies Folgendes: Sie müssen MongoDB einfach entpacken und den Mongod-Daemon ausführen, und das war's ... es läuft.

Das ist natürlich nur ein Anfang, aber es ist ganz einfach, damit Sie anfangen können.

19
dalton

Ich habe gestern eine Präsentation auf Mongodb gesehen. Ich kann definitiv sagen, dass das Setup "einfach" war, so einfach wie das Auspacken und Starten. Getan.

Ich glaube, dass sowohl mongodb als auch cassandra auf praktisch jeder regulären Linux-Hardware laufen werden, daher sollten Sie in diesem Bereich nicht zu viele Barrieren finden.

Ich denke, in diesem Fall wird es am Ende des Tages darauf ankommen, womit Sie sich persönlich wohler fühlen und welches Toolset Sie bevorzugen. Was die Präsentation auf Mongodb angeht, gab der Moderator an, dass das Toolset für Mongodb ziemlich leicht sei und dass es nicht viele (sie sagten es wirklich) Tools gäbe, die mit den für MySQL verfügbaren vergleichbar sind. Dies war natürlich ihre Erfahrung, so YMMV. Eine Sache, die ich an Mongodb mochte, war, dass es anscheinend viel Sprachunterstützung dafür gab (Python und .NET sind die beiden, die ich hauptsächlich benutze).

Die Liste der Websites, auf denen mongodb verwendet wird, ist hübsch beeindruckend , und ich weiß, dass Twitter gerade auf Cassandra umgestellt hat.

12
GrayWizardx