Microsoft AZ-204: Azure Cosmos DB — Guide d'étude

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

Fait partie du Microsoft Azure Developer Associate AZ-204 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure Cosmos DB est une base de données multimodèle, distribuée à l’échelle mondiale et entièrement gérée, conçue pour des applications à faible latence et élastiquement scalables. Elle expose plusieurs API sur un moteur de stockage et de réplication commun et partitionné, fournit cinq niveaux de cohérence ajustables et offre des SLA complets pour la disponibilité, la latence, le débit et la cohérence. Les données sont organisées en comptes, bases de données et conteneurs (ou collections/tables/graphes selon l’API). Les conteneurs sont partitionnés horizontalement et mis à l’échelle par une clé de partition, et toutes les opérations sont mesurées en Unités de Requête (RU), une monnaie normalisée qui abstrait le CPU, les IOPS et la mémoire.

API et Programmabilité

Cosmos DB prend en charge plusieurs API compatibles au niveau du protocole afin que vous puissiez utiliser des SDK et des pilotes natifs sans réécrire votre modèle de données :

API SQL (Core) : L’option par défaut recommandée pour les nouvelles charges de travail. Stocke des documents JSON avec des requêtes riches de type SQL (SELECT, WHERE, ORDER BY, JOIN au sein d’un document, agrégats) et des fonctions définies par l’utilisateur (UDF) déterministes pour les prédicats/projections calculés. La logique métier côté serveur s’exécute sous forme de procédures stockées JavaScript et de déclencheurs pre/post au sein d’une partition logique unique, permettant des transactions ACID sur plusieurs éléments qui partagent la clé de partition. TransactionalBatch fournit des opérations sur plusieurs éléments dans une partition. Les lectures de point (id + clé de partition) sont les plus efficaces en termes de RU. Créez un client .NET avec un code tel que :

undefined

API MongoDB : Compatible au niveau du protocole avec MongoDB, permettant l’utilisation des pilotes et outils MongoDB standard (par exemple, mongodump/mongorestore pour les migrations). Vous pouvez utiliser les fonctionnalités de MongoDB soutenues par la distribution, la mise à l’échelle automatique et les SLA de Cosmos DB. Les transactions multi-documents sont prises en charge au sein de la même partition logique ; pour une atomicité stricte par utilisateur, utilisez une collection non partitionnée (unsharded) ou partitionnez par une propriété telle que username afin que les documents associés partagent une partition.
API Cassandra : Compatible avec les pilotes Apache Cassandra et CQL. Idéale pour les modèles d’accès en colonnes larges et en séries temporelles. Vous bénéficiez d’une distribution mondiale automatique et d’une mise à l’échelle basée sur les RU au lieu de la gestion des nœuds.
API Gremlin : Modèle de graphe de propriétés avec des requêtes et des parcours Gremlin de TinkerPop. Le partitionnement est essentiel pour distribuer les sommets et les arêtes afin de permettre des parcours scalables.
API Table : Clé-valeur avec des SDK et une sémantique compatibles avec Azure Table Storage, mais soutenue par la distribution mondiale, le débit en RU et les index à plus faible latence de Cosmos DB.

Les opérations SDK courantes à travers les API incluent le CRUD, la concurrence optimiste avec les ETags, les upserts, les scripts côté serveur (procédures stockées, déclencheurs) et les UDF (API SQL). Les requêtes sont paramétrées pour réduire les RU et améliorer la sécurité. Les opérations en bloc et les API de streaming minimisent la surcharge du client et les coûts en RU pour une ingestion à haut débit.

Cohérence, Indexation et Sémantique des Requêtes

Cosmos DB offre cinq niveaux de cohérence bien définis par compte (pouvant être surchargés par requête dans de nombreux SDK) :

Forte (Strong) : Linéarisabilité — les lectures voient l’écriture validée la plus récente à l’échelle mondiale. Maximise l’exactitude, limite la latence d’écriture et la flexibilité régionale, et n’est pas disponible lorsque les écritures multirégions sont activées.
Obsolescence limitée (Bounded Staleness) : Les lectures ont un retard sur les écritures d’au plus K versions ou d’un temps T. Garantit un ordre de lecture et d’écriture monotone ; c’est un bon compromis pour les lectures distribuées mondialement qui tolèrent un retard limité.
Session (par défaut) : Par session, lecture de ses propres écritures (read-your-writes), l’écriture suit la lecture (write-follows-reads) et lectures monotones. Chaque client maintient un jeton de session ; le partager entre les nœuds (par exemple, via les options de requête dans le SDK) préserve la lecture de ses propres écritures sur ces nœuds.
Préfixe cohérent (Consistent Prefix) : Les lectures n’observent jamais d’écritures dans le désordre, mais peuvent voir un préfixe du journal des transactions.
Éventuelle (Eventual) : Disponibilité la plus élevée et latence la plus faible sans aucune garantie d’ordre.

L’indexation est automatique et cohérente par défaut pour l’API SQL. Chaque élément et chaque propriété sont indexés sans gestion de schéma, de sorte que les écritures mettent à jour l’index immédiatement (mode d’indexation Consistent). Vous pouvez affiner la politique d’indexation pour :

Exclure les chemins volumineux ou à forte sollicitation en écriture pour réduire les coûts d’écriture en RU.
Ajouter des index composites pour prendre en charge un ORDER BY efficace sur plusieurs propriétés et des requêtes combinant des filtres et des tris sur différentes propriétés.
Ajouter des index spatiaux pour les types GeoJSON (Point, LineString, Polygon, MultiPolygon) et interroger avec des fonctions spatiales telles que ST_DISTANCE, ST_WITHIN et ST_INTERSECTS. Le mode d’indexation peut également être défini sur None pour les conteneurs optimisés pour l’écriture qui sont lus uniquement par id/clé de partition. Différentes API exposent l’indexation via leurs paradigmes natifs (par exemple, les constructions des pilotes MongoDB et Cassandra), mais toutes exploitent le moteur d’indexation sous-jacent de Cosmos.

Soyez attentif à la taille des éléments et à la forme des requêtes. L’API SQL impose une limite de taille d’élément (par exemple, 2 Mo), et les requêtes inter-partitions, les projections larges et les prédicats complexes augmentent la consommation de RU. Utilisez des projections sélectives, des filtres appropriés et des requêtes tenant compte de la partition pour minimiser le coût en RU.

Partitionnement et Débit (RU)

Cosmos DB sépare les partitions logiques et physiques :

Les partitions logiques regroupent les éléments par la valeur d’une clé de partition. Tous les éléments partageant la même clé participent ensemble aux lots transactionnels et aux scripts côté serveur.
Les partitions physiques sont gérées par le service et hébergent de nombreuses partitions logiques. Le débit (RU) et le stockage sont répartis entre les partitions physiques ; les partitions logiques « surchargées » (hot) peuvent créer un goulot d’étranglement pour le débit d’une partition physique.

Choisissez une clé de partition efficace avec une cardinalité élevée et une distribution d’accès uniforme dans le temps. Les bonnes clés sont en corrélation avec votre chemin d’accès principal (par exemple, userId, deviceId, tenantId ou orderId). Évitez les clés à faible cardinalité ou basées sur des intervalles de temps qui provoquent un déséquilibre (skew) (par exemple, country, status ou day). Lorsqu’aucune propriété unique n’est appropriée :

Utilisez une clé synthétique qui concatène plusieurs propriétés.
Ajoutez un suffixe aléatoire ou haché pour répartir la charge entre les partitions tout en préservant la capacité d’interrogation par préfixe ou en maintenant une table de correspondance (lookup).
Envisagez d’utiliser des clés de partition hiérarchiques pour combiner plusieurs propriétés, permettant une meilleure distribution et des requêtes par préfixe efficaces.

Modèles de débit :

Débit provisionné : Réservez des RU/s sur un conteneur ou une base de données (partagés par les conteneurs enfants). Performances prévisibles avec une stabilité des coûts. Mise à l’échelle manuelle ou via les API/CLI.
Mise à l’échelle automatique (Autoscale) : Définissez un maximum de RU/s ; Cosmos DB effectue une mise à l’échelle élastique entre 10 % et 100 % de ce maximum en fonction de la charge. Facturé sur le nombre de RU le plus élevé utilisé au cours d’une heure ; excellent pour les charges de travail variables et les pics inconnus.
Serverless : Pas de RU/s provisionnées ; payez par consommation de RU de chaque opération. Idéal pour le développement, les charges de travail en dents de scie (spiky) ou à faible débit sans base de référence prévisible.

Les techniques d’optimisation des RU incluent les lectures de point (point reads) par id+clé de partition, les requêtes paramétrées, les projections sélectives, la dénormalisation pour réduire les schémas de type JOIN, et l’utilisation du flux de modification (change feed) pour les vues dérivées plutôt que des requêtes complexes sur plusieurs conteneurs. Utilisez les ETags avec If-Match pour le contrôle de la concurrence afin d’éviter les nouvelles tentatives coûteuses en RU. Surveillez les métriques de RU et la limitation (throttling) (HTTP 429) et implémentez des politiques de nouvelle tentative avec de la gigue (jitter) dans les SDK.

Distribution mondiale et flux de modification

La distribution multirégion clé en main de Cosmos DB vous permet d’ajouter ou de supprimer des régions à tout moment. Toutes les régions sont lisibles ; l’activation des écritures multirégions permet des écritures simultanées partout avec une latence de lecture inférieure à 10 ms au 99e centile dans les régions proches. Les SDK clients doivent être configurés avec des régions préférées pour router le trafic localement et basculer de manière transparente. En .NET, fournissez les régions préférées via CosmosClientOptions ApplicationPreferredRegions (ou l’équivalent dans d’autres SDK). Les écritures multirégions nécessitent une politique de résolution des conflits :

La dernière écriture l’emporte (Last Write Wins) : Utilisez un chemin de résolution de conflit (par exemple, une propriété d’horodatage ou de version). S’il n’est pas spécifié, l’horodatage système peut être utilisé.
Résolution personnalisée : Utilisez une procédure stockée de fusion pour réconcilier les conflits de manière déterministe.
Manuelle : Inspectez le flux des conflits et résolvez-les explicitement.

Le flux de modification (change feed) fournit un journal ordonné et en ajout seul des modifications par clé de partition logique. Il est idéal pour :

Les architectures événementielles et CQRS (projection de documents dans des vues optimisées pour la lecture).
Les pipelines en aval (ingestion dans un data lake, indexation pour la recherche, invalidation de cache).
L’analytique et l’audit en quasi-temps réel. Il existe deux principaux modèles de consommation :
Bibliothèque Change Feed Processor : Traitement distribué et tolérant aux pannes qui utilise un conteneur de baux pour équilibrer les partitions entre les workers et effectuer une mise à l’échelle horizontale en toute sécurité.
Modèle pull avec FeedIterator : Itérez explicitement sur les modifications avec une logique de point de contrôle que vous contrôlez ; segmentez le travail sur plusieurs FeedRange pour paralléliser. Azure Functions propose un déclencheur Cosmos DB qui encapsule le modèle de processeur pour un traitement serverless. Vous pouvez commencer depuis le début ou à partir de « maintenant », et le flux de modification haute fidélité capture les mises à jour intermédiaires et les suppressions pour des pistes d’audit complètes. Concevez votre conteneur de baux avec un débit suffisant et choisissez des gestionnaires idempotents pour gérer les nouvelles tentatives et la livraison au moins une fois.

Scénario de problème pratique

Spotify doit fournir un service de personnalisation disponible mondialement qui ingère les interactions des utilisateurs en temps réel, met à jour les recommandations par utilisateur et sert des lectures à faible latence depuis la région la plus proche. Les écritures peuvent provenir de clients mobiles du monde entier, et les mises à jour des recommandations doivent être diffusées aux systèmes en aval.

Choisir l’API Cosmos DB SQL (Core) avec les écritures multirégions

Pourquoi : L’API Core offre des fonctionnalités de requête riches et une programmabilité côté serveur. Les écritures multirégions minimisent la latence d’écriture à l’échelle mondiale et tolèrent le basculement régional sans interruption des écritures.

Définir une clé de partition à haute cardinalité et des clés hiérarchiques

Approche : Partitionner sur userId ; pour les utilisateurs extrêmement actifs, utiliser des clés hiérarchiques telles que [“userId”, “bucket”] où bucket est un suffixe de hachage.
Pourquoi : Répartit uniformément la charge de lecture et d’écriture, permet des mises à jour transactionnelles par utilisateur et évite les partitions surchargées (hot partitions).

Configurer le débit à mise à l’échelle automatique sur les conteneurs principaux

Pourquoi : Le trafic est diurne et piloté par les campagnes ; la mise à l’échelle automatique gère les pics jusqu’au maximum de RU/s configuré tout en maintenant un coût proportionnel à la charge réelle.

Définir la cohérence sur Session au niveau du compte

Pourquoi : Les clients mobiles nécessitent la lecture de leurs propres écritures (read-your-writes) pour l’expérience utilisateur sans les contraintes de latence de la cohérence Forte (Strong). Les jetons de session sont transportés par les clients et la couche de passerelle pour préserver la sémantique de session entre les nœuds.

Implémenter le traitement du flux de modification avec Azure Functions et le Change Feed Processor

Approche : Créer une application Functions avec un déclencheur Cosmos DB lié au conteneur d’interactions. Utiliser un conteneur de baux dédié et activer plusieurs instances pour le parallélisme.
Pourquoi : Cela fournit un traitement résilient, évolutif et à faible charge opérationnelle pour mettre à jour les vues matérialisées (par ex., un conteneur de recommandations) et pour publier des événements vers Event Hubs pour l’analytique en streaming.

Créer un conteneur de recommandations dérivé avec une politique d’indexation sur mesure

Approche : Exclure de l’indexation les propriétés volumineuses et à forte écriture ; ajouter des index composites pour (userId, score DESC) afin de prendre en charge les requêtes TOP-K.
Pourquoi : Réduit les coûts d’écriture en RU tout en permettant des recherches triées efficaces pour les flux personnalisés.

Activer la distribution mondiale avec les régions préférées dans les SDK

Approche : Ajouter des régions en Amérique du Nord, en Europe et en APAC. Configurer CosmosClientOptions avec ApplicationPreferredRegions en fonction de la région de déploiement de l’application.
Pourquoi : Garantit que les lectures sont servies localement pour une latence inférieure à 10 ms et que le basculement est transparent.

Configurer la résolution des conflits et l’observabilité

Approche : Utiliser la politique “La dernière écriture l’emporte” (Last Write Wins) avec une horloge logique générée par le serveur (propriété de version) pour les mises à jour idempotentes, et router les conflits vers une file d’attente de surveillance pour les cas limites rares.
Pourquoi : Garantit une convergence déterministe en cas d’écritures multirégions concurrentes et offre une visibilité opérationnelle.

Cette architecture offre des lectures et écritures à faible latence à l’échelle mondiale, un traitement d’événements résilient via le flux de modification, une mise à l’échelle automatique rentable et une sémantique de cohérence robuste adaptée aux charges de travail de personnalisation.

← Stockage Azure et Stockage Blob · Tous les domaines · Solutions de conteneurs Azure →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →