MongoDB vs. Cassandra [cerrado]

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

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.

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.

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

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.

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.

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.