A la lliçó 01-02 vam veure les quatre famílies NoSQL des de molt amunt: què són i per a què serveixen, en un parell de paràgrafs cadascuna. A la lliçó anterior vam entendre el perquè del moviment i vam fer les primeres passes amb MongoDB. Ara toca baixar a terra.

"NoSQL" no és una tecnologia: és una etiqueta que agrupa quatre models de dades radicalment diferents entre si. Una base documental i una base de grafs s'assemblen tant com un full de càlcul i un mapa de metro. Dir "farem servir NoSQL" és tan poc informatiu com dir "farem servir un vehicle": la pregunta útil és quin, i per a què.

En aquesta lliçó recorrem les quatre famílies amb operació real i executable: documental amb MongoDB, clau-valor amb Redis, columnar amb Cassandra i grafs amb Neo4j. De cadascuna en veurem el model de dades, com es consulta, quins productes la representen, els seus punts forts, els seus límits i —el que enfilarà tota la lliçó— quina peça de BiblioRed li encaixa. Al final, una taula comparativa i un arbre de decisió per triar.

1. Les quatre famílies d'un cop d'ull
2. Bases documentals: MongoDB
3. Bases clau-valor: Redis
4. Bases columnars: Cassandra
5. Bases de grafs: Neo4j
6. Famílies especialitzades que aquest curs no torna a tractar
7. Taula comparativa de les quatre famílies
8. Arbre de decisió
9. El repartiment final de BiblioRed
10. Errors habituals i consells
11. Exercicis
12. Conclusió

Les quatre es poden ordenar per la riquesa de l'estructura que entenen: des de la que no entén res del valor que guarda fins a la que entén les relacions entre entitats.

I les quatre peces de BiblioRed que busquen acomodament:

• Ressenyes i catàleg enriquit → estructura rica, heterogènia, consultada per contingut → documental.
• Portades i sessions del portal → accés per clau, molt freqüent, amb caducitat → clau-valor.
• Registre d'activitat → altíssim volum d'escriptura, consulta per soci i rang de dates → columnar.
• Motor de recomanacions → recórrer relacions entre lectors i títols → grafs.

Un advertiment abans de començar, perquè aquesta lliçó no es llegeixi malament: BiblioRed no desplegarà quatre bases de dades. Desplegarà PostgreSQL i MongoDB. Redis, Cassandra i Neo4j apareixen aquí perquè són la millor manera d'entendre què resol cada família i perquè el dia que BiblioRed creixi, sabrà reconèixer el moment. Confondre "entendre una família" amb "instal·lar-la" és el camí més ràpid cap a una arquitectura ingovernable.

La unitat és el document: una estructura tipus JSON —guardada en BSON, com vam veure a 03-01— que admet imbricació i arrays. Els documents viuen en col·leccions, que no imposen esquema.

Tres propietats que defineixen la família:

1. El document és autocontingut. Tot el que l'aplicació necessita per mostrar una entitat hi cap a dins.
2. El motor entén l'interior. Pot filtrar, ordenar, indexar i agregar per qualsevol camp, fins i tot imbricat o dins d'un array. Això és el que separa una base documental d'una clau-valor que guardés JSON: per a la segona, el valor és una bossa de bytes opaca.
3. L'escriptura d'un document és atòmica, sense necessitat de transacció.

Productes representatius: MongoDB (el dominant i la nostra referència), Couchbase, Amazon DocumentDB, RavenDB, Firestore. I una nota important: PostgreSQL amb el tipus jsonb fa moltes d'aquestes coses sense deixar de ser relacional; ho compararem amb detall a la lliçó 03-04.

Continuem sobre la col·lecció ressenyes que vam crear a la lliçó anterior. Un filtre és un document; cada camp és una condició i diversos camps es combinen amb I lògic. Quan la condició no és una igualtat, el valor passa a ser un document amb un operador que comença per $.

$exists no té equivalent en SQL, i per una raó de fons: en una taula, la columna existeix sempre; com a molt val NULL. En una col·lecció, un camp pot senzillament no ser-hi. És la diferència entre "no té valor" i "aquesta entitat no té aquest concepte", i al món documental són dues coses diferents.

El segon argument de find és la projecció: quins camps s'han de retornar. 1 inclou, 0 exclou.

Regles de la projecció que convé memoritzar:

• No es poden barrejar inclusions i exclusions a la mateixa projecció, amb una única excepció: _id: 0 es pot combinar amb inclusions.
• L'_id es retorna sempre llevat que l'excloguis explícitament.
• .sort(), .limit() i .skip() s'encadenen sobre el cursor i equivalen a ORDER BY, LIMIT i OFFSET. A sort, 1 és ascendent i -1 descendent.

Aquí apareix una diferència gran respecte de SQL: a MongoDB no es reescriu el document sencer, s'apliquen operadors d'actualització sobre parts d'ell.

Atura't un segon en el que acaba de passar. El camp editada no existia en cap document de la col·lecció i ara existeix en un. No ha calgut cap ALTER TABLE, no hi ha hagut bloqueig i els altres tres documents no se n'han assabentat. Això és l'esquema flexible en la seva forma més pràctica.

L'operador posicional $ es refereix al primer element de l'array que ha coincidit amb el filtre. És la manera de modificar un element concret sense reescriure l'array sencer.

Compte amb un detall que ha causat incidents reals: deleteMany({}) amb filtre buit esborra la col·lecció sencera i no demana confirmació. En SQL, DELETE FROM taula fa el mateix, però almenys hi ha una transacció que es pot desfer amb ROLLBACK. Aquí, llevat que siguis dins d'una transacció explícita, no n'hi ha.

Les consultes de resum —el que a la lliçó 02-05 vam fer amb GROUP BY— es fan a MongoDB amb el marc d'agregació: una canalització d'etapes, on cada etapa rep documents, els transforma i els passa a la següent.

Objectiu: la puntuació mitjana i el nombre de ressenyes de cada llibre, ordenat de millor a pitjor.

Traducció etapa per etapa, que és la millor manera d'entendre-ho:

Dues convencions de sintaxi que cal fixar:

• "$camp" amb dòlar davant significa "el valor d'aquest camp", no la cadena literal. "$puntuacio" és el número; "puntuacio" seria el text.
• A $group, _id és la clau d'agrupació, no un identificador. _id: "$llibre_id" és literalment el GROUP BY llibre_id. Si hi poses _id: null, agrupes tot en una sola fila, que és el SELECT AVG(...) FROM taula sense GROUP BY.

Un exemple més, amb $unwind, que no té contrapartida neta en SQL: les etiquetes més usades.

$unwind ha "desplegat" la ressenya de la Núria, que tenia quatre etiquetes, en quatre documents idèntics tret de l'etiqueta. Després, $group compta. És exactament la feina que en el model relacional faria la taula intermèdia ressenyes_etiquetes que vam evitar en incrustar l'array.

Punts forts

• Estructures heterogènies i imbricades sense taules auxiliars ni columnes nul·les.
• L'esquema evoluciona sense migració.
• Lectura d'una entitat completa en un sol accés.
• Llenguatge de consulta ric: filtres, agregació, índexs sobre qualsevol camp.

Límits

• Creuar col·leccions ($lookup) és car i no ha de ser la norma.
• Sense integritat referencial declarativa.
• El límit de 16 MB per document acota el que pots incrustar.
• Les transaccions multidocument existeixen, però costen rendiment; el disseny ha de minimitzar-ne la necessitat.

Encaix a BiblioRed: les ressenyes i el catàleg enriquit. Són entitats autocontingudes, heterogènies, que es llegeixen senceres i canvien de forma amb freqüència. És l'encaix perfecte, i per això MongoDB és la base NoSQL que BiblioRed desplegarà de debò.

El model més simple que existeix: un diccionari gegant i distribuït. Una clau, un valor. El motor no sap res del contingut del valor —per a ell és una cadena o una estructura, però no una cosa que es pugui filtrar pel seu interior—.

Aquesta renúncia radical compra una cosa: velocitat. Redis manté totes les dades en memòria i respon en microsegons, amb xifres habituals de més de 100.000 operacions per segon en una màquina modesta.

Productes representatius: Redis (la nostra referència), Valkey (la seva bifurcació de codi obert), Memcached (encara més simple), Amazon DynamoDB (clau-valor amb capacitats documentals), etcd (configuració de clústers).

L'operació estrella d'aquesta família és la caducitat, i mereix un apartat propi perquè és el que la diferencia de tota la resta:

Per què la caducitat és una funció de primera classe. En una base relacional, "esborrar el que hagi caducat" és una tasca programada que algú ha d'escriure, vigilar i executar; i mentre no s'executa, les dades caducades continuen ocupant espai i embrutant consultes. A Redis, la caducitat és una propietat de la clau: el sistema l'elimina sol, sense intervenció. Per a una memòria cau —on la dada antiga no és un error, només és inútil— i per a sessions —on la dada ha de desaparèixer per seguretat—, aquesta diferència és la raó mateixa de triar l'eina.

Redis no és només cadenes. El seu veritable valor són les estructures natives, cadascuna amb operacions atòmiques pròpies.

INCR és atòmic: si mil socis obren la fitxa alhora, el comptador acaba en mil exactes. Fer això en SQL exigeix UPDATE ... SET n = n + 1 amb el seu bloqueig de fila i el seu cost transaccional; aquí és una operació de microsegons.

Un rànquing sempre ordenat, actualitzat al moment i consultable en temps constant. L'alternativa relacional és un ORDER BY COUNT(*) DESC sobre milions de files cada vegada que algú mira la pàgina d'inici.

Punts forts: latència de microsegons, operacions atòmiques sobre estructures, caducitat nativa, model trivial d'entendre i d'operar.

Límits: només es consulta per clau (no hi ha "dóna'm tot el que tingui puntuació 5"); les dades viuen en memòria, així que la RAM és el sostre i el cost; la persistència existeix (instantànies i registre d'operacions) però està pensada per a recuperació, no com a magatzem principal.

Encaix a BiblioRed: memòria cau de les fitxes i portades del catàleg —evita anar a MongoDB a cada visita d'una pàgina molt visitada— i sessions del portal —que han de caducar soles—. Mai com a font de veritat: si Redis es buida, BiblioRed ha de continuar funcionant, només que més a poc a poc. Aquesta és la prova del cotó d'una memòria cau ben plantejada.

El nom "columnar" despista. Aquí no significa "orientada a columnes per a anàlisi" (això són ClickHouse o Amazon Redshift), sinó famílies de columnes: files identificades per una clau, agrupades físicament, on cada fila pot tenir columnes diferents i molt nombroses.

Les dues peces que cal entendre són:

• Clau de partició: decideix a quin node viu la fila. Totes les files amb la mateixa clau de partició són juntes al mateix node i contigües al disc.
• Clau d'agrupament (clustering key): decideix l'ordre de les files dins de la partició.

Aquesta contigüitat física és tot el secret: llegir "els 50 últims esdeveniments del soci 15" és una lectura seqüencial de disc dins d'una sola partició en un sol node. No hi ha cerca dispersa, no hi ha JOIN, no hi ha coordinació entre màquines.

Productes representatius: Apache Cassandra (la nostra referència), ScyllaDB (compatible i més ràpida), Apache HBase, Google Bigtable (l'article del 2006 que va originar la família), Amazon Keyspaces.

Cassandra es consulta amb CQL, que s'escriu gairebé com SQL. Aquesta familiaritat és un parany amable: la sintaxi és semblant, les regles no.

Llegeix amb cura aquesta clau primària, perquè conté tota la lliçó:

• (soci_id), entre parèntesis propis, és la clau de partició. Tots els esdeveniments d'un soci viuen junts.
• data_esdeveniment i esdeveniment_id són les claus d'agrupament: ordenen dins de la partició, de més recent a més antic.
• esdeveniment_id hi és per desempatar: sense ell, dos esdeveniments del mateix mil·lisegon se sobreescriurien.

Ara, les regles que trenquen les expectatives de qui ve de SQL:

Cassandra es nega a executar una consulta que no pugui resoldre de manera eficient. No hi ha WHERE lliure sobre qualsevol columna, no hi ha JOIN, no hi ha subconsultes i l'ORDER BY només pot seguir l'ordre d'agrupament ja definit. I aquest error, lluny de ser una limitació molesta, és una de les millors decisions de disseny del producte: t'avisa en desenvolupament que la teva consulta no escala, en comptes de deixar que ho descobreixis en producció amb deu milions de files.

De la restricció anterior surt el principi central de la família:

A Cassandra no es dissenya un model de dades i després es consulta. Es parteix de la llista de consultes i es crea una taula per consulta, duplicant les dades tantes vegades com calgui.

Si BiblioRed també necessita "els termes més cercats d'un dia", no s'hi afegeix un índex: es crea una altra taula, amb una altra clau de partició, alimentada amb la mateixa escriptura.

A algú que ve del mòdul 5 —que encara no hem vist— això li semblarà una heretgia: és duplicació pura i dura. I ho és, deliberadament. A Cassandra el disc és barat, les escriptures són baratíssimes i el que és car és la lectura ineficient. Duplicar és l'estratègia, no l'error. És la manifestació més extrema del principi de modelar a partir de les consultes que estudiarem a fons a la lliçó 03-03.

Punts forts: escriptura extraordinàriament ràpida i sostinguda; escalat lineal (el doble de nodes, aproximadament el doble de capacitat); sense node primari —tots els nodes accepten escriptures, així que no hi ha punt únic de fallada—; replicació entre centres de dades integrada; caducitat per fila (TTL) nativa.

Límits: consultes rígides, lligades al disseny de la clau; sense JOIN ni agregacions lliures; duplicació massiva que l'aplicació ha de mantenir coherent; operació d'un clúster no trivial; una consulta nova pot exigir una taula nova i un reprocés de tot l'històric.

Encaix a BiblioRed: el registre d'activitat. Disset milions d'esdeveniments anuals, escriptura contínua, lectura per soci i rang de dates, sense necessitat d'integritat referencial i amb valor que decau amb el temps. És el cas d'ús canònic de la família.

Ara bé, siguem conseqüents amb el que vam dir a 03-01: 17 milions de documents l'any no justifiquen desplegar i operar un clúster Cassandra. MongoDB els absorbeix sense dificultat amb el patró d'agrupació que veurem a 03-03. Cassandra entraria en escena si BiblioRed passés d'una xarxa municipal a una xarxa autonòmica amb centenars de milions d'esdeveniments. Conèixer el criteri és el que et permet prendre aquesta decisió el dia que arribi.

Tres elements i prou:

• Nodes: les entitats (un soci, un llibre, un autor). Porten una o més etiquetes (:Soci, :Llibre) i propietats.
• Relacions: les connexions entre nodes. Tenen tipus (VA_LLEGIR, VA_ESCRIURE), direcció i també propietats pròpies.
• Propietats: parells clau-valor a nodes i relacions.

La diferència decisiva amb el model relacional: en una base relacional, una relació es calcula en el moment de la consulta comparant valors de clau forana; en una base de grafs, la relació està materialitzada com un punter físic. Recórrer-la no costa una cerca, costa seguir una referència. A això se'n diu adjacència sense índex, i és la raó que els recorreguts profunds siguin tan ràpids.

Productes representatius: Neo4j (la nostra referència), Amazon Neptune, ArangoDB, JanusGraph, Memgraph.

Cypher es llegeix dibuixant. () és un node, -[]-> és una relació dirigida.

Aquí és on la família es guanya el sou. La pregunta de negoci de BiblioRed és: "lectors com tu també van llegir". Formalment: partint d'un soci, anar als llibres que ha llegit, d'aquí als altres socis que també els van llegir, i d'aquí als llibres que aquells socis van llegir i el nostre no.

Són tres salts al graf.

Fixa't en la primera línia del MATCH: és literalment el dibuix del camí. Llegeixes "jo vaig llegir un llibre que va ser llegit per un altre que va llegir un suggeriment" seguint les fletxes. I WHERE NOT (jo)-[:VA_LLEGIR]->(suggeriment) és un antipatró de camí: descarta el que la Marta ja ha llegit, igual que l'anti-join de la lliçó 02-04 descartava files amb NOT EXISTS.

L'equivalent SQL d'aquesta consulta, sobre l'esquema del mòdul 2, seria aproximadament:

Sis JOIN i una subconsulta correlacionada per a tres salts. Funciona, és correcte i amb les dades de BiblioRed respondrà ràpid. El problema és la corba:

Cada salt en SQL afegeix un o més JOIN, i el cost de cada JOIN depèn de la mida total de les taules. En un graf, cada salt segueix punters des dels nodes que ja tens: el cost depèn del nombre de veïns, no de la mida de la base. Per això la profunditat és gratis en un graf i caríssima en SQL.

Regla pràctica: fins a dos salts, SQL. A partir de tres, i sobretot si la profunditat és variable, graf.

Punts forts: recorreguts profunds a cost gairebé constant; el model es dibuixa igual que es pensa; relacions amb propietats pròpies; excel·lent per a recomanacions, detecció de frau, xarxes socials, anàlisi de dependències i arbres genealògics o organitzatius.

Límits: mala elecció per a agregacions massives sobre tots els nodes; escalat horitzontal més difícil que a les altres famílies (repartir un graf entre màquines sense tallar relacions és un problema dur); ecosistema i talent més petits; sol ser una base secundària alimentada des de la principal.

Encaix a BiblioRed: el motor de recomanacions. I amb la mateixa honestedat d'abans: BiblioRed no el desplegarà de moment; amb 12.000 socis, una consulta SQL nocturna que precalculi recomanacions i les deixi en una col·lecció de MongoDB resol el problema amb una peça menys per operar. Neo4j entra quan les recomanacions hagin de ser interactives, personalitzades i de profunditat variable.

Fora de les quatre grans hi ha tres famílies que apareixen constantment en arquitectures reals. Les anomenem perquè les reconeguis, sense desenvolupar-les.

Motors de cerca (Elasticsearch, OpenSearch, Solr). Tècnicament són documentals, però el seu motor està construït sobre un índex invertit —una estructura que va de cada paraula als documents que la contenen—. Això els dóna rellevància ordenada, tolerància a errades, ressaltat de coincidències, sinònims i facetes. Si BiblioRed volgués un cercador del catàleg de qualitat professional, amb suggeriments mentre s'escriu i correcció de "Jules Vern" a "Jules Verne", aquesta seria l'eina. MongoDB té índexs de text que cobreixen el bàsic; un motor de cerca cobreix l'exigent.

Sèries temporals (InfluxDB, TimescaleDB, Prometheus). Optimitzades per a dades de la forma (instant, mesura, valor) amb escriptura contínua i consulta per finestres. Comprimeixen extraordinàriament bé perquè els valors contigus s'assemblen, i porten agregació per intervals i caducitat automàtica de les dades antigues. TimescaleDB és una extensió de PostgreSQL, cosa que la fa especialment còmoda si ja tens la relacional. El registre d'activitat de BiblioRed també podria viure aquí.

Vectorials (Pinecone, Weaviate, Qdrant, pgvector). Guarden vectors numèrics —representacions de significat generades per models de llenguatge— i responen a "què és el més semblant a això?" mitjançant cerca de veïns propers. Són la peça que permetria a BiblioRed respondre a "vull una cosa semblant a El mapa del temps però més curta" sense que cap paraula coincideixi. És la família més jove i la de creixement més ràpid.

Presta atenció a l'última branca: quan cap de les quatre famílies no encaixa amb claredat, la resposta correcta és la relacional. No és un consol, és el criteri professional. Ho desenvoluparem amb més arguments a la lliçó 03-04.

Unint el que es va decidir a 01-02 amb el que hem vist aquí:

Dues bases de dades, quatre necessitats cobertes i un criteri escrit per quan cada ajornament deixi de ser raonable. Aquesta barreja deliberada de motors s'anomena persistència poliglota; l'anomenarem formalment a la lliçó 03-04 i serà el cas d'estudi complet de la 08-03.

Error 1: fer servir una base de grafs perquè el domini "té relacions". Tots els dominis tenen relacions; per això existeix el model relacional. El graf guanya quan el recorregut de profunditat variable és la consulta principal. Un parell de JOIN no justifiquen una altra base de dades.

Error 2: fer servir Redis com a magatzem principal. És memòria: si el procés cau i la persistència no estava ben configurada, es perden dades. Regla: si buidar Redis fa perdre informació que no pots reconstruir, l'estàs fent servir malament.

Error 3: escriure CQL com si fos SQL. La sintaxi enganya. A Cassandra no hi ha JOIN, el WHERE només funciona sobre les columnes de la clau i ORDER BY està lligat a l'ordre d'agrupament. Si et veus escrivint ALLOW FILTERING perquè una consulta funcioni, el problema no és la consulta: és el model de dades.

Error 4: confondre "columnar" amb "analítica". Cassandra (famílies de columnes) està pensada per a operació transaccional a gran escala. ClickHouse o Redshift (emmagatzematge per columnes) estan pensades per a anàlisi OLAP, que vam veure a 01-02. Comparteixen adjectiu i no propòsit.

Error 5: fer servir $lookup de MongoDB com si fos un JOIN normal. Funciona, però delata que el disseny de documents no és l'adequat. A la lliçó següent el veurem catalogat com a antipatró.

Consell 1: dissenya les claus de Redis amb una convenció jeràrquica. entitat:identificador:aspecte, per exemple cataleg:MAT-0331:fitxa o sessio:8f3a2b1c. Sense aquesta disciplina, d'aquí a sis mesos ningú no sabrà què hi ha dins d'una clau anomenada m331.

Consell 2: a Cassandra, escriu la llista de consultes abans que el CREATE TABLE. És l'ordre invers al relacional i és obligatori. Una consulta no prevista pot costar una taula nova i reprocessar tot l'històric.

Consell 3: prova les quatre famílies en Docker. Una tarda aixecant Redis, Cassandra i Neo4j en contenidors i trastejant amb vint documents ensenya més que qualsevol comparativa escrita. I docker rm -f ho deixa tot com estava.

Consell 4: cada base de dades afegida és una base de dades per operar. Còpies de seguretat, actualitzacions, supervisió, permisos, un expert a l'equip. Abans d'afegir la tercera, pregunta't si el problema no es resol amb un índex a la primera.

BiblioRed vol una pàgina "El més valorat del mes" amb, per a cada llibre, la seva puntuació mitjana i el seu nombre de ressenyes, considerant només ressenyes d'abril del 2026 i mostrant únicament els llibres amb mitjana igual o superior a 4. Escriu l'aggregation pipeline de MongoDB i el seu equivalent SQL, i explica a quina clàusula de SQL correspon cada etapa.

Per a cadascuna d'aquestes quatre necessitats noves de BiblioRed, tria la família NoSQL més adequada i justifica-ho en dues o tres frases:

• (a) Un comptador d'"exemplars disponibles ara mateix" per sucursal, consultat a cada càrrega de la pàgina d'inici i que ha de ser rapidíssim.
• (b) Un històric de tots els canvis d'estat de cada exemplar (disponible, prestat, reparacio, baixa), amb uns 300.000 canvis l'any, consultat com a "història d'aquest exemplar".
• (c) Detectar clubs de lectura informals: grups de socis que coincideixen repetidament llegint els mateixos títols les mateixes setmanes.
• (d) Fitxes d'autor amb biografia, foto, premis, enllaços externs i bibliografia, on cada autor té un conjunt diferent de dades disponibles.

Dissenya la taula de Cassandra que resoldria aquesta consulta de BiblioRed: "mostra'm els últims 20 esdeveniments d'activitat d'una sucursal concreta, del més recent al més antic". Escriu el CREATE TABLE, indica quina és la clau de partició i quina la d'agrupament, i respon: per què aquesta taula no pot respondre també a "els últims 20 esdeveniments d'un soci concret"?

Solució 1

Solució 2

(a) Comptador de disponibles → clau-valor (Redis). Accés sempre per una clau coneguda (disponibles:sucursal:2), lectura molt freqüent, valor diminut i tolerància a uns segons de desfasament. INCR/DECR són atòmics i responen en microsegons, mentre que un COUNT(*) sobre exemplars a cada càrrega de la pàgina d'inici és un malbaratament evitable.

(b) Històric d'estats d'exemplars → columnar (Cassandra). És una sèrie d'esdeveniments immutables, amb escriptura contínua i una consulta perfectament coneguda per endavant: per exemplar i ordenada per data. Clau de partició exemplar_id, clau d'agrupament data descendent. Dit això, i sent coherents amb el criteri de l'apartat 9: 300.000 canvis l'any són pocs, i una taula a PostgreSQL amb un índex sobre (exemplar_id, data) resoldria això perfectament durant molts anys.

(c) Detectar clubs de lectura informals → grafs (Neo4j). Buscar grups de socis densament connectats entre si a través dels títols que comparteixen és detecció de comunitats, un problema clàssic de grafs que exigeix recorreguts de profunditat variable. En SQL seria una autounió repetida de cost creixent; en Cypher és un patró de camí, i Neo4j fins i tot porta algoritmes de comunitat ja implementats.

(d) Fitxes d'autor → documental (MongoDB). Estructura rica i heterogènia (un autor té tres premis i cap foto, un altre cinc enllaços i una biografia llarga), llegida sencera d'una vegada per pintar la fitxa i consultada pel seu contingut ("autors nascuts a Vallmar"). És exactament el mateix argument que va portar el catàleg a MongoDB, així que a més reutilitza una base que BiblioRed ja opera.

Solució 3

• Clau de partició: (sucursal_id). Tota l'activitat d'una sucursal viu junta al mateix node.
• Claus d'agrupament: data_esdeveniment (descendent, perquè els 20 últims siguin els 20 primers de la partició) i esdeveniment_id (per desempatar esdeveniments simultanis).

Per què no serveix per consultar per soci. Perquè soci_id no forma part de la clau: és una columna normal. Cassandra necessita conèixer la clau de partició per saber a quin node ha d'anar; sense ella hauria de preguntar a tots els nodes i filtrar cada partició sencera, que és precisament el que el motor es nega a fer sense ALLOW FILTERING.

I això il·lustra la regla central de la família: una taula per consulta. Si BiblioRed necessita les dues vistes, manté les dues taules —activitat_per_soci i activitat_per_sucursal— i escriu cada esdeveniment a totes dues. La duplicació no és un defecte del disseny: és el disseny.

Un avís addicional que un bon dissenyador veuria: si una sucursal genera milions d'esdeveniments, la seva partició creixerà sense límit, i les particions il·limitades són un problema conegut a Cassandra. La solució habitual és una clau de partició composta que inclogui el període, ((sucursal_id, mes), data_esdeveniment, esdeveniment_id), acotant cada partició a un mes. És la mateixa idea que el patró d'agrupació (bucket) que estudiarem a la lliçó següent.

Hem recorregut les quatre famílies NoSQL amb operació real:

• Documentals (MongoDB): documents BSON imbricats en col·leccions sense esquema. Filtres amb $gt, $in, $regex, $exists, $all; projecció amb 1/0; sort, limit, skip; actualitzacions per parts amb $set, $inc, $push, $addToSet i l'operador posicional $; i l'aggregation pipeline com a equivalent del GROUP BY, on $match és WHERE abans d'agrupar i HAVING després, $group agrupa amb _id com a clau i $unwind desplega arrays. Encaix: ressenyes i catàleg.
• Clau-valor (Redis): el motor no veu l'interior del valor i a canvi respon en microsegons. SET/GET/EXPIRE/TTL, més estructures natives —llistes, conjunts, conjunts ordenats, hashes i comptadors atòmics amb INCR—. La caducitat és una funció de primera classe, i per això és l'eina natural per a memòria cau i sessions. Mai com a font de veritat.
• Columnars (Cassandra): files amples agrupades per clau de partició i ordenades per clau d'agrupament; CQL s'escriu com SQL però prohibeix JOIN, subconsultes i WHERE lliure —l'error d'ALLOW FILTERING és un avís de disseny, no una molèstia—. El principi és una taula per consulta, amb duplicació deliberada. Encaix: registres d'activitat d'altíssim volum.
• Grafs (Neo4j): nodes, relacions amb propietats i direcció, i Cypher, que s'escriu dibuixant el camí. L'adjacència sense índex fa que el cost d'un salt depengui del nombre de veïns i no de la mida de la base: fins a dos salts, SQL; a partir de tres, graf. Encaix: el "lectors com tu també van llegir".
• Especialitzades: motors de cerca amb índex invertit (Elasticsearch), sèries temporals (InfluxDB, TimescaleDB) i vectorials (pgvector, Qdrant) per a cerca per similitud semàntica.
• La decisió real de BiblioRed: PostgreSQL i MongoDB. Redis, Cassandra i Neo4j queden ajornats amb un criteri escrit de quan deixarien d'estar-ho. Cada base afegida és una base per operar.

Ja sabem quines famílies existeixen i com s'opera cadascuna. Falta el més difícil i el que més s'equivoca a la pràctica: dissenyar bé. A la lliçó 03-03, Modelatge de Dades en NoSQL, invertirem l'ordre que vam aprendre al món relacional —deixarem de modelar el domini per modelar a partir de les consultes—, definirem el concepte d'agregat, resoldrem la decisió central d'incrustar enfront de referenciar amb criteris explícits, estudiarem els patrons documentals (referència estesa, subconjunt, agrupació, valor atípic, camp calculat) i els seus antipatrons, i lliurarem el disseny final i justificat de les col·leccions de BiblioRed: ressenyes, cataleg i activitat.