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 quelle version des tables globales 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 une collection d'une ou plusieurs tables de réplique, toutes détenues par un seul compte AWS.

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.

1. Créez une table DynamoDB ordinaire, avec DynamoDB Streams activé, dans une région AWS.

2. Répétez l'étape 1 pour toute autre région dans laquelle vous souhaitez répliquer vos données.

3. Définissez une table globale DynamoDB basée sur les tables que vous avez créées.

L'AWS Management Console automatisant ces tâches, vous pouvez créer une table globale plus rapidement et plus facilement. Pour plus d’informations, consultez 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

Gardez à l’esprit que la suppression d'un réplica 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é, attendez que tous les points de terminaison de région de réplica affichent le réplica comme étant dissocié avant d'y effectuer d'autres écritures en tant que tableau des régions isolé.

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 politique IAM pour n'autoriser les écritures que dans la table d'une seule région.

• Utiliser une politique IAM pour acheminer les utilisateurs vers une seule région et laisser l'autre en veille inactive, ou acheminer les utilisateurs impairs vers une région et les 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.

Durée de vie (TTL)

Vous pouvez utiliser la Durée de vie (TTL) pour spécifier un nom d'attribut dont la valeur indique l'heure d'expiration de l'article. 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 suppressions TTL ne sont pas automatiquement répliquées sur d'autres répliques. Lorsqu'un élément est supprimé via une règle TTL, ce travail est effectué sans consommer d'unités d'écriture.

Notez que si la capacité d'écriture provisionnée des tables sources et cibles est très faible, cela peut entraîner une limitation, car les suppressions TTL 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 offrent des garanties ACID (atomicité, cohérence, isolation et durabilité) UNIQUEMENT dans la région dans laquelle a été effectuée l'écriture d'origine. Les transactions ne sont pas prises en charge entre les régions dans les tables globales.

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, DAX ne se rendra pas compte qu'il contient des données périmées. Le cache DAX ne sera actualisé que lorsque le TTL du cache expirera.

• 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 le tableau est configuré pour prendre en charge la mise à l'échelle automatique ou est en mode à la demande, la capacité d'écriture est automatiquement synchronisée. La capacité d'écriture actuellement allouée dans chaque région augmentera et diminuera indépendamment de ces paramètres de dimensionnement automatique synchronisés. 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. 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 utilise uniquement des lectures éventuellement cohérentes et n'émet de lectures que sur une région AWS, 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 région AWS vient à être isolée ou dégradée, votre application peut rediriger vers une autre région et effectuer des lectures et écritures dans une table de réplique différente. 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.