Pregunta 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 ninguna consulta SQL compleja (ya se ha migrado desde que particioné mi db).

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

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

673
2018-05-23 17:39


origen


Respuestas:


Muchas lecturas en cada consulta, menos escrituras regulares

Ambas bases de datos funcionan bien en lecturas donde el conjunto de datos calientes se ajusta a la memoria. Ambos también enfatizan los modelos de datos sin unión (y fomentan la desnormalización en su lugar), y ambos proporcionan índices sobre 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 cuán 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 a la por bloqueo de escritura de base de datos.

Para análisis, MongoDB proporciona una implementación de mapa / reducción personalizada; Cassandra brinda soporte nativo de Hadoop, que incluye Colmena (un data warehouse SQL construido en Hadoop map / reduce) y Cerdo (un lenguaje de análisis específico de Hadoop que muchos piensan que es más apropiado para mapear / reducir cargas de trabajo que SQL).

No está preocupado por la escalabilidad "masiva"

Si está buscando un solo servidor, MongoDB es probablemente una mejor opción. Para aquellos más preocupados por la escala, la arquitectura de un solo punto de falla de Cassandra será más fácil de configurar y más confiable. (El bloqueo de escritura global de MongoDB tiende a ser más doloroso también). Cassandra también le da mucho más control sobre cómo funciona su réplica, incluida la compatibilidad con 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 fácil de configurar en una configuración de varios servidores, ya que no hay que preocuparse por los nodos de roles especiales; aquí hay un screencast que demuestra configurar un clúster Cassandra de 4 nodos en dos minutos.

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


525
2018-05-24 03:58



He usado MongoDB extensivamente (durante los últimos 6 meses), construyendo un sistema de administración de datos jerárquico, y puedo responder tanto por la facilidad de configuración (¡instálala, ejecútala, úsala!) Como por la velocidad. Siempre que piense en los índices con cuidado, puede gritar absolutamente, con rapidez.

Entiendo que Cassandra, debido a su uso con proyectos a gran escala como Twitter, tiene una mejor funcionalidad de escalado, 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, así que no puedo hablar por los detalles.

El verdadero golpe para mí, cuando estábamos evaluando las bases de datos NoSQL, fue la consulta: Cassandra es básicamente una tienda clave / valor gigante, y la consulta es un poco complicada (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 de 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 buscar a todos los usuarios llamados Smith que tienen derechos de administrador, simplemente crearía 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 añadidos para las comparaciones, el filtrado RegEx, etc., pero todo es bastante simple, y la documentación basada en Wiki es bastante buena.


137
2017-07-01 22:29



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

Las áreas de almacenamiento de datos de 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 empresas de nueva creación usan soluciones NoSQL. No es solo que los geeks se drogan con la nueva tecnología.


97
2018-04-17 00:45



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.

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

Ahora, si no eres de ese tipo, especifica qué es desaparecido en MySQL y lo que busca en una base de datos diferente (como fragmentación automática, conmutación por error automática, replicación multimaestro, una garantía de coherencia de datos más débil en el clúster que paga con un mayor rendimiento de escritura, etc.).


55
2018-02-23 20:50



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

Si después de su configuración simple, esto es todo. Simplemente deshaces MongoDB y ejecutas el daemon mongod y listo ... se está ejecutando.

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


18
2018-05-23 17:57



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

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

Creo que en este caso, al final del día, se reducirá a lo que personalmente se sienta más cómodo y que tenga 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 liviano y que no había muchas herramientas (dicen que realmente) similares a las que están disponibles para MySQL. Esta fue, por supuesto, su experiencia, así que YMMV. Una cosa que me gustó de mongodb fue que parecía haber un gran soporte de idiomas (Python y .NET son los dos que uso principalmente).

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


12
2018-05-23 17:57