En la lección 01-02 vimos las cuatro familias NoSQL desde muy arriba: qué son y para qué sirven, en un par de párrafos cada una. En la lección anterior entendimos el porqué del movimiento y dimos los primeros pasos con MongoDB. Ahora toca bajar al suelo.

"NoSQL" no es una tecnología: es una etiqueta que agrupa cuatro modelos de datos radicalmente distintos entre sí. Una base documental y una base de grafos se parecen tanto como una hoja de cálculo y un mapa de metro. Decir "vamos a usar NoSQL" es tan poco informativo como decir "vamos a usar un vehículo": la pregunta útil es cuál, y para qué.

En esta lección recorremos las cuatro familias con operación real y ejecutable: documental con MongoDB, clave-valor con Redis, columnar con Cassandra y grafos con Neo4j. De cada una veremos su modelo de datos, cómo se consulta, qué productos la representan, sus fortalezas, sus límites y —lo que hilará toda la lección— qué pieza de BiblioRed le encaja. Al final, una tabla comparativa y un árbol de decisión para elegir.

1. Las cuatro familias de un vistazo
2. Bases documentales: MongoDB
3. Bases clave-valor: Redis
4. Bases columnares: Cassandra
5. Bases de grafos: Neo4j
6. Familias especializadas que este curso no vuelve a tratar
7. Tabla comparativa de las cuatro familias
8. Árbol de decisión
9. El reparto final de BiblioRed
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Las cuatro se pueden ordenar por la riqueza de la estructura que entienden: desde la que no entiende nada del valor que guarda hasta la que entiende las relaciones entre entidades.

Y las cuatro piezas de BiblioRed que buscan acomodo:

• Reseñas y catálogo enriquecido → estructura rica, heterogénea, consultada por contenido → documental.
• Portadas y sesiones del portal → acceso por clave, muy frecuente, con caducidad → clave-valor.
• Registro de actividad → altísimo volumen de escritura, consulta por socio y rango de fechas → columnar.
• Motor de recomendaciones → recorrer relaciones entre lectores y títulos → grafos.

Una advertencia antes de empezar, para que esta lección no se lea mal: BiblioRed no va a desplegar cuatro bases de datos. Va a desplegar PostgreSQL y MongoDB. Redis, Cassandra y Neo4j aparecen aquí porque son la mejor forma de entender qué resuelve cada familia y porque el día que BiblioRed crezca, sabrá reconocer el momento. Confundir "entender una familia" con "instalarla" es el camino más rápido a una arquitectura ingobernable.

La unidad es el documento: una estructura tipo JSON —guardada en BSON, como vimos en 03-01— que admite anidamiento y arrays. Los documentos viven en colecciones, que no imponen esquema.

Tres propiedades que definen la familia:

1. El documento es autocontenido. Todo lo que la aplicación necesita para mostrar una entidad cabe dentro.
2. El motor entiende el interior. Puede filtrar, ordenar, indexar y agregar por cualquier campo, incluso anidado o dentro de un array. Esto es lo que separa a una base documental de una clave-valor que guardase JSON: para la segunda, el valor es una bolsa de bytes opaca.
3. La escritura de un documento es atómica, sin necesidad de transacción.

Productos representativos: MongoDB (el dominante y nuestra referencia), Couchbase, Amazon DocumentDB, RavenDB, Firestore. Y una nota importante: PostgreSQL con el tipo jsonb hace muchas de estas cosas sin dejar de ser relacional; lo compararemos con detalle en la lección 03-04.

Seguimos sobre la colección resenas que creamos en la lección anterior. Un filtro es un documento; cada campo es una condición y varios campos se combinan con Y lógico. Cuando la condición no es una igualdad, el valor pasa a ser un documento con un operador que empieza por $.

$exists no tiene equivalente en SQL, y por una razón de fondo: en una tabla, la columna existe siempre; como mucho vale NULL. En una colección, un campo puede sencillamente no estar. Es la diferencia entre "no tiene valor" y "esta entidad no tiene ese concepto", y en el mundo documental son dos cosas distintas.

El segundo argumento de find es la proyección: qué campos devolver. 1 incluye, 0 excluye.

Reglas de la proyección que conviene memorizar:

• No se pueden mezclar inclusiones y exclusiones en la misma proyección, con una única excepción: _id: 0 se puede combinar con inclusiones.
• El _id se devuelve siempre salvo que lo excluyas explícitamente.
• .sort(), .limit() y .skip() se encadenan sobre el cursor y equivalen a ORDER BY, LIMIT y OFFSET. En sort, 1 es ascendente y -1 descendente.

Aquí aparece una diferencia grande respecto a SQL: en MongoDB no se reescribe el documento entero, se aplican operadores de actualización sobre partes de él.

Detente un segundo en lo que acaba de pasar. El campo editada no existía en ningún documento de la colección y ahora existe en uno. No ha hecho falta un ALTER TABLE, no ha habido bloqueo y los otros tres documentos no se han enterado. Eso es el esquema flexible en su forma más práctica.

El operador posicional $ se refiere al primer elemento del array que ha coincidido con el filtro. Es la forma de modificar un elemento concreto sin reescribir el array entero.

Cuidado con un detalle que ha causado incidentes reales: deleteMany({}) con filtro vacío borra la colección entera y no pide confirmación. En SQL, DELETE FROM tabla hace lo mismo, pero al menos hay una transacción que se puede deshacer con ROLLBACK. Aquí, salvo que estés dentro de una transacción explícita, no la hay.

Las consultas de resumen —lo que en la lección 02-05 hicimos con GROUP BY— se hacen en MongoDB con el marco de agregación: una tubería de etapas, donde cada etapa recibe documentos, los transforma y se los pasa a la siguiente.

Objetivo: la puntuación media y el número de reseñas de cada libro, ordenado de mejor a peor.

Traducción etapa por etapa, que es la mejor forma de entenderlo:

Dos convenciones de sintaxis que hay que fijar:

• "$campo" con dólar delante significa "el valor de ese campo", no la cadena literal. "$puntuacion" es el número; "puntuacion" sería el texto.
• En $group, _id es la clave de agrupación, no un identificador. _id: "$libro_id" es literalmente el GROUP BY libro_id. Si pones _id: null, agrupas todo en una sola fila, que es el SELECT AVG(...) FROM tabla sin GROUP BY.

Un ejemplo más, con $unwind, que no tiene contrapartida limpia en SQL: las etiquetas más usadas.

$unwind ha "desplegado" la reseña de Nuria, que tenía cuatro etiquetas, en cuatro documentos idénticos salvo por la etiqueta. Después, $group cuenta. Es exactamente el trabajo que en el modelo relacional haría la tabla intermedia resenas_etiquetas que evitamos al embeber el array.

Fortalezas

• Estructuras heterogéneas y anidadas sin tablas auxiliares ni columnas nulas.
• El esquema evoluciona sin migración.
• Lectura de una entidad completa en un solo acceso.
• Lenguaje de consulta rico: filtros, agregación, índices sobre cualquier campo.

Límites

• Cruzar colecciones ($lookup) es caro y no debe ser la norma.
• Sin integridad referencial declarativa.
• El límite de 16 MB por documento acota lo que puedes embeber.
• Las transacciones multidocumento existen, pero cuestan rendimiento; el diseño debe minimizar su necesidad.

Encaje en BiblioRed: las reseñas y el catálogo enriquecido. Son entidades autocontenidas, heterogéneas, que se leen enteras y cambian de forma con frecuencia. Es el encaje perfecto, y por eso MongoDB es la base NoSQL que BiblioRed va a desplegar de verdad.

El modelo más simple que existe: un diccionario gigante y distribuido. Una clave, un valor. El motor no sabe nada del contenido del valor —para él es una cadena o una estructura, pero no algo que se pueda filtrar por su interior—.

Esa renuncia radical compra una cosa: velocidad. Redis mantiene todos los datos en memoria y responde en microsegundos, con cifras habituales de más de 100.000 operaciones por segundo en una máquina modesta.

Productos representativos: Redis (nuestra referencia), Valkey (su bifurcación de código abierto), Memcached (más simple aún), Amazon DynamoDB (clave-valor con capacidades documentales), etcd (configuración de clústeres).

La operación estrella de esta familia es la caducidad, y merece su propio apartado porque es lo que la diferencia de todo lo demás:

Por qué la caducidad es una función de primera clase. En una base relacional, "borrar lo que haya caducado" es una tarea programada que alguien tiene que escribir, vigilar y ejecutar; y mientras no se ejecuta, los datos caducados siguen ocupando espacio y ensuciando consultas. En Redis, la caducidad es una propiedad de la clave: el sistema la elimina solo, sin intervención. Para una caché —donde el dato antiguo no es un error, solo es inútil— y para sesiones —donde el dato debe desaparecer por seguridad—, esa diferencia es la razón misma de elegir la herramienta.

Redis no es solo cadenas. Su verdadero valor son las estructuras nativas, cada una con operaciones atómicas propias.

INCR es atómico: si mil socios abren la ficha a la vez, el contador acaba en mil exactos. Hacer esto en SQL requiere UPDATE ... SET n = n + 1 con su bloqueo de fila y su coste transaccional; aquí es una operación de microsegundos.

Un ranking siempre ordenado, actualizado en el momento y consultable en tiempo constante. La alternativa relacional es un ORDER BY COUNT(*) DESC sobre millones de filas cada vez que alguien mira la página de inicio.

Fortalezas: latencia de microsegundos, operaciones atómicas sobre estructuras, caducidad nativa, modelo trivial de entender y operar.

Límites: solo se consulta por clave (no hay "dame todo lo que tenga puntuación 5"); los datos viven en memoria, así que la RAM es el techo y el coste; la persistencia existe (instantáneas y registro de operaciones) pero está pensada para recuperación, no como almacén principal.

Encaje en BiblioRed: caché de las fichas y portadas del catálogo —evita ir a MongoDB en cada visita a una página muy visitada— y sesiones del portal —que deben caducar solas—. Nunca como fuente de verdad: si Redis se vacía, BiblioRed debe seguir funcionando, solo que más despacio. Esa es la prueba del algodón de una caché bien planteada.

El nombre "columnar" despista. Aquí no significa "orientada a columnas para análisis" (eso son ClickHouse o Amazon Redshift), sino familias de columnas: filas identificadas por una clave, agrupadas físicamente, donde cada fila puede tener columnas distintas y muy numerosas.

Las dos piezas que hay que entender son:

• Clave de partición: decide en qué nodo vive la fila. Todas las filas con la misma clave de partición están juntas en el mismo nodo y contiguas en disco.
• Clave de agrupamiento (clustering key): decide el orden de las filas dentro de la partición.

Esa contigüidad física es todo el secreto: leer "los 50 últimos eventos del socio 15" es una lectura secuencial de disco dentro de una sola partición en un solo nodo. No hay búsqueda dispersa, no hay JOIN, no hay coordinación entre máquinas.

Productos representativos: Apache Cassandra (nuestra referencia), ScyllaDB (compatible y más rápida), Apache HBase, Google Bigtable (el artículo de 2006 que originó la familia), Amazon Keyspaces.

Cassandra se consulta con CQL, que se escribe casi como SQL. Esa familiaridad es una trampa amable: la sintaxis es parecida, las reglas no.

Lee con cuidado esa clave primaria, porque contiene toda la lección:

• (socio_id), entre paréntesis propios, es la clave de partición. Todos los eventos de un socio viven juntos.
• fecha_evento y evento_id son las claves de agrupamiento: ordenan dentro de la partición, de más reciente a más antiguo.
• evento_id está ahí para desempatar: sin él, dos eventos en el mismo milisegundo se sobrescribirían.

Ahora, las reglas que rompen las expectativas de quien viene de SQL:

Cassandra se niega a ejecutar una consulta que no pueda resolver de forma eficiente. No hay WHERE libre sobre cualquier columna, no hay JOIN, no hay subconsultas y el ORDER BY solo puede seguir el orden de agrupamiento ya definido. Y ese error, lejos de ser una limitación molesta, es una de las mejores decisiones de diseño del producto: te avisa en desarrollo de que tu consulta no escala, en vez de dejar que lo descubras en producción con diez millones de filas.

De la restricción anterior sale el principio central de la familia:

En Cassandra no se diseña un modelo de datos y luego se consulta. Se parte de la lista de consultas y se crea una tabla por consulta, duplicando los datos tantas veces como haga falta.

Si BiblioRed también necesita "los términos más buscados de un día", no se añade un índice: se crea otra tabla, con otra clave de partición, alimentada con la misma escritura.

A alguien que viene del módulo 5 —que aún no hemos visto— esto le parecerá una herejía: es duplicación pura y dura. Y lo es, deliberadamente. En Cassandra el disco es barato, las escrituras son baratísimas y lo caro es la lectura ineficiente. Duplicar es la estrategia, no el error. Es la manifestación más extrema del principio de modelar a partir de las consultas que estudiaremos a fondo en la lección 03-03.

Fortalezas: escritura extraordinariamente rápida y sostenida; escalado lineal (el doble de nodos, aproximadamente el doble de capacidad); sin nodo primario —todos los nodos aceptan escrituras, así que no hay punto único de fallo—; replicación entre centros de datos integrada; caducidad por fila (TTL) nativa.

Límites: consultas rígidas, atadas al diseño de la clave; sin JOIN ni agregaciones libres; duplicación masiva que la aplicación debe mantener coherente; operación de un clúster no trivial; una consulta nueva puede exigir una tabla nueva y un reproceso de todo el histórico.

Encaje en BiblioRed: el registro de actividad. Diecisiete millones de eventos anuales, escritura continua, lectura por socio y rango de fechas, sin necesidad de integridad referencial y con valor que decae con el tiempo. Es el caso de uso canónico de la familia.

Ahora bien, seamos consecuentes con lo que dijimos en 03-01: 17 millones de documentos al año no justifican desplegar y operar un clúster Cassandra. MongoDB los absorbe sin dificultad con el patrón de agrupación que veremos en 03-03. Cassandra entraría en escena si BiblioRed pasara de una red municipal a una red autonómica con cientos de millones de eventos. Conocer el criterio es lo que te permite tomar esa decisión el día que llegue.

Tres elementos y ya está:

• Nodos: las entidades (un socio, un libro, un autor). Llevan una o más etiquetas (:Socio, :Libro) y propiedades.
• Relaciones: las conexiones entre nodos. Tienen tipo (LEYO, ESCRIBIO), dirección y también propiedades propias.
• Propiedades: pares clave-valor en nodos y relaciones.

La diferencia decisiva con el modelo relacional: en una base relacional, una relación se calcula en el momento de la consulta comparando valores de clave ajena; en una base de grafos, la relación está materializada como un puntero físico. Recorrerla no cuesta una búsqueda, cuesta seguir una referencia. A eso se le llama adyacencia sin índice, y es la razón de que los recorridos profundos sean tan rápidos.

Productos representativos: Neo4j (nuestra referencia), Amazon Neptune, ArangoDB, JanusGraph, Memgraph.

Cypher se lee dibujando. () es un nodo, -[]-> es una relación dirigida.

Aquí es donde la familia se gana el sueldo. La pregunta de negocio de BiblioRed es: "lectores como tú también leyeron". Formalmente: partiendo de un socio, ir a los libros que ha leído, de ahí a los otros socios que también los leyeron, y de ahí a los libros que esos socios leyeron y el nuestro no.

Son tres saltos en el grafo.

Fíjate en la primera línea del MATCH: es literalmente el dibujo del camino. Lees "yo leí un libro que fue leído por otro que leyó una sugerencia" siguiendo las flechas. Y WHERE NOT (yo)-[:LEYO]->(sugerencia) es un anti-patrón de camino: descarta lo que Marta ya ha leído, igual que el anti-join de la lección 02-04 descartaba filas con NOT EXISTS.

El equivalente SQL de esa consulta, sobre el esquema del módulo 2, sería aproximadamente:

Seis JOIN y una subconsulta correlacionada para tres saltos. Funciona, es correcto y con los datos de BiblioRed responderá rápido. El problema es la curva:

Cada salto en SQL añade uno o más JOIN, y el coste de cada JOIN depende del tamaño total de las tablas. En un grafo, cada salto sigue punteros desde los nodos que ya tienes: el coste depende del número de vecinos, no del tamaño de la base. Por eso la profundidad es gratis en un grafo y carísima en SQL.

Regla práctica: hasta dos saltos, SQL. A partir de tres, y sobre todo si la profundidad es variable, grafo.

Fortalezas: recorridos profundos a coste casi constante; el modelo se dibuja igual que se piensa; relaciones con propiedades propias; excelente para recomendaciones, detección de fraude, redes sociales, análisis de dependencias y árboles genealógicos u organizativos.

Límites: mala elección para agregaciones masivas sobre todos los nodos; escalado horizontal más difícil que en las otras familias (repartir un grafo entre máquinas sin cortar relaciones es un problema duro); ecosistema y talento más pequeños; suele ser una base secundaria alimentada desde la principal.

Encaje en BiblioRed: el motor de recomendaciones. Y con la misma honestidad de antes: BiblioRed no lo va a desplegar de momento; con 12.000 socios, una consulta SQL nocturna que precalcule recomendaciones y las deje en una colección de MongoDB resuelve el problema con una pieza menos que operar. Neo4j entra cuando las recomendaciones deban ser interactivas, personalizadas y de profundidad variable.

Fuera de las cuatro grandes hay tres familias que aparecen constantemente en arquitecturas reales. Las nombramos para que las reconozcas, sin desarrollarlas.

Motores de búsqueda (Elasticsearch, OpenSearch, Solr). Técnicamente son documentales, pero su motor está construido sobre un índice invertido —una estructura que va de cada palabra a los documentos que la contienen—. Eso les da relevancia ordenada, tolerancia a erratas, resaltado de coincidencias, sinónimos y facetas. Si BiblioRed quisiera un buscador del catálogo de calidad profesional, con sugerencias mientras se escribe y corrección de "Julo Verne" a "Julio Verne", esta sería la herramienta. MongoDB tiene índices de texto que cubren lo básico; un motor de búsqueda cubre lo exigente.

Series temporales (InfluxDB, TimescaleDB, Prometheus). Optimizadas para datos de la forma (instante, medida, valor) con escritura continua y consulta por ventanas. Comprimen extraordinariamente bien porque los valores contiguos se parecen, y traen agregación por intervalos y caducidad automática de los datos antiguos. TimescaleDB es una extensión de PostgreSQL, lo que la hace especialmente cómoda si ya tienes la relacional. El registro de actividad de BiblioRed también podría vivir aquí.

Vectoriales (Pinecone, Weaviate, Qdrant, pgvector). Guardan vectores numéricos —representaciones de significado generadas por modelos de lenguaje— y responden a "¿qué es lo más parecido a esto?" mediante búsqueda de vecinos próximos. Son la pieza que permitiría a BiblioRed responder a "quiero algo parecido a El mapa del tiempo pero más corto" sin que ninguna palabra coincida. Es la familia más joven y la de crecimiento más rápido.

Presta atención a la última rama: cuando ninguna de las cuatro familias encaja con claridad, la respuesta correcta es la relacional. No es un consuelo, es el criterio profesional. Lo desarrollaremos con más argumentos en la lección 03-04.

Uniendo lo decidido en 01-02 con lo que hemos visto aquí:

Dos bases de datos, cuatro necesidades cubiertas y un criterio escrito para cuando cada aplazamiento deje de ser razonable. Esa mezcla deliberada de motores se llama persistencia políglota; la nombraremos formalmente en la lección 03-04 y será el caso de estudio completo de la 08-03.

Error 1: usar una base de grafos porque el dominio "tiene relaciones". Todos los dominios tienen relaciones; para eso existe el modelo relacional. El grafo gana cuando el recorrido de profundidad variable es la consulta principal. Un par de JOIN no justifican otra base de datos.

Error 2: usar Redis como almacén principal. Es memoria: si el proceso cae y la persistencia no estaba bien configurada, se pierden datos. Regla: si vaciar Redis pierde información que no puedes reconstruir, lo estás usando mal.

Error 3: escribir CQL como si fuera SQL. La sintaxis engaña. En Cassandra no hay JOIN, el WHERE solo funciona sobre las columnas de la clave y ORDER BY está atado al orden de agrupamiento. Si te ves escribiendo ALLOW FILTERING para que una consulta funcione, el problema no es la consulta: es el modelo de datos.

Error 4: confundir "columnar" con "analítica". Cassandra (familias de columnas) está pensada para operación transaccional a gran escala. ClickHouse o Redshift (almacenamiento por columnas) están pensadas para análisis OLAP, que vimos en 01-02. Comparten adjetivo y no propósito.

Error 5: usar $lookup de MongoDB como si fuera un JOIN normal. Funciona, pero delata que el diseño de documentos no es el adecuado. En la lección siguiente lo veremos catalogado como anti-patrón.

Consejo 1: diseña las claves de Redis con una convención jerárquica. entidad:identificador:aspecto, por ejemplo catalogo:MAT-0331:ficha o sesion:8f3a2b1c. Sin esa disciplina, en seis meses nadie sabrá qué hay dentro de una clave llamada m331.

Consejo 2: en Cassandra, escribe la lista de consultas antes que el CREATE TABLE. Es el orden inverso al relacional y es obligatorio. Una consulta no prevista puede costar una tabla nueva y reprocesar todo el histórico.

Consejo 3: prueba las cuatro familias en Docker. Una tarde levantando Redis, Cassandra y Neo4j en contenedores y trasteando con veinte documentos enseña más que cualquier comparativa escrita. Y docker rm -f lo deja todo como estaba.

Consejo 4: cada base de datos añadida es una base de datos que operar. Copias de seguridad, actualizaciones, supervisión, permisos, un experto en el equipo. Antes de añadir la tercera, pregúntate si el problema no se resuelve con un índice en la primera.

BiblioRed quiere una página "Lo más valorado del mes" con, para cada libro, su puntuación media y su número de reseñas, considerando solo reseñas de abril de 2026 y mostrando únicamente los libros con media igual o superior a 4. Escribe la aggregation pipeline de MongoDB y su equivalente SQL, y explica a qué cláusula de SQL corresponde cada etapa.

Para cada una de estas cuatro necesidades nuevas de BiblioRed, elige la familia NoSQL más adecuada y justifícalo en dos o tres frases:

• (a) Un contador de "ejemplares disponibles ahora mismo" por sucursal, consultado en cada carga de la página de inicio y que debe ser rapidísimo.
• (b) Un histórico de todos los cambios de estado de cada ejemplar (disponible, prestado, reparación, baja), con unos 300.000 cambios al año, consultado como "historia de este ejemplar".
• (c) Detectar clubes de lectura informales: grupos de socios que coinciden repetidamente leyendo los mismos títulos en las mismas semanas.
• (d) Fichas de autor con biografía, foto, premios, enlaces externos y bibliografía, donde cada autor tiene un conjunto distinto de datos disponibles.

Diseña la tabla de Cassandra que resolvería esta consulta de BiblioRed: "muéstrame los últimos 20 eventos de actividad de una sucursal concreta, del más reciente al más antiguo". Escribe el CREATE TABLE, indica cuál es la clave de partición y cuál la de agrupamiento, y responde: ¿por qué esta tabla no puede responder también a "los últimos 20 eventos de un socio concreto"?

Solución 1

Solución 2

(a) Contador de disponibles → clave-valor (Redis). Acceso siempre por una clave conocida (disponibles:sucursal:2), lectura muy frecuente, valor diminuto y tolerancia a unos segundos de desfase. INCR/DECR son atómicos y responden en microsegundos, mientras que un COUNT(*) sobre ejemplares en cada carga de la página de inicio es un desperdicio evitable.

(b) Histórico de estados de ejemplares → columnar (Cassandra). Es una serie de eventos inmutables, con escritura continua y una consulta perfectamente conocida de antemano: por ejemplar y ordenada por fecha. Clave de partición ejemplar_id, clave de agrupamiento fecha descendente. Dicho esto, y siendo coherentes con el criterio del apartado 9: 300.000 cambios al año son pocos, y una tabla en PostgreSQL con un índice sobre (ejemplar_id, fecha) resolvería esto perfectamente durante muchos años.

(c) Detectar clubes de lectura informales → grafos (Neo4j). Buscar grupos de socios densamente conectados entre sí a través de los títulos que comparten es detección de comunidades, un problema clásico de grafos que requiere recorridos de profundidad variable. En SQL sería una autounión repetida de coste creciente; en Cypher es un patrón de camino, y Neo4j incluso trae algoritmos de comunidad ya implementados.

(d) Fichas de autor → documental (MongoDB). Estructura rica y heterogénea (un autor tiene tres premios y ninguna foto, otro cinco enlaces y una biografía larga), leída entera de una vez para pintar la ficha y consultada por su contenido ("autores nacidos en Vallmar"). Es exactamente el mismo argumento que llevó el catálogo a MongoDB, así que además reutiliza una base que BiblioRed ya opera.

Solución 3

• Clave de partición: (sucursal_id). Toda la actividad de una sucursal vive junta en el mismo nodo.
• Claves de agrupamiento: fecha_evento (descendente, para que los 20 últimos sean los 20 primeros de la partición) y evento_id (para desempatar eventos simultáneos).

Por qué no sirve para consultar por socio. Porque socio_id no forma parte de la clave: es una columna normal. Cassandra necesita conocer la clave de partición para saber a qué nodo ir; sin ella tendría que preguntar a todos los nodos y filtrar cada partición entera, que es precisamente lo que el motor se niega a hacer sin ALLOW FILTERING.

Y esto ilustra la regla central de la familia: una tabla por consulta. Si BiblioRed necesita las dos vistas, mantiene las dos tablas —actividad_por_socio y actividad_por_sucursal— y escribe cada evento en ambas. La duplicación no es un defecto del diseño: es el diseño.

Un aviso adicional que un buen diseñador vería: si una sucursal genera millones de eventos, su partición crecerá sin límite, y las particiones ilimitadas son un problema conocido en Cassandra. La solución habitual es una clave de partición compuesta que incluya el periodo, ((sucursal_id, mes), fecha_evento, evento_id), acotando cada partición a un mes. Es la misma idea que el patrón de agrupación (bucket) que estudiaremos en la lección siguiente.

Hemos recorrido las cuatro familias NoSQL con operación real:

• Documentales (MongoDB): documentos BSON anidados en colecciones sin esquema. Filtros con $gt, $in, $regex, $exists, $all; proyección con 1/0; sort, limit, skip; actualizaciones por partes con $set, $inc, $push, $addToSet y el operador posicional $; y la aggregation pipeline como equivalente del GROUP BY, donde $match es WHERE antes de agrupar y HAVING después, $group agrupa con _id como clave y $unwind despliega arrays. Encaje: reseñas y catálogo.
• Clave-valor (Redis): el motor no ve el interior del valor y a cambio responde en microsegundos. SET/GET/EXPIRE/TTL, más estructuras nativas —listas, conjuntos, conjuntos ordenados, hashes y contadores atómicos con INCR—. La caducidad es una función de primera clase, y por eso es la herramienta natural para caché y sesiones. Nunca como fuente de verdad.
• Columnares (Cassandra): filas anchas agrupadas por clave de partición y ordenadas por clave de agrupamiento; CQL se escribe como SQL pero prohíbe JOIN, subconsultas y WHERE libre —el error de ALLOW FILTERING es un aviso de diseño, no una molestia—. El principio es una tabla por consulta, con duplicación deliberada. Encaje: registros de actividad de altísimo volumen.
• Grafos (Neo4j): nodos, relaciones con propiedades y dirección, y Cypher, que se escribe dibujando el camino. La adyacencia sin índice hace que el coste de un salto dependa del número de vecinos y no del tamaño de la base: hasta dos saltos, SQL; a partir de tres, grafo. Encaje: el "lectores como tú también leyeron".
• Especializadas: motores de búsqueda con índice invertido (Elasticsearch), series temporales (InfluxDB, TimescaleDB) y vectoriales (pgvector, Qdrant) para búsqueda por similitud semántica.
• La decisión real de BiblioRed: PostgreSQL y MongoDB. Redis, Cassandra y Neo4j quedan aplazados con un criterio escrito de cuándo dejarían de estarlo. Cada base añadida es una base que operar.

Sabemos ya qué familias existen y cómo se opera cada una. Falta lo más difícil y lo que más se equivoca en la práctica: diseñar bien. En la lección 03-03, Modelado de Datos en NoSQL, invertiremos el orden que aprendimos en el mundo relacional —dejaremos de modelar el dominio para modelar a partir de las consultas—, definiremos el concepto de agregado, resolveremos la decisión central de embeber frente a referenciar con criterios explícitos, estudiaremos los patrones documentales (referencia extendida, subconjunto, agrupación, valor atípico, campo calculado) y sus anti-patrones, y entregaremos el diseño final y justificado de las colecciones de BiblioRed: resenas, catalogo y actividad.