nosql - diferencia - Procesamiento de datos a gran escala Hbase vs Cassandra

cassandra hadoop (3)

Como desarrollador de Cassandra, soy mejor respondiendo el otro lado de la pregunta:

Cassandra escalas mejor. Se sabe que Cassandra escala a más de 400 nodos en un clúster ; cuando Facebook implementó Mensajería encima de HBase, tuvieron que dividirlo en sub-clústeres HBase de 100 nodos .
Cassandra admite cientos, incluso miles de ColumnFamilies. " HBase actualmente no le va bien a nada por encima de dos o tres familias de columna ".
Como un sistema totalmente distribuido sin nodos o procesos "especiales" , Cassandra es más fácil de instalar 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 obtienes la potencia obvia de múltiples centros de datos (redundancia geográfica, latencias locales) sino que también puedes dividir cargas de trabajo en tiempo real y analíticas en grupos separados, con replicación bidireccional en tiempo real entre ellos . Si no divide esas cargas de trabajo, competirán espectacularmente.
Debido a que cada nodo de Cassandra maneja 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 commits de Cassandra en un dispositivo separado para que pueda realizar sus escrituras secuenciales sin impedimentos de E / S aleatorias de las solicitudes de lectura).
Cassandra le permite elegir qué tan fuerte desea que requiera consistencia para cada operación. A veces esto es mal interpretado ya que "Cassandra no te da consistencia fuerte", pero eso es incorrecto.
Cassandra ofrece RandomPartitioner, así como el OrderedPartitioner más parecido a Bigtable. RandomPartitioner es mucho menos propenso a los puntos calientes.
Cassandra ofrece un almacenamiento en memoria caché "on-or-heap" con un rendimiento comparable al de los "memcached", pero sin los problemas de consistencia de caché o la complejidad de requerir piezas móviles adicionales.
Los clientes que no son Java no son ciudadanos de segunda clase

Que yo sepa, la principal ventaja de HBase en este momento (HBase 0.90.4 y Cassandra 0.8.4) es que Cassandra todavía no es compatible con la compresión de datos transparente. (Esto se ha agregado para Cassandra 1.0 , que vence a principios de octubre, pero hoy esa es una ventaja real para HBase). HBase también puede optimizarse mejor para los tipos de escaneos realizados por el procesamiento por lotes de Hadoop.

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

¡Espero que ayude!

Estoy casi aterrizado en Cassandra después de mi investigación sobre soluciones de almacenamiento de datos a gran escala. Pero generalmente se dice que Hbase es la 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, entonces lo que hace a Hadoop un mejor candidato cuando se requiere el procesamiento / análisis en datos de gran tamaño.

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

pero todavía estoy buscando ventajas concretas de Hbase.

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

La razón para usar clústeres hBase de 100 nodos no se debe a que HBase no se adapte a tamaños más grandes. Esto se debe a que es más fácil hacer actualizaciones de software hBase / HDFS de forma progresiva sin reducir todo el servicio. Otra razón es evitar que un solo NameNode sea un SPOF para todo el servicio. Además, HBase está siendo utilizado para varios servicios (no solo para mensajes FB) y es prudente tener un enfoque simplificado para configurar numerosos clústeres 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.

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

Habiendo dicho eso, voy a parafrasear al comentarista de HBase Andrew Purtell y agregar algunas de mis propias experiencias:

HBase está en entornos de producción más grandes (1000 nodos) aunque todavía está en el estadio de las instalaciones de Cassandra de ~ 400 nodos, por lo que es realmente una diferencia marginal.
HBase y Cassandra admiten replicación entre clusters / datacenters. Creo que HBase expone más al usuario, por lo que parece más complicado, pero también se obtiene más flexibilidad.
Si lo que necesita su aplicación es una consistencia fuerte, es probable que HBase se ajuste mejor. Está diseñado desde cero para ser consistente. Por ejemplo, permite una implementación más sencilla de los contadores atómicos (creo que Cassandra acaba de obtenerlos), así como las operaciones de Verificar y Poner.
El rendimiento de escritura es excelente, por lo que entiendo que fue una de las razones por las que Facebook fue con HBase para su mensajera.
No estoy seguro del estado actual del particionador ordenado de Cassandra, pero en el pasado requería un reequilibrio manual. HBase maneja eso por ti si quieres. El particionador ordenado es importante para el procesamiento de estilo de Hadoop.
Cassandra y HBase son complejas, Cassandra simplemente lo oculta. HBase lo expone más a través del uso de HDFS para su almacenamiento, si nos fijamos en la base de código, Cassandra tiene las mismas capas. Si compara los documentos de Dynamo y Bigtable puede ver que la teoría de operación 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 quieres velocidad absoluta, el cliente Java nativo está allí.
Hay ventajas para el esclavo tanto de igual a igual como maestro. La configuración maestro - esclavo generalmente facilita la depuración y reduce bastante complejidad.
HBase no está vinculado únicamente al HDFS tradicional, puede cambiar su almacenamiento subyacente según sus necesidades. MapR parece bastante interesante y he escuchado cosas buenas, aunque no las he usado yo mismo.