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

Question

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

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

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

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.

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

81

nosql cassandra hadoop hbase data-processing

Author: jbellis, 2011-08-30

Source

3 answers

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

Cassandra escala mejor. Cassandra es conocida por escalar a más de 400 nodos en un clúster; cuando Facebook desplegó Mensajes sobre HBase, tuvieron que dividirlos en subgrupos de HBase de 100 nodos.
Cassandra soporta cientos, incluso miles de familias de columnas. " HBase actualmente no funciona bien con nada por encima de dos o tres familias de columnas."
As un sistema completamente distribuido sin nodos o procesos"especiales" , Cassandra es más simple de configurar y operar, más fácil de solucionar problemas y más robusto.
El soporte de Cassandra para la replicación multi-maestro significa que no solo obtiene el poder obvio de múltiples centros de datos redundancy redundancia geográfica, latencias locales but 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 divides esas cargas de trabajo, ellas contenderán espectacularmente.
Debido a 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 poner el commitlog de Cassandra en un dispositivo separado para que pueda hacer sus escrituras secuenciales sin impedimentos por e/s aleatorias de solicitudes de lectura.)
Cassandra le permite elegir qué tan fuerte desea que requiera consistencia para estar en un base por operación. A veces esto se malinterpreta como "Cassandra no te da una consistencia fuerte", pero eso es incorrecto.
Cassandra ofrece RandomPartitioner, así como el más Bigtable-como OrderedPartitioner. RandomPartitioner es mucho menos propenso a 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 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 que tiene HBase en este momento (HBase 0.90.4 y Cassandra 0.8.4) es que Cassandra todavía no admite la compresión transparente de datos. (Esto ha sido añadido para Cassandra 1.0, debido a principios de octubre, pero hoy en día es una ventaja real para HBase.) HBase también puede optimizarse mejor para los tipos de exploraciones de rango realizadas por el procesamiento por lotes de Hadoop.

También hay algunas cosas que no son necesariamente mejores o peores, simplemente diferente. HBase se adhiere más estrictamente al modelo de datos Bigtable, donde cada columna está versionada implícitamente. Cassandra elimina el control de versiones y añade Supercolumnas en su lugar.

Espero que eso ayude!

113

Author: jbellis,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-08-30 04:48:05

La razón para usar 100 clusters de HBase no es porque la HBase no se escale a tamaños más grandes. Esto se debe a que es más fácil hacer actualizaciones de software HBase/HDFS de una manera rodante sin derribar todo su 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 corte de cookies para configurar numerosos clústeres de HBase basados en un pod de 100 nodos enfoque. El número 100 es adhoc, no nos hemos centrado en si 100 es óptimo o no.

22

Author: dhruba,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-08-30 17:13:20

score 89 · Accepted Answer

Tratar de determinar cuál es el mejor para ti realmente depende de para qué lo vas a usar, cada uno tiene sus ventajas y sin más detalles se convierte más en una guerra religiosa. Ese post que mencionaste también tiene más de un año y ambos han pasado por muchos cambios desde entonces. Por favor también tenga en cuenta que no estoy familiarizado con los desarrollos más recientes de Cassandra.

Dicho esto, parafrasearé al committer de HBase Andrew Purtell y añadiré algunos de los míos 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 apoyan 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 se obtiene más flexibilidad.
Si lo que necesita su aplicación es una consistencia fuerte, entonces HBase es probablemente un mejor ajuste. Está diseñado desde cero para ser consistente. Por ejemplo, permite una implementación más simple de contadores atómicos (creo que Cassandra acaba de conseguirlos), así como operaciones de Comprobación y Colocación.
El rendimiento de escritura es genial, por lo que entiendo que fue una de las razones por las que Facebook eligió HBase para su messenger.
No estoy seguro del estado actual del repartidor ordenado de Cassandra, pero en el pasado requería un reequilibrio manual. HBase se encarga de eso si quieres. El particionador ordenado es importante para el procesamiento de estilo Hadoop.
Cassandra y HBase son complejos, Cassandra lo esconde mejor. 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 es igual de capas. Si se comparan los documentos Dynamo y Bigtable se puede ver que la teoría de la operación de Cassandra es en realidad más compleja.
HBase tiene más pruebas unitarias FWIW.
Todo Cassandra RPC es Thrift, HBase tiene un Thrift, RESTO y Java nativo. El Thrift y REST solo ofrecen un subconjunto de la API de cliente total, pero si desea velocidad pura, el cliente Java nativo está allí.
Hay ventajas tanto para peer to peer como para master to slave. La configuración maestro - esclavo generalmente facilita la depuración y reduce un poco la complejidad.
HBase no está ligado solo a HDFS tradicionales, puede cambiar su almacenamiento subyacente en función de sus necesidades. MapR parece bastante interesante y he escuchado cosas buenas aunque yo mismo no lo he usado.