Choisir le bon niveau de cohérence
Chacun des modèles de cohérence peut être utilisé pour des scénarios réels spécifiques. Chacun fournit des compromis précis en matière de disponibilité et de niveau de performance, et chacun est accompagné de contrats SLA complets. Les considérations simples suivantes vous aideront à faire le bon choix dans de nombreux scénarios courants.
Configurer le niveau de cohérence par défaut
Vous pouvez configurer le niveau de cohérence par défaut sur votre compte Azure Cosmos DB à tout moment. Le niveau de cohérence par défaut configuré sur votre compte s’applique à toutes les bases de données Azure Cosmos DB et tous les conteneurs sous ce compte. Toutes les lectures et requêtes émises vers un conteneur ou une base de données utilisent le niveau de cohérence par défaut spécifié.
La cohérence de lecture s’applique à une même opération de lecture dans une partition logique. L’opération de lecture peut être émise par un client distant ou une procédure stockée.
Garanties associées aux niveaux de cohérence
Azure Cosmos DB garantit que 100 % des requêtes de lecture respecteront la garantie de cohérence dans le cadre du niveau de cohérence choisi. Les définitions précises des cinq niveaux de cohérence dans Azure Cosmos DB (en utilisant le langage de spécification TLA +) sont fournies dans le référentiel GitHub azure-cosmos-tla.
Cohérence forte
une cohérence forte offre une garantie de linéarisabilité. La linéarisabilité fait référence aux demandes de traitement simultanées. Garantit que les lectures retournent la version validée la plus récente d’un élément. Un client ne voit jamais une écriture partielle ou non validée. Les utilisateurs sont toujours assurés de lire la toute dernière écriture validée.
Niveau de cohérence obsolescence limitée
Dans la cohérence de l’obsolescence limitée, le décalage des données entre deux régions est toujours inférieur à une quantité spécifiée. La quantité peut être exprimée en « K » versions (c’est-à-dire « mises à jour ») d’un élément ou par rapport à « T » intervalles de temps, suivant le seuil qui est atteint en premier. En d’autres termes, lorsque vous choisissez l’obsolescence limitée, « l’obsolescence » maximum des données dans n’importe quelle région peut être configurée de deux manières :
- Nombre de versions (K) de l’élément
- Intervalle de temps (T) pendant lequel les lectures peuvent être en retard par rapport aux écritures
L’obsolescence limitée est principalement bénéfique pour les comptes d’écriture dans une seule région avec deux régions ou plus. Si le décalage des données dans une région (déterminé par partition physique) dépasse la valeur d’obsolescence configurée, les écritures pour cette partition sont limitées jusqu’à ce que l’obsolescence soit rétablie dans la limite supérieure configurée.
Pour un compte monorégion, l’obsolescence limitée fournit les mêmes garanties de cohérence d’écriture que les niveaux de cohérence Session et Éventuel. Avec l’obsolescence limitée, les données sont répliquées vers une majorité locale (trois réplicas dans un jeu de quatre réplicas) dans la région unique.
Cohérence de session
Avec une cohérence de session, dans une session à un seul client, il est garanti que les lectures honorent les lectures de vos écritures et les écritures suivant les lectures. Cette garantie suppose une session avec un seul « processus d’écriture » ou le partage du jeton de session pour plusieurs processus d’écriture.
Comme tous les niveaux de cohérence inférieurs au niveau Fort (Strong), les écritures sont répliquées sur un minimum de trois réplicas (dans un jeu de quatre réplicas) dans la région locale, avec une réplication asynchrone vers toutes les autres régions.
Niveau de cohérence préfixe cohérent
Dans le préfixe cohérent, les mises à jour effectuées en tant qu’écritures de documents uniques voient la cohérence éventuelle. Les mises à jour effectuées en tant que lot dans une transaction, sont retournées cohérentes avec la transaction dans laquelle elles ont été validées. Les opérations d’écriture dans une transaction de plusieurs documents sont toujours visibles ensemble.
Imaginez que deux opérations d’écriture sont effectuées sur les documents Doc 1 et Doc 2, dans les transactions T1 et T2. Lorsque le client effectue une lecture dans un réplica, l’utilisateur voit « Doc 1 v1 et Doc 2 v1 » ou « Doc 1 v2 et Doc 2 v2 », mais jamais « Doc 1 v1 et Doc 2 v2 » ou « Doc 1 v2 et Doc 2 v1 » pour la même opération de lecture ou de requête.
Cohérence éventuelle
Avec une cohérence d’événement, il n’existe aucune garantie de classement des lectures. En l’absence d’autres écritures, les réplicas finissent par converger.
La cohérence éventuelle est la forme de cohérence la plus faible, car un client peut lire des valeurs plus anciennes que celles qu’il a déjà lues. La cohérence éventuelle est idéale quand l’application ne demande aucune garantie de classement. Le nombre de retweets, de mentions J’aime ou de commentaires non liés à un thread en sont des exemples.