Traitement de données à grande échelle Hbase vs Cassandra [fermé]

Je suis presque arrivé à Cassandra après mes recherches sur les solutions de stockage de données à grande échelle. Mais on dit généralement que Hbase est la meilleure solution pour le traitement et l'analyse de données à grande échelle.

Alors que les deux sont le même stockage de clé / valeur et que les deux sont / peuvent exécuter (Cassandra récemment) la couche Hadoop, ce qui fait de Hadoop un meilleur candidat lorsque le traitement / l'analyse est nécessaire sur de grandes données.

J'ai également trouvé de bons détails sur les deux sur http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

mais je suis toujours à la recherche des avantages concrets d'Hbase.

Bien que je sois plus convaincu de Cassandra en raison de sa simplicité pour l'ajout de nœuds et d'une réplication transparente et sans point de défaillance. Et il conserve également la fonction d'index secondaire, donc c'est un bon plus.

Essayer de déterminer ce qui vous convient le mieux dépend vraiment de l'utilisation que vous en ferez, ils ont chacun leurs avantages et sans plus de détails, cela devient plus une guerre de religion. Ce poste que vous avez référencé a également plus d'un an et tous deux ont subi de nombreux changements depuis lors. Veuillez également garder à l'esprit que je ne connais pas les développements plus récents de Cassandra.

Cela dit, je paraphraserai le commetteur HBase Andrew Purtell et ajouterai certaines de mes propres expériences:

• HBase se trouve dans des environnements de production plus importants (1000 nœuds), bien que ce soit toujours dans le stade des ~ 400 installations de nœuds de Cassandra, donc c'est vraiment une différence marginale.

• HBase et Cassandra prennent tous deux en charge la réplication entre les clusters / centres de données. Je pense que HBase expose plus à l'utilisateur, donc cela semble plus compliqué, mais vous obtenez également plus de flexibilité.

• Si votre application a besoin d'une cohérence forte, HBase est probablement la meilleure solution. Il est conçu dès le départ pour être cohérent. Par exemple, cela permet une implémentation plus simple des compteurs atomiques (je pense que Cassandra vient de les avoir) ainsi que des opérations Check and Put.

• Les performances d'écriture sont excellentes, d'après ce que je comprends, c'est l'une des raisons pour lesquelles Facebook a opté pour HBase pour son messager.

• Je ne suis pas sûr de l'état actuel du partitionneur commandé par Cassandra, mais dans le passé, il nécessitait un rééquilibrage manuel. HBase gère cela pour vous si vous le souhaitez. Le partitionneur ordonné est important pour le traitement de style Hadoop.

• Cassandra et HBase sont toutes deux complexes, Cassandra le cache mieux. HBase l'expose davantage en utilisant HDFS pour son stockage, si vous regardez la base de code, Cassandra est tout aussi en couches. Si vous comparez les documents Dynamo et Bigtable, vous pouvez voir que la théorie du fonctionnement de Cassandra est en fait plus complexe.

• HBase a plus de tests unitaires FWIW.

• Tout Cassandra RPC est Thrift, HBase a un Thrift, REST et Java natif. Thrift et REST n'offrent qu'un sous-ensemble de l'API client totale, mais si vous voulez une vitesse pure, le client Java natif est là.

• Il y a des avantages à la fois d'égal à égal et de maître à esclave. La configuration maître-esclave facilite généralement le débogage et réduit un peu la complexité.

• HBase n'est pas uniquement lié au HDFS traditionnel, vous pouvez modifier votre stockage sous-jacent en fonction de vos besoins. MapR semble assez intéressant et j'ai entendu de bonnes choses même si je ne l'ai pas utilisé moi-même.

En tant que développeur Cassandra, je suis meilleur pour répondre à l'autre côté de la question:

• Cassandra évolue mieux. Cassandra est connu pour évoluer jusqu'à plus de 400 nœuds dans un cluster ; lorsque Facebook a déployé la messagerie au-dessus de HBase, ils ont dû le partager entre des sous-clusters HBase de 100 nœuds .
• Cassandra prend en charge des centaines, voire des milliers de ColumnFamilies. " HBase ne fonctionne actuellement pas bien avec tout ce qui dépasse deux ou trois familles de colonnes ."
• En tant que système entièrement distribué sans nœuds ou processus «spéciaux» , Cassandra est plus simple à configurer et à utiliser , plus facile à dépanner et plus robuste.
• La prise en charge de Cassandra pour la réplication multimaître signifie que non seulement vous bénéficiez de la puissance évidente de plusieurs centres de données - redondance géographique, latences locales - mais vous pouvez également diviser les charges de travail en temps réel et analytiques en groupes séparés, avec une réplication bidirectionnelle en temps réel entre eux . Si vous ne divisez pas ces charges de travail, elles s'affronteront de manière spectaculaire.
• Étant donné que chaque nœud Cassandra gère son propre stockage local, Cassandra a un avantage de performances substantiel qui ne sera probablement pas réduit de manière significative. (Par exemple, il est courant de placer le journal de validation Cassandra sur un périphérique séparé afin qu'il puisse effectuer ses écritures séquentielles sans être gêné par des entrées / sorties aléatoires à partir de demandes de lecture.)
• Cassandra vous permet de choisir la force que vous souhaitez qu'il exige de la cohérence pour chaque opération. Parfois, cela est mal compris car "Cassandra ne vous donne pas une cohérence forte", mais c'est incorrect.
• Cassandra propose RandomPartitioner ainsi que OrderedPartitioner, plus Bigtable. RandomPartitioner est beaucoup moins sujet aux points chauds.
• Cassandra offre une mise en cache sur ou hors tas avec des performances comparables à Memcached, mais sans les problèmes de cohérence du cache ou la complexité de nécessiter des pièces mobiles supplémentaires
• Les clients non Java ne sont pas des citoyens de seconde zone

À ma connaissance, le principal avantage de HBase à l'heure actuelle (HBase 0.90.4 et Cassandra 0.8.4) est que Cassandra ne prend pas encore en charge la compression transparente des données. (Ceci a été ajouté pour Cassandra 1.0 , prévu début octobre, mais c'est aujourd'hui un réel avantage pour HBase.) HBase peut également être mieux optimisé pour les types d'analyses de portée effectuées par le traitement par lots Hadoop.

Il y a aussi des choses qui ne sont pas nécessairement meilleures, ou pires, simplement différentes. HBase adhère plus strictement au modèle de données Bigtable, où chaque colonne est versionnée implicitement. Cassandra supprime la gestion des versions et ajoute des SuperColonnes à la place.

J'espère que ça t'as aidé!

L'utilisation de clusters hBase à 100 nœuds n'est pas due au fait que HBase ne s'adapte pas à des tailles plus grandes. C'est parce qu'il est plus facile d'effectuer des mises à niveau logicielles hBase / HDFS de manière continue sans interrompre l'ensemble de votre service. Une autre raison est d'empêcher qu'un seul NameNode soit un SPOF pour l'ensemble du service. En outre, HBase est utilisé pour divers services (pas seulement pour les messages FB) et il est prudent d'avoir une approche à l'emporte-pièce pour configurer de nombreux clusters HBase basés sur une approche de pod à 100 nœuds. Le nombre 100 est adhoc, nous ne nous sommes pas concentrés sur la question de savoir si 100 est optimal ou non.