Bases de Datos NoSQL: Modelado de Datos en MongoDB y Cassandra

Introducción al Modelado de Datos en el Mundo NoSQL

El auge de las aplicaciones modernas ha puesto contra las cuerdas a las bases de datos relacionales tradicionales. Cuando hablamos de escalabilidad horizontal, alta disponibilidad y esquemas flexibles, el ecosistema NoSQL se convierte en el protagonista indiscutible. Sin embargo, una de las trampas más comunes para los desarrolladores y administradores de sistemas es intentar aplicar las mismas técnicas de modelado de datos de SQL a sistemas como MongoDB o Cassandra.

Este artículo es una inmersión técnica profunda en el modelado de datos para dos de los sistemas NoSQL más representativos: MongoDB (orientado a documentos) y Cassandra (orientado a columnas anchas). Entender sus diferencias fundamentales no solo te permitirá diseñar esquemas eficientes, sino que evitará costosos errores de rendimiento y mantenimiento.

MongoDB: El Arte del Modelado por Documentos Embebidos

MongoDB es una base de datos documental que almacena datos en formato BSON (JSON binario). Su filosofía de diseño se basa en la premisa de que los datos que se acceden juntos deben almacenarse juntos. Aquí no existen las JOINs tradicionales; en su lugar, se favorece la desnormalización y la incrustación de documentos.

Principios Clave del Modelado en MongoDB

Para diseñar un modelo eficiente en MongoDB, debes olvidarte de la tercera forma normal y pensar en patrones de acceso a la aplicación.

Documentos Embebidos vs. Referencias

La decisión más crítica es cuándo incrustar un subdocumento y cuándo usar una referencia (similar a una clave foránea).

• Incrustar (Embed): Ideal para relaciones "uno a uno" o "uno a pocos". Por ejemplo, las direcciones de un usuario o los items de una orden de compra. Esto evita lecturas adicionales.
• Referenciar (Reference): Necesario para relaciones "uno a muchos" o "muchos a muchos" donde el subdocumento es grande o se actualiza con frecuencia. Por ejemplo, los posts de un blog y sus autores.

// Ejemplo de documento embebido (Óptimo)
{
  _id: ObjectId("..."),
  nombre: "Carlos Ruiz",
  direccion: {
    calle: "Av. Siempre Viva 742",
    ciudad: "Springfield",
    pais: "MX"
  },
  pedidos: [
    { producto: "Laptop", cantidad: 1, precio: 1200 },
    { producto: "Mouse", cantidad: 2, precio: 25 }
  ]
}

// Ejemplo con referencias (Necesario para escalar)
{
  _id: ObjectId("..."),
  nombre: "Carlos Ruiz",
  direccion_id: ObjectId("..."), // Referencia a otra colección
  pedidos_ids: [ ObjectId("..."), ObjectId("...") ]
}

[TIP]

Si tu aplicación necesita leer el 100% de los datos de un agregado en cada consulta, la incrustación es siempre la opción correcta. Si solo necesitas una parte, las referencias pueden ahorrar ancho de banda.

Estrategias de Indexación para Consultas

El modelado no termina en el esquema. En MongoDB, el índice correcto define el rendimiento. Debes crear índices compuestos que cubran los filtros y ordenamientos de tus consultas más frecuentes.

• Índices de un solo campo: Básicos, pero insuficientes para consultas complejas.
• Índices compuestos (ESR): Sigue la regla Equality, Sort, Range. Primero los campos de igualdad, luego los de ordenamiento y finalmente los de rango.
• Índices de texto y geoespaciales: Esenciales para búsquedas full-text y coordenadas.

// Creando un índice compuesto siguiendo ESR
// Consulta: db.ventas.find({ status: "completada" }).sort({ fecha: -1 }).limit(10)
db.ventas.createIndex( { status: 1, fecha: -1 } )

El Patrón de Polimorfismo y Esquemas Flexibles

Una de las mayores ventajas de MongoDB es su esquema flexible. Puedes tener documentos con campos diferentes en la misma colección. Esto es ideal para sistemas de catálogos de productos donde cada tipo de producto tiene atributos únicos.

// Producto tipo "Libro"
{ "sku": "001", "tipo": "libro", "autor": "Gabriel GM", "paginas": 350 }

// Producto tipo "Ropa"
{ "sku": "002", "tipo": "camiseta", "talla": "M", "material": "Algodon" }

[WARNING]

El esquema flexible no significa "sin esquema". Debes validar los datos a nivel de aplicación (usando Mongoose o validadores de MongoDB 5+) para evitar inconsistencias que rompan tu lógica de negocio.

Cassandra: Modelado Basado en Clustering y Particionamiento

Si MongoDB piensa en agregados, Cassandra piensa en distribución. Diseñada por Facebook para el motor de búsqueda de mensajes, Cassandra es una base de datos orientada a columnas anchas (wide-column store) que brilla por su escalabilidad lineal y ausencia de punto único de fallo.

El Modelo de Datos: Partition Key y Clustering Columns

En Cassandra, el modelo de datos se define mediante una CQL (Cassandra Query Language) que se parece a SQL, pero con reglas muy diferentes. La clave está en entender la Primary Key, que se divide en dos partes:

1. Partition Key: Determina en qué nodo del clúster se almacenará la fila. Es la clave de la escalabilidad horizontal. Todas las filas con la misma Partition Key se almacenan juntas.
2. Clustering Columns: Determinan el orden físico de los datos dentro de una misma partición.

-- Ejemplo de creación de tabla en Cassandra
CREATE TABLE sensores.lecturas (
    sensor_id UUID,           -- Partition Key
    timestamp TIMESTAMP,      -- Clustering Column (orden descendente)
    temperatura FLOAT,
    humedad FLOAT,
    PRIMARY KEY ((sensor_id), timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC);

[INFO]

En Cassandra, la consulta define el modelo. No puedes hacer una consulta eficiente si no modelas la tabla para esa consulta específica. Una tabla por patrón de acceso es la norma.

Desnormalización Agresiva y Tablas de Materialización

A diferencia de MongoDB, donde la desnormalización es una opción, en Cassandra es una obligación. No existen las JOINs. Si necesitas consultar datos por diferentes criterios, debes crear tablas duplicadas (materialized views o tablas manuales).

Imagina que necesitas consultar sensores por ubicación y por fecha.

-- Tabla 1: Por ubicación
CREATE TABLE sensores.por_ubicacion (
    ubicacion TEXT,
    timestamp TIMESTAMP,
    sensor_id UUID,
    valor FLOAT,
    PRIMARY KEY ((ubicacion), timestamp, sensor_id)
);

-- Tabla 2: Por sensor (para consultas rápidas)
CREATE TABLE sensores.por_sensor (
    sensor_id UUID,
    timestamp TIMESTAMP,
    ubicacion TEXT,
    valor FLOAT,
    PRIMARY KEY ((sensor_id), timestamp)
);

Este diseño, aunque parece redundante, es la clave del rendimiento en Cassandra. Cada tabla está optimizada para una consulta específica, y la aplicación es responsable de mantener la consistencia escribiendo en ambas tablas (o usando un batch).

El Concepto de TTL (Time-To-Live)

Cassandra está diseñado para manejar enormes volúmenes de datos, a menudo de series temporales. Para evitar que el disco se llene, el modelado debe incluir el uso de TTL.

-- Insertando datos que expirarán en 7 días (604800 segundos)
INSERT INTO sensores.lecturas (sensor_id, timestamp, temperatura)
VALUES (uuid(), toTimestamp(now()), 25.5)
USING TTL 604800;

Los datos se eliminan automáticamente mediante un proceso de compactación (compaction). No necesitas hacer DELETE manualmente.

Comparativa Práctica: MongoDB vs. Cassandra

A la hora de elegir, debes analizar el patrón de carga de trabajo.

Característica	MongoDB	Cassandra
Modelo de datos	Documentos JSON (Agregados)	Columnas anchas (Filas)
Escalabilidad	Horizontal (Sharding)	Horizontal (Nativa, Peer-to-Peer)
Consistencia	Fuerte por defecto (configurable)	Eventual o fuerte (configurable por query)
Lecturas	Rápidas con índices, JOINs costosas	Muy rápidas si la query usa Partition Key
Escrituras	Rápidas, pero con bloqueo a nivel de documento	Extremadamente rápidas (log-structured)
Casos de uso	Catálogos, gestión de contenido, IoT simple	Series temporales, mensajería, carritos de compra

Mejores Prácticas Transversales para el Modelado NoSQL

Independientemente de la base de datos que elijas, estas reglas te salvarán de dolores de cabeza.

1. Conoce tu patrón de acceso antes de modelar. No modeles los datos, modela las consultas. Esto es especialmente crítico en Cassandra.
2. Evita documentos/filas demasiado grandes. MongoDB tiene un límite de 16MB por documento. En Cassandra, una partición demasiado grande (más de 100MB) degradará el rendimiento.
3. Usa tipos de datos adecuados. En MongoDB, usa NumberDecimal para precios. En Cassandra, usa counter para contadores y evita TEXT para todo.
4. Planifica la partición. En Cassandra, una Partition Key con baja cardinalidad (ej: pais) creará hotspots. En MongoDB, una shard key monotónica (ej: timestamp) causará problemas de distribución.

El Problema de las Hot Partitions en Cassandra

Uno de los errores más comunes es elegir una Partition Key que concentre todos los datos en un solo nodo.

-- MAL: Todos los datos de "México" van a un solo nodo
PRIMARY KEY ((pais), timestamp)

-- BIEN: Se distribuye la carga usando un bucket
PRIMARY KEY ((pais, bucket), timestamp)
-- donde bucket = hash(timestamp) % 10

[WARNING]

Si tu aplicación tiene picos de escritura masivos, como en un sistema de logs, asegúrate de que tu Partition Key tenga suficiente cardinalidad para distribuir la carga entre todos los nodos del clúster.

Conclusión: El Modelado es un Arte, No una Ciencia

Tanto MongoDB como Cassandra representan un cambio de paradigma respecto a las bases de datos relacionales. MongoDB te ofrece esquemas flexibles y una gran facilidad para modelar agregados complejos, ideal para equipos que priorizan la velocidad de desarrollo. Cassandra, por otro lado, te exige una planificación rigurosa de las consultas y la distribución, pero a cambio te da una escalabilidad horizontal casi ilimitada y una resiliencia asombrosa.

El mejor consejo que puedo darte como SysAdmin es: nunca trates a una NoSQL como si fuera SQL. Si intentas forzar un modelo relacional en MongoDB, terminarás con un rendimiento pésimo. Si intentas modelar Cassandra como si fuera una base de datos documental, te enfrentarás a consultas lentas y a una distribución de datos desastrosa.

Dedica tiempo a entender los patrones de acceso de tu aplicación, realiza prototipos con volúmenes de datos realistas y monitoriza el rendimiento de tus particiones. Solo así lograrás dominar el arte del modelado de datos en el mundo NoSQL.