Apache Cassandra frente a MongoDB

Apache Cassandra y MongoDB son bases de datos NoSQL ampliamente adoptadas 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 alta escalabilidad y disponibilidad. Ambos también han estado en uso durante más de una década: Cassandra se lanzó como un 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 lo que respecta a las características clave y pueden influir en los casos de uso de la gestión de datos a los que sirven mejor.

Antes de comparar Apache Cassandra y MongoDB, es útil establecer una comprensión de las bases de datos NoSQL.

Las bases de datos NoSQL, también denominadas “no solo SQL” o “no SQL”, son bases de datos distribuidas. Esto significa que la información que contienen se somete a replicación en varios nodos (servidores individuales que almacenan datos). Esta arquitectura distribuida permite una alta disponibilidad y durabilidad; si uno o varios nodos se desconectan, el resto de la base de datos puede seguirse ejecutando.

Sin embargo, lo más notable 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 estructura tabular estricta 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 no estructurados.

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

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

Aunque ambos se originaron solo 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 buscaban 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 un 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ó de enfoque para centrarse en MongoDB (su nombre es un juego de palabras con la palabra "humongous") y lo desarrolló como una base de datos orientada a documentos que funcionaba rápidamente y era fácil de usar. ¹

10Gen, que finalmente cambió su nombre a MongoDB Inc., lanzó MongoDB como un 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 su rendimiento y los casos de uso ideales. Entre los elementos clave figuran:

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

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

• Modelo de documento: los datos se almacenan como documentos estructurados, normalmente en JSON (JavaScript Object Notation) o BSON (Binary JSON).
• 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 emparejados con valores específicos).
• Modelo gráfico: los datos se almacenan como nodos y bordes, que representan entidades y relaciones.

El modelo de datos de Cassandra es un modelo de columna ancha, también conocido como almacén 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 filas de forma única 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 abordar los obstáculos que JSON estándar presentaba para las bases de datos: admitir 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 eficiencia 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 peer-to-peer. 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 la salida se utiliza para asignar datos a nodos específicos. Los datos también se copian en otros nodos.

El factor de replicación de una base de datos de Cassandra describe el número de copias de datos almacenados en la base de datos. El motor de almacenamiento de Cassandra emplea 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 maneja 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 (múltiples conjuntos de réplicas y un enrutador que transmite consultas de las aplicaciones a los conjuntos de réplicas) para mejorar la capacidad del sistema para manejar 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 de almacenamiento (que se indexa para columnas que no son particiones) como apropiada 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 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). Si bien 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 marca una mayor desviación de SQL que Cassandra Query Language. MQL se promociona para permitir una variedad de consultas y capacidades de manipulación de datos, incluidas consultas complejas, pipelines 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 son ofrecidos en gran medida por proveedores externos.

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

CAP es una abreviatura que representa tres características deseadas de los sistemas distribuidos: coherencia (todos los clientes ven los mismos datos al mismo tiempo), disponibilidad (cualquier cliente que haga una petición de datos recibe una respuesta, incluso si uno o más nodos están caídos) y tolerancia a la partición (un clúster de nodos sigue funcionando incluso en medio de cortes de comunicaciones entre dos o más nodos).

El teorema CAP dicta que un sistema distribuido puede ofrecer solo 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 cuanto a disponibilidad y tolerancia a la partición.

Mientras tanto, MongoDB se conoce como una base de datos "CP", que se 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, coherencia para Cassandra y disponibilidad para MongoDB.

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

Cassandra admite alta disponibilidad porque, como sistema descentralizado con datos replicados en múltiples nodos, presenta una alta tolerancia a fallas y ningún punto único de falla. Si un nodo experimenta tiempo de inactividad, otros nodos con copias de los mismos datos pueden cumplir con una solicitud de datos. Además, la replicación de datos a 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, un único punto de falla puede ocurrir cuando un nodo primario se desactiva. Sin embargo, la conmutación por error de MongoDB se considera robusta: durante lo que se conoce como elecciones de conjuntos de réplicas, los nodos que pertenecen a un conjunto de réplicas seleccionan un nuevo nodo principal para reemplazar el 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 elegir el nuevo nodo primario.

MongoDB ofrece inherentemente alta coherencia porque todos los clientes escriben en una única fuente de información; cada conjunto de réplicas puede tener solo un nodo primario que recibe todas las operaciones de escritura. En contraste, Apache Cassandra proporciona coherencia eventual: los clientes pueden escribir en cualquier nodo en cualquier momento, y luego las incoherencias se concilian lo más rápido posible.

Cassandra también permite a los usuarios optimizar la coherencia (mientras se 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 reconocer 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 la partición porque cada uno está diseñado para continuar funcionando incluso cuando se produce una interrupción de las comunicaciones 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 está limitada para garantizar la coherencia de los datos mientras se direcciona la partición.

Apache Cassandra se recomienda a menudo para cargas de trabajo de alto rendimiento, distribuidas globalmente y con gran cantidad de escritura, donde la disponibilidad y la escalabilidad son críticas, como la transmisión y el entretenimiento. Por ejemplo, los servicios de streaming como Netflix emplean 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 del desarrollador y una sólida coherencia. Las empresas a menudo confían 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 para Apache Cassandra y los casos de uso para MongoDB pueden superponerse. Los estudios de caso para cada base de datos demuestran su efectividad para aplicaciones del Internet de las cosas (IoT), comercio electrónico y más.