db-reservas resol molt bé el problema que una plaça no es vengui dues vegades, però és una mala casa per al catàleg de tarifes de Contoso Airlines. Una tarifa «Flex Business Llarga Distància» té condicions de canvi, equipatge permès, acumulació de punts, penalitzacions per tram i restriccions per temporada; una tarifa «Bàsica Nacional» té quatre camps. Normalitzar això significa vint taules i consultes amb deu unions per respondre una cosa tan simple com «dona'm aquesta tarifa sencera». A més, el catàleg es llegeix milers de vegades per minut des de la web i des de l'API de Disponibilitat, s'escriu dues vegades al dia, i hi ha clients a Europa i a Amèrica esperant la resposta.

Aquest és exactament el terreny d'Azure Cosmos DB: una base de dades NoSQL distribuïda globalment, amb latència garantida d'un dígit en mil·lisegons, escalat elàstic i esquema flexible. Aquesta lliçó la desplega per al catàleg de tarifes i els perfils de passatger, i s'atura amb calma en les dues decisions que la gent pren malament: la clau de partició i el nivell de consistència.

Avís de cost important: Cosmos DB pot ser barat o caríssim segons com es configuri. Un contenidor amb 400 RU/s aprovisionades costa uns 23 € al mes i factura encara que ningú no el faci servir; activar escriptures multiregió multiplica el cost per regió. Per aprendre, fes servir el nivell gratuït (1000 RU/s i 25 GB sense cost, un compte per subscripció) o el mode sense servidor, i elimina el compte en acabar.

1. Quin problema resol que no resol una base relacional
2. Les API disponibles i quina triar
3. Model de recursos: compte, base de dades, contenidor i element
4. La clau de partició: la decisió més irreversible
5. Unitats de sol·licitud (RU/s) i models de capacitat
6. Els cinc nivells de consistència
7. Distribució global i escriptures multiregió
8. Desplegament amb Azure CLI
9. Documents de tarifes: inserció i consulta
10. Política d'indexació i temps de vida
11. La font de canvis com a base de la integració
12. Còpies de seguretat contínues i control de la despesa
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

Azure SQL Database escala verticalment: si necessites més, puges de nivell, fins que arribes al sostre de la màquina. Cosmos DB escala horitzontalment i de manera transparent: reparteix les dades entre particions físiques que el servei afegeix tot sol, sense que tu facis res, i pot replicar aquestes particions en tantes regions com vulguis amb un clic. Les diferències que importen a l'hora de decidir:

La conclusió no és que un sigui millor: és que responen preguntes diferents. Si la teva consulta creua entitats que ningú no havia previst, vols SQL. Si la teva consulta és «dona'm aquest document per la seva clau, ràpid, des de qualsevol continent, i que no m'importi quants milions n'hi hagi», vols Cosmos DB.

Cosmos DB és un motor amb diverses cares compatibles amb protocols existents. L'API es tria en crear el compte i no es pot canviar després:

Contoso tria l'API NoSQL per tres motius concrets: és un desenvolupament nou sense res a migrar, les funcionalitats noves arriben sempre primer a aquesta API, i l'equip del Diego Salas ja escriu consultes SQL, així que la sintaxi els resulta familiar des del primer dia.

La jerarquia té quatre nivells i cadascun decideix una cosa diferent:

• Compte (cosmos-contoso-tarifas-pro): el límit de l'API, de les regions, de la consistència predeterminada i de les claus d'accés. És el recurs que apareix al portal i a la factura.
• Base de dades (catalogo): agrupació lògica; pot tenir rendiment compartit per tots els seus contenidors.
• Contenidor (tarifas, perfiles): la unitat real d'escalat i distribució. Aquí es defineix la clau de partició, el rendiment i la política d'indexació. És l'equivalent conceptual a una taula, però sense esquema.
• Element: el document JSON. Cadascun té un id obligatori i el seu valor de clau de partició; la parella id + clau de partició identifica de manera única un element.

Cosmos DB agrupa els elements que comparteixen valor de clau de partició en una partició lògica, i reparteix aquestes particions lògiques entre particions físiques de fins a 50 GB i 10.000 RU/s. Tota l'escalabilitat depèn que aquest repartiment sigui uniforme. Una bona clau de partició compleix tres coses alhora:

1. Cardinalitat alta: molts valors diferents, perquè hi hagi moltes particions lògiques.
2. Repartiment uniforme de peticions i dades, sense valors molt més actius que altres.
3. Apareix a la majoria de les consultes, perquè aquestes es resolguin en una sola partició.

Aplicat al catàleg de tarifes de Contoso:

El cas de /fecha mereix aturar-s'hi, perquè és l'error més repetit del sector. Sembla raonable: les tarifes es consulten per data de vol. Però el 90 % de les consultes es refereixen als propers 30 dies, així que un grapat de particions lògiques rep gairebé tot el trànsit mentre la resta dorm. Aquest desequilibri s'anomena partició calenta: encara que el contenidor tingui 10.000 RU/s, cada partició física només pot fer servir la seva part, així que comencen a arribar errors de límit excedit (codi 429) amb el contenidor globalment ociós.

I per què és irreversible: la clau de partició d'un contenidor no es pot canviar. Corregir-la obliga a crear un contenidor nou i migrar totes les dades, amb l'aplicació escrivint als dos durant la transició. Per això aquesta decisió es pren escrivint abans les consultes, no després.

Si cap propietat no serveix tota sola, es fa servir una clau sintètica: concatenar dos camps ("BCN-CDG_2026-07") per pujar la cardinalitat mantenint el filtre habitual.

Una unitat de sol·licitud (RU) és la moneda de Cosmos DB: normalitza el cost de CPU, memòria i E/S de cada operació. La referència és que llegir per id un document d'1 KB costa 1 RU. Una escriptura d'aquest mateix document costa unes 5 RU, i una consulta que recorre molts documents pot costar centenars. El que contractes és un cabal: RU per segon.

El millor d'aquest model és que cada resposta et diu el que ha costat, a la capçalera x-ms-request-charge. És la manera d'optimitzar sense endevinar:

Aquestes dues xifres expliquen tota la història: la primera consulta porta la clau de partició i es resol en una de sola; la segona és una consulta entre particions i costa 17 vegades més. Per estimar el cabal necessari n'hi ha prou de multiplicar: si Contoso espera 900 lectures per segon de 3 RU cadascuna, necessita unes 2700 RU/s més marge per als pics.

Aquí és on el teorema CAP de la lliçó 03-01 es converteix en una casella de configuració. Cosmos DB ofereix cinc nivells, de més estricte a més relaxat, i es poden relaxar per petició des de l'SDK:

Aplicat a l'exemple de l'inventari de places: amb consistència eventual, dos clients a Madrid i a Bogotà podrien llegir alhora que queden 2 places quan en realitat ja només n'hi ha 1, i vendries un seient inexistent. Per això Contoso no posa l'inventari de places a Cosmos DB: viu a db-reservas amb la seva restricció CHECK, tal com es va decidir a 03-01. El que sí que va a Cosmos DB tolera perfectament la consistència de sessió, que és el nivell predeterminat i el millor equilibri per al 90 % de les aplicacions.

Afegir una regió a un compte de Cosmos DB replica totes les dades i permet que els clients llegeixin del punt més proper. Hi ha dues configuracions molt diferents en cost i en conseqüències:

• Escriptures en una sola regió: una regió és la d'escriptura i les altres són de lectura. Senzill, sense conflictes possibles i amb la meitat de cost.
• Escriptures multiregió: es pot escriure a qualsevol regió, amb latència d'escriptura mínima a totes. El preu és doble: costa més per RU i apareixen conflictes quan dues regions modifiquen el mateix document, que cal resoldre (per defecte guanya l'última escriptura segons una marca de temps, o amb un procediment propi).

La decisió de Contoso és coherent amb tot el curs: escriptura només a West Europe, lectura també a North Europe. Les tarifes les publica un únic equip des de Barcelona, així que les escriptures multiregió resoldrien un problema inexistent a canvi de duplicar la factura i afegir conflictes.

Per a l'entorn de desenvolupament, el compte es crea amb --enable-free-tier true (només un per subscripció) o en mode sense servidor amb --capabilities EnableServerless, que no admet autoescalat però només cobra el que es consumeix. Fixa't que --partition-key-path és l'únic paràmetre d'aquest script que no podràs canviar després.

Així és un document de tarifa. Tot el que en un model relacional serien cinc taules aquí està imbricat i es llegeix d'una sola vegada:

Aquest mateix document com a files relacionals exigiria taules de tarifes, condicions, equipatge i temporades, més tres unions per reconstruir-lo. Aquí és una lectura per clau: 1 RU.

I les consultes típiques, en el dialecte de l'API NoSQL, on c és cada document del contenidor:

El JOIN de la segona consulta no uneix contenidors —això no existeix a Cosmos DB—, sinó que desplega un array dins del mateix document. És la diferència conceptual que més costa a qui ve del món relacional.

Per defecte, Cosmos DB indexa totes les propietats de tots els documents. És còmode al principi i car quan el volum creix: cada índex consumeix RU a cada escriptura. En un contenidor amb escriptures intenses, afinar la política és dels ajustos que més diners estalvien.

S'indexa el que apareix a clàusules WHERE o ORDER BY i s'exclou el que només es llegeix com a part del document: les condicions i les temporades es retornen en llegir la tarifa, però ningú no hi filtra. En els perfils de passatger, Contoso aplica el mateix criteri i baixa el cost d'escriptura gairebé a la meitat.

El temps de vida (TTL) esborra automàticament els documents caducats sense consumir RU del teu contenidor, i és perfecte per a dades amb venciment natural:

Un document concret pot sobreescriure aquest valor amb la seva pròpia propietat ttl, o desactivar-lo amb ttl: -1.

La font de canvis (change feed) és un registre ordenat i persistent de totes les creacions i modificacions d'un contenidor, que es pot llegir en qualsevol moment des del principi o des d'un punt desat. Converteix Cosmos DB en el punt de partida d'arquitectures basades en esdeveniments, sense cues addicionals.

A Contoso resol tres necessitats reals amb el mateix mecanisme: quan canvia una tarifa, invalidar la memòria cau de la web i avisar el motor de preus; quan es crea un perfil de passatger, disparar-li el correu de benvinguda; i copiar cada canvi al llac de dades per a l'analítica del mòdul 3.6. L'habitual és consumir-la amb un desencadenador d'Azure Functions, que gestiona per tu el repartiment entre instàncies i el punt de lectura desat; es munta a la lliçó 06-03. La font de canvis no registra els esborrats: quan importa saber-los, es fa un esborrat lògic marcant el document i deixant que el TTL l'elimini després.

Cosmos DB ofereix dos modes de còpia de seguretat, i el triat al desplegament de l'apartat 8 és el bo:

• Periòdiques: instantànies cada cert interval, amb restauració a través d'un tiquet de suport. És el mode antic.
• Contínues (--backup-policy-type Continuous): restauració a qualsevol segon dels últims 7 o 30 dies, executada per tu mateix i a un compte nou, igual que la restauració a un moment donat d'Azure SQL Database.

Sobre la despesa, tres regles que eviten ensurts: el rendiment aprovisionat factura encara que ningú no llegeixi res, així que un contenidor de proves oblidat costa diners cada hora; cada regió afegida multiplica el cost de rendiment i d'emmagatzematge; i el mínim d'un contenidor amb autoescalat és el 10 % del màxim, de manera que fixar 40.000 RU/s de sostre implica pagar com a mínim 4000 RU/s sempre. Per deixar de pagar, az cosmosdb delete --name $COMPTE --resource-group $GRUP --yes, perquè un compte de Cosmos DB no es pot pausar.

• Triar la clau de partició sense escriure abans les consultes. És irreversible: corregir-la obliga a crear un altre contenidor i migrar-ho tot. Escriu primer les cinc consultes més freqüents.
• Fer servir la data com a clau de partició. Concentra el trànsit recent en poques particions i provoca errors 429 amb el contenidor gairebé ociós.
• Consultar sense la clau de partició. Una consulta entre particions pot costar 20 vegades més. Si és inevitable i freqüent, replanteja el model o crea una vista materialitzada amb la font de canvis.
• Deixar la indexació predeterminada en contenidors amb moltes escriptures. Indexar-ho tot encareix cada escriptura; exclou el que mai no es filtra.
• Posar l'inventari de places a Cosmos DB amb consistència eventual. Es venen seients que no existeixen. Aquesta dada pertany a la base relacional.
• Activar escriptures multiregió «per si de cas». Duplica el cost i porta conflictes que cal resoldre. Només té sentit si hi ha usuaris escrivint des de diversos continents.
• Consell: mira sempre el càrrec de RU (x-ms-request-charge) en desenvolupar una consulta nova. Optimitzar amb aquesta xifra al davant converteix l'afinació en una cosa mesurable.
• Consell: per aprendre, activa el nivell gratuït o el mode sense servidor. La diferència entre una factura de 0 € i una de 300 € és una casella marcada en crear el compte.

Contoso afegeix un contenidor embarques amb un document per passatger embarcat: uns 90 milions l'any, escrits en el moment de l'escaneig i consultats gairebé sempre com «tots els embarcaments d'un vol concret en una data».

1. Avalua com a clau de partició /aeropuerto, /fechaEmbarque, /numeroVuelo i una clau sintètica /vueloFecha ("CT1042_2026-07-14"), aplicant els tres criteris.
2. Tria'n una i justifica-la.
3. Quina política de TTL proposaries i per què?

Per a cada dada, tria nivell de consistència i justifica'l:

1. Preu d'una tarifa publicada, que canvia dues vegades al dia.
2. Preferència de seient del passatger, que ell mateix acaba de desar a la web.
3. Quota restant de places promocionals d'una campanya, amb tolerància d'uns segons.
4. Historial d'estats d'una tarifa, on l'ordre importa però el retard no.

Un contenidor perfiles de 5 milions de documents té 20.000 RU/s aprovisionades fixes, indexació predeterminada, clau de partició /pais i una consulta molt freqüent: SELECT * FROM c WHERE c.correo = @correo.

1. Identifica els tres problemes.
2. Proposa una correcció per a cadascun, indicant quina exigeix recrear el contenidor.
3. Quin model de capacitat recomanaries si el trànsit es concentra entre les 8 i les 22 h?

Solució 1:

2. /vueloFecha. És l'únic candidat que compleix els tres criteris alhora, i a més converteix la consulta més freqüent en una consulta de partició única, de cost mínim.
3. TTL d'uns 400 dies: l'explotació operativa necessita l'històric de la temporada i de l'any anterior; el més antic ja és al llac de dades per a analítica (lliçó 03-06) i mantenir-lo a Cosmos DB només hi afegeix cost d'emmagatzematge.

Solució 2:

1. Eventual: és la dada més tolerant del catàleg; que una rèplica mostri el preu anterior durant uns segons no té conseqüències, i és el nivell més barat i ràpid.
2. Sessió: el requisit és exactament «que el client vegi les seves pròpies escriptures». Amb eventual, el passatger podria desar el seu seient, recarregar la pàgina i veure l'anterior, que és la fallada que més tiquets de suport genera.
3. Obsolescència limitada, acotada per temps: garanteix que el desfasament no superi uns segons, prou per a una quota promocional on un petit excés és assumible.
4. Prefix coherent: no exigeix immediatesa, però impedeix veure els estats desordenats, que és l'única cosa que trencaria la lectura de l'historial.

Solució 3:

1. Problemes: (a) la clau de partició /pais té una cardinalitat baixíssima i un repartiment pèssim —Espanya concentraria la majoria dels perfils—; (b) la consulta per correo no porta la clau de partició, així que s'executa contra totes les particions i costa desenes de RU; (c) 20.000 RU/s aprovisionades fixes es paguen les 24 hores, incloses les de matinada, i la indexació predeterminada encareix cada escriptura.
2. Correccions: canviar la clau de partició a /correo (o /pasajeroId, si és el que fa servir la resta de l'aplicació), cosa que obliga a crear un contenidor nou i migrar les dades, ja que la clau és immutable; excloure de la indexació les propietats que mai no es filtren; i passar a autoescalat.
3. Autoescalat amb un màxim de 20.000 RU/s: a la nit baixarà fins a 2000 RU/s (el 10 % del màxim) i només pagarà el pic real de cada hora. Encara que la RU d'autoescalat costa un 50 % més, amb un perfil de 14 hores actives de 24 l'estalvi és clar.

Ja tens les dues meitats del cor de dades de Contoso Airlines: el transaccional a Azure SQL Database i el flexible i global a Azure Cosmos DB. Saps quin problema resol que no resol una base relacional —escalat horitzontal transparent, latència garantida d'un dígit en mil·lisegons i distribució global— i a què renuncies a canvi: unions entre entitats i transaccions més enllà d'una partició. Coneixes les cinc API i per què en un projecte nou es tria la de NoSQL, i manegues la jerarquia de compte, base de dades, contenidor i element sabent que el contenidor és on es decideix tot el que és important.

Sobretot, has treballat a fons la decisió que marca el destí d'un projecte: la clau de partició. En saps els tres criteris, per què /origenDestino funciona per al catàleg de tarifes i per què /fecha crea una partició calenta que dispara errors 429 amb el contenidor ociós, què és una clau sintètica i per què corregir-se costa una migració completa. Entens les unitats de sol·licitud, els quatre models de capacitat i com llegir el càrrec de RU de cada consulta per optimitzar amb dades i no amb intuïcions. Has triat nivell de consistència dada a dada amb la taula dels cinc nivells, entenent per què l'inventari de places es queda a la base relacional i per què el nivell de sessió és l'equilibri correcte per a gairebé tot. Has desplegat cosmos-contoso-tarifas-pro amb lectura a North Europe i escriptura només a West Europe, has inserit i consultat documents de tarifes veient la diferència de cost entre una consulta de partició única i una entre particions, has afinat la política d'indexació, aplicat TTL i conegut la font de canvis que alimentarà les integracions del mòdul 6, a més de les còpies contínues i les tres regles que eviten ensurts a la factura.

A la lliçó següent baixem de les decisions de disseny a un problema molt més terrenal i molt freqüent en qualsevol migració real. El portal de continguts i el blog corporatiu de Contoso són un WordPress que fa vuit anys que funciona sobre un MySQL instal·lat en un servidor del soterrani de Barcelona, amb la seva versió antiga, les seves còpies de seguretat en un disc USB i ningú que s'atreveixi a tocar-lo. Ningú no el reescriurà. A Azure Database for MySQL veuràs com es porta al núvol tal qual: servidor flexible, nivells de còmput, accés privat des de la xarxa virtual, paràmetres del servidor, rèpliques de lectura i, sobretot, la migració des del servidor propi amb mysqldump o amb el servei de migració de bases de dades, amb la seva llista de verificació i la seva finestra de manteniment acordada.