Cassandra Apache: qué es y por qué importa

Apple almacena más de mil millones de dispositivos activos y procesa petabytes de datos de telemetría al día. Una parte significativa de esa infraestructura corre sobre Cassandra Apache. No es el único caso: Netflix, Walmart y Huawei también confían en esta base de datos para cargas donde el fallo sencillamente no es una opción.

Pero ¿qué tiene Cassandra Apache de especial frente a otros sistemas distribuidos? La respuesta no está en un único superpoder, sino en una combinación de decisiones de diseño que la hacen casi imbatible en escenarios de escritura masiva y disponibilidad continua. Desde sus raíces en los servidores de Facebook hasta la versión 5.0 lanzada en 2024, con soporte nativo para búsqueda vectorial orientada a inteligencia artificial, este sistema ha recorrido un camino largo y bien documentado.

Qué es Cassandra Apache y de dónde viene

Cassandra Apache es un sistema de gestión de bases de datos NoSQL distribuido, de código abierto y escrito en Java. Su diseño se basa en un modelo de almacenamiento tabular de columnas anchas (wide-column store), lo que le permite manejar enormes volúmenes de datos repartidos entre cientos o miles de servidores manteniendo alta disponibilidad y sin ningún punto único de fallo.

El proyecto nació dentro de Facebook alrededor de 2007. Los ingenieros Avinash Lakshman —uno de los autores del paper de Amazon Dynamo— y Prashant Malik necesitaban resolver el problema de la búsqueda en la bandeja de entrada para cientos de millones de usuarios. Las bases de datos relacionales tradicionales no podían escalar al ritmo que exigía la red social. El resultado fue un sistema que tomó prestadas ideas de Dynamo (distribución y disponibilidad) y de Google Bigtable (modelo de datos orientado a columnas).

Del problema de Facebook a la Apache Software Foundation

En julio de 2008, Facebook liberó el código bajo una licencia open source. En marzo de 2009 entró en el Apache Incubator y en febrero de 2010 se convirtió en proyecto de primer nivel dentro de la Apache Software Foundation (ASF), que es quien lo mantiene hasta hoy. Desde entonces, la comunidad ha crecido de forma sostenida: hoy el proyecto acumula cientos de colaboradores activos y publicaciones académicas que analizan su rendimiento.

Un estudio de investigadores de la Universidad de Toronto concluyó que Cassandra «logra el más alto rendimiento para el número máximo de nodos en todos los experimentos» entre los sistemas NoSQL evaluados, aunque apuntaron que ese rendimiento tiene como contrapartida latencias de lectura y escritura más altas en determinadas configuraciones. Es una advertencia honesta que merece tenerse en cuenta antes de adoptar la tecnología.

Arquitectura de Cassandra Apache: sin nodo maestro

La característica que más diferencia a Cassandra Apache de la mayoría de sistemas distribuidos es su arquitectura masterless o sin nodo maestro. No hay un servidor principal al que los demás reportan. Todos los nodos son iguales en funciones y capacidades: cualquier nodo puede recibir lecturas y escrituras, y el fallo de uno —o incluso de un centro de datos entero— no detiene el sistema.

Esta simetría se organiza mediante una topología en anillo. Los datos se distribuyen entre los nodos usando una función de hash consistente que asigna rangos de claves a cada nodo. Cuando se añade un nodo nuevo o se elimina uno existente, la redistribución de datos ocurre de forma automática y sin interrumpir el servicio. Esto es lo que se conoce como escalabilidad lineal: duplicar nodos equivale, en términos prácticos, a duplicar la capacidad de escritura.

El protocolo gossip y la topología en anillo

Para que todos los nodos estén sincronizados sin un coordinador central, Cassandra usa el protocolo gossip. Es una comunicación peer-to-peer donde cada nodo intercambia periódicamente información sobre su propio estado y el de los nodos que conoce. El resultado es que la información se propaga por el clúster de forma similar a como se extiende un rumor: rápida y sin necesidad de una fuente única de verdad.

La replicación también es configurable. El parámetro de replication factor determina cuántas copias de cada dato existen en el clúster. Con un factor de replicación de 3, los datos sobreviven al fallo simultáneo de dos nodos sin pérdida de disponibilidad. Además, Cassandra soporta replicación multi-datacenter de forma nativa y asíncrona, lo que permite mantener réplicas en distintas regiones geográficas con latencia baja para los clientes locales.

Modelo de datos: columnas, particiones y CQL

El modelo de datos de Cassandra no es el de una base de datos relacional tradicional, y entender esta diferencia es clave para usarla bien. Los datos se organizan en tablas formadas por filas identificadas por una clave primaria compuesta. El primer componente de esa clave es la partition key, que determina en qué nodo del anillo se almacena la fila. Los componentes adicionales son las clustering columns, que ordenan las filas dentro de una partición.

Esta estructura tiene una consecuencia importante: las consultas deben diseñarse alrededor de las claves. Cassandra no soporta JOIN ni subconsultas como lo haría SQL. En cambio, favorece la desnormalización: guardar los datos en el formato exacto en que se van a consultar, aunque eso implique duplicarlos. Es un cambio de mentalidad que puede resultar incómodo al principio, pero que se traduce en lecturas extremadamente rápidas y predecibles.

Las tablas pueden crearse, modificarse y eliminarse en tiempo de ejecución sin bloquear las operaciones en curso. Este esquema schema-flexible facilita los ciclos de desarrollo ágil sin necesidad de ventanas de mantenimiento.

CQL: el lenguaje que simplificó Cassandra

Las versiones iniciales de Cassandra usaban una API propia bastante cruda. Con el tiempo, el proyecto apostó por CQL (Cassandra Query Language), un lenguaje cuya sintaxis recuerda a SQL aunque con menos funcionalidades. La curva de aprendizaje es mucho menor que la de la API Thrift que reemplazó, y hoy es la forma estándar de interactuar con el sistema.

Con CQL se pueden hacer consultas como SELECT * FROM usuarios WHERE id = ? de una forma que resulta inmediatamente familiar para cualquier desarrollador que haya tocado SQL. Las diferencias importantes aparecen cuando se intentan consultas complejas: agregaciones sobre colecciones, filtros sobre columnas no indexadas o subconsultas requieren diseñar el modelo de datos de otra manera.

Cassandra Apache frente a otras bases de datos NoSQL

Elegir una base de datos distribuida no es una decisión de una línea. La tabla siguiente resume las diferencias más relevantes entre Cassandra y sus principales alternativas:

La elección depende del caso de uso. Si se necesitan consultas ad hoc ricas y el volumen es manejable, MongoDB puede ser más cómodo. Si la prioridad es la disponibilidad continua a escala masiva con escrituras intensivas, Cassandra Apache difícilmente tiene rival entre las opciones de código abierto.

Novedades de Cassandra 5.0: IA, índices y rendimiento

En octubre de 2024, la Apache Software Foundation anunció la disponibilidad general de Cassandra 5.0, describida como la versión «más avanzada, segura y lista para IA» de su historia. El salto desde la versión 4.x es considerable, tanto en rendimiento como en funcionalidades nuevas.

Cassandra Apache 5.0 introduce cinco mejoras principales que merecen atención:

• Storage Attached Indexes (SAI): Un sistema de indexación secundaria que consume aproximadamente un 14% del espacio que usaba el anterior sistema SASI. Permite consultas más flexibles sobre columnas no primarias con un impacto mínimo en el almacenamiento.
• Trie Memtables y Trie SSTables: Nuevas estructuras de datos en memoria y en disco basadas en árboles trie que optimizan el uso de memoria y mejoran el rendimiento sin necesidad de cambiar los modelos de datos existentes.
• Unified Compaction Strategy (UCS): Una estrategia de compactación unificada que combina los enfoques de niveles y escalonado en un único algoritmo configurable. Reduce significativamente la intervención manual en la organización de datos.
• Vector Search: Soporte nativo para búsqueda de vectores mediante Approximate Nearest Neighbor (ANN), abriendo la puerta a casos de uso de inteligencia artificial y búsqueda semántica directamente sobre Cassandra.
• Java 17 y recolectores de bajo pausa: La adopción de JDK 17 permite usar recolectores de basura como ZGC y Shenandoah, con pausas submilisegundo que mejoran la latencia de forma medible en producción.

Además, se añadió autenticación mTLS (mutual TLS) para entornos que requieren autenticación basada en certificados sin contraseñas, y enmascaramiento dinámico de datos (DDM) para ocultar información sensible en columnas sin modificar los datos subyacentes.

Storage Attached Indexes y búsqueda vectorial

El impacto real de SAI va más allá del ahorro de espacio. Durante las reuniones de contribuidores, el equipo del proyecto subrayó que las consultas sobre índices secundarios son ahora considerablemente más rápidas, aunque siguen rindiendo mejor cuando se aplican sobre un número acotado de particiones. No es una bala de plata, pero representa un avance sustancial frente a la situación anterior.

La búsqueda vectorial es, probablemente, la novedad más llamativa desde el punto de vista estratégico. Según la Apache Software Foundation, esta capacidad «abre nuevas posibilidades para cómo las organizaciones pueden aprovechar sus datos en la era de la IA». La idea es que aplicaciones que necesitan búsqueda semántica —motores de recomendación, chatbots con memoria, sistemas RAG— puedan almacenar y consultar embeddings directamente en Cassandra sin necesitar una base de datos vectorial separada.

Casos de uso reales: quién usa Cassandra Apache y para qué

La lista de organizaciones que confían en Cassandra para sus cargas de producción más críticas habla por sí sola. Apple la usa para almacenar datos de millones de dispositivos. Netflix la emplea para gestionar el estado de sesiones de sus usuarios en todo el mundo. Walmart la utiliza para el seguimiento de inventario y ventas en tiempo real. Huawei la integra en sus plataformas de comunicaciones.

Más allá de los grandes nombres, los sectores donde Cassandra Apache brilla con más fuerza son:

• Series temporales e IoT: Sensores industriales, telemetría de dispositivos, métricas de aplicaciones. La capacidad de escribir millones de puntos por segundo sin degradación es difícil de igualar.
• Plataformas de mensajería: La historia se repite con el origen del proyecto: sistemas de bandeja de entrada, notificaciones push, registros de actividad.
• E-commerce a escala: Catálogos de productos con alta disponibilidad, carritos de compra distribuidos, historial de pedidos.
• Fintech y registro de eventos: Sistemas de auditoría, logs de transacciones, seguimiento de fraude donde perder un evento no es aceptable.
• Juegos online: Perfiles de jugadores, puntuaciones globales, estado de partidas en tiempo real con millones de usuarios concurrentes.

Cuándo usar Cassandra Apache y cuándo no

La pregunta más honesta antes de adoptar cualquier tecnología es cuándo no usarla. Cassandra Apache es una herramienta extraordinariamente potente para un perfil específico de problemas, pero no es la solución correcta para todo.

Úsala cuando:

• La escritura supera a la lectura en volumen o en importancia de latencia.
• Necesitas disponibilidad del 100% y puedes tolerar consistencia eventual.
• El sistema debe escalar horizontalmente de forma predecible y sin interrupciones.
• Los datos tienen una estructura bien definida por claves de acceso conocidas.
• La distribución geográfica es un requisito, no un extra.

Evítala cuando:

• Las consultas son ad hoc, exploratorias o cambian frecuentemente.
• Necesitas transacciones ACID complejas que abarquen múltiples filas o tablas.
• El modelo de datos requiere JOIN intensivos o relaciones complejas.
• El volumen de datos es pequeño y la simplicidad operativa es prioritaria.
• El equipo no tiene experiencia con sistemas distribuidos y el tiempo de formación es un problema.

La documentación oficial recomienda claramente no usar Cassandra para análisis ad hoc ni para cargas con muchas transacciones entre particiones. Esa honestidad es, paradójicamente, una de las razones por las que el proyecto goza de tan buena reputación entre los ingenieros que la han usado en serio.

Preguntas frecuentes sobre Cassandra Apache

¿Cassandra Apache es gratuita? Sí, Cassandra Apache es completamente gratuita y de código abierto, distribuida bajo la licencia Apache 2.0. Cualquier persona u organización puede descargarla, usarla en producción y modificarla sin pagar licencias. Existen servicios comerciales gestionados —como los ofrecidos por DataStax o proveedores cloud— que añaden soporte empresarial, pero el software base no tiene coste.

¿Cuál es la diferencia entre Cassandra Apache y DataStax Enterprise? DataStax Enterprise (DSE) es una distribución comercial basada en Cassandra Apache que añade funcionalidades propietarias como búsqueda integrada con Apache Solr, soporte para grafos y herramientas de monitorización avanzadas. El núcleo es el mismo, pero DSE incluye componentes adicionales y soporte profesional. Para la mayoría de casos de uso, la versión open source de Cassandra es más que suficiente.

¿Cómo gestiona Cassandra Apache la consistencia de los datos? Cassandra Apache utiliza el modelo de consistencia eventual por defecto, pero permite configurar el nivel de consistencia por operación. Parámetros como QUORUM obligan a que una mayoría de réplicas confirme la operación antes de devolverla como exitosa, lo que aumenta la consistencia a costa de algo de latencia. Esta flexibilidad permite ajustar el balance entre disponibilidad y consistencia según las necesidades de cada consulta.

¿Es difícil migrar datos a Cassandra Apache desde una base de datos relacional? La migración requiere un rediseño del modelo de datos, no solo una importación directa. Hay que pensar en los patrones de acceso antes de definir las tablas y claves. Herramientas como dsbulk facilitan la carga masiva de datos, pero el trabajo conceptual de adaptar un esquema relacional al modelo orientado a columnas es el verdadero desafío. Con el diseño correcto, el rendimiento resultante justifica el esfuerzo.

¿Qué versión de Cassandra Apache debería usar en la actualidad? Para nuevos proyectos, la recomendación general es usar Cassandra 5.0 o la última versión estable del ciclo 5.x, que incluye todas las mejoras de rendimiento, los nuevos índices SAI y el soporte para búsqueda vectorial. El proyecto mantiene en soporte activo las tres últimas versiones, por lo que la rama 4.1 sigue siendo válida para entornos que ya están en producción y no quieren asumir la actualización de inmediato.

Conclusión

Pocas bases de datos han demostrado tanta resiliencia como tecnología a lo largo de más de quince años. Lo que comenzó como una solución interna para gestionar la bandeja de entrada de Facebook se ha convertido en uno de los pilares de la infraestructura de datos global. La versión 5.0 no es un simple mantenimiento: el soporte para búsqueda vectorial y los índices SAI posicionan a Cassandra en el centro de la arquitectura de aplicaciones que integran inteligencia artificial con datos a escala.

Entender cuándo esta tecnología encaja —y cuándo no— es la diferencia entre construir un sistema que funciona elegantemente y uno que genera fricción constante. Su arquitectura sin nodo maestro, la escalabilidad lineal y la tolerancia a fallos por diseño no son características para impresionar en presentaciones: son garantías operativas que se notan cuando el tráfico se dispara o cuando un datacenter cae a las tres de la madrugada.

Si estás evaluando opciones para una arquitectura distribuida con alta disponibilidad, vale la pena dedicar tiempo a explorar la documentación oficial en cassandra.apache.org y probar un clúster local con Docker antes de tomar una decisión. Las herramientas están ahí; el criterio para elegirlas bien, también.