Tables globales DynamoDB : fonctionnement

Les sections suivantes décrivent les concepts et les comportements des tables globales dans Amazon DynamoDB.

Concepts des tables globales

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 . Pour en savoir plus sur la façon de commencer à utiliser des tables globales, consultez Didacticiel : création d'une table globale.

Lorsque vous créez une table globale DynamoDB, celle-ci 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. Lorsqu'une application écrit des données dans une table de réplique d'une région, DynamoDB propage automatiquement l'écriture vers les autres tables de réplication des autres régions. AWS

Vous pouvez ajouter des tables de réplique à la table globale afin que celle-ci soit disponible dans des régions supplémentaires.

Avec la version 2019.11.21 (actuelle), lorsque vous créez un index secondaire global dans une région, il est automatiquement répliqué dans les autres régions et renvoyé.

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 interrompre la réplication et faire en sorte que des copies de la table existent en tant qu'entités indépendantes. Vous pouvez copier la table globale dans une table locale de cette région, puis supprimer le réplica global pour cette région.

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 :

• N'autorisez les écritures dans la table que dans une seule région.

• Acheminez le trafic utilisateur vers différentes régions conformément à vos politiques d'écriture, afin de garantir l'absence de conflits.

• Éviter l'utilisation de mises à jour non idempotentes telles que Bookmark = Bookmark + 1, au profit de mises à jour statiques telles que Bookmark=25.

• N'oubliez pas que lorsque vous acheminez des écritures ou des lectures vers une région, c'est à votre application de s'assurer que ce flux est appliqué.

Surveillance des tables globales

Vous pouvez l'utiliser CloudWatch pour observer la métriqueReplicationLatency. Cette mesure suit le temps écoulé entre le moment où un élément est écrit dans une table de réplique et celui où il apparaît dans un autre réplica dans la table globale. Elle est exprimée en millisecondes et est émise pour chaque paire source-région et destination-région. Cette métrique est conservée dans la région source. Il s'agit de la seule CloudWatch métrique fournie par Global Tables v2.

La latence de réplication que vous rencontrerez dépend de la distance entre la variable que vous avez choisie Régions AWS et d'autres variables. Si votre table d'origine se trouvait dans la région USA Ouest (Californie du Nord) (us-west-1), une réplique située dans une région plus proche, telle que la région USA Ouest (Oregon) (us-west-2), aurait une latence de réplication inférieure à celle d'une réplique située dans une région beaucoup plus éloignée, telle que la région Afrique (Le Cap) (af-south-1).

Note

La latence de réplication n'a aucun effet sur la API latence. Si vous avez un client et une table dans la région A et que vous ajoutez une réplique de tables globales dans la région B, le client et la table dans la région A auront la même latence qu'avant l'ajout de la région B. Si vous appelez l'PutItemAPIopération dans la région B, elle pourra éventuellement être lue dans la région A après un délai d'environ ReplicationLatency le chiffre disponible sur Amazon CloudWatch. Avant qu'il ne soit répliqué, vous recevrez une réponse vide et après la réplication, vous recevrez l'élément ; les deux appels auraient à peu près la même API latence.

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 donnée sous forme de nombre en secondes depuis le début de l'ère Unix. Passé ce délai, DynamoDB peut supprimer l'élément sans frais d'écriture.

Avec les tables globales, vous configurez TTL dans une région, et ce paramètre est automatiquement répliqué dans les autres régions. Lorsqu'un élément est supprimé via une TTL règle, ce travail est effectué sans consommer d'unités d'écriture dans la table source, mais les tables cibles entraîneront des coûts d'unités d'écriture répliquées.

Sachez que si les tables source et cible ont de très faibles capacités d'écriture provisionnées, 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 traitées mais pas des écritures répliquées, vous pouvez ajouter votre propre attribut Region à 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é) uniquement dans la région où l'écriture a été 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 modifications ne seront répliquées dans d'autres régions qu'une fois qu'elles auront été validées 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. Cela signifie qu'une modification de la capacité d'écriture d'une table est répliquée dans les autres.

• 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 une seconde.

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. 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 cohérentes fortes, elle doit effectuer toutes ses lectures et écritures cohérentes fortes dans la même région. DynamoDB ne prend pas en charge les lectures très cohérentes entre les régions. Ainsi, 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.

Si des applications mettent à jour le même élément dans différentes régions presque simultanément, des conflits peuvent apparaître. 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. Ceci est effectué au niveau de l'article. 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 est isolée ou dégradée, DynamoDB garde une trace de toutes les écritures effectuées mais qui n'ont pas été propagées à toutes les tables de réplication. 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 provenant d'autres tables de réplication vers la région qui est désormais de nouveau en ligne.