Apache Cassandra vs. MongoDB

Apache Cassandra y MongoDB son  bases de datos NoSQL muy adoptadas y diseñadas para almacenar y gestionar grandes cantidades de datos.

La popularidad de estos dos sistemas de bases de datos se debe en parte a su gran escalabilidad y disponibilidad. Ambas se utilizan también desde hace más de una década: Cassandra se lanzó como proyecto de código abierto en 2008; el lanzamiento de MongoDB se produjo al año siguiente.

A pesar de las similitudes, Apache Cassandra y MongoDB difieren significativamente con respecto a sus modelos de datos, arquitectura y otros componentes. Estas diferencias fundamentales afectan su rendimiento en cuanto a las características clave y pueden influir en los casos de uso de gestión de datos para los que son más adecuados.

Antes de comparar Apache Cassandra y MongoDB, conviene comprender bien qué son las bases de datos NoSQL.

Las bases de datos NoSQL, también conocidas como bases de datos "no solo SQL" o "no SQL", son bases de datos distribuidas. Esto significa que la información que contienen se replica en varios nodos (servidores individuales que almacenan datos). Esta arquitectura distribuida admite alta disponibilidad y durabilidad; si uno o más nodos se desconectan, el resto de la base de datos puede continuar.

Sin embargo, lo más importante es que las bases de datos NoSQL están diseñadas para almacenar y consultar datos fuera de las estructuras tradicionales que se encuentran en los sistemas de gestión de bases de datos relacionales (RDBMS). En lugar de adherirse a una estricta estructura tabular inherente a las bases de datos relacionales tradicionales, el diseño de bases de datos no relacionales no requiere un esquema rígido. Esto permite una rápida escalabilidad para gestionar grandes conjuntos de datos, incluidos conjuntos de datos estructurados, semiestructurados y datos no estructurados.

(Es importante tener en cuenta que la escalabilidad apreciada en las bases de datos NoSQL, incluidas Cassandra y MongoDB, es la escalabilidad horizontal o "escalado horizontal". En la escalabilidad horizontal, las cargas de trabajo se pueden dividir entre servidores, a diferencia de la escalabilidad vertical o “escalado ascendente” asociada a las bases de datos SQL, que requiere la adición de memoria al hardware existente).

Gracias a su rendimiento, escalabilidad y flexibilidad, las bases de datos NoSQL se han convertido en la opción ideal para soportar aplicaciones de big data y cargas de trabajo en tiempo real. Además de Apache Cassandra y MongoDB, otras bases de datos NoSQL populares son DynamoDB (proporcionada por AWS), Redis y CouchDB.

Aunque ambos se originaron apenas unos años después del cambio de milenio, Apache Cassandra y MongoDB tienen historias distintas.

Apache Cassandra se remonta a Facebook alrededor de 2007, cuando los ingenieros buscaron un sistema que pudiera almacenar datos para la creciente plataforma de mensajería de la empresa. Al combinar modelos de bases de datos NoSQL establecidos, crearon un sistema con estructuras de datos eficientes y coherencia eventual, donde las actualizaciones se propagan hasta que todas las réplicas coinciden con el tiempo. Los ingenieros lanzaron Cassandra como proyecto de código abierto en 2008. Un año después, Apache Software Foundation asumió la administración. 

MongoDB comenzó como parte de un proyecto de plataforma como servicio de la empresa 10Gen en 2007. La empresa cambió para centrarse en MongoDB, su nombre es un juego de palabras con "humongous", y la desarrolló como una base de datos orientada a documentos que funcionaba rápido y era fácil de usar¹.

10Gen, que finalmente cambió su nombre a MongoDB Inc., lanzó MongoDB como proyecto de código abierto en 2009. Sin embargo, las versiones más recientes de MongoDB se publican bajo la licencia pública del lado del servidor v1.

Las diferencias fundamentales entre Apache Cassandra y MongoDB afectan a su rendimiento y a sus casos de uso ideales. Los elementos clave incluyen:

• Modelos de datos
• Arquitectura y almacenamiento
• Consulta y otros lenguajes

Las bases de datos NoSQL se basan en uno de los cuatro tipos de modelos de datos:

• Modelo de documento: los datos se almacenan como documentos estructurados, normalmente en JSON (Notación de objetos JavaScript) o BSON (JSON binario).
• Modelo de columna ancha: los datos se almacenan en tablas con columnas dispersas, lo que significa que cada fila de una tabla puede tener un número diferente de columnas.
• Modelo clave-valor: los datos se almacenan como pares clave-valor (identificadores o etiquetas combinados con valores específicos).
• Modelo gráfico: los datos se almacenan como nodos y aristas, que representan entidades y relaciones.

El modelo de datos de Cassandra es un modelo de columna ancha, también conocido como almacenar de columna ancha. Cada fila de una tabla de Cassandra tiene una colección de columnas y una clave de partición única que se utiliza para distribuir datos entre nodos y centros de datos. Las filas se identifican mediante claves primarias, que pueden estar compuestas por claves de partición y, opcionalmente, claves de clúster (columnas que pueden identificar de forma única filas dentro de una partición o grupo relacionado).

Este enfoque es más flexible que el de las bases de datos relacionales, que tienen espacio asignado a un número determinado de columnas. A través del modelo de datos de Cassandra, el uso de columnas solo cuando sea necesario da como resultado un almacenamiento más eficiente y consultas más rápidas².

Por el contrario, MongoDB utiliza un modelo de documento. Los datos se almacenan principalmente como BSON, una representación binaria de JSON desarrollada por MongoDB.

BSON ayuda a superar los obstáculos que el JSON estándar presentaba para las bases de datos: compatibilidad con tipos de datos limitados, falta de longitud fija para los objetos (lo que ralentiza la velocidad de recorrido) y falta de metadatos (lo que ralentiza la recuperación de documentos). BSON se diseñó para optimizar la velocidad y la eficacia mediante la codificación de la información de formato y longitud. También admite algunos tipos de datos JSON no nativos, como fechas y datos binarios. ³

Como bases de datos NoSQL, tanto Apache Cassandra como MongoDB admiten sistemas distribuidos, con almacenamiento de datos en múltiples recursos informáticos para mitigar el tiempo de inactividad. Pero, al igual que con sus modelos de datos, la arquitectura subyacente a esta distribución es fundamentalmente diferente.

Apache Cassandra se basa en una arquitectura entre pares. Todos los nodos de un clúster de Cassandra son iguales, sin depender de un nodo maestro. Cuando los datos se colocan en un clúster, se aplica una función hash a la clave de partición de la fila y el resultado se utiliza para asignar datos a nodos específicos. Los datos también se copian en otros nodos.

El factor de replicación de un almacén de datos Cassandra describe el número de copias de datos almacenados en el almacén de datos. El motor de almacenamiento de Cassandra utiliza un flujo paso a paso (o ruta de escritura) que consta de un registro de confirmación, una tabla en memoria (memtable) y archivos de tabla de cadenas ordenadas (SSTable).

A diferencia de Cassandra, MongoDB utiliza un modelo primario/secundario para su arquitectura distribuida. En MongoDB, un conjunto de réplicas (un grupo de instancias) consta de un nodo principal que gestiona todas las operaciones de escritura (adiciones o modificaciones de datos) y nodos secundarios que reflejan los datos en el nodo principal.

Los grandes conjuntos de datos en MongoDB también se pueden distribuir a varias máquinas a través de un proceso conocido como fragmentación. La información se divide en clústeres fragmentados (varios conjuntos de réplicas y un enrutador que transmite las consultas de las aplicaciones a los conjuntos de réplicas) para mejorar la capacidad del sistema para gestionar las solicitudes de datos.

Las bases de datos también emplean diferentes métodos de indexación. En Apache Cassandra, el índice principal es la clave de partición, aunque la documentación de Cassandra cita la indexación adjunta al almacenamiento como característica para la mayoría de los casos de uso. ⁴ Cassandra también tiene índices secundarios, que son índices locales almacenados en tablas separadas de los valores que se indexan. MongoDB admite varios tipos de índices diferentes para diferentes casos de uso, incluidos índices geoespaciales, índices multiclave e índices de texto.

Por definición, las bases de datos NoSQL no utilizan Structured Query Language (SQL), el lenguaje de programación estandarizado para las bases de datos relacionales. Sin embargo, tanto Apache Cassandra como MongoDB tienen sus propios lenguajes de consulta.

Cassandra utiliza una versión personalizada de SQL llamada Cassandra Query Language (CQL). Aunque CQL se parece en gran medida a SQL, existen diferencias clave entre ambos. Por ejemplo, SQL opera en tablas normalizadas, mientras que CQL está diseñado para datos de Cassandra desnormalizados alineados con claves de partición. Además, SQL está optimizado para transacciones, mientras que CQL está diseñado para consultas en tiempo real y operaciones de escritura de gran volumen.

MongoDB utiliza MongoDB Query Language (MQL). Diseñado para consultar modelos de documentos, MQL comparte la misma sintaxis que los documentos, lo que supone una mayor diferencia con respecto a SQL que el Cassandra Query Language. MQL se promociona para permitir una variedad de consultas y capacidades de manipulación de datos, incluidas consultas complejas, canalizaciones de agregación y consultas de datos geoespaciales ⁵

Además de sus respectivos lenguajes de consulta, las bases de datos difieren en el soporte de programación. MongoDB proporciona controladores oficiales para más de una docena de lenguajes de programación, como Java, Python, Ruby y Node.js. Estos y otros lenguajes también son compatibles con Cassandra, pero los controladores los ofrecen en su mayoría proveedores externos.

Las diferencias fundamentales entre Apache Cassandra y MongoDB dan lugar a algunas variaciones en las características asociadas a su rendimiento. Estas variaciones también pueden explicarse mediante el teorema CAP.

CAP es una abreviatura que representa tres características deseadas de los sistemas distribuidos: consistencia (todos los clientes ven los mismos datos al mismo tiempo), disponibilidad (cualquier cliente que realiza una solicitud de datos recibe una respuesta, incluso si uno o más nodos están inactivos) y tolerancia a la partición (un grupo de nodos continúa funcionando incluso en medio de fallas en las comunicaciones entre dos o más nodos).

El teorema CAP dicta que un sistema distribuido solo puede ofrecer dos de las tres características deseadas. Apache Cassandra generalmente se clasifica como una base de datos “AP”, que ofrece un alto rendimiento principalmente en disponibilidad y tolerancia a particiones.

Mientras tanto, MongoDB se conoce como una base de datos "CP", que destaca en los frentes de tolerancia a la partición y coherencia. Pero para ambas bases de datos, también existen medidas para mejorar el rendimiento en características supuestamente comprometidas, es decir, la coherencia para Cassandra y la disponibilidad para MongoDB.

Echemos un vistazo más de cerca a las tres características deseadas.

Cassandra admite alta disponibilidad porque, al ser un sistema descentralizado con datos replicados en múltiples nodos, ofrece una alta tolerancia a fallos y no tiene un único punto de fallo. Si un nodo experimenta un tiempo de inactividad, otros con copias de los mismos datos pueden satisfacer una solicitud de datos. Además, la replicación de datos en centros de datos de todo el mundo permite una baja latencia para los usuarios locales.

Dado que la arquitectura de MongoDB se basa en un modelo primario/secundario, puede ocurrir un único punto de fallo cuando un nodo primario deja de funcionar. Sin embargo, la conmutación por error de MongoDB se considera robusta: durante lo que se conoce como elecciones de conjunto de réplicas, los nodos que pertenecen a un conjunto de réplicas seleccionan un nuevo nodo principal para reemplazar al nodo principal no disponible. Este proceso permite que MongoDB también ofrezca alta disponibilidad, aunque con un breve retraso: el rendimiento se reanuda solo después de que se elige el nuevo nodo principal.

MongoDB ofrece intrínsecamente una alta coherencia porque todos los clientes escriben en una única fuente fiable: cada conjunto de réplicas solo puede tener un nodo principal que reciba todas las operaciones de escritura. Por el contrario, Apache Cassandra proporciona coherencia eventual: los clientes pueden escribir en cualquier nodo en cualquier momento y, a continuación, las incoherencias se concilian lo antes posible.

Cassandra también permite a los usuarios optimizar la coherencia (al mismo tiempo que resta prioridad a la disponibilidad) a través de lo que se conoce como coherencia ajustable. Los usuarios pueden seleccionar un nivel de coherencia, que establece cuántas réplicas deben confirmar una lectura o escritura antes de confirmarla en la aplicación cliente. Los niveles más altos de coherencia requieren más réplicas para responder con confirmaciones, pero esto también aumenta la latencia y disminuye la disponibilidad.

Tanto Apache Cassandra como MongoDB ofrecen tolerancia a las particiones porque cada uno está diseñado para continuar funcionando incluso cuando se produce una interrupción de la comunicación en una parte del sistema.

En Apache Cassandra, los nodos permanecen disponibles en caso de un problema de comunicación, pero es posible que algunos nodos no entreguen las versiones más actualizadas de los datos (en respuesta a las solicitudes de datos) hasta que se resuelva la partición. En MongoDB, la disponibilidad se limita para garantizar la coherencia de los datos mientras se resuelve la partición.

Apache Cassandra se recomienda con frecuencia para cargas de trabajo de alto rendimiento, distribuidas globalmente y de escritura intensiva, en las que la disponibilidad y la escalabilidad son críticas, como el streaming y el entretenimiento. Por ejemplo, los servicios de streaming como Netflix utilizan Cassandra para gestionar la actividad global de los usuarios.

MongoDB es ideal para casos de uso de esquemas flexibles centrados en documentos que se benefician de la agilidad de los desarrolladores y una fuerte coherencia. Las empresas suelen confiar en MongoDB para respaldar sus sistemas de gestión de contenido porque MongoDB almacena y sirve una variedad de activos de contenido.

A pesar de las diferencias entre las dos bases de datos, los casos de uso de Apache Cassandra y los casos de uso de MongoDB pueden superponerse. Los casos de éxito para cada base de datos demuestran su eficacia para las aplicaciones de Internet de las cosas (IoT), el comercio electrónico y más.