Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Fonctionnement des tables globales
Important
Cette documentation concerne la version 2017.11.29 (ancienne) des tables globales, qui doit être évitée pour les nouvelles tables globales. Les clients doivent utiliser la version 2019.11.21 (actuelle) de Global Tables dans la mesure du possible, car elle offre une plus grande flexibilité, une efficacité accrue et consomme moins de capacité d'écriture que la version 2017.11.29 (ancienne version).
Pour déterminer quelle version vous utilisez, consultez Déterminer la version de la table globale DynamoDB que vous utilisez. Pour mettre à jour les tables globales de la version 2017.11.29 (ancienne) vers la version 2019.11.21 (actuelle), consultez Mise à niveau des tables globales.
Les sections suivantes vous aideront à comprendre les concepts et le comportement des tables globales dans Amazon DynamoDB.
Concepts de table globaux pour la version 2017.11.29 (ancienne)
Une table globale est un ensemble d'une ou plusieurs répliques de tables, toutes détenues par un seul AWS compte.
Une table de réplique (ou réplica) est une table DynamoDB unique qui fonctionne comme une partie d'une table globale. Chaque réplica stocke le même ensemble d'éléments de données. Une table globale donnée ne peut avoir qu'une seule table de réplique par région AWS .
Voici une présentation conceptuelle de la création d'une table globale.
-
Créez une table DynamoDB ordinaire, avec DynamoDB Streams activé, dans une région. AWS
-
Répétez l'étape 1 pour toute autre région dans laquelle vous souhaitez répliquer vos données.
-
Définissez une table globale DynamoDB basée sur les tables que vous avez créées.
AWS Management Console Automatise ces tâches, ce qui vous permet de créer un tableau global plus rapidement et plus facilement. Pour de plus amples informations, veuillez consulter Création d'une table globale.
La table globale DynamoDB ainsi obtenue se compose de plusieurs tables de réplique, une par région, que DynamoDB traite comme une seule unité. Les réplicas a les mêmes nom de table et schéma de clé primaire. Quand une application écrit des données dans une table de réplique dans une région, DynamoDB propage automatiquement l'écriture aux autres tables de réplique dans les autres régions AWS .
Important
Pour assurer la synchronisation de vos données de table, les tables globales créent automatiquement les attributs suivants pour chaque élément :
-
aws:rep:deleting -
aws:rep:updatetime -
aws:rep:updateregion
Ne modifiez pas ces attributs et ne créez pas d'attributs du même nom.
Vous pouvez ajouter des tables de réplique à la table globale de façon que celle-ci soit disponible dans d'autres régions. (Pour ce faire, la table globale doit être vide. En d'autres termes, aucune des tables de réplique ne peut contenir de données.)
Vous pouvez également supprimer une table de réplique d'une table globale. Si vous faites cela, la table est complètement dissociée de la table globale. Cette table nouvellement indépendante n'interagit plus avec la table globale, et les données ne sont plus propagées vers ou depuis la table globale.
Avertissement
Sachez que le retrait d'une réplique n'est pas un processus atomique. Pour garantir un comportement cohérent et un état connu, vous pouvez envisager de détourner le trafic d'écriture de votre application du réplica pour qu'il soit supprimé à l'avance. Après l'avoir supprimée, attendez que tous les points de terminaison de la région de réplication indiquent que la réplique est dissociée avant de procéder à d'autres écritures dans sa propre table régionale isolée.
Tâches courantes
Les tâches courantes pour les tables globales fonctionnent comme suit.
Vous pouvez supprimer la table de réplica d'une table globale de la même manière qu'une table normale. Cela arrêtera la réplication vers cette région et supprimera la copie de la table conservée dans cette région. Vous ne pouvez pas séparer la réplication et créer des copies de la table en tant qu'entités indépendantes.
Note
Vous ne pourrez supprimer une table source qu'au moins 24 heures après son utilisation pour créer une nouvelle région. Si vous essayez de la supprimer trop tôt, vous recevrez une erreur.
Des conflits peuvent apparaître si des applications mettent à jour le même élément dans différentes régions presque simultanément. Pour garantir la cohérence finale, les tables globales DynamoDB utilisent une méthode « priorité à la dernière écriture » pour rapprocher des mises à jour simultanées. Tous les réplicas s'accordent sur la dernière mise à jour et convergent vers un état dans lequel ils ont tous des données identiques.
Note
Il existe plusieurs méthodes pour éviter les conflits, notamment :
Utiliser une IAM politique pour n'autoriser les écritures dans la table que dans une seule région.
Utiliser une IAM politique pour acheminer les utilisateurs vers une seule région et conserver l'autre en veille inactive, ou acheminer alternativement des utilisateurs impairs vers une région et des utilisateurs pairs vers une autre région.
Éviter l'utilisation de mises à jour non idempotentes telles que Bookmark = Bookmark + 1, au profit de mises à jour statiques telles que Bookmark=25.
Surveillance des tables globales
Vous pouvez l'utiliser CloudWatch pour observer la métriqueReplicationLatency. Cette métrique suit le temps écoulé entre le moment où un élément mis à jour apparaît dans le flux DynamoDB pour une table de réplication et le moment où cet élément apparaît dans un autre réplica de la table globale. ReplicationLatencyest exprimé en millisecondes et est émis pour chaque paire source-région et destination-région. Il s'agit de la seule CloudWatch métrique fournie par Global Tables v2.
Les latences que vous observerez dépendent de la distance entre les régions que vous avez choisies, ainsi que d'autres variables. Les latences comprises entre 0,5 et 2,5 secondes pour les régions peuvent être courantes dans la même zone géographique.
Il est temps de vivre (TTL)
Vous pouvez utiliser Time To Live (TTL) pour spécifier un nom d'attribut dont la valeur indique l'heure d'expiration de l'élément. Cette valeur est spécifiée sous forme de nombre en secondes depuis le début de l'ère Unix.
Avec l'ancienne version des tables globales, les TTL suppressions ne sont pas automatiquement répliquées sur d'autres répliques. Lorsqu'un élément est supprimé via une TTL règle, ce travail est effectué sans consommer d'unités d'écriture.
Sachez que si la capacité d'écriture provisionnée des tables source et cible est très faible, cela peut entraîner un ralentissement, car les TTL suppressions nécessitent une capacité d'écriture.
Flux et transactions avec des transactions globales
Chaque table globale produit un flux indépendant basé sur toutes ses écritures, quel que soit le point d'origine de ces écritures. Vous pouvez choisir de consommer ce flux DynamoDB dans une région ou dans toutes les régions indépendamment.
Si vous souhaitez des écritures locales mais pas répliquées, vous pouvez ajouter votre propre attribut de région à chaque élément. Vous pouvez ensuite utiliser un filtre d'événements Lambda pour appeler uniquement le Lambda pour les écritures dans la région locale.
Les opérations transactionnelles fournissent des garanties ACID (atomicité, cohérence, isolation et durabilité) ONLY dans la région où l'écriture est initialement effectuée. Les transactions ne sont pas prises en charge dans toutes les régions dans les tableaux globaux.
Par exemple, si vous disposez d'une table globale contenant des répliques dans les régions USA Est (Ohio) et USA Ouest (Oregon) et que vous effectuez une TransactWriteItems opération dans la région USA Est (Ohio), vous pouvez observer des transactions partiellement achevées dans la région USA Ouest (Oregon) à mesure que les modifications sont répliquées. Les changements seront uniquement répliqués aux autres régions une fois validés dans la région source.
Note
Les tables globales « contournent » DynamoDB Accelerator en mettant directement à jour DynamoDB. Par conséquent, je ne DAX saurai pas qu'il contient des données périmées. Le DAX cache ne sera actualisé qu'à TTL son expiration.
Les balises des tables globales ne se propagent pas automatiquement.
Débit de lecture et d'écriture
Les tables globales gèrent le débit de lecture et d'écriture de la manière suivante.
La capacité d'écriture doit être identique sur toutes les instances de table dans toutes les régions.
Avec la version 2019.11.21 (actuelle), si la table est configurée pour prendre en charge le dimensionnement automatique ou si elle est en mode à la demande, la capacité d'écriture est automatiquement synchronisée. La quantité actuelle de capacité d'écriture allouée dans chaque région augmentera et diminuera indépendamment dans le cadre de ces paramètres de mise à l'échelle automatique synchronisée. Si la table est mise en mode à la demande, ce mode sera synchronisé avec les autres répliques.
La capacité de lecture peut varier d'une région à l'autre, car les lectures peuvent ne pas être égales. Lorsque vous ajoutez une réplique globale à une table, la capacité de la région source est propagée. Après la création, vous pouvez ajuster la capacité de lecture d'une réplique, et ce nouveau paramètre n'est pas transféré de l'autre côté.
Cohérence et résolution des conflits
Toute modification apportée à un élément d'une table de réplique est répliquée dans tous les autres réplicas au sein de la même table globale. Dans une table globale, un élément nouvellement écrit est généralement propagé à toutes les tables de réplique en quelques secondes.
Avec une table globale, chaque table de réplique stocke le même ensemble d'éléments de données. DynamoDB ne prend pas en charge une réplication partielle limitée à certains éléments.
Une application peut lire et écrire des données dans n'importe quelle table de réplique. DynamoDB prend en charge les lectures éventuellement cohérentes entre régions, mais pas celles fortement cohérentes entre régions. Si votre application n'utilise finalement que des lectures cohérentes et n'émet des lectures que pour une seule AWS région, elle fonctionnera sans aucune modification. En revanche, si votre application nécessite des lectures fortement cohérentes, elle doit effectuer toutes les lectures et écritures fortement cohérentes dans la même région. Autrement, si vous écrivez dans une région et lisez dans une autre, la réponse de lecture peut inclure des données obsolètes ne reflétant pas les résultats des écritures récentes dans l'autre région.
Des conflits peuvent apparaître si des applications mettent à jour le même élément dans différentes régions presque simultanément. Pour veiller à la cohérence éventuelle, les tables globales DynamoDB utilisent un rapprochement de type priorité à la dernière écriture entre des mises à jour quasi-simultanées, où DynamoDB s'efforce de déterminer la dernière écriture. Avec ce mécanisme de résolution de conflits, tous les réplicas s'accordent sur la dernière mise à jour et convergent vers un état dans lequel ils ont tous des données identiques.
Disponibilité et durabilité
Si une seule AWS région est isolée ou dégradée, votre application peut être redirigée vers une autre région et effectuer des lectures et des écritures sur une autre table de réplication. Vous pouvez appliquer une logique métier personnalisée pour déterminer quand rediriger des demandes vers d'autres régions.
Si une région vient à être isolée ou dégradée, DynamoDB conserve une trace des écritures effectuées qui n'ont pas encore été propagées à toutes les tables de réplique. Lorsque la région revient en ligne, DynamoDB reprend la propagation des écritures en attente de cette région vers les tables de réplique dans les autres régions. Il reprend également la propagation des écritures des autres tables de réplique vers la région revenue en ligne. Tous les écrits précédemment réussis finiront par être diffusés, quelle que soit la durée de l'isolement de la région.
