Datenverarbeitung in großem Maßstab Hbase vs Cassandra [geschlossen]

Ich bin fast bei Cassandra gelandet, nachdem ich nach umfangreichen Datenspeicherlösungen gesucht habe. Es wird jedoch allgemein gesagt, dass Hbase eine bessere Lösung für die Verarbeitung und Analyse von Daten in großem Maßstab ist.

Während beide derselbe Schlüssel- / Wertspeicher sind und beide die Hadoop-Schicht ausführen können (Cassandra kürzlich), ist Hadoop ein besserer Kandidat, wenn die Verarbeitung / Analyse großer Datenmengen erforderlich ist.

Gute Details zu beiden habe ich auch unter http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/ gefunden.

aber ich suche immer noch nach konkreten Vorteilen von Hbase.

Ich bin zwar mehr von Cassandra überzeugt, weil es einfach ist, Knoten hinzuzufügen und nahtlos zu replizieren, und keine Point-of-Failure-Funktionen bietet. Und es behält auch sekundäre Indexfunktion bei, so dass es ein gutes Plus ist.

Der Versuch, herauszufinden, welches für Sie am besten geeignet ist, hängt wirklich davon ab, wofür Sie es verwenden. Sie haben jeweils ihre Vorteile, und ohne weitere Details wird es eher zu einem Religionskrieg. Der Beitrag, auf den Sie verwiesen haben, ist ebenfalls älter als ein Jahr und beide haben seitdem viele Änderungen erfahren. Bitte denken Sie auch daran, dass ich mit den neueren Entwicklungen von Cassandra nicht vertraut bin.

Trotzdem werde ich den HBase-Committer Andrew Purtell umschreiben und einige meiner eigenen Erfahrungen hinzufügen:

• HBase befindet sich in größeren Produktionsumgebungen (1000 Knoten), obwohl sich das noch im Ballpark von Cassandras ~ 400-Knoten-Installationen befindet, so dass es wirklich ein geringfügiger Unterschied ist.

• HBase und Cassandra unterstützen beide die Replikation zwischen Clustern / Rechenzentren. Ich glaube, dass HBase dem Benutzer mehr zur Verfügung stellt, so dass es komplizierter erscheint, aber dann erhalten Sie auch mehr Flexibilität.

• Wenn Ihre Anwendung eine starke Konsistenz benötigt, ist HBase wahrscheinlich besser geeignet. Es ist von Grund auf konsequent konzipiert. Zum Beispiel ermöglicht es eine einfachere Implementierung von Atomzählern (ich glaube, Cassandra hat sie gerade erhalten) sowie von Check and Put-Operationen.

• Die Schreibleistung ist großartig. Soweit ich weiß, war dies einer der Gründe, warum Facebook HBase als Messenger gewählt hat.

• Ich bin mir nicht sicher über den aktuellen Status von Cassandras bestelltem Partitionierer, aber in der Vergangenheit war eine manuelle Neuausrichtung erforderlich. HBase erledigt das für Sie, wenn Sie möchten. Der bestellte Partitionierer ist wichtig für die Verarbeitung im Hadoop-Stil.

• Cassandra und HBase sind beide komplex, Cassandra versteckt es einfach besser. HBase macht es mehr durch die Verwendung von HDFS für seine Speicherung verfügbar, wenn Sie sich die Codebasis ansehen, die Cassandra genauso vielschichtig ist. Wenn Sie die Papiere Dynamo und Bigtable vergleichen, können Sie sehen, dass Cassandras Betriebstheorie tatsächlich komplexer ist.

• HBase hat mehr Unit-Tests FWIW.

• Alle Cassandra RPC sind Thrift, HBase hat Thrift, REST und natives Java. Thrift und REST bieten nur eine Teilmenge der gesamten Client-API. Wenn Sie jedoch reine Geschwindigkeit wünschen, ist der native Java-Client vorhanden.

• Peer-to-Peer und Master-to-Slave bieten Vorteile. Das Master-Slave-Setup erleichtert im Allgemeinen das Debuggen und reduziert die Komplexität erheblich.

• HBase ist nicht nur an herkömmliches HDFS gebunden, sondern Sie können den zugrunde liegenden Speicher je nach Ihren Anforderungen austauschen. MapR sieht ziemlich interessant aus und ich habe gute Dinge gehört, obwohl ich es selbst nicht benutzt habe.

Als Cassandra-Entwickler kann ich die andere Seite der Frage besser beantworten:

• Cassandra skaliert besser. Es ist bekannt, dass Cassandra auf über 400 Knoten in einem Cluster skaliert . Als Facebook Messaging auf HBase bereitstellte, musste es über HBase-Subcluster mit 100 Knoten verteilt werden .
• Cassandra unterstützt Hunderte, sogar Tausende von ColumnFamilies. " HBase kommt derzeit mit nichts über zwei oder drei Spaltenfamilien gut zurecht ."
• Als vollständig verteiltes System ohne "spezielle" Knoten oder Prozesse ist Cassandra einfacher einzurichten und zu betreiben , einfacher zu beheben und robuster.
• Durch die Unterstützung von Cassandra für die Multi-Master-Replikation erhalten Sie nicht nur die offensichtliche Leistung mehrerer Rechenzentren - geografische Redundanz, lokale Latenzen -, sondern können auch Echtzeit- und analytische Workloads in separate Gruppen aufteilen, wobei eine bidirektionale Echtzeitreplikation zwischen ihnen erfolgt . Wenn Sie diese Workloads nicht aufteilen, werden sie spektakulär miteinander konkurrieren.
• Da jeder Cassandra-Knoten seinen eigenen lokalen Speicher verwaltet, bietet Cassandra einen erheblichen Leistungsvorteil, der wahrscheinlich nicht wesentlich eingeschränkt wird. (Zum Beispiel ist es üblich, das Cassandra-Commitlog auf einem separaten Gerät abzulegen, damit es seine sequentiellen Schreibvorgänge ungehindert durch zufällige E / A aus Leseanforderungen ausführen kann.)
• Mit Cassandra können Sie auswählen, wie stark die Konsistenz pro Operation sein soll. Manchmal wird dies als "Cassandra gibt Ihnen keine starke Konsistenz" missverstanden, aber das ist falsch.
• Cassandra bietet RandomPartitioner sowie den Bigtable-ähnlichen OrderedPartitioner an. RandomPartitioner ist viel weniger anfällig für Hot Spots.
• Cassandra bietet On- oder Off-Heap-Caching mit einer Leistung, die mit Memcached vergleichbar ist, jedoch ohne die Probleme mit der Cache-Konsistenz oder die Komplexität, zusätzliche bewegliche Teile zu benötigen
• Nicht-Java-Clients sind keine Bürger zweiter Klasse

Meines Wissens besteht der Hauptvorteil, den HBase derzeit hat (HBase 0.90.4 und Cassandra 0.8.4), darin, dass Cassandra die transparente Datenkomprimierung noch nicht unterstützt. (Dies wurde für Cassandra 1.0 hinzugefügt , das Anfang Oktober erscheinen soll, aber heute ist dies ein echter Vorteil für HBase.) HBase kann auch besser für die Arten von Bereichsscans optimiert werden, die durch die Hadoop-Stapelverarbeitung durchgeführt werden.

Es gibt auch einige Dinge, die nicht unbedingt besser oder schlechter sind, nur anders. HBase hält sich strenger an das Bigtable-Datenmodell, bei dem jede Spalte implizit versioniert wird. Cassandra lässt die Versionierung fallen und fügt stattdessen SuperColumns hinzu.

Hoffentlich hilft das!

Der Grund für die Verwendung von 100-Knoten-hBase-Clustern liegt nicht darin, dass HBase nicht auf größere Größen skaliert werden kann. Dies liegt daran, dass es einfacher ist, hBase / HDFS-Software-Upgrades fortlaufend durchzuführen, ohne Ihren gesamten Service zu beeinträchtigen. Ein weiterer Grund besteht darin, zu verhindern, dass ein einzelner NameNode ein SPOF für den gesamten Dienst ist. Außerdem wird HBase für verschiedene Dienste (nicht nur für FB-Nachrichten) verwendet, und es ist ratsam, einen Cookie-Cutter-Ansatz zum Einrichten zahlreicher HBase-Cluster auf der Grundlage eines 100-Knoten-Pod-Ansatzes zu verwenden. Die Zahl 100 ist adhoc, wir haben uns nicht darauf konzentriert, ob 100 optimal ist oder nicht.