MongoDB vs. Cassandra [cerrado]


738

Estoy evaluando cuál podría ser la mejor opción de migración.

Actualmente, estoy en un MySQL fragmentado (partición horizontal), con la mayoría de mis datos almacenados en blobs JSON. No tengo consultas SQL complejas (ya migré después desde que particioné mi base de datos).

En este momento, parece que tanto MongoDB como Cassandra serían opciones posibles. Mi situación:

  • Muchas lecturas en cada consulta, escrituras menos regulares
  • No le preocupa la escalabilidad "masiva"
  • Más preocupado por la configuración simple, el mantenimiento y el código
  • Minimice el costo de hardware / servidor

44
Se dispone de estadísticas oficiales de referencia de rendimiento. Cassandra vs MongoDB vs HBase
Ravi

1
> Muchas lecturas en cada consulta, escrituras menos regulares => Busque CQRS (separe sus lecturas de sus escrituras probablemente sin fuente de eventos, pero verifique si puede actualizar su modelo de lectura asíncrono ... la sincronización puede funcionar también ... depende de su uso -Los casos)
bodrin

2
Esta es una gran pregunta en realidad. Me pregunto si hay una versión actualizada de la misma. Este es muy viejo ahora
slashdottir

Respuestas:


584

Muchas lecturas en cada consulta, menos escrituras regulares

Ambas bases de datos funcionan bien en lecturas donde el conjunto de datos activos se ajusta en la memoria. Ambos también enfatizan los modelos de datos sin unión (y en su lugar fomentan la desnormalización), y ambos proporcionan índices en documentos o filas , aunque los índices de MongoDB son actualmente más flexibles.

El motor de almacenamiento de Cassandra proporciona escrituras de tiempo constante sin importar qué tan grande crezca su conjunto de datos. Las escrituras son más problemáticas en MongoDB, en parte debido al motor de almacenamiento basado en b-tree, pero más debido al bloqueo de granularidad múltiple que tiene.

Para análisis, MongoDB proporciona un mapa personalizado / implementación de reducción; Cassandra proporciona soporte nativo de Hadoop, incluso para Hive (un almacén de datos SQL construido en Hadoop map / reduce) y Pig (un lenguaje de análisis específico de Hadoop que muchos piensan que es mejor para mapear / reducir cargas de trabajo que SQL). Cassandra también admite el uso de Spark .

No le preocupa la escalabilidad "masiva"

Si está buscando un solo servidor, MongoDB es probablemente una mejor opción. Para aquellos más preocupados por el escalado, la arquitectura de Cassandra de punto único de falla será más fácil de configurar y más confiable. (El bloqueo de escritura global de MongoDB también tiende a ser más doloroso). Cassandra también brinda mucho más control sobre cómo funciona su replicación, incluido el soporte para múltiples centros de datos.

Más preocupado por la configuración simple, el mantenimiento y el código

Ambos son triviales de configurar, con valores predeterminados razonables listos para usar para un solo servidor. Cassandra es más sencillo de configurar en una configuración multiservidor ya que no hay nodos de roles especiales de los que preocuparse.

Si actualmente usa blobs JSON, MongoDB es una combinación increíblemente buena para su caso de uso, dado que usa BSON para almacenar los datos. Podrá tener datos más ricos y más consultables de los que tendría en su base de datos actual. Esta sería la victoria más importante para Mongo.


86
Totalmente diferente, un comentario no es lo suficientemente grande, pero ... Cassandra es un híbrido dynamo / google bigtable linealmente escalable (tiempo constante de lectura y escritura amortizado) que presenta escrituras rápidas independientemente del tamaño de los datos. Su conjunto de características es minimalista, poco más que el de un almacén de valores clave ordenado. MongoDB es un almacén de documentos con muchas funciones (y rápido) a costa de durabilidad y garantiza la persistencia de las escrituras (ya que no se escriben inmediatamente en el disco). Son diferentes bestias con diferentes filosofías, MongoDB está más cerca de un reemplazo de RDMS ...
Michael

28
mientras que Cassandra es de nivel inferior pero permite una escala superior (ver Twitter / Digg / Facebook), pero tendrá que ser deliberado sobre cómo distribuir sus datos, crear índices secundarios, etc., ya que no se permiten consultas flexibles.
Michael

11
Debido a que todos mencionaron Twitter aquí en relación con Cassandra: no están usando Cassandra para los tweets persistentes, todavía usan MySQL aquí ( engineering.twitter.com/2010/07/cassandra-at-twitter-today.html ). Ok, pero me imagino que todavía almacenan muchos datos para otros fines en Cassandra.
H6.

77
Parece que el bloqueo global de escritura puede haberse eliminado en Mongo 2.2 ...
Matt Farmer

16
Incluso antes de que mi proyecto se pusiera en marcha, siento los puntos débiles de Mongodb. La copia de seguridad en caliente es un requisito básico. Para hacer una copia de seguridad en caliente en un servidor Linux, primero debe configurar una partición LVM (no tan común) y tomar una instantánea antes de cada sesión de copia de seguridad. Otra forma fácil es usar el servicio de respaldo pago Mongodb. Pero ese servicio es costoso (2.3 $ / GB / mes). Pronto necesitará un conjunto de réplica para tolerancia a fallas. Con la versión de código abierto, los nodos pueden intercambiar datos solo como texto sin cifrar. Para SSL tienes que ir con la edición Entprise. Y eso es 10,000 $. Adios Mongodb. Refactorizando mi código a Cassandra.
Karthik Sankar

146

He usado MongoDB ampliamente (durante los últimos 6 meses), construyendo un sistema de gestión de datos jerárquico, y puedo garantizar tanto la facilidad de configuración (¡instálela, ejecútela, úsela!) Y la velocidad. Siempre que piense en los índices con cuidado, puede gritar absolutamente, en cuanto a velocidad.

Supongo que Cassandra, debido a su uso con proyectos a gran escala como Twitter, tiene una mejor funcionalidad de escala, aunque el equipo de MongoDB está trabajando en la paridad allí. Debo señalar que no he usado a Cassandra más allá de la etapa de prueba, por lo que no puedo hablar por los detalles.

El verdadero cambio para mí, cuando estábamos evaluando las bases de datos NoSQL, fue la consulta: Cassandra es básicamente un almacén de clave / valor gigante, y las consultas son un poco complicadas (al menos en comparación con MongoDB), por lo que para el rendimiento tendrías que duplicar bastantes datos como una especie de índice manual. MongoDB, por otro lado, utiliza un modelo de "consulta por ejemplo".

Por ejemplo, supongamos que tiene una Colección (lenguaje MongoDB para el equivalente a una tabla RDMS) que contiene Usuarios. MongoDB almacena registros como documentos, que son básicamente objetos JSON binarios. p.ej:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

Si desea encontrar a todos los usuarios llamados Smith que tienen derechos de administrador, simplemente cree un nuevo documento (en la consola de administración usando Javascript, o en producción usando el idioma de su elección):

{
   LastName: "Smith",
   Groups: "Admin"
}

... y luego ejecuta la consulta. Eso es. Hay operadores adicionales para comparaciones, filtros RegEx, etc., pero todo es bastante simple y la documentación basada en Wiki es bastante buena.


54
Actualización (8 de agosto de 2011): el centro de datos de Amazon EC2 en Irlanda tuvo un incidente relacionado con un rayo anoche, y al ordenar la recuperación de nuestro servidor, descubrí un punto crucial: si tienes un conjunto de replicación de dos servidores (y ellos es fácil de configurar), asegúrese de tener un nodo Arbiter, de modo que si uno cae, el otro no entra en pánico y se detiene en el modo Secundario. Confía en mí, eso es una molestia para resolver con una gran base de datos.
Richard K.

8
Para agregar lo que dijo @ Richard K, debe tener un nodo árbitro cuando tenga un número par de nodos (primario + secundario) en un conjunto de réplicas.
Amareswar

Además de eso, considere mongodb cuando se haga más agregación en el análisis de datos.
user1503117

As long as you think about indexes carefully, it can absolutely scream along, speed-wise.Espere hasta que su memoria física se llene y el sistema operativo comience a fallar la página lol
sturcotte06

117

¿Por qué elegir entre una base de datos tradicional y un almacén de datos NoSQL? ¡Usa ambos! El problema con las soluciones NoSQL (más allá de la curva de aprendizaje inicial) es la falta de transacciones: realiza todas las actualizaciones en MySQL y hace que MySQL llene un almacén de datos NoSQL para lecturas, y luego se beneficia de las fortalezas de cada tecnología. Esto agrega más complejidad, pero ya tiene el lado de MySQL: solo agregue MongoDB, Cassandra, etc. a la mezcla.

Los almacenes de datos NoSQL generalmente se escalan mucho mejor que una base de datos tradicional para las mismas especificaciones; de lo contrario, hay una razón por la cual Facebook, Twitter, Google y la mayoría de las nuevas empresas están usando soluciones NoSQL. No solo los geeks se drogan con las nuevas tecnologías.


8
Estoy totalmente de acuerdo. Estoy usando mongodb + mysql en uno de los próximos productos que estoy diseñando. Es una próxima nube de productos financieros. mysql se usa donde absolutamente necesitamos capacidades transaccionales. mongodb se usa para almacenar estructuras de datos complejas no computacionales que solo necesitan extraerse cuando sea necesario. funcionando bien hasta ahora. :)
Ram on Rails-n-React

También utilicé un enfoque doble en la mayoría de mis proyectos, y en algunos otros el sistema de archivos montado en NFS se utilizó junto con PostgreSQL para blobs sísmicos cercanos a 1 Gb en algunos casos. Una ruta es un tipo de consulta a la base de datos de valores clave.
Audrius Meskauskas

1
Aquí hay un enlace a una pregunta que hice sobre cómo diseñar bases de datos sql y nosql: dba.stackexchange.com/questions/102053/… Podría usar alguna información que pueda tener
j será

Ya se ha escapado de las transacciones para siempre => ahora podría ser posible una escalabilidad infinita ... de lo contrario -> no :)
bodrin

1
Esta no es una buena solución si sus datos se distribuyen
Esteban Verbel

60

Probablemente voy a ser un hombre extraño, pero creo que debes quedarte con MySQL. No ha descrito un problema real que necesita resolver, y MySQL / InnoDB es un excelente back-end de almacenamiento incluso para datos blob / json.

Hay un truco común entre los ingenieros web para tratar de usar más NoSQL tan pronto como se dé cuenta de que no se utilizan todas las características de un RDBMS. Esto por sí solo no es una buena razón, ya que la mayoría de las veces las bases de datos NoSQL tienen motores de datos bastante pobres (lo que MySQL llama un motor de almacenamiento).

Ahora, si no es de ese tipo, especifique lo que falta en MySQL y lo está buscando en una base de datos diferente (por ejemplo, auto-fragmentación, conmutación por error automática, replicación multimaestro, una garantía de consistencia de datos más débil en clúster dando sus frutos en un mayor rendimiento de escritura, etc.


13
Está utilizando el fragmentación, lo que significa que sus datos se particionan manualmente en los servidores. Mongodb puede automatizar el fragmentación, lo que puede ser un beneficio.
fabspro

18
También está almacenando principalmente blobs JSON en RDBMS, lo que hace que el diseño relacional (características) sea inútil.
Damir Sudarevic el

44
El modelo de datos y el particionamiento automático son realmente diferentes, pero al elegir una base de datos, primero debe mirar el motor de almacenamiento y el resto de campanas y silbatos en segundo lugar. ¿Cómo va a funcionar el motor de almacenamiento bajo un pico de carga? ¿Cómo va a funcionar la función de autocompartición bajo un pico de entrada de datos? Antes de ceder el control a la base de datos para estos aspectos importantes, es mejor asegurarse de que sea capaz de realizar la tarea.
Kostja

77
El modelo relacional es uno de los modelos de datos más bien pensados, eficientes de implementar y frugales. "Hacer que las características del diseño relacional sean inútiles" puede relacionarse con restricciones, disparadores o integridad referencial, pero todos estos son pagos por uso.
Kostja

20

No he usado Cassandra, pero he usado MongoDB y creo que es increíble.

Si buscas una configuración simple, esto es todo: simplemente descomprimes MongoDB y ejecutas el demonio mongod y listo ... se está ejecutando.

Obviamente, eso es solo un comienzo, pero para comenzar es fácil.


22
AFAIK, lo mismo se aplica a Cassandra también. Untar, corre el demonio. ¡El clúster de prueba está configurado y listo para la producción!
Pide

13

Ayer vi una presentación sobre mongodb. Definitivamente puedo decir que la configuración fue "simple", tan simple como desempacarlo y encenderlo. Hecho.

Creo que tanto mongodb como cassandra se ejecutarán en prácticamente cualquier hardware de Linux regular, por lo que no debería encontrar mucha barrera en esa área.

Creo que en este caso, al final del día, se reducirá a lo que personalmente se siente más cómodo y cuál tiene un conjunto de herramientas que prefiera. En cuanto a la presentación en mongodb, el presentador indicó que el conjunto de herramientas para mongodb era bastante ligero y que no había muchas (dijeron que realmente) herramientas similares a las disponibles para MySQL. Por supuesto, esta fue su experiencia, así que YMMV. Una cosa que me gustó de mongodb fue que parecía haber mucho soporte de lenguaje (Python y .NET son los dos que uso principalmente).

La lista de sitios que usan mongodb es bastante impresionante , y sé que Twitter simplemente cambió a usar cassandra.


44
Al final del día, es una comparación entre manzanas y naranjas. Ambas bases de datos tienen sus propias fortalezas. Aquí hay algunas cosas a tener en cuenta: el modelo de objetos, los índices secundarios, la escalabilidad de escritura, la alta disponibilidad, etc. tienen una publicación de blog que explica las diferencias estratégicas de alto nivel entre mongodb y cassandra aquí: scalegrid.io/blog/cassandra-vs-mongodb
Dharshan
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.