Microsoft AZ-204: Azure Cosmos DB — Guida allo studio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Developer Associate AZ-204 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure Cosmos DB è un database multimodello, distribuito a livello globale e completamente gestito, progettato per applicazioni a bassa latenza e scalabili in modo elastico. Espone molteplici API su un motore di archiviazione e replica partizionato comune, fornisce cinque livelli di coerenza regolabili e offre SLA completi per disponibilità, latenza, throughput e coerenza. I dati sono organizzati in account, database e contenitori (o collection/tabelle/grafi a seconda dell’API). I contenitori sono partizionati orizzontalmente e scalati tramite una chiave di partizione, e tutte le operazioni sono misurate in Request Unit (RU), una valuta normalizzata che astrae CPU, IOPS e memoria.

API e Programmabilità

Cosmos DB supporta diverse API compatibili a livello di protocollo (wire-compatible), così da poter utilizzare SDK e driver nativi senza riscrivere il modello dei dati:

API SQL (Core): L’impostazione predefinita consigliata per i nuovi carichi di lavoro. Archivia documenti JSON con query ricche simili a SQL (SELECT, WHERE, ORDER BY, JOIN all’interno di un documento, aggregazioni) e UDF deterministiche per predicati/proiezioni calcolate. La logica di business lato server viene eseguita come stored procedure JavaScript e trigger pre/post all’interno di una singola partizione logica, abilitando transazioni ACID su più elementi che condividono la chiave di partizione. TransactionalBatch fornisce operazioni su più elementi in una partizione. Le letture puntuali (id + chiave di partizione) sono le più efficienti in termini di RU. Creare un client .NET con codice come:

undefined

API MongoDB: Compatibile a livello di protocollo con MongoDB, consentendo l’uso di driver e strumenti standard di MongoDB (ad esempio, mongodump/mongorestore per le migrazioni). È possibile utilizzare le funzionalità di MongoDB supportate dalla distribuzione, dalla scalabilità automatica e dagli SLA di Cosmos DB. Le transazioni multi-documento sono supportate all’interno della stessa partizione logica; per un’atomicità rigorosa per utente, utilizzare una collection non partizionata (unsharded) o partizionare per una proprietà come lo username, in modo che i documenti correlati condividano una partizione.
API Cassandra: Compatibile con i driver Apache Cassandra e CQL. Ideale per pattern di accesso a colonna larga (wide-column) e time-series. Si ottiene una distribuzione globale automatica e una scalabilità basata su RU invece della gestione dei nodi.
API Gremlin: Modello di grafo di proprietà con query e attraversamenti Gremlin di TinkerPop. Il partizionamento è essenziale per distribuire vertici e archi per attraversamenti scalabili.
API Table: Modello chiave-valore con SDK e semantica compatibili con Azure Table Storage, ma supportato dalla distribuzione globale, dal throughput in RU e dagli indici a latenza inferiore di Cosmos DB.

Le operazioni SDK comuni a tutte le API includono CRUD, concorrenza ottimistica con ETag, operazioni di upsert, script lato server (stored procedure, trigger) e UDF (API SQL). Le query sono parametrizzate per ridurre le RU e migliorare la sicurezza. Le operazioni bulk e le API di streaming minimizzano l’overhead del client e i costi in RU per l’ingestion ad alto throughput.

Coerenza, Indicizzazione e Semantica delle Query

Cosmos DB offre cinque livelli di coerenza ben definiti per account (sovrascrivibili per richiesta in molti SDK):

Forte (Strong): Linearizzabilità: le letture vedono globalmente la scrittura committed più recente. Massimizza la correttezza, limita la latenza di scrittura e la flessibilità regionale, e non è disponibile con le scritture multi-regione abilitate.
Obsolescenza Limitata (Bounded Staleness): Le letture sono in ritardo rispetto alle scritture di al massimo K versioni o un tempo T. Garantisce un ordinamento monotonico di lettura e scrittura; un buon compromesso per letture distribuite a livello globale che tollerano un ritardo limitato.
Sessione (Session) (predefinito): Per sessione, garantisce read-your-writes, write-follows-reads e letture monotoniche. Ogni client mantiene un token di sessione; condividerlo tra i nodi (ad esempio, tramite le opzioni di richiesta nell’SDK) preserva il comportamento read-your-writes su tali nodi.
Prefisso Coerente (Consistent Prefix): Le letture non osservano mai scritture fuori ordine, ma potrebbero vedere un prefisso del log.
Finale (Eventual): Massima disponibilità e latenza più bassa senza garanzie di ordinamento.

L’indicizzazione è automatica e coerente per impostazione predefinita per l’API SQL. Ogni elemento e proprietà viene indicizzato senza gestione dello schema, quindi le scritture aggiornano l’indice immediatamente (modalità di indicizzazione Consistent). È possibile perfezionare la policy di indicizzazione per:

Escludere percorsi (path) di grandi dimensioni o con scritture intensive per ridurre i costi di scrittura in RU.
Aggiungere indici compositi per supportare in modo efficiente ORDER BY su più proprietà e query che combinano filtri e ordinamenti su proprietà diverse.
Aggiungere indici spaziali per i tipi GeoJSON (Point, LineString, Polygon, MultiPolygon) ed eseguire query con funzioni spaziali come ST_DISTANCE, ST_WITHIN e ST_INTERSECTS. La modalità di indicizzazione può anche essere impostata su None per contenitori ottimizzati per la scrittura che vengono letti solo tramite id/chiave di partizione. Diverse API espongono l’indicizzazione tramite i loro paradigmi nativi (ad es., costrutti dei driver MongoDB e Cassandra), ma tutte sfruttano il motore di indicizzazione sottostante di Cosmos.

Prestare attenzione alle dimensioni degli elementi e alla forma delle query. L’API SQL impone un limite alla dimensione degli elementi (ad esempio, 2 MB), e le query cross-partizione, le proiezioni di grandi dimensioni e i predicati complessi aumentano il consumo di RU. Utilizzare proiezioni selettive, filtri appropriati e query consapevoli della partizione per minimizzare il costo in RU.

Partizionamento e Throughput (RU)

Cosmos DB separa le partizioni logiche da quelle fisiche:

Le partizioni logiche raggruppano gli elementi in base al valore di una chiave di partizione. Tutti gli elementi che condividono la stessa chiave partecipano insieme a batch transazionali e script lato server.
Le partizioni fisiche sono gestite dal servizio e ospitano molte partizioni logiche. Il throughput (RU) e lo storage sono distribuiti tra le partizioni fisiche; partizioni logiche “calde” (hot) possono creare un collo di bottiglia nel throughput di una partizione fisica.

Scegliere una chiave di partizione efficace con alta cardinalità e una distribuzione uniforme degli accessi nel tempo. Le chiavi valide sono correlate al percorso di accesso primario (ad esempio, userId, deviceId, tenantId o orderId). Evitare chiavi a bassa cardinalità o basate su intervalli di tempo (time-bucketed) che causano sbilanciamento (skew) (ad esempio, country, status o day). Quando nessuna singola proprietà è adatta:

Utilizzare una chiave sintetica che concatena più proprietà.
Aggiungere un suffisso casuale o hashato per distribuire il carico tra le partizioni, preservando la capacità di interrogazione tramite prefisso o mantenendo una tabella di ricerca (lookup).
Considerare le chiavi di partizione gerarchiche per combinare più proprietà, consentendo una migliore distribuzione e query efficienti sui prefissi.

Modelli di throughput:

Throughput con provisioning (Provisioned throughput): Riserva RU/s su un contenitore o un database (condiviso dai contenitori figli). Prestazioni prevedibili con stabilità dei costi. Scalabilità manuale o tramite API/CLI.
Scalabilità automatica (Autoscale): Imposta un valore massimo di RU/s; Cosmos DB scala in modo elastico tra il 10% e il 100% di tale massimo in base al carico. La fatturazione si basa sul valore orario più alto di RU utilizzate; eccellente per carichi di lavoro variabili e picchi sconosciuti.
Serverless: Nessuna RU/s con provisioning; si paga per il consumo di RU di ogni operazione. Ideale per sviluppo, carichi di lavoro con picchi improvvisi (spiky) o a basso throughput senza una baseline prevedibile.

Le tecniche di ottimizzazione delle RU includono letture puntuali (point read) tramite id+chiave di partizione, query con parametri, proiezioni selettive, denormalizzazione per ridurre i pattern simili a JOIN e l’uso del change feed per viste derivate anziché query complesse su più contenitori. Utilizzare gli ETag con If-Match per il controllo della concorrenza al fine di evitare tentativi di ripetizione (retry) costosi in termini di RU. Monitorare le metriche delle RU e il throttling (HTTP 429) e implementare policy di retry con jitter negli SDK.

Distribuzione globale e feed di modifiche

La distribuzione multi-regionale chiavi in mano di Cosmos DB consente di aggiungere o rimuovere regioni in qualsiasi momento. Tutte le regioni sono leggibili; l’abilitazione delle scritture multi-regione permette scritture simultanee ovunque con una latenza di lettura inferiore a 10 ms al 99° percentile nelle regioni vicine. Gli SDK client dovrebbero essere configurati con le regioni preferite per instradare il traffico localmente ed eseguire il failover in modo controllato. In .NET, fornire le regioni preferite tramite CosmosClientOptions ApplicationPreferredRegions (o l’equivalente in altri SDK). Le scritture multi-regione richiedono una policy di risoluzione dei conflitti:

Last Write Wins (L’ultima scrittura vince): Utilizzare un percorso di risoluzione dei conflitti (ad esempio, una proprietà timestamp o di versione). Se non specificato, può essere utilizzato il timestamp di sistema.
Risoluzione personalizzata: Utilizzare una stored procedure di unione (merge) per riconciliare i conflitti in modo deterministico.
Manuale: Ispezionare il feed dei conflitti e risolverli esplicitamente.

Il feed di modifiche (change feed) fornisce un log ordinato e di solo accodamento (append-only) delle modifiche per ogni chiave di partizione logica. È ideale per:

Architetture event-driven e CQRS (proiettando i documenti in viste ottimizzate per la lettura).
Pipeline downstream (ingestion in data lake, indicizzazione per la ricerca, invalidazione della cache).
Analisi e auditing quasi in tempo reale. Esistono due principali modelli di consumo:
Libreria Change Feed Processor: Elaborazione distribuita e fault-tolerant che utilizza un contenitore di lease per bilanciare le partizioni tra i worker e scalare orizzontalmente in sicurezza.
Modello pull con FeedIterator: Iterare esplicitamente le modifiche con una logica di checkpointing controllata dall’utente; segmentare il lavoro su FeedRange per parallelizzare. Azure Functions offre un trigger di Cosmos DB che incapsula il modello del processore per l’elaborazione serverless. È possibile iniziare dall’inizio o da “adesso”, e il feed di modifiche a piena fedeltà (full-fidelity) cattura aggiornamenti e cancellazioni intermedi per audit trail completi. Progettare il contenitore dei lease con un throughput sufficiente e scegliere gestori (handler) idempotenti per gestire i tentativi (retry) e la consegna “almeno una volta” (at-least-once).

Scenario pratico

Spotify deve fornire un servizio di personalizzazione disponibile a livello globale che ingerisca le interazioni degli utenti in tempo reale, aggiorni i consigli per utente e serva letture a bassa latenza dalla regione più vicina. Le scritture possono avvenire da client mobili in tutto il mondo e gli aggiornamenti dei consigli devono essere distribuiti (fan-out) ai sistemi downstream.

Scegliere l’API SQL (Core) di Cosmos DB con scritture multi-regione

Perché: L’API Core offre funzionalità di query avanzate e programmabilità lato server. Le scritture multi-regione minimizzano la latenza di scrittura a livello globale e tollerano il failover regionale senza tempi di inattività per le scritture.

Definire una chiave di partizione ad alta cardinalità e chiavi gerarchiche

Approccio: Partizionare per userId; per utenti estremamente attivi, utilizzare chiavi gerarchiche come [“userId”, “bucket”] dove bucket è un suffisso hash.
Perché: Distribuisce uniformemente il carico di scrittura e lettura, abilita aggiornamenti transazionali per utente ed evita partizioni “calde” (hot partition).

Configurare il throughput con scalabilità automatica (autoscale) sui contenitori primari

Perché: Il traffico è diurno e guidato da campagne; la scalabilità automatica gestisce i picchi fino al massimo di RU/s configurato, mantenendo i costi proporzionali al carico effettivo.

Impostare la coerenza a Sessione (Session) a livello di account

Perché: I client mobili richiedono la coerenza “leggi le tue scritture” (read-your-writes) per l’esperienza utente senza i vincoli di latenza della coerenza Forte (Strong). I token di sessione vengono trasportati dai client e dal livello gateway per preservare la semantica di sessione tra i nodi.

Implementare l’elaborazione del feed di modifiche con Azure Functions e il Change Feed Processor

Approccio: Creare un’app Functions con un trigger di Cosmos DB collegato al contenitore delle interazioni. Utilizzare un contenitore di lease dedicato e abilitare più istanze per il parallelismo.
Perché: Questo fornisce un’elaborazione resiliente, scalabile e a basso impatto operativo (low-ops) per aggiornare le viste materializzate (ad es. un contenitore di consigli) e per pubblicare eventi su Event Hubs per l’analisi in streaming.

Creare un contenitore di consigli derivato con una policy di indicizzazione personalizzata

Approccio: Escludere dall’indicizzazione le proprietà di grandi dimensioni e con molte scritture; aggiungere indici compositi per (userId, score DESC) per supportare le query TOP-K.
Perché: Riduce i costi di scrittura in RU consentendo al contempo ricerche ordinate efficienti per i feed personalizzati.

Abilitare la distribuzione globale con regioni preferite negli SDK

Approccio: Aggiungere regioni in Nord America, Europa e APAC. Configurare CosmosClientOptions con ApplicationPreferredRegions in base alla regione di deployment dell’applicazione.
Perché: Assicura che le letture vengano servite localmente per una latenza inferiore a 10 ms e che il failover sia trasparente.

Configurare la risoluzione dei conflitti e l’osservabilità

Approccio: Utilizzare Last Write Wins con un orologio logico generato dal server (proprietà di versione) per aggiornamenti idempotenti e instradare i conflitti a una coda di monitoraggio per i rari casi limite.
Perché: Garantisce una convergenza deterministica in caso di scritture simultanee multi-regione e fornisce visibilità operativa.

Questa architettura offre letture e scritture a bassa latenza a livello globale, elaborazione resiliente degli eventi tramite il feed di modifiche, scalabilità automatica efficiente in termini di costi e una semantica di coerenza robusta adatta ai carichi di lavoro di personalizzazione.

← Azure Storage e Blob Storage · Tutti i domini · Soluzioni Container di Azure →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →