Microsoft AZ-204: Azure Cosmos DB — Lernleitfaden

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

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure Cosmos DB ist eine vollständig verwaltete, global verteilte Multimodell-Datenbank, die für elastisch skalierbare Anwendungen mit niedriger Latenz entwickelt wurde. Sie stellt mehrere APIs über eine gemeinsame, partitionierte Speicher- und Replikations-Engine bereit, bietet fünf anpassbare Konsistenzebenen und umfassende SLAs für Verfügbarkeit, Latenz, Durchsatz und Konsistenz. Daten werden in Konten, Datenbanken und Containern (oder Sammlungen/Tabellen/Graphen je nach API) organisiert. Container werden horizontal partitioniert und über einen Partitionsschlüssel skaliert. Alle Operationen werden in Anforderungseinheiten (Request Units, RUs) gemessen, einer normalisierten Währung, die CPU, IOPS und Arbeitsspeicher abstrahiert.

APIs und Programmierbarkeit

Cosmos DB unterstützt mehrere Wire-kompatible APIs, sodass Sie native SDKs und Treiber verwenden können, ohne Ihr Datenmodell neu schreiben zu müssen:

SQL (Core) API: Der empfohlene Standard für neue Workloads. Speichert JSON-Dokumente mit umfangreichen, SQL-ähnlichen Abfragen (SELECT, WHERE, ORDER BY, JOIN innerhalb eines Dokuments, Aggregate) und deterministischen UDFs für berechnete Prädikate/Projektionen. Serverseitige Geschäftslogik wird als gespeicherte JavaScript-Prozeduren und Pre-/Post-Trigger innerhalb einer einzelnen logischen Partition ausgeführt, was ACID-Transaktionen über mehrere Elemente ermöglicht, die denselben Partitionsschlüssel verwenden. TransactionalBatch bietet Operationen über mehrere Elemente in einer Partition. Punktlesevorgänge (ID + Partitionsschlüssel) sind am RU-effizientesten. Erstellen Sie einen .NET-Client mit Code wie: new CosmosClient(endpoint, key).
MongoDB API: Wire-kompatibel mit MongoDB, was die Verwendung von Standard-MongoDB-Treibern und -Tools ermöglicht (zum Beispiel mongodump/mongorestore für Migrationen). Sie können MongoDB-Funktionen nutzen, die durch die Verteilung, automatische Skalierung und SLAs von Cosmos DB unterstützt werden. Transaktionen über mehrere Dokumente werden innerhalb derselben logischen Partition unterstützt; für strikte Atomarität pro Benutzer verwenden Sie eine nicht geshardete Sammlung oder sharden Sie nach einer Eigenschaft wie dem Benutzernamen, sodass zusammengehörige Dokumente dieselbe Partition teilen.
Cassandra API: Kompatibel mit Apache Cassandra-Treibern und CQL. Ideal für Wide-Column- und Zeitreihen-Zugriffsmuster. Sie erhalten automatische globale Verteilung und RU-basiertes Skalieren anstelle der Knotenverwaltung.
Gremlin API: Eigenschaftsgraphenmodell mit TinkerPop Gremlin-Abfragen und -Traversierungen. Die Partitionierung ist entscheidend, um Knoten (Vertices) und Kanten (Edges) für skalierbare Traversierungen zu verteilen.
Table API: Schlüssel-Wert-Speicher mit zu Azure Table Storage kompatiblen SDKs und Semantiken, aber unterstützt durch die globale Verteilung, den RU-Durchsatz und die Indizes mit geringerer Latenz von Cosmos DB.

Zu den gängigen SDK-Operationen über alle APIs hinweg gehören CRUD, optimistische Nebenläufigkeit mit ETags, Upserts, serverseitige Skripte (gespeicherte Prozeduren, Trigger) und UDFs (SQL API). Abfragen werden parametrisiert, um RUs zu reduzieren und die Sicherheit zu verbessern. Massenoperationen und Streaming-APIs minimieren den Client-Overhead und die RU-Kosten bei der Erfassung mit hohem Durchsatz.

Konsistenz, Indizierung und Abfragesemantik

Cosmos DB bietet fünf klar definierte Konsistenzebenen pro Konto (die pro Anfrage in vielen SDKs überschrieben werden können):

Stark (Strong): Linearisierbarkeit – Lesevorgänge sehen global den zuletzt committeten Schreibvorgang. Maximiert die Korrektheit, begrenzt die Schreiblatenz und die regionale Flexibilität und ist nicht verfügbar, wenn Schreibvorgänge in mehreren Regionen aktiviert sind.
Begrenzte Veraltung (Bounded Staleness): Lesevorgänge hinken Schreibvorgängen um höchstens K Versionen oder eine Zeitspanne T hinterher. Garantiert eine monotone Lese- und Schreibreihenfolge; ein guter Kompromiss für global verteilte Lesevorgänge, die eine begrenzte Verzögerung tolerieren.
Sitzung (Session) (Standard): Pro Sitzung Read-Your-Writes, Write-Follows-Reads und monotone Lesevorgänge. Jeder Client verwaltet ein Sitzungstoken; das Teilen dieses Tokens über Knoten hinweg (z. B. über Anforderungsoptionen im SDK) erhält Read-Your-Writes über diese Knoten hinweg aufrecht.
Konsistenter Präfix (Consistent Prefix): Lesevorgänge beobachten niemals Schreibvorgänge in falscher Reihenfolge, sehen aber möglicherweise einen Präfix des Protokolls.
Letztendlich (Eventual): Höchste Verfügbarkeit und niedrigste Latenz ohne Garantien für die Reihenfolge.

Die Indizierung ist für die SQL API standardmäßig automatisch und konsistent. Jedes Element und jede Eigenschaft wird ohne Schemaverwaltung indiziert, sodass Schreibvorgänge den Index sofort aktualisieren (Indizierungsmodus: Konsistent). Sie können die Indizierungsrichtlinie verfeinern, um:

Große oder schreibintensive Pfade auszuschließen, um die RU-Kosten für Schreibvorgänge zu senken.
Zusammengesetzte Indizes hinzuzufügen, um effiziente ORDER BY-Operationen über mehrere Eigenschaften und Abfragen zu unterstützen, die Filter und Sortierungen über verschiedene Eigenschaften kombinieren.
Räumliche Indizes für GeoJSON-Typen (Point, LineString, Polygon, MultiPolygon) hinzuzufügen und mit räumlichen Funktionen wie ST_DISTANCE, ST_WITHIN und ST_INTERSECTS abzufragen. Der Indizierungsmodus kann auch auf Keine (None) gesetzt werden für schreiboptimierte Container, die nur über ID/Partitionsschlüssel gelesen werden. Verschiedene APIs stellen die Indizierung über ihre nativen Paradigmen bereit (z. B. MongoDB- und Cassandra-Treiberkonstrukte), aber alle nutzen die zugrunde liegende Cosmos-Indizierungs-Engine.

Achten Sie auf die Elementgröße und die Abfragestruktur. Die SQL API erzwingt ein Limit für die Elementgröße (z. B. 2 MB), und partitionsübergreifende Abfragen, große Projektionen und komplexe Prädikate erhöhen den RU-Verbrauch. Verwenden Sie selektive Projektionen, geeignete Filter und partitionsbewusste Abfragen, um die RU-Kosten zu minimieren.

Partitionierung und Durchsatz (RUs)

Cosmos DB trennt zwischen logischen und physischen Partitionen:

Logische Partitionen gruppieren Elemente nach einem Partitionsschlüsselwert. Alle Elemente mit demselben Schlüssel nehmen gemeinsam an Transaktions-Batches und serverseitigen Skripten teil.
Physische Partitionen werden vom Dienst verwaltet und hosten viele logische Partitionen. Durchsatz (RUs) und Speicher werden auf die physischen Partitionen verteilt; „heiße“ logische Partitionen können den Durchsatz einer physischen Partition zu einem Engpass machen.

Wählen Sie einen effektiven Partitionsschlüssel mit hoher Kardinalität und gleichmäßiger Zugriffsverteilung über die Zeit. Gute Schlüssel korrelieren mit Ihrem primären Zugriffspfad (z. B. userId, deviceId, tenantId oder orderId). Vermeiden Sie Schlüssel mit niedriger Kardinalität oder zeitbasierte Schlüssel, die zu einer Schieflage (Skew) führen (z. B. country, status oder day). Wenn keine einzelne Eigenschaft geeignet ist:

Verwenden Sie einen synthetischen Schlüssel, der mehrere Eigenschaften verknüpft.
Hängen Sie ein zufälliges oder gehashtes Suffix an, um die Last auf die Partitionen zu verteilen, während die Abfragbarkeit durch Präfixe oder durch die Pflege einer Nachschlagetabelle (Lookup) erhalten bleibt.
Ziehen Sie hierarchische Partitionsschlüssel in Betracht, um mehrere Eigenschaften zu kombinieren, was eine bessere Verteilung und effiziente Präfix-Abfragen ermöglicht.

Durchsatzmodelle:

Bereitgestellter Durchsatz (Provisioned Throughput): Reservieren Sie RU/s für einen Container oder eine Datenbank (wird von untergeordneten Containern gemeinsam genutzt). Vorhersehbare Leistung bei Kostenstabilität. Skalieren Sie manuell oder über APIs/CLI.
Automatische Skalierung (Autoscale): Legen Sie einen maximalen RU/s-Wert fest; Cosmos DB skaliert elastisch zwischen 10 % und 100 % dieses Maximums basierend auf der Last. Abgerechnet wird auf Basis der höchsten genutzten RU pro Stunde; ausgezeichnet für variable Workloads und unbekannte Spitzenlasten.
Serverless: Keine bereitgestellten RU/s; Bezahlung pro RU-Verbrauch einer Operation. Ideal für Entwicklung, stark schwankende (spiky) oder Workloads mit geringem Durchsatz ohne vorhersagbare Grundlast.

Techniken zur RU-Optimierung umfassen Punktlesevorgänge (Point Reads) nach ID+Partitionsschlüssel, parametrisierte Abfragen, selektive Projektionen, Denormalisierung zur Reduzierung von JOIN-ähnlichen Mustern und die Verwendung des Change Feed für abgeleitete Ansichten anstelle komplexer Abfragen über mehrere Container. Verwenden Sie ETags mit If-Match zur Nebenläufigkeitssteuerung, um RU-intensive Wiederholungsversuche zu vermeiden. Überwachen Sie RU-Metriken und Drosselung (Throttling, HTTP 429) und implementieren Sie Wiederholungsrichtlinien mit Jitter in den SDKs.

Globale Verteilung und Änderungsfeed

Die schlüsselfertige, multiregionale Verteilung von Cosmos DB ermöglicht es Ihnen, jederzeit Regionen hinzuzufügen oder zu entfernen. Alle Regionen sind lesbar; die Aktivierung von multiregionalen Schreibvorgängen ermöglicht gleichzeitige Schreibvorgänge überall mit einer Leselatenz von unter 10 ms im 99. Perzentil in benachbarten Regionen. Client-SDKs sollten mit bevorzugten Regionen konfiguriert werden, um den Datenverkehr lokal zu leiten und ein reibungsloses Failover zu ermöglichen. In .NET geben Sie bevorzugte Regionen über CosmosClientOptions ApplicationPreferredRegions an (oder das Äquivalent in anderen SDKs). Multiregionale Schreibvorgänge erfordern eine Richtlinie zur Konfliktlösung:

Last Write Wins: Verwenden Sie einen Pfad zur Konfliktlösung (z. B. eine Zeitstempel- oder Versionseigenschaft). Wenn nicht angegeben, kann der Systemzeitstempel verwendet werden.
Benutzerdefinierte Lösung: Verwenden Sie eine Merge-Stored-Procedure, um Konflikte deterministisch abzugleichen.
Manuell: Überprüfen Sie den Konflikt-Feed und lösen Sie Konflikte explizit.

Der Änderungsfeed stellt ein geordnetes, nur anfügbares Protokoll (Append-Only) von Änderungen pro logischem Partitionsschlüssel bereit. Er ist ideal für:

Ereignisgesteuerte Architekturen und CQRS (Projektion von Dokumenten in leseroptimierte Ansichten).
Nachgelagerte Pipelines (Data-Lake-Ingestion, Suchindizierung, Cache-Invalidierung).
Nahezu-Echtzeit-Analysen und Auditing. Es gibt zwei Hauptmuster für den Konsum:
Change Feed Processor-Bibliothek: Verteilte, fehlertolerante Verarbeitung, die einen Leases-Container verwendet, um Partitionen auf Worker zu verteilen und sicher zu skalieren.
Pull-Modell mit FeedIterator: Explizites Iterieren von Änderungen mit von Ihnen gesteuerter Checkpointing-Logik; Segmentieren der Arbeit über FeedRange zur Parallelisierung. Azure Functions bietet einen Cosmos DB-Trigger, der das Prozessor-Muster für die serverlose Verarbeitung kapselt. Sie können von Anfang an oder ab „jetzt“ starten, und der Full-Fidelity-Änderungsfeed erfasst Zwischen-Updates und Löschvorgänge für vollständige Audit-Trails. Entwerfen Sie Ihren Lease-Container mit ausreichendem Durchsatz und wählen Sie idempotente Handler, um Wiederholungsversuche und eine „At-least-once“-Zustellung zu ermöglichen.

Praktisches Problemszenario

Spotify muss einen global verfügbaren Personalisierungsdienst bereitstellen, der Benutzerinteraktionen in Echtzeit erfasst, benutzerspezifische Empfehlungen aktualisiert und Lesevorgänge mit geringer Latenz aus der nächstgelegenen Region bereitstellt. Schreibvorgänge können von mobilen Clients weltweit erfolgen, und Aktualisierungen von Empfehlungen müssen an nachgelagerte Systeme verteilt werden (Fan-Out).

Auswahl der Cosmos DB SQL (Core) API mit multiregionalen Schreibvorgängen

Warum: Die Core API bietet umfangreiche Abfrage- und serverseitige Programmierbarkeit. Multiregionale Schreibvorgänge minimieren die Schreiblatenz weltweit und tolerieren regionale Failover ohne Ausfallzeiten bei Schreibvorgängen.

Definition eines Partitionsschlüssels mit hoher Kardinalität und hierarchischer Schlüssel

Ansatz: Partitionierung nach userId; für extrem aktive Benutzer verwenden Sie hierarchische Schlüssel wie [“userId”, “bucket”], wobei bucket ein Hash-Suffix ist.
Warum: Verteilt die Schreib- und Leselast gleichmäßig, ermöglicht transaktionale Updates pro Benutzer und vermeidet Hot Partitions.

Konfiguration des Autoscale-Durchsatzes für die primären Container

Warum: Der Datenverkehr ist tageszeitabhängig und kampagnengesteuert; Autoscale bewältigt Lastspitzen bis zum konfigurierten Maximum an RU/s, während die Kosten proportional zur tatsächlichen Last bleiben.

Einstellung der Konsistenz auf „Session“ auf Kontoebene

Warum: Mobile Clients erfordern für die Benutzererfahrung „Read-your-writes“, ohne die Latenzbeschränkungen von „Strong“. Session-Token werden von Clients und der Gateway-Schicht übertragen, um die Session-Semantik über Knoten hinweg zu erhalten.

Implementierung der Änderungsfeed-Verarbeitung mit Azure Functions und dem Change Feed Processor

Ansatz: Erstellen Sie eine Functions-App mit einem Cosmos DB-Trigger, der an den Interaktions-Container gebunden ist. Verwenden Sie einen dedizierten Leases-Container und aktivieren Sie mehrere Instanzen zur Parallelisierung.
Warum: Dies bietet eine resiliente, skalierbare und betriebsarme (Low-Ops) Verarbeitung zur Aktualisierung von materialisierten Sichten (z. B. ein Empfehlungs-Container) und zur Veröffentlichung von Ereignissen in Event Hubs für Streaming-Analysen.

Erstellung eines abgeleiteten Empfehlungs-Containers mit einer angepassten Indizierungsrichtlinie

Ansatz: Schließen Sie große, schreibintensive Eigenschaften von der Indizierung aus; fügen Sie zusammengesetzte Indizes für (userId, score DESC) hinzu, um TOP-K-Abfragen zu unterstützen.
Warum: Reduziert die RU-Kosten für Schreibvorgänge und ermöglicht gleichzeitig effiziente sortierte Suchen für personalisierte Feeds.

Aktivierung der globalen Verteilung mit bevorzugten Regionen in den SDKs

Ansatz: Fügen Sie Regionen in Nordamerika, Europa und APAC hinzu. Konfigurieren Sie CosmosClientOptions mit ApplicationPreferredRegions basierend auf der Bereitstellungsregion der Anwendung.
Warum: Stellt sicher, dass Lesevorgänge lokal mit einer Latenz von unter 10 ms bedient werden und dass das Failover transparent ist.

Konfiguration der Konfliktlösung und Beobachtbarkeit (Observability)

Ansatz: Verwenden Sie „Last Write Wins“ mit einer serverseitig generierten logischen Uhr (Versionseigenschaft) für idempotente Updates und leiten Sie Konflikte für seltene Edge-Cases an eine Überwachungswarteschlange weiter.
Warum: Garantiert eine deterministische Konvergenz bei gleichzeitigen multiregionalen Schreibvorgängen und bietet operative Transparenz.

Diese Architektur liefert global Lese- und Schreibvorgänge mit geringer Latenz, eine resiliente Ereignisverarbeitung über den Änderungsfeed, kosteneffizientes Autoscaling und eine robuste Konsistenzsemantik, die für Personalisierungs-Workloads geeignet ist.

← Azure Storage und Blob Storage · Alle Domänen · Azure-Containerlösungen →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →