Cassandra contra MongoDB
¿Está considerando a Cassandra o MongoDB como el almacén de datos para su próximo proyecto? ¿Le gustaría comparar las dos bases de datos? Cassandra y MongoDB son bases de datos "NoSQL", pero la realidad es que son muy diferentes. Tienen fortalezas y propuestas de valor muy diferentes, por lo que cualquier comparación debe ser matizada. Comencemos con los requisitos iniciales... Ninguna de estas bases de datos reemplaza a RDBMS, ni son bases de datos "ACID". Entonces, si tiene una carga de trabajo transaccional donde la normalización y la consistencia son los requisitos principales, ninguna de estas bases de datos funcionará para usted. Es mejor que se quede con las bases de datos relacionales tradicionales como MySQL, PostgreSQL, Oracle, etc. Ahora que ya no tenemos las bases de datos relacionales, consideremos las principales diferencias entre Cassandra y MongoDB que lo ayudarán a tomar una decisión. En esta publicación, no voy a discutir funciones específicas, pero señalaré algunas diferencias estratégicas de alto nivel para ayudarlo a elegir.
1. Modelo de objetos expresivos
MongoDB admite un modelo de objetos rico y expresivo. Los objetos pueden tener propiedades y los objetos se pueden anidar entre sí (para varios niveles). Este modelo está muy "orientado a objetos" y puede representar fácilmente cualquier estructura de objeto en su dominio. También puede indexar la propiedad de cualquier objeto en cualquier nivel de la jerarquía:¡esto es sorprendentemente poderoso! Cassandra, por otro lado, ofrece una estructura de tabla bastante tradicional con filas y columnas. Los datos están más estructurados y cada columna tiene un tipo específico que se puede especificar durante la creación.
Veredicto:si su dominio problemático necesita un modelo de datos enriquecido, entonces el alojamiento de MongoDB es una mejor opción para usted.
2. Índices secundarios
Los índices secundarios son una construcción de primera clase en MongoDB. Esto facilita la indexación de cualquier propiedad de un objeto almacenado en MongoDB, incluso si está anidado. Esto hace que sea realmente fácil consultar en función de estos índices secundarios. Cassandra solo tiene soporte superficial para índices secundarios. Los índices secundarios también se limitan a columnas individuales y comparaciones de igualdad. Si la mayoría de las veces va a realizar consultas mediante la clave principal, Cassandra funcionará bien para usted.
Veredicto: Si su aplicación necesita índices secundarios y necesita flexibilidad en el modelo de consulta, entonces MongoDB es una mejor opción para usted.
3. Alta disponibilidad
MongoDB admite un modelo de "maestro único". Esto significa que tiene un nodo maestro y varios nodos esclavos. En caso de caída del maestro, uno de los esclavos es elegido como maestro. Este proceso ocurre automáticamente pero lleva tiempo, generalmente de 10 a 40 segundos. Durante este tiempo de elección de nuevo líder, su conjunto de réplicas está inactivo y no puede aceptar escrituras. Esto funciona para la mayoría de las aplicaciones, pero en última instancia depende de sus necesidades. Cassandra admite un modelo de "múltiples maestros". La pérdida de un solo nodo no afecta la capacidad del clúster para realizar escrituras, por lo que puede lograr un tiempo de actividad del 100 % para las escrituras.
Veredicto:si necesita un tiempo de actividad del 100 %, Cassandra es una mejor opción para usted.
4. Escalabilidad de escritura
MongoDB con su modelo de "maestro único" puede aceptar escrituras solo en el primario. Los servidores secundarios solo se pueden usar para lecturas. Entonces, esencialmente, si tiene un conjunto de réplicas de tres nodos, solo el maestro está tomando escrituras y los otros dos nodos solo se usan para lecturas. Esto limita en gran medida la escalabilidad de escritura. Puede implementar varios fragmentos, pero esencialmente solo 1/3 de sus nodos de datos pueden aceptar escrituras. Cassandra con su modelo de "múltiples maestros" puede realizar escrituras en cualquier servidor. Básicamente, su escalabilidad de escritura está limitada por la cantidad de servidores que tiene en el clúster. Cuantos más servidores tenga en el clúster, mejor escalará.
Veredicto:si la escalabilidad de escritura es lo tuyo, Cassandra es una mejor opción para ti.
5. Soporte de lenguaje de consulta
Cassandra admite el lenguaje de consulta CQL, que es muy similar a SQL. Si ya tiene un equipo de analistas de datos, podrán transferir la mayoría de sus habilidades de SQL, lo cual es muy importante para las grandes organizaciones. Sin embargo, CQL no es ANSI SQL completo:tiene varias limitaciones (no admite unión, no incluye cláusulas OR), etc. MongoDB en este momento no admite un lenguaje de consulta. Las consultas están estructuradas como fragmentos JSON.
Veredicto:si necesita compatibilidad con el lenguaje de consulta, Cassandra es la mejor opción para usted.
6. Puntos de referencia de rendimiento
Hablemos de rendimiento. En este punto, probablemente esté esperando una comparación comparativa de rendimiento de las bases de datos. Deliberadamente no he incluido puntos de referencia de rendimiento en la comparación. En cualquier comparación, debemos asegurarnos de que estamos haciendo una comparación de manzanas con manzanas.
1. Modelo de base de datos - El modelo/esquema de la base de datos de la aplicación que se está probando marca una gran diferencia. Algunos esquemas son adecuados para MongoDB y otros para Cassandra. Por lo tanto, al comparar bases de datos, es importante utilizar un modelo que funcione razonablemente bien para ambas bases de datos.
2. Características de carga – Las características de la carga de referencia son muy importantes. P.ej. En los puntos de referencia de escritura pesada, esperaría que Cassandra fumara MongoDB. Sin embargo, en los puntos de referencia de lectura intensiva, MongoDB y Cassandra deberían tener un rendimiento similar.
3. Requisitos de coherencia - Esta es complicada. Debe asegurarse de que los requisitos de consistencia de lectura/escritura especificados sean idénticos en ambas bases de datos y no estén sesgados hacia un participante. Muy a menudo, en varios de los puntos de referencia de "Marketing", las perillas se ajustan para poner en desventaja al otro lado. Por lo tanto, preste mucha atención a la configuración de consistencia.
Una última cosa a tener en cuenta es que la carga de referencia puede o no reflejar el rendimiento de su aplicación. Entonces, para que los puntos de referencia sean útiles, es muy importante encontrar una carga de punto de referencia que refleje las características de rendimiento de su aplicación. Aquí hay algunos puntos de referencia que quizás desee ver:
- Puntos de referencia de rendimiento de NoSQL
- Cassandra vs. MongoDB vs. Couchbase vs. HBase
7. Facilidad de uso
Si hubiera hecho esta pregunta hace un par de años, MongoDB sería el ganador indiscutible. Es una tarea bastante simple poner en marcha MongoDB. En los últimos años, sin embargo, Cassandra ha hecho grandes avances en este aspecto del producto. Con la adopción de CQL como la interfaz principal para Cassandra, ha ido un paso más allá:ha hecho que sea muy sencillo para legiones de programadores de SQL usar Cassandra muy fácilmente.
Veredicto:Ambos son bastante fáciles de usar y aumentar.
8. Agregación nativa
MongoDB tiene un marco de agregación incorporado para ejecutar una canalización ETL para transformar los datos almacenados en la base de datos. Esto es excelente para trabajos pequeños a medianos, pero a medida que sus necesidades de procesamiento de datos se vuelven más complicadas, el marco de agregación se vuelve más difícil de depurar. Cassandra no tiene un marco de agregación incorporado. Para esto se utilizan herramientas externas como Hadoop, Spark.
9. Modelos sin esquema
En MongoDB, puede optar por no aplicar ningún esquema en sus documentos. Si bien este era el valor predeterminado en versiones anteriores, en la versión más reciente tiene la opción de aplicar un esquema para sus documentos. Cada documento en MongoDB puede tener una estructura diferente y depende de su aplicación interpretar los datos. Si bien esto no es relevante para la mayoría de las aplicaciones, en algunos casos la flexibilidad adicional es importante. Cassandra en las versiones más nuevas (con CQL como idioma predeterminado) proporciona escritura estática. Debe definir el tipo de columna por adelantado.
Para resumir, aquí están las diferencias importantes en la forma de la tabla: 
Si desea ver la infografía completa, puede visitar nuestra página de comparación Cassandra vs MongoDB.
