Bases de Datos de Columnas Anchas: Apache Cassandra y ScyllaDB

Las bases de datos de columnas anchas (Wide-Column Stores), inspiradas en el influyente artículo de Google sobre Bigtable (2006), son sistemas NoSQL distribuidos de altísimo rendimiento diseñados para almacenar petabytes de datos estructurados y semiestructurados distribuidos entre cientos o miles de servidores sin punto único de fallo (Peer-to-Peer).

Los principales exponentes de este modelo son Apache Cassandra, ScyllaDB y Apache HBase.

1. ¿Cómo funciona el Modelo de Columnas Anchas? #

A diferencia de una base de datos relacional (donde todas las filas de una tabla tienen exactamente las mismas columnas y tipos fijos):

• Cada fila se identifica por una Clave de Fila (Row Key).
• Cada fila puede contener un número dinámico y variable de columnas (desde unas pocas hasta millones).
• Cada celda o columna contiene tres elementos: $\text{Columna} = (\text{Nombre / Clave}, \text{Valor}, \text{Timestamp / Marca de Tiempo})$

1Row Key (id_usuario) │ Columna 1              │ Columna 2            │ Columna 3
2─────────────────────┼────────────────────────┼──────────────────────┼────────────────────────
3"user_101"           │ email: "ana@mail.com"  │ ciudad: "Madrid"     │ edad: 28
4"user_102"           │ email: "carlos@box.es" │ telefono: "600112233"│ (sin ciudad ni edad)
5"user_103"           │ activo: true           │ (solo una columna)   │

2. Arquitectura de Apache Cassandra: Sin Maestro (Masterless) #

Cassandra utiliza una topología en anillo descentralizada (Ring Topology):

• Todos los nodos son idénticos: No existe un nodo maestro (Master) que pueda convertirse en un cuello de botella o punto único de fallo.
• Escalabilidad Lineal: Añadir 10 servidores duplica con precisión la capacidad de almacenamiento y el rendimiento de lecturas/escrituras.
• Escritura ultra rápida basada en LSM-Trees: Las escrituras se guardan primero en un log secuencial en disco (CommitLog) y en memoria (Memtable), volcándose periódicamente a ficheros inmutables (SSTables).

3. Claves de Partición y Claves de Agrupación (Clustering Keys) #

En Cassandra y su lenguaje de consulta CQL (Cassandra Query Language), el diseño de la clave primaria (PRIMARY KEY) es el aspecto más crítico del modelado:

$\text{PRIMARY KEY} = (\text{Partition Key}, \text{Clustering Keys})$

1CREATE TABLE historial_temperaturas (
2    id_sensor INT,          -- Partition Key (determina en qué nodo del clúster se guarda)
3    fecha_hora TIMESTAMP,   -- Clustering Key (determina el orden físico dentro del nodo)
4    temperatura FLOAT,
5    humedad FLOAT,
6    PRIMARY KEY (id_sensor, fecha_hora)
7) WITH CLUSTERING ORDER BY (fecha_hora DESC);

1. Partition Key (id_sensor): Se pasa por una función de hash para determinar en qué nodo del anillo físico se almacenará la partición.
2. Clustering Key (fecha_hora): Ordena físicamente los registros en disco dentro de la partición, permitiendo consultas de rango ultrarrápidas:

   1SELECT * FROM historial_temperaturas 
   2WHERE id_sensor = 42 AND fecha_hora >= '2026-09-01 00:00:00';

4. Filosofía de Modelado: Orientado a Consultas (Query-Driven) #

IMPORTANT
En Cassandra no existen los JOINs ni las transacciones complejas entre tablas. La regla fundamental de diseño es: «Crea una tabla por cada consulta que necesite tu aplicación». Si necesitas consultar usuarios por email y también por teléfono, creas dos tablas desnormalizadas (usuarios_por_email y usuarios_por_telefono).