MongoDB frente a Cassandra: escrituras a escala planetaria

MongoDB y Apache Cassandra gestionan datos distribuidos a gran escala, pero con arquitecturas fundamentalmente distintas. MongoDB utiliza un modelo de líder-seguidor (primario-secundario), en el que las escrituras se dirigen a un único primario por conjunto de réplicas. Cassandra utiliza un modelo sin líder (entre pares), en el que cualquier nodo puede aceptar cualquier escritura. Esta diferencia arquitectónica determina todas las ventajas y desventajas de rendimiento, coherencia y operación entre ambos sistemas.

En Cassandra, todos los nodos son pares equivalentes en una topología de anillo. Una escritura se puede enviar a cualquier nodo (el coordinador), que la reenvía a los N nodos réplica responsables de la clave de partición de esa fila. El número de nodos que deben confirmar la escritura se configura mediante el nivel de coherencia (por ejemplo, ONE, QUORUM o ALL). Esta arquitectura elimina el cuello de botella del primario único y permite escrituras multi-primary y multirregión reales: todos los centros de datos pueden aceptar escrituras simultáneamente.

Cassandra está optimizado para un rendimiento de escritura extremadamente alto. Las escrituras se añaden a un registro de confirmación y a una estructura rápida en memoria (Memtable) antes de volcarse al disco (SSTables) en bloque. Este enfoque de solo adición significa que las escrituras nunca entran en conflicto en el disco y que el rendimiento escala linealmente con el número de nodos. Las plataformas de IoT que ingieren millones de mediciones por segundo, los sistemas de registro de eventos y las cargas de trabajo de series temporales cuyas tasas de escritura saturan un único primario de MongoDB son casos de uso ideales para Cassandra.

El nivel de coherencia de Cassandra se puede configurar para cada consulta. ONE significa que una réplica confirma la operación (la mayor velocidad y la coherencia más débil). QUORUM significa que la mayoría de las réplicas confirma la operación (equilibra la latencia y la coherencia). ALL significa que todas las réplicas confirman la operación (la menor velocidad y la coherencia más sólida). La fórmula clave es la siguiente: si coherencia de lectura + coherencia de escritura > factor de replicación, se obtiene coherencia fuerte. Esta flexibilidad permite que Cassandra atienda distintas cargas de trabajo de manera diferente dentro del mismo clúster.

El modelo de datos de Cassandra está basado fundamentalmente en las consultas. Las tablas se diseñan para responder eficazmente a consultas específicas; no existe un motor de consultas ad hoc como el de MongoDB. Las tablas deben particionarse mediante una clave de partición (que determina qué nodo almacena la fila), y las filas de una partición se ordenan mediante una clave de agrupación. Existen índices secundarios, pero son mucho menos completos que los de MongoDB. Las consultas complejas (uniones, agregaciones y filtros por varios campos) que MongoDB gestiona con el pipeline de agregación no son posibles en CQL estándar.

El pipeline de agregación y los operadores de consulta avanzados de MongoDB permiten realizar consultas ad hoc sobre cualquier campo. ¿Necesita encontrar a todos los usuarios de Estambul que hayan comprado un producto concreto en los últimos 30 días? Una consulta de MongoDB con el índice compuesto adecuado responde directamente a esta necesidad. En Cassandra, tendría que crear una tabla prediseñada para esa consulta específica, desnormalizar los datos en varias tablas o utilizar Spark para las consultas analíticas. MongoDB es mucho más flexible cuando los requisitos de consulta evolucionan.

La replicación sin líder y entre varios centros de datos de Cassandra permite implementaciones activo-activo: todas las regiones aceptan escrituras simultáneamente. Un usuario de Nueva York escribe en el centro de datos de Estados Unidos; los datos de ese mismo usuario se replican de forma asíncrona en Europa y Asia. MongoDB admite varias regiones mediante preferencias de lectura de conjuntos de réplicas y clústeres globales (Atlas), pero las escrituras aún deben dirigirse a una única región primaria. Para las aplicaciones que requieren escrituras con latencia cero desde todas las regiones, Cassandra tiene una ventaja estructural.

MongoDB con w: majority proporciona coherencia fuerte: una vez confirmada una escritura, todas las lecturas posteriores devuelven el nuevo valor. La configuración predeterminada de Cassandra ofrece coherencia eventual: una escritura confirmada con ONE puede no estar visible de inmediato en las lecturas de otras réplicas. Las aplicaciones deben tolerarlo o configurar lecturas y escrituras con QUORUM para lograr coherencia fuerte, a costa de una mayor latencia. Esto afecta considerablemente a la complejidad de la aplicación.

Ambos sistemas requieren conocimientos operativos, pero en áreas diferentes. La arquitectura de conjuntos de réplicas de MongoDB se conoce bien, y Atlas automatiza casi todas las operaciones. La topología de anillo de Cassandra requiere una cuidadosa planificación de capacidad, gestión de tokens, supervisión de la compactación y gestión de tombstones. Las eliminaciones en Cassandra producen tombstones que pueden acumularse y degradar el rendimiento de lectura con el tiempo. El modelo de eliminación de MongoDB es más sencillo desde el punto de vista operativo. Para equipos pequeños o medianos, la carga operativa de MongoDB suele ser menor.

Ambas bases de datos se utilizan para cargas de trabajo de IoT y series temporales, pero con enfoques diferentes. La partición de series temporales de Cassandra (particionar por dispositivo y agrupar por tiempo) ofrece un rendimiento de escritura extremadamente alto y lecturas eficientes de rangos temporales por dispositivo. Las colecciones nativas de series temporales de MongoDB (añadidas en la versión 5.0) reducen gran parte de la diferencia mediante la creación automática de buckets y el almacenamiento columnar. Para tasas de escritura de millones por segundo en miles de dispositivos, Cassandra aún lleva ventaja. Para cargas de trabajo de menor escala con necesidades de consulta más avanzadas, las series temporales de MongoDB suelen ser más prácticas.

Utilice Cassandra cuando el rendimiento de escritura sea de millones por segundo; se requieran escrituras activo-activo multirregión; el patrón de acceso sea muy predecible (una tabla por consulta); y los TTL de retención de datos sean sencillos. Utilice MongoDB cuando los patrones de consulta evolucionen con frecuencia; se necesiten agregaciones y uniones complejas; se valore la flexibilidad de los documentos; el equipo sea pequeño o mediano; o necesite transacciones ACID completas en varios documentos.

En esta lección ha aprendido lo siguiente: la arquitectura sin líder de Cassandra permite un rendimiento de escritura masivo y verdaderas escrituras activo-activo multirregión, algo que el modelo primario-secundario de MongoDB no puede igualar; el modelo de consultas de Cassandra prioriza el esquema y las tablas, mientras que MongoDB admite consultas ad hoc avanzadas; y la decisión entre ambos depende de los requisitos de escala de escritura, las necesidades de flexibilidad de las consultas y la capacidad operativa del equipo. A continuación compararemos MongoDB con DynamoDB.