MongoDB contra 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 migré desde que particioné mi base de datos).
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 nos preocupa la escalabilidad "masiva"
- Más preocupado por la configuración, el mantenimiento y el código sencillos
- Minimizar 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 cabe 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 en tiempo constante sin importar el tamaño de su conjunto de datos. Las escrituras son más problemáticas en MongoDB, en parte debido al motor de almacenamiento basado en árbol b, pero más por el bloqueo de granularidad múltiple que realiza.
Para análisis, MongoDB proporciona una implementación personalizada de mapa/reducción; Cassandra proporciona soporte nativo para Hadoop, incluso para Hive (un almacén de datos SQL construido sobre 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 nos preocupa la escalabilidad "masiva"
Si está buscando un solo servidor, MongoDB probablemente sea la mejor opción. Para aquellos más preocupados por la escalabilidad, la arquitectura sin punto único de falla de Cassandra 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, el mantenimiento y el código sencillos
Ambos son fáciles de configurar, con valores predeterminados razonables para un solo servidor. Cassandra es más sencilla de configurar en una configuración de múltiples servidores, ya que no hay nodos con funciones especiales de los que preocuparse.
Si actualmente estás usando blobs JSON, MongoDB es una opción increíblemente buena para tu caso de uso, dado que usa BSON para almacenar los datos. Podrá tener datos más ricos y consultables que los que tendría en su base de datos actual. Esta sería la victoria más importante para Mongo.
He usado MongoDB extensamente (durante los últimos 6 meses), creando un sistema de administración de datos jerárquico, y puedo dar fe tanto de la facilidad de configuración (¡instalarlo, ejecutarlo, usarlo!) como de la velocidad. Siempre que piense detenidamente en los índices, puede avanzar absolutamente a gran velocidad.
Deduzco que Cassandra, debido a su uso con proyectos de 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 Cassandra más allá de la etapa de prueba, por lo que no puedo hablar de los detalles.
El verdadero problema para mí, cuando estábamos evaluando las bases de datos NoSQL, fueron las consultas: Cassandra es básicamente un almacén gigante de claves/valores, y las consultas son un poco complicadas (al menos en comparación con MongoDB), por lo que para el rendimiento tendrías que duplicar una gran cantidad de 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 (en el lenguaje de MongoDB, 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: "[email protected]",
Groups: ["Admin", "User", "SuperUser"]
}
Si quisiera encontrar 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 ejecute la consulta. Eso es todo. Hay operadores agregados para comparaciones, filtrado RegEx, etc., pero todo es bastante simple y la documentación basada en Wiki es bastante buena.
