mongodb cassandra hbase couchdb nosql

HBase cassandra couchdb mongodb... ¿alguna diferencia fundamental?



nosql (4)

Cassandra es buena para escribir los datos. Tiene la ventaja de que "las escrituras nunca fallan". No tiene un solo punto de falla.

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

¿Qué tal Riak? Alguien tiene experiencia en el uso de RIAK. Yo escribo un poco donde debes pagar, no estoy seguro. Necesita explicacion

Una cosa más que preferirás usar cuando solo te interesa leer muchos datos. No tienes ninguna preocupación con la escritura. Imagínese que tiene una base de datos con pitabyte y desea realizar una búsqueda rápida en qué base de datos NOSQL prefiere.

Solo quería saber si hay una diferencia fundamental entre hbase, cassandra, couchdb y monogodb? En otras palabras, ¿están todos compitiendo en el mismo mercado e intentando resolver los mismos problemas? ¿O encajan mejor en diferentes escenarios?

Todo esto viene a la pregunta, ¿qué debo elegir cuándo? ¿Cuestion de gusto?

Gracias,

Federico

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

La verdad es que están "como" compitiendo. Pero definitivamente tienen diferentes fortalezas y debilidades y definitivamente no todos resuelven los mismos problemas.

Por ejemplo, Couch y Mongo proporcionan 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 obtiene MR a través de Hadoop. Cassandra está muy concentrada en ser una tienda de valor-clave y tiene complementos para "colocar" Hadoop en la parte superior (para que pueda reducir el mapa).

Algunas de las bases de datos proporcionan MVCC (Control de concurrencia de varias versiones). Mongo no lo hace.

Todas estas bases de datos están diseñadas para escalar horizontalmente, pero lo hacen de diferentes maneras. Todas estas bases de datos también están tratando de proporcionar flexibilidad de diferentes maneras. Tamaños de documentos flexibles o API REST, o alta redundancia o facilidad de uso, todos están haciendo concesiones diferentes.

Entonces, para su pregunta: en otras palabras, ¿todos ellos compiten en el mismo mercado e intentan resolver los mismos problemas?

  1. Sí : todos intentan resolver el problema de la escalabilidad y el rendimiento de la base de datos.
  2. No : definitivamente están haciendo diferentes conjuntos de compensaciones.

¿Con qué deberías empezar?

Hombre, esa es una pregunta difícil. Trabajo para una empresa grande que está generando toneladas de datos y hemos pasado por algunos años. Probamos a Cassandra en un momento dado hace un par de años y no podía manejar la carga. Estamos usando Hadoop en todas partes, pero definitivamente tiene una curva de aprendizaje empinada 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 está moviendo varias cosas a MongoDB . Nuestras razones para esto son honestamente la simplicidad.

La configuración de Mongo en una caja de Linux toma minutos y no requiere acceso de raíz o un cambio en el sistema de archivos o cualquier cosa de lujo. No hay archivos de configuración locos o compilaciones de Java requeridas. Así que, desde esa perspectiva, Mongo ha sido el "fármaco de acceso" más fácil para que las personas accedan a las tiendas de documentos / KV.

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

Puedo ofrecer mi experiencia tanto con HBase (extenso) como con MongoDB (recién empezando).

Aunque no son el mismo tipo de tiendas, resuelven los mismos problemas:

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

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

  • HBase es frágil
  • la pesadilla del administrador (llena de ajustes de configuración donde los valores predeterminados son menos que perfectos, configuración no transparente, cambios de versión a versión, ...)
  • pierde datos (a menos que haya configurado la configuración X y haya cambiado Y a ... se entiende el punto :): descubrimos eso cuando HBase se bloqueó y perdimos 2 horas (!!!) de datos porque WAL no se configuró correctamente
  • carece de índices secundarios
  • carece de cualquier forma de realizar una copia de seguridad de la base de datos sin cerrarla

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

MongoDB resuelve todos estos problemas y muchos más. Es un placer de configurar, hace que su administración sea un trabajo simple y transparente, y los ajustes de configuración predeterminados realmente tienen sentido. Puede realizar copias de seguridad (en caliente), puede tener índices secundarios. Por lo que leí, no recomendaría MapReduce en MongoDB (JavaScript, solo 1 hilo por nodo), 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 mas? :)

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