Procesamiento de datos a gran escala Hbase vs Cassandra [cerrado]

Casi llego a Cassandra después de mi investigación sobre soluciones de almacenamiento de datos a gran escala. Pero generalmente se dice que Hbase es una mejor solución para el procesamiento y análisis de datos a gran escala.

Si bien ambos son el mismo almacenamiento de clave / valor y ambos son / pueden ejecutar (Cassandra recientemente) la capa de Hadoop, lo que hace que Hadoop sea un mejor candidato cuando se requiere procesamiento / análisis de datos grandes.

También encontré buenos detalles sobre ambos en http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

pero sigo buscando ventajas concretas de Hbase.

Si bien estoy más convencido de Cassandra por su simplicidad para agregar nodos y replicación perfecta y sin características de punto de falla. Y también mantiene la función de índice secundario, por lo que es una buena ventaja.

Tratar de determinar cuál es mejor para ti realmente depende de para qué lo vas a usar, cada uno tiene sus ventajas y sin más detalles se vuelve más una guerra religiosa. Esa publicación a la que hizo referencia también tiene más de un año y ambas han pasado por muchos cambios desde entonces. También tenga en cuenta que no estoy familiarizado con los desarrollos más recientes de Cassandra.

Habiendo dicho eso, parafrasearé al autor de HBase Andrew Purtell y agregaré algunas de mis propias experiencias:

• HBase se encuentra en entornos de producción más grandes (1000 nodos), aunque todavía está en el estadio de las instalaciones de 400 nodos de Cassandra, por lo que es realmente una diferencia marginal.

• HBase y Cassandra admiten la replicación entre clústeres / centros de datos. Creo que HBase expone más al usuario, por lo que parece más complicado, pero también obtiene más flexibilidad.

• Si lo que necesita su aplicación es una gran consistencia, es probable que HBase sea la mejor opción. Está diseñado desde cero para ser consistente. Por ejemplo, permite una implementación más sencilla de contadores atómicos (creo que Cassandra los acaba de obtener), así como las operaciones Check y Put.

• El rendimiento de escritura es excelente, por lo que tengo entendido, esa fue una de las razones por las que Facebook eligió HBase para su mensajería.

• No estoy seguro del estado actual del particionador ordenado de Cassandra, pero en el pasado requería un reequilibrio manual. HBase se encarga de eso por ti si quieres. El particionador ordenado es importante para el procesamiento de estilo Hadoop.

• Cassandra y HBase son complejos, Cassandra simplemente lo oculta mejor. HBase lo expone más mediante el uso de HDFS para su almacenamiento, si nos fijamos en la base de código, Cassandra tiene las mismas capas. Si compara los artículos de Dynamo y Bigtable, puede ver que la teoría de funcionamiento de Cassandra es en realidad más compleja.

• HBase tiene más pruebas unitarias FWIW.

• Todo Cassandra RPC es Thrift, HBase tiene Thrift, REST y Java nativo. Thrift y REST solo ofrecen un subconjunto de la API total del cliente, pero si desea velocidad pura, el cliente Java nativo está ahí.

• Hay ventajas tanto de igual a igual como de maestro a esclavo. La configuración maestro-esclavo generalmente facilita la depuración y reduce bastante la complejidad.

• HBase no está vinculado solo a HDFS tradicional, puede cambiar su almacenamiento subyacente según sus necesidades. MapR parece bastante interesante y he escuchado cosas buenas, aunque no lo he usado yo mismo.

Como desarrollador de Cassandra, respondo mejor al otro lado de la pregunta:

• Cassandra escala mejor. Se sabe que Cassandra escala a más de 400 nodos en un clúster ; cuando Facebook implementó Messaging encima de HBase, tuvo que dividirlo en subgrupos de HBase de 100 nodos .
• Cassandra admite cientos, incluso miles de ColumnFamilies. " Actualmente, HBase no funciona bien con nada por encima de dos o tres familias de columnas ".
• Como un sistema completamente distribuido sin nodos o procesos "especiales" , Cassandra es más simple de configurar y operar , más fácil de solucionar y más robusto.
• El soporte de Cassandra para la replicación multimaestro significa que no solo obtiene el poder obvio de múltiples centros de datos (redundancia geográfica, latencias locales), sino que también puede dividir las cargas de trabajo analíticas y en tiempo real en grupos separados, con replicación bidireccional en tiempo real entre ellos . Si no divide esas cargas de trabajo, competirán espectacularmente.
• Dado que cada nodo de Cassandra administra su propio almacenamiento local, Cassandra tiene una ventaja de rendimiento sustancial que es poco probable que se reduzca significativamente. (Por ejemplo, es una práctica estándar colocar el registro de confirmación de Cassandra en un dispositivo separado para que pueda realizar sus escrituras secuenciales sin impedimentos por la E / S aleatoria de las solicitudes de lectura).
• Cassandra le permite elegir qué tan fuerte desea que sea la consistencia para cada operación. A veces esto se malinterpreta como "Cassandra no te da una gran consistencia", pero eso es incorrecto.
• Cassandra ofrece RandomPartitioner, así como el OrderedPartitioner más parecido a Bigtable. RandomPartitioner es mucho menos propenso a tener puntos calientes.
• Cassandra ofrece almacenamiento en caché dentro o fuera del montón con un rendimiento comparable al de memcached, pero sin los problemas de coherencia de la caché o la complejidad de requerir piezas móviles adicionales.
• Los clientes que no son de Java no son ciudadanos de segunda clase

Que yo sepa, la principal ventaja que tiene HBase en este momento (HBase 0.90.4 y Cassandra 0.8.4) es que Cassandra aún no admite la compresión de datos transparente. (Esto se ha agregado para Cassandra 1.0 , que saldrá a principios de octubre, pero hoy es una ventaja real para HBase). HBase también puede estar mejor optimizado para los tipos de escaneos de rango realizados por el procesamiento por lotes de Hadoop.

También hay algunas cosas que no son necesariamente mejores o peores, simplemente diferentes. HBase se adhiere más estrictamente al modelo de datos de Bigtable, donde cada columna tiene una versión implícita. Cassandra elimina el control de versiones y, en su lugar, agrega SuperColumns.

¡Espero que ayude!

La razón para usar clústeres de hBase de 100 nodos no es porque HBase no se escala a tamaños más grandes. Esto se debe a que es más fácil realizar actualizaciones de software hBase / HDFS de forma continua sin interrumpir todo el servicio. Otra razón es evitar que un solo NameNode sea un SPOF para todo el servicio. Además, HBase se está utilizando para varios servicios (no solo mensajes FB) y es prudente tener un enfoque de cookie cutter para configurar numerosos clústeres de HBase basados ​​en un enfoque de pod de 100 nodos. El número 100 es ad hoc, no nos hemos centrado en si 100 es óptimo o no.