Microsoft AZ-204: Azure Cosmos DB — Studiegids

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

Onderdeel van de Microsoft Azure Developer Associate AZ-204 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Azure Cosmos DB is een volledig beheerde, wereldwijd gedistribueerde multi-model database, ontworpen voor elastisch schaalbare applicaties met lage latentie. Het biedt meerdere API’s bovenop een gemeenschappelijke, gepartitioneerde opslag- en replicatie-engine, levert vijf afstelbare consistentieniveaus en biedt uitgebreide SLA’s voor beschikbaarheid, latentie, doorvoer en consistentie. Data wordt georganiseerd in accounts, databases en containers (of collecties/tabellen/grafen, afhankelijk van de API). Containers worden horizontaal gepartitioneerd en geschaald door een partitiesleutel, en alle operaties worden gemeten in Request Units (RU’s), een genormaliseerde eenheid die CPU, IOPS en geheugen abstraheert.

API’s en Programmeerbaarheid

Cosmos DB ondersteunt verschillende wire-compatible API’s, zodat u native SDK’s en stuurprogramma’s kunt gebruiken zonder uw datamodel te hoeven herschrijven:

SQL (Core) API: De aanbevolen standaard voor nieuwe workloads. Slaat JSON-documenten op met rijke, SQL-achtige query’s (SELECT, WHERE, ORDER BY, JOIN binnen een document, aggregaties) en deterministische UDF’s voor berekende predikaten/projecties. Server-side bedrijfslogica draait als JavaScript stored procedures en pre/post-triggers binnen één logische partitie, wat ACID-transacties mogelijk maakt over meerdere items die dezelfde partitiesleutel delen. TransactionalBatch biedt operaties voor meerdere items binnen een partitie. Point reads (id + partitiesleutel) zijn het meest RU-efficiënt. Maak een .NET-client met code zoals:

undefined

MongoDB API: Wire-compatible met MongoDB, wat het gebruik van standaard MongoDB-stuurprogramma’s en -tools mogelijk maakt (bijvoorbeeld mongodump/mongorestore voor migraties). U kunt MongoDB-functies gebruiken die worden ondersteund door de distributie, autoscale en SLA’s van Cosmos DB. Transacties met meerdere documenten worden ondersteund binnen dezelfde logische partitie; voor strikte atomiciteit per gebruiker, gebruik een niet-gesharde collectie of shard op basis van een eigenschap zoals gebruikersnaam, zodat gerelateerde documenten een partitie delen.
Cassandra API: Compatibel met Apache Cassandra-stuurprogramma’s en CQL. Ideaal voor wide-column en time-series-toegangspatronen. U krijgt automatische wereldwijde distributie en op RU gebaseerde schaling in plaats van nodebeheer.
Gremlin API: Property graph-model met TinkerPop Gremlin-query’s en -traversals. Partitionering is essentieel om vertices en edges te verdelen voor schaalbare traversals.
Table API: Sleutel-waarde met SDK’s en semantiek die compatibel zijn met Azure Table Storage, maar ondersteund door de wereldwijde distributie, RU-doorvoer en indexen met lagere latentie van Cosmos DB.

Veelvoorkomende SDK-operaties voor alle API’s omvatten CRUD, optimistische concurrency met ETags, upserts, server-side scripts (stored procedures, triggers) en UDF’s (SQL API). Query’s worden geparameteriseerd om RU’s te verminderen en de beveiliging te verbeteren. Bulkoperaties en streaming-API’s minimaliseren de client-overhead en RU-kosten voor opname met hoge doorvoer.

Consistentie, Indexering en Query-semantiek

Cosmos DB biedt vijf goed gedefinieerde consistentieniveaus per account (die in veel SDK’s per request kunnen worden overschreven):

Strong: Lineariseerbaarheid—leesbewerkingen zien wereldwijd de meest recente vastgelegde schrijfbewerking. Maximaliseert de correctheid, beperkt de schrijflatentie en regionale flexibiliteit, en is niet beschikbaar als schrijfbewerkingen in meerdere regio’s zijn ingeschakeld.
Bounded Staleness: Leesbewerkingen lopen maximaal K versies of een T-tijd achter op schrijfbewerkingen. Garandeert een monotone lees- en schrijfvolgorde; een goede afweging voor wereldwijd gedistribueerde leesbewerkingen die een begrensde vertraging tolereren.
Session (standaard): Per sessie read-your-writes, write-follows-reads en monotoon lezen. Elke client onderhoudt een sessietoken; het delen hiervan tussen nodes (bijvoorbeeld via request-opties in de SDK) behoudt read-your-writes over die nodes.
Consistent Prefix: Leesbewerkingen zien nooit schrijfbewerkingen die niet in de juiste volgorde zijn, maar kunnen een voorvoegsel van het logboek zien.
Eventual: Hoogste beschikbaarheid en laagste latentie zonder volgordegaranties.

Indexering is standaard automatisch en consistent voor de SQL API. Elk item en elke eigenschap wordt geïndexeerd zonder schemabeheer, dus schrijfbewerkingen werken de index onmiddellijk bij (indexeringsmodus Consistent). U kunt het indexeringsbeleid verfijnen om:

Grote of schrijfintensieve paden uitsluiten om de RU-kosten voor schrijven te verlagen.
Samengestelde indexen toevoegen om efficiënte ORDER BY op meerdere eigenschappen en query’s die filters en sortering over verschillende eigenschappen combineren, te ondersteunen.
Ruimtelijke indexen toevoegen voor GeoJSON-typen (Point, LineString, Polygon, MultiPolygon) en query’s uitvoeren met ruimtelijke functies zoals ST_DISTANCE, ST_WITHIN en ST_INTERSECTS. De indexeringsmodus kan ook worden ingesteld op None voor voor schrijven geoptimaliseerde containers die alleen worden gelezen via id/partitiesleutel. Verschillende API’s bieden indexering aan via hun native paradigma’s (bijv. constructies in MongoDB- en Cassandra-stuurprogramma’s), maar ze maken allemaal gebruik van de onderliggende Cosmos-indexeringsengine.

Houd rekening met de itemgrootte en de query-vorm. De SQL API dwingt een limiet voor de itemgrootte af (bijvoorbeeld 2 MB), en cross-partitie query’s, grote projecties en complexe predikaten verhogen het RU-verbruik. Gebruik selectieve projecties, geschikte filters en partitiebewuste query’s om de RU-kosten te minimaliseren.

Partitionering en Doorvoer (RU’s)

Cosmos DB scheidt logische en fysieke partities:

Logische partities groeperen items op basis van een partitiesleutelwaarde. Alle items die dezelfde sleutel delen, nemen samen deel aan transactionele batches en server-side scripts.
Fysieke partities worden beheerd door de service en hosten vele logische partities. Doorvoer (RU’s) en opslag worden verdeeld over fysieke partities; “hot” logische partities kunnen de doorvoer van een fysieke partitie knelpunten.

Kies een effectieve partitiesleutel met hoge cardinaliteit en een gelijkmatige toegangsverdeling over tijd. Goede sleutels correleren met uw primaire toegangspad (bijvoorbeeld userId, deviceId, tenantId of orderId). Vermijd sleutels met lage cardinaliteit of op tijd gebaseerde ‘buckets’ die ‘skew’ (scheefgroei) veroorzaken (bijvoorbeeld country, status of day). Wanneer geen enkele eigenschap geschikt is:

Gebruik een synthetische sleutel die meerdere eigenschappen samenvoegt.
Voeg een willekeurig of gehasht achtervoegsel toe om de belasting over partities te spreiden, terwijl de querymogelijkheden via een prefix of door het bijhouden van een ’lookup’ behouden blijven.
Overweeg hiërarchische partitiesleutels om meerdere eigenschappen te combineren, wat een betere verdeling en efficiënte prefix-queries mogelijk maakt.

Doorvoermodellen:

Provisioned throughput: Reserveer RU/s op een container of database (gedeeld door onderliggende containers). Voorspelbare prestaties met kostenstabiliteit. Schaal handmatig of via API’s/CLI.
Autoscale: Stel een maximum aantal RU/s in; Cosmos DB schaalt elastisch tussen 10% en 100% van dat maximum op basis van de belasting. Gefactureerd op basis van de hoogste gebruikte RU per uur; uitstekend voor variabele workloads en onbekende pieken.
Serverless: Geen ‘provisioned’ RU/s; betaal per RU-verbruik van een operatie. Ideaal voor ontwikkeling, ‘spiky’ (piekbelasting) of workloads met lage doorvoer zonder voorspelbare basislijn.

RU-optimalisatietechnieken omvatten ‘point reads’ via id+partitiesleutel, geparametriseerde queries, selectieve projecties, denormaliseren om JOIN-achtige patronen te verminderen, en het gebruik van de ‘change feed’ voor afgeleide views in plaats van complexe multi-container queries. Gebruik ETags met If-Match voor ‘concurrency control’ om RU-dure ‘retries’ te vermijden. Monitor RU-metrics en ’throttling’ (HTTP 429) en implementeer ‘retry policies’ met ‘jitter’ in de SDK’s.

Wereldwijde Distributie en Change Feed

De kant-en-klare, multi-region distributie van Cosmos DB stelt u in staat om op elk moment regio’s toe te voegen of te verwijderen. Alle regio’s zijn leesbaar; het inschakelen van multi-region writes maakt gelijktijdige schrijfacties overal mogelijk met een leeslatentie van minder dan 10 ms bij het 99e percentiel in nabijgelegen regio’s. Client-SDK’s moeten worden geconfigureerd met voorkeursregio’s om verkeer lokaal te routeren en een graceful failover uit te voeren. In .NET geeft u voorkeursregio’s op via CosmosClientOptions ApplicationPreferredRegions (of het equivalent in andere SDK’s). Multi-region writes vereisen een conflictresolutiebeleid:

Laatste Schrijfactie Wint (Last Write Wins): Gebruik een pad voor conflictresolutie (bijvoorbeeld een timestamp- of versie-eigenschap). Indien niet gespecificeerd, kan de systeemtijdstempel worden gebruikt.
Aangepaste Resolutie (Custom Resolution): Gebruik een merge stored procedure om conflicten deterministisch op te lossen.
Handmatig (Manual): Inspecteer de conflictenfeed en los conflicten expliciet op.

De change feed levert een geordend, append-only log van wijzigingen per logische partitiesleutel. Dit is ideaal voor:

Event-driven architecturen en CQRS (het projecteren van documenten naar voor lezen geoptimaliseerde views).
Downstream pipelines (data lake-ingestie, zoekindexering, cache-invalidatie).
Near-real-time analytics en auditing. Er zijn twee belangrijke consumptiepatronen:
Change Feed Processor-bibliotheek: Gedistribueerde, fouttolerante verwerking die een leases-container gebruikt om partities over workers te verdelen en veilig uit te schalen.
Pull-model met FeedIterator: Itereer expliciet door wijzigingen met checkpointing-logica die u zelf beheert; segmenteer werk over FeedRange om te parallelliseren. Azure Functions biedt een Cosmos DB-trigger die het processor-patroon omhult voor serverless verwerking. U kunt vanaf het begin of vanaf “nu” starten, en de full-fidelity change feed legt tussentijdse updates en verwijderingen vast voor volledige audittrails. Ontwerp uw lease-container met voldoende doorvoer en kies idempotente handlers om rekening te houden met nieuwe pogingen (retries) en at-least-once delivery.

Praktijkscenario

Spotify moet een wereldwijd beschikbare personalisatiedienst leveren die gebruikersinteracties in realtime verwerkt, aanbevelingen per gebruiker bijwerkt en leesbewerkingen met lage latentie levert vanuit de dichtstbijzijnde regio. Schrijfacties kunnen wereldwijd plaatsvinden vanaf mobiele clients, en updates van aanbevelingen moeten uitwaaieren (fan-out) naar downstream systemen.

Kies de Cosmos DB SQL (Core) API met multi-region writes

Waarom: De Core API biedt uitgebreide query-mogelijkheden en server-side programmeerbaarheid. Multi-region writes minimaliseren de schrijflatentie wereldwijd en tolereren regionale failover zonder downtime voor schrijfacties.

Definieer een partitiesleutel met hoge kardinaliteit en hiërarchische sleutels

Aanpak: Partitioneer op userId; gebruik voor extreem actieve gebruikers hiërarchische sleutels zoals [“userId”, “bucket”], waarbij bucket een hash-achtervoegsel is.
Waarom: Verdeelt de schrijf- en leesbelasting gelijkmatig, maakt transactionele updates per gebruiker mogelijk en vermijdt ‘hot partitions’.

Configureer autoscale-doorvoer op de primaire containers

Waarom: Het verkeer is diurnaal (dag/nacht-cyclus) en campagne-gedreven; autoscale vangt pieken op tot de geconfigureerde maximale RU/s, terwijl de kosten proportioneel blijven aan de daadwerkelijke belasting.

Stel de consistentie in op Session op accountniveau

Waarom: Mobiele clients vereisen ‘read-your-writes’ voor de gebruikerservaring, zonder de latentiebeperkingen van Strong. Sessietokens worden meegedragen door clients en de gateway-laag om de semantiek van de sessie te behouden over verschillende nodes.

Implementeer change feed-verwerking met Azure Functions en de Change Feed Processor

Aanpak: Maak een Functions-app met een Cosmos DB-trigger die is gekoppeld aan de interactiecontainer. Gebruik een dedicated leases-container en schakel meerdere instanties in voor parallellisme.
Waarom: Dit zorgt voor een veerkrachtige, schaalbare en low-ops verwerking om gematerialiseerde views (bijv. een aanbevelingencontainer) bij te werken en om events te publiceren naar Event Hubs voor streaming analytics.

Maak een afgeleide aanbevelingencontainer met een op maat gemaakt indexeringsbeleid

Aanpak: Sluit grote, schrijfintensieve eigenschappen uit van indexering; voeg samengestelde indexen toe voor (userId, score DESC) om TOP-K-query’s te ondersteunen.
Waarom: Verlaagt de RU-kosten voor schrijfacties en maakt tegelijkertijd efficiënte gesorteerde zoekopdrachten voor gepersonaliseerde feeds mogelijk.

Schakel wereldwijde distributie in met voorkeursregio’s in de SDK’s

Aanpak: Voeg regio’s toe in Noord-Amerika, Europa en APAC. Configureer CosmosClientOptions met ApplicationPreferredRegions op basis van de implementatieregio van de app.
Waarom: Zorgt ervoor dat leesbewerkingen lokaal worden afgehandeld voor een latentie van minder dan 10 ms en dat failover transparant is.

Configureer conflictresolutie en observeerbaarheid

Aanpak: Gebruik ‘Last Write Wins’ met een door de server gegenereerde logische klok (versie-eigenschap) voor idempotente updates, en routeer conflicten naar een monitoring-wachtrij voor zeldzame edge cases.
Waarom: Garandeert deterministische convergentie bij gelijktijdige multi-region schrijfacties en biedt operationele zichtbaarheid.

Deze architectuur levert wereldwijd lees- en schrijfacties met lage latentie, veerkrachtige eventverwerking via de change feed, kostenefficiënte autoscaling en robuuste consistentiesemantiek die geschikt is voor personalisatie-workloads.

← Azure Storage en Blob Storage · Alle domeinen · Azure Containeroplossingen →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →