2010-09-06 14 views
16

Solo quería saber si existe una diferencia fundamental entre hbase, cassandra, couchdb y monogodb. En otras palabras, ¿compiten todos en el mismo mercado e intentan resolver exactamente los mismos problemas? ¿O encajan mejor en diferentes escenarios?HBase cassandra couchdb mongodb ... ¿alguna diferencia fundamental?

Todo esto viene a la pregunta, ¿qué debo elegir cuando. ¿Cuestion de gusto?

Gracias,

Federico

+0

Este artículo actualizado es útil: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis – coderz

Respuesta

12

Esas son algunas de las respuestas largas de @Bohzo. (Pero son buenos enlaces)

La verdad es que son "una especie de" competir. Pero definitivamente tienen diferentes fortalezas y debilidades y definitivamente no todos resuelven los mismos problemas.

Por ejemplo Couch y Mongo tanto proporcionar motores Map-Reduce como parte del paquete principal. HBase es (básicamente) una capa sobre la parte superior de Hadoop, por lo que también obtienes M-R a través de Hadoop. Cassandra está muy centrada en ser una tienda de Key-Value y tiene complementos para "superponer" Hadoop por encima (para que pueda mapear-reducir).

Algunos de los DBs proporcionan MVCC (control de concurrencia multi-versión). Mongo no.

Todas estas DBs están destinados a escalar horizontalmente, pero lo hacen de diferentes maneras. Todos estos DB también intentan proporcionar flexibilidad de diferentes maneras. Tamaños de documentos flexibles o API REST o alta redundancia o facilidad de uso, todos hacen diferentes intercambios.

Por lo tanto, a su pregunta: En otras palabras, ¿están todos compitiendo en el mismo mercado y tratando de resolver exactamente los mismos problemas?

  1. : todos están tratando de resolver el problema de la base de datos escalabilidad y el rendimiento.
  2. Sin: Son definitivamente hacer diferentes conjuntos de compensaciones.

¿Qué debe comenzar con?

Hombre, esa es una pregunta difícil. Trabajo para una gran empresa que genera toneladas de datos y hemos pasado por algunos años. Probamos Cassandra en un momento hace un par de años y no pudo con la carga. Estamos usando Hadoop en todas partes, pero definitivamente tiene una gran curva de aprendizaje y no ha funcionado en algunos de nuestros entornos. Más recientemente, hemos intentado hacer Cassandra + Hadoop, pero resultó ser una gran cantidad de trabajo de configuración.

Personalmente, mi departamento se está moviendo varias cosas al MongoDB. Nuestros motivos para esto son honestamente solo simplicidad.

Configurar Mongo en una caja de linux toma minutos y no requiere acceso de root o un cambio en el sistema de archivos o algo sofisticado. No hay archivos de configuración locos ni recompilaciones java requeridas. Entonces, desde esa perspectiva, Mongo ha sido la "droga de puerta de enlace" más fácil para llevar a las personas a las tiendas de documentos/KV.

+0

¿Qué hay del sofá? ¿Has probado eso? –

+0

¿Qué parte? Conozco a algunas personas que usan Membase (memcache w/persistence). Es fácil de administrar y tiene una buena interfaz de usuario para hacerlo. Pero tampoco está tratando de hacer mucho. CouchDB se ha vendido a sí mismo como muy bueno para la configuración con múltiples maestros, pero nunca he tenido que usar esto en absoluto. CouchDB tiene índices secundarios y varias características similares a MongoDB, por lo que realmente se trata de lo cómodo que está usando todo. –

+0

¿Es mejor mongo que Cassandra para escribir? Escribe Cassandra en la memoria y todos dicen que cassandra solo funciona muy bien con las escrituras. ¿Mongo es aún mejor? – Peter

5

Respuesta breve: prueba antes de usar en producción.

puedo ofrecer mi experiencia con ambos HBase (extensa) y MongoDB (acaba de empezar).

A pesar de que no son el mismo tipo de tiendas, los que resuelven los mismos problemas:

  • almacenamiento escalable de datos
  • acceso aleatorio a los datos
  • el acceso de baja latencia

Estábamos muy entusiasmados con HBase al principio. Está construido en Hadoop (que es sólido como una roca), está bajo Apache, está activo ... ¿qué más podrías desear? Nuestra experiencia:

  • HBase es frágil
  • pesadilla de administrador (completo de configuraciones donde falta de pago son menos de la configuración perfecta, no transparente, los cambios de una versión a otra, ...)
  • pierde datos (a menos ha establecido la configuración X y ha cambiado Y a ... obtiene el punto :) - lo descubrimos cuando HBase se bloqueó y perdimos 2 horas (!!!) de datos porque WAL no se configuró correctamente
  • carece de datos secundarios índices
  • carece de cualquier forma de realizar una copia de seguridad de la base de datos withou t cerrándolo

En general, HBase fue una pesadilla. No se lo recomendaría a nadie, excepto a nuestros competidores directos. :)

MongoDB resuelve todos estos problemas y muchos más. Es una delicia configurarlo, hace que administrarlo sea un trabajo simple y transparente, y la configuración de configuración predeterminada realmente tiene sentido. Puede realizar copias de seguridad (en caliente), puede tener índices secundarios. Por lo que leí, no recomendaría MapReduce en MongoDB (JavaScript, 1 hilo por nodo solamente), pero puede usar Hadoop para eso.

Y también es MUY activo en comparación con HBase.

también: http://www.google.com/trends?q=HBase%2CMongoDB

Necesito decir más? :)

ACTUALIZACIÓN: muchos meses después Debo decir MongoDB entregado en todas las cuentas y más. El único inconveniente real es que las empresas de hosting no lo ofrecen de la misma forma que ofrecen MySQL. ;) También parece que MapReduce se convertirá en multi-threaded en 2.2. Aún así, no usaría MR de esta manera. YMMV.

1

Cassandra es bueno para escribir los datos. tiene la ventaja de "escribe nunca falla". No tiene falla de punto único.

HBase es muy bueno para el procesamiento de datos. HBase se basa en Hadoop File System (HDFS), por lo que HBase no necesita preocuparse por la replicación de datos, la coherencia de los datos. HBase tiene el único punto de falla. No estoy seguro de qué significa si tiene un único punto de falla, entonces es similar a RDBMS donde tenemos un único punto de falla. Podría estar equivocado en sentido ya que soy bastante nuevo.

¿Cómo abou RIAK? ¿Alguien tiene experiencia en usar RIAK? Redicé algo de lo que necesita pagar, no estoy seguro. Necesito una explicación.

Una cosa más que preferirá utilizar cuando solo desee leer muchos datos. Usted no tiene ninguna preocupación con la escritura. Imagine que tiene una base de datos con pitabyte y desea hacer una búsqueda rápida de la base de datos NOSQL que prefiere.

Cuestiones relacionadas