Guide

Une relation de un à peu existe lorsque les données connexes sont limitées, petites et souvent lues ensemble.

→Intégrer les données connexes en tant qu'objet imbriqué ou tableau au sein du document principal.

Pourquoi: Optimise les performances de lecture en récupérant toutes les données nécessaires en une seule lecture ponctuelle, minimisant ainsi le coût en RU et la latence. Évite les jointures côté client.

Référence↗

Une relation de un à plusieurs où le côté "plusieurs" croît de manière illimitée ou est mis à jour indépendamment du côté "un".

→Stocker les éléments connexes en tant que documents séparés et utiliser l'ID du document parent comme référence.

Pourquoi: Empêche les documents de dépasser la limite de taille de 2 Mo et évite des coûts RU élevés pour les mises à jour sur de grands tableaux intégrés.

Référence↗

Un document contient un tableau qui peut croître de manière illimitée au fil du temps, risquant de dépasser la limite de taille de document de 2 Mo (par exemple, journaux d'événements, commentaires).

→Diviser le tableau entre plusieurs documents "bucket". Lorsqu'un bucket atteint un seuil de taille/d'éléments, en créer un nouveau.

Pourquoi: Maintient la taille des documents individuels gérable tout en conservant le regroupement logique des données connexes.

Modéliser une relation de plusieurs à plusieurs, comme les étudiants et les cours, ou les articles et les balises.

→Pour les relations bornées, dupliquer les données de relation des deux côtés (par exemple, intégrer les ID de cours dans le document étudiant, les ID d'étudiant dans le document de cours). Pour les relations non bornées, utiliser un conteneur de documents "join" ou "edge" séparé.

Pourquoi: La dénormalisation optimise les deux sens de requête (étudiants dans un cours, cours pour un étudiant) sans nécessiter de jointures. Un conteneur de jointure est utilisé pour les cas non bornés.

Modéliser des données hiérarchiques (par exemple, organigramme, catégories de produits) et avoir besoin de rechercher tous les descendants d'un nœud.

→Stocker un tableau de tous les ID ou noms d'ancêtres (le chemin) dans chaque document.

Pourquoi: Permet des requêtes de sous-arborescence efficaces avec un seul filtre `ARRAY_CONTAINS`, évitant les recherches récursives coûteuses.

Un document contient un tableau non borné (par exemple, commentaires de blog), mais la requête la plus courante ne nécessite que les N éléments les plus récents.

→Intégrer un sous-ensemble d'éléments récents dans le document principal et stocker tous les éléments en tant que documents référencés séparés.

Pourquoi: Optimise le chemin de lecture principal pour la performance et le coût, tout en permettant l'accès à l'ensemble complet des données si nécessaire.

Stocker une séquence d'événements immuables pour une entité et avoir besoin de requêter l'état actuel ou les agrégats analytiques.

→Stocker les événements dans un seul conteneur partitionné par l'ID de l'entité. Utiliser le Change Feed ou Synapse Link pour calculer et stocker des vues matérialisées ou des agrégats.

Pourquoi: Fournit une piste d'audit complète et découple le modèle d'écriture de divers modèles de lecture, offrant une grande flexibilité.

Besoin de préserver l'état des données connexes à un moment précis (par exemple, l'adresse d'un client sur une commande).

→Intégrer une copie (snapshot) des données connexes dans le document, plutôt que de les référencer.

Pourquoi: Assure l'exactitude historique en découplant le document des changements futurs des données référencées.

Ingestion de données de séries chronologiques à haute fréquence (par exemple, lectures de capteurs IoT) et interrogation par appareil sur des plages de temps.

→Utiliser l'ID de l'appareil comme clé de partition. Agréger les lectures dans des documents regroupés par temps (par exemple, toutes les heures ou toutes les minutes) au lieu d'un document par lecture.

Pourquoi: Réduit drastiquement le nombre de documents et les RU d'écriture, tout en co-localisant les données pour des requêtes de plage de temps efficaces au sein d'une partition.

Besoin d'effectuer plusieurs opérations de création, de mise à jour ou de suppression en une seule transaction atomique.

→Utiliser la fonctionnalité TransactionalBatch du SDK. Toutes les opérations doivent cibler la même clé de partition logique.

Pourquoi: Fournit des garanties ACID pour jusqu'à 100 opérations au sein d'une seule partition, garantissant que toutes les opérations réussissent ou échouent ensemble.

Les documents doivent être automatiquement supprimés d'un conteneur après une période spécifique (par exemple, 30 jours).

→Activer le Time to Live (TTL) sur le conteneur et définir la valeur `ttl` par défaut en secondes (par exemple, 2592000 pour 30 jours). Un `ttl` de -1 sur un document individuel remplace la valeur par défaut et empêche l'expiration.

Pourquoi: Le TTL est une fonctionnalité sans coût qui utilise les RU restants pour effectuer des suppressions en arrière-plan, offrant un moyen efficace et sans intervention de gérer le cycle de vie des données.

Besoin de stocker de grands objets binaires (images, vidéos, documents > 2 Mo) associés aux métadonnées Cosmos DB.

→Stocker l'objet binaire dans Azure Blob Storage. Stocker l'URI du blob dans le document Cosmos DB avec les métadonnées.

Pourquoi: Cosmos DB est optimisé pour les métadonnées structurées et a une limite de document de 2 Mo. Blob Storage est un service économique et évolutif pour le stockage de grands objets.

Les mêmes données doivent être interrogées par différentes propriétés, ce qui conduit à des requêtes inter-partitions inefficaces (par exemple, interroger les commandes par client, puis par produit).

→Utiliser le Change Feed pour remplir un second conteneur (une vue matérialisée) avec les mêmes données, mais partitionnées par la propriété de requête secondaire.

Pourquoi: Déplace le calcul du temps de lecture vers le temps d'écriture, permettant des requêtes efficaces sur une seule partition pour plusieurs modèles d'accès.

Besoin d'exécuter des requêtes analytiques complexes (agrégations, jointures) sur des données opérationnelles en direct sans impacter la charge de travail transactionnelle.

→Activer Azure Synapse Link sur le conteneur Cosmos DB. Exécuter des requêtes analytiques sur le magasin analytique du conteneur en utilisant les pools SQL serverless ou Spark de Synapse.

Pourquoi: Fournit une solution HTAP cloud-native sans ETL. Les requêtes sur le magasin analytique en colonnes ne consomment pas de RU transactionnels et sont très performantes.

Besoin de déclencher des actions en aval de manière évolutive, fiable et serverless en réponse aux changements de données.

→Utiliser une fonction Azure avec le déclencheur Cosmos DB. Le déclencheur utilise automatiquement la bibliothèque Change Feed Processor.

Pourquoi: C'est le modèle recommandé pour les architectures événementielles. Il offre une mise à l'échelle automatique, un pointage de contrôle et une gestion des baux de partition.

Référence↗

Une opération doit mettre à jour atomiquement la base de données et publier un message vers un système de messagerie (par exemple, Service Bus, Event Hubs).

→Effectuer l'écriture dans la base de données. Utiliser un processeur Change Feed pour lire de manière fiable le changement validé et publier le message correspondant, avec une logique de réessai.

Pourquoi: Évite les écritures doubles non fiables et la nécessité de transactions distribuées. Le Change Feed agit comme une boîte d'envoi durable, garantissant la livraison éventuelle du message.

Choisir une clé de partition pour un nouveau conteneur afin d'assurer performance et évolutivité.

→Sélectionner une propriété avec une cardinalité élevée qui est présente dans la plupart, sinon toutes, les opérations de lecture ponctuelle et de requête.

Pourquoi: Aligner la clé de partition avec le filtre de requête le plus courant garantit que la plupart des opérations sont acheminées vers une seule partition logique, ce qui est le modèle d'accès le plus efficace.

Référence↗

Une seule valeur de clé de partition reçoit un volume de requêtes disproportionnellement élevé, entraînant un étranglement (une "partition chaude").

→Créer une clé de partition synthétique en concaténant la clé originale avec un suffixe aléatoire ou une autre propriété à forte cardinalité (par exemple, `userId + "-" + random(1-10)`).

Pourquoi: Distribue la charge d'écriture et de lecture pour une seule entité logique sur plusieurs partitions physiques, atténuant ainsi l'étranglement.

Les données doivent être partitionnées sur plusieurs niveaux (par exemple, tenant, puis année, puis mois) pour éviter les grandes partitions et prendre en charge les requêtes multiniveaux.

→Configurer une clé de partition hiérarchique avec un tableau ordonné de chemins, comme `["/tenantId", "/year"]`.

Pourquoi: Permet un sous-partitionnement pour éviter la limite de partition logique de 20 Go et permet un routage plus efficace pour les requêtes qui filtrent sur la hiérarchie.

Une application distribuée globalement avec écritures multi-régions activées doit gérer les mises à jour concurrentes du même document.

→Pour les écrasements simples, utiliser Last-Writer-Wins (LWW). Pour les opérations nécessitant une logique de fusion (par exemple, incrémenter un compteur, mettre à jour un inventaire), utiliser une politique de résolution de conflits personnalisée avec une procédure stockée de fusion.

Pourquoi: La logique de fusion personnalisée empêche la perte de données (par exemple, un incrément perdu) qui se produirait avec LWW, garantissant l'intégrité des données pour les opérations commerciales critiques.

Équilibrer la latence de lecture, la disponibilité et la cohérence des données pour une application distribuée globalement.

→Par défaut, utiliser la cohérence de Session pour un bon équilibre et la lecture de ses propres écritures. Utiliser Bounded Staleness pour un décalage de lecture prévisible. Remplacer les opérations d'écriture/lecture critiques spécifiques par une cohérence Strong si nécessaire.

Pourquoi: Session est le niveau le plus largement utilisé, offrant une faible latence et des garanties solides au sein d'une session client. Le remplacement par requête permet une flexibilité.

Les opérations d'écriture consomment des RU excessifs, et seul un petit sous-ensemble de propriétés de document est utilisé dans les filtres de requête.

→Passer de la politique d'indexation par défaut à une politique personnalisée. Inclure explicitement les chemins pour les propriétés interrogées et exclure tous les autres chemins (`"/*"` dans `excludedPaths`).

Pourquoi: Chaque propriété indexée entraîne un coût RU lors des écritures. L'exclusion des propriétés inutilisées peut réduire considérablement la consommation de RU en écriture et la taille de stockage de l'index.

Référence↗

Une requête fréquente filtre sur une propriété et trie par une autre (par exemple, `WHERE c.status = "active" ORDER BY c.timestamp DESC`).

→Créer un index composite sur les propriétés dans l'ordre où elles apparaissent dans la requête : `(status ASC, timestamp DESC)`.

Pourquoi: Permet au moteur de requête de servir le résultat filtré et trié directement à partir de l'index, évitant une opération de tri en mémoire coûteuse et réduisant drastiquement la charge en RU.

Une requête récupère de grands documents, mais l'application n'a besoin que d'une ou deux petites propriétés de ceux-ci.

→Utiliser la projection de requête pour sélectionner uniquement les propriétés requises (par exemple, `SELECT c.id, c.name FROM c`) au lieu de `SELECT *`.

Pourquoi: Réduit le coût RU en diminuant la taille de la charge utile de données transférée du moteur de base de données au client.

Une application interroge fréquemment les mises à jour de documents, mais les données changent rarement, ce qui entraîne des coûts RU élevés pour les lectures.

→Stocker l'ETag de la dernière lecture. Lors des lectures ultérieures, envoyer l'ETag dans un en-tête `If-None-Match`.

Pourquoi: Si le document n'a pas changé, Cosmos DB renvoie un statut 304 Not Modified avec une charge RU minimale (généralement ~1 RU), économisant coût et bande passante.

Une charge de travail présente des modèles de trafic variables ou imprévisibles, avec des pics et des creux significatifs.

→Configurer le débit Autoscale sur la base de données ou le conteneur. Définir le maximum de RU/s nécessaires pour la charge maximale.

Pourquoi: Met automatiquement à l'échelle le débit entre 10 % du maximum et le maximum de RU/s en fonction de l'utilisation, optimisant les coûts en ne payant pas pour la capacité provisionnée inactive.

Une charge de travail est destinée au développement, aux tests, ou à une application à faible trafic avec de longues périodes d'inactivité.

→Utiliser le mode de capacité Serverless pour le compte Cosmos DB.

Pourquoi: Vous ne payez que les RU consommés par opération, sans capacité minimale provisionnée. C'est l'option la plus rentable pour les charges de travail sporadiques.

Besoin d'ingérer ou de modifier un grand nombre de documents (milliers à millions) le plus rapidement possible.

→Utiliser la fonctionnalité de support en bloc du SDK (par exemple, `AllowBulkExecution = true` dans le SDK .NET v3).

Pourquoi: Le SDK optimise pour un débit élevé en regroupant les opérations par lots, en gérant la concurrence et en gérant les réessais/l'étranglement en interne, surpassant de loin les opérations séquentielles.

Une procédure stockée traitant un grand lot de documents expire.

→Implémenter une exécution bornée. La procédure stockée doit vérifier si elle approche la limite d'exécution de 5 secondes et, si tel est le cas, renvoyer un jeton de continuation au client. Le client ré-invoque ensuite la procédure avec le jeton pour reprendre le traitement.

Pourquoi: Les procédures stockées ont une limite de temps d'exécution stricte. Un modèle de continuation est la méthode standard pour gérer une logique côté serveur longue et en plusieurs étapes.

Une application critique nécessite une haute disponibilité avec une perte de données minimale (RPO) et un temps de récupération rapide (RTO) en cas de panne régionale.

→Configurer le compte Cosmos DB avec plusieurs régions d'écriture et activer le basculement automatique.

Pourquoi: Fournit les RPO et RTO les plus bas. Les données sont répliquées entre les régions et, en cas de panne, Cosmos DB promeut automatiquement une région secondaire pour devenir la nouvelle région d'écriture principale.

Besoin de la capacité de récupérer suite à une suppression ou corruption accidentelle de données en restaurant la base de données à un point spécifique dans le temps.

→Activer le mode de sauvegarde continue sur le compte Cosmos DB.

Pourquoi: La sauvegarde continue vous permet de restaurer à n'importe quel point dans le temps (à la seconde près) pendant la période de rétention (7 ou 30 jours). L'opération de restauration crée un nouveau compte.

Référence↗

Une exigence de conformité stipule que les clés de chiffrement des données doivent être gérées et contrôlées par le client.

→Configurer le compte Cosmos DB avec des clés gérées par le client (CMK), en utilisant une clé d'un Azure Key Vault.

Pourquoi: Fournit une couche de sécurité supplémentaire où vous contrôlez le cycle de vie des clés (y compris la rotation et la révocation) pour le chiffrement au repos.

Besoin d'accorder à une application ou à un utilisateur un accès granulaire, basé sur l'identité, aux données, en suivant le principe du moindre privilège.

→Utiliser l'intégration Azure AD et attribuer un rôle intégré (par exemple, Lecteur de données intégré Cosmos DB) ou un rôle RBAC personnalisé, limité au conteneur ou à la base de données spécifique.

Pourquoi: Élimine le besoin de gérer et de partager les clés maîtresses. RBAC fournit un contrôle d'accès basé sur l'identité et auditable.

Un compte Cosmos DB doit être accessible uniquement depuis un Réseau Virtuel Azure (VNet) spécifique, sans trafic sur l'internet public.

→Créer un Private Endpoint pour le compte Cosmos DB dans le VNet et désactiver l'accès réseau public dans les paramètres du pare-feu.

Pourquoi: Les Private Endpoints fournissent une adresse IP privée pour le compte Cosmos DB au sein de votre VNet, garantissant que tout le trafic transite par le backbone sécurisé d'Azure.

Diagnostiquer la cause profonde des erreurs d'étranglement HTTP 429 (Trop de requêtes).

→Surveiller la métrique "Normalized RU Consumption" dans Azure Monitor. Utiliser les journaux de diagnostic (`CDBPartitionKeyRUConsumption`) pour identifier quelles clés de partition consomment le plus de RU.

Pourquoi: La consommation normalisée de RU indique si le débit global est épuisé. Les journaux au niveau de la partition identifient les partitions chaudes, ce qui est une cause fréquente d'étranglement même lorsque l'utilisation globale est faible.

Besoin de surveiller et d'alerter sur la latence des requêtes pour assurer la conformité aux SLA.

→Surveiller la métrique "Server Side Latency P99" dans Azure Monitor. Créer une règle d'alerte lorsque cette métrique dépasse le seuil de SLA.

Pourquoi: La latence P99 représente l'expérience la plus défavorable pour 99% des requêtes et est la base des SLA de Cosmos DB. C'est un indicateur plus significatif des problèmes de performance que la latence moyenne.

Une exigence de conformité stipule que toutes les opérations d'accès aux données (lectures, écritures, requêtes) doivent être auditées.

→Activer les Paramètres de Diagnostic sur le compte Cosmos DB et transférer la catégorie de journal `DataPlaneRequests` vers un espace de travail Log Analytics ou un compte de stockage.

Pourquoi: Le journal `DataPlaneRequests` fournit des informations détaillées sur chaque opération de données, y compris le type d'opération, l'adresse IP du client et la ressource accédée, ce qui est essentiel pour l'audit de sécurité.

Un client non fiable (par exemple, une application mobile) a besoin d'un accès temporaire et limité à des ressources Cosmos DB spécifiques (par exemple, uniquement les documents de sa propre partition).

→Implémenter un service de niveau intermédiaire fiable qui authentifie l'utilisateur, puis utilise une clé principale pour générer et renvoyer un jeton de ressource de courte durée et à portée de permission au client.

Pourquoi: C'est le modèle le plus sécurisé pour l'accès côté client, car il évite d'exposer les clés principales et fournit un contrôle d'accès temporaire et granulaire.