Procesamiento de datos a gran escala Hbase vs Cassandra

Question

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 ejecutarse (Cassandra recientemente) la capa Hadoop es lo que hace que Hadoop sea un mejor candidato cuando se requiere procesamiento/análisis en datos grandes.

También encontré buenos detalles acerca tanto a http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/

pero todavía estoy en busca de ventajas concretas de hbase.

Mientras 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.

Answer 1

Tratar de determinar cuál es el mejor para usted realmente depende de lo que se va a utilizar para, cada uno tiene sus ventajas y sin más detalles se convierte más 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.

Dicho esto, voy a parafrasear HBase committer Andrew Purtell y añadir algunas de mis propias experiencias:

• HBase es en entornos de producción más grandes (1000 nodos) a pesar de que todavía está en el estadio de béisbol de Cassandra ~ 400 instalaciones de nodos por lo que es realmente una diferencia marginal.

• HBase y Cassandra tanto soporta la replicación entre clusters/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 su aplicación necesita una consistencia fuerte, es probable que HBase encaje 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 grande, por lo que entiendo que fue una de las razones Facebook fue, sin más HBase para su mensajero.

• No estoy seguro del estado actual de particionador ordenada de Cassandra, pero en el pasado se requería 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 complejos, 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 de unidad FWIW.

• Todo Cassandra RPC es Thrift, HBase tiene una Thrift, REST y Java nativa. Thrift y REST solo ofrecen un subconjunto de la API total del cliente, pero si quieres velocidad absoluta, el cliente Java nativo está allí.

• Existen ventajas tanto para el esclavo homólogo como maestro. La configuración maestro - esclavo generalmente facilita la depuración y reduce bastante complejidad.

• HBase no sólo está vinculada a HDFS tradicional, puede cambiar a cabo su almacenamiento subyacente en función de sus necesidades.MapR parece bastante interesante y he escuchado cosas buenas, aunque no las he usado yo mismo.

Answer 2

Como desarrollador Cassandra, yo soy mejor en responder a la otra cara de la cuestión:

• Cassandra escala mejor. Se sabe que Cassandra escala a over 400 nodes in a cluster; cuando Facebook implementó Mensajería encima de HBase, tuvieron que pasarlo por 100-node HBase sub-clusters.
• Cassandra admite cientos, incluso miles de familias de columnas. "HBase currently does not do well with anything above two or three column families".
• Como un sistema totalmente distribuido sin "special" nodes or processes, Cassandra es simpler to set up and operate, más fácil de solucionar y más robusto.
• El soporte de Cassandra para 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 las cargas de trabajo analíticas y en tiempo real en grupos separados, con realtime, bidirectional replication between them. Si no divide esas cargas de trabajo, competirán espectacularmente.
• Debido a que cada nodo de Cassandra administra su propio almacenamiento local, Cassandra tiene una ventaja de rendimiento considerable 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 restricciones mediante E/S aleatorias de las solicitudes de lectura).
• Cassandra le permite elegir la fuerza que desea que requiera coherencia estar en una base por 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 Ordenador más ordenado de tipo Bigtable. RandomPartitioner es mucho menos propenso a los 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 caché o la complejidad de requerir partes móviles adicionales
• clientes que no son Java 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 ha sido added for Cassandra 1.0, con vencimiento 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!

Answer 3

El motivo por el que se utilizan los clústeres hBase de 100 nodos no se debe a que HBase no se adapta a tamaños más grandes. Esto se debe a que es más fácil hacer actualizaciones de software hBase/HDFS de forma continua 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.