Questions fréquentes (FAQ) sur les tables globales - AWS Conseils prescriptifs

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.

Questions fréquentes (FAQ) sur les tables globales

Cette section contient les réponses aux questions fréquentes sur les tables globales DynamoDB.

Quel est le coût des tables globales ?

  • Le prix d'une opération d'écriture dans une table DynamoDB classique est exprimé en unités de capacité d'écriture WCUs () pour les tables provisionnées ou en unités de demande d'écriture () pour les tables à la demande. WRUs Si vous écrivez un élément de 5 Ko, il implique des frais de 5 unités. Le prix d'une écriture dans une table globale est exprimé en unités de capacité d'écriture répliquées (rWCUs) pour les tables provisionnées ou en unités de demande d'écriture répliquées (rWRUs) pour les tables à la demande. r WCUs et r ont le même prix WRUs que et. WCUs WRUs

  • Des frais RWcu et RWru sont facturés dans chaque région où l'élément est écrit directement ou écrit par réplication.

  • Des frais de transfert de données entre régions s’appliquent.

  • L’écriture dans un index secondaire global (GSI) est considérée comme une opération d’écriture locale et utilise des unités d’écriture normales.

  • Aucune capacité réservée n'est disponible pour r WCUs ou r pour le WRUs moment. L'achat de capacité réservée WCUs peut toujours être avantageux pour les tables qui GSIs consomment des unités d'écriture.

  • Lorsque vous ajoutez une nouvelle région à une table globale, DynamoDB démarre automatiquement la nouvelle région et vous facture comme s’il s’agissait d’une restauration de table, en fonction de la taille en Go de la table. Il facture également des frais de transfert de données entre régions.

Quelles sont les régions prises en charge par les tables globales ?

Les tables globales (version actuelle, version 2019) prennent en charge toutes Régions AWS les tables MREC et les ensembles régionaux suivants pour les tables MRSC :

  • Ensemble de régions des États-Unis : USA Est (Virginie du Nord), USA Est (Ohio), USA Ouest (Oregon)

  • Ensemble de régions de l'UE : Europe (Irlande), Europe (Londres), Europe (Paris), Europe (Francfort)

  • Ensemble de régions AP : Asie-Pacifique (Tokyo), Asie-Pacifique (Séoul) et Asie-Pacifique (Osaka)

Comment sont GSIs gérées les tables globales ?

Dans les tables globales (version actuelle de 2019), lorsque vous créez un GSI dans une région, il est automatiquement créé dans les autres régions participantes et automatiquement rempli.

Comment arrêter la réplication d’une table globale ?

  • Vous pouvez supprimer une table de réplica de la même manière qu’une autre table. La suppression de la table globale arrête la réplication vers cette région et supprime la copie de la table conservée dans cette région. Toutefois, vous ne pouvez pas arrêter la réplication tout en conservant des copies de la table en tant qu’entités indépendantes, ni suspendre la réplication.

  • Une table MRSC doit être déployée dans exactement trois régions. Pour supprimer les répliques, vous devez supprimer toutes les répliques ainsi que le témoin afin que la table MRSC devienne une table locale.

Comment Amazon DynamoDB Streams interagit-il avec les tables globales ?

  • Chaque table globale produit un flux indépendant basé sur toutes ses opérations d’écriture, d’où qu’elles proviennent. Vous pouvez choisir de consommer ce flux DynamoDB dans une région ou dans toutes les régions (indépendamment). Si vous souhaitez traiter des opérations d’écritures locales mais pas répliquées, vous pouvez ajouter votre propre attribut de région à chaque élément afin d’identifier la région d’écriture. Vous pouvez ensuite utiliser un filtre d' AWS Lambda événements pour appeler la fonction Lambda uniquement pour les opérations d'écriture dans la région locale. Cela facilite les opérations d’insertion et de mise à jour, mais pas les opérations de suppression.

  • Les tables globales configurées pour une cohérence éventuelle entre plusieurs régions (tables MREC) répliquent les modifications en lisant ces modifications à partir d'un flux DynamoDB sur une table de réplication et en appliquant ces modifications à toutes les autres tables de réplication. Par conséquent, DynamoDB Streams est activé par défaut sur toutes les répliques d'une table globale MREC et ne peut pas être désactivé sur ces répliques. Le processus de réplication MREC peut combiner plusieurs modifications en un court laps de temps en une seule opération d'écriture répliquée. Par conséquent, le flux de chaque réplique peut contenir des enregistrements légèrement différents. Les enregistrements DynamoDB Streams sur les répliques MREC sont toujours classés par article, mais l'ordre entre les éléments peut différer selon les répliques.

  • Les tables globales configurées pour une forte cohérence multirégionale (tables MRSC) n'utilisent pas DynamoDB Streams pour la réplication. Cette fonctionnalité n'est donc pas activée par défaut sur les répliques MRSC. Vous pouvez activer DynamoDB Streams sur une réplique MRSC. Les enregistrements DynamoDB Streams sur les répliques MRSC sont identiques pour chaque réplique et sont toujours commandés par article, mais l'ordre des articles peut différer selon les répliques.

Comment les tables globales gèrent-elles les transactions ?

  • Les opérations transactionnelles sur les tables MRSC généreront des erreurs.

  • Les opérations transactionnelles sur les tables MREC fournissent des garanties d'atomicité, de cohérence, d'isolation et de durabilité (ACID) uniquement dans la région où l'opération d'écriture a eu lieu initialement. 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 MREC avec 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) lorsque les modifications sont répliquées. Les modifications seront uniquement répliquées sur les autres régions une fois validées dans la région source.

Comment les tables globales interagissent-elles avec le cache de DynamoDB Accelerator (DAX) ?

Les tables globales contournent le DAX en mettant directement à jour DynamoDB. Ainsi, DAX ne sait pas qu’il contient des données obsolètes. Le cache DAX n’est actualisé que lorsque la durée de vie du cache expire.

Les balises présentes sur les tables se propagent-elles ?

Non, les balises ne se propagent pas automatiquement.

Dois-je sauvegarder des tables dans toutes les régions ou dans une seule ?

La réponse dépend de l’objectif de la sauvegarde.

  • Si vous souhaitez garantir la durabilité des données, DynamoDB fournit déjà cette garantie. Le service garantit la durabilité.

  • Si vous souhaitez conserver un instantané des enregistrements historiques (par exemple, pour répondre à des exigences réglementaires), une sauvegarde dans une région doit suffire. Vous pouvez copier la sauvegarde vers d’autres régions en utilisant AWS Backup.

  • Si vous souhaitez récupérer des données supprimées ou modifiées par erreur, utilisez DynamoDB point-in-time recovery (PITR) dans une région.

Comment déployer des tables globales à l'aide de AWS CloudFormation ?

  • CloudFormation représente une table DynamoDB et une table globale sous la forme de deux ressources distinctes : et. AWS::DynamoDB::Table AWS::DynamoDB::GlobalTable Une méthode consiste à créer toutes les tables susceptibles d’être globales à l’aide de la construction GlobalTable, à les conserver dans un premier temps sous forme de tables autonomes et à ajouter des régions ultérieurement, si nécessaire.

  • Dans CloudFormation, chaque table globale est contrôlée par une seule pile, dans une seule région, quel que soit le nombre de répliques. Lorsque vous déployez votre modèle, il CloudFormation crée et met à jour toutes les répliques dans le cadre d'une opération de pile unique. Vous ne devez pas déployer la même ressource AWS::DynamoDB::GlobalTable dans plusieurs régions. Cette opération n'est pas prise en charge et entraînera des erreurs. Si vous déployez votre modèle d’application dans plusieurs régions, vous pouvez utiliser des conditions pour ne créer la ressource AWS::DynamoDB::GlobalTable que dans une seule région. Vous pouvez également choisir de définir vos ressources AWS::DynamoDB::GlobalTable dans une pile distincte de votre pile d’applications et vous assurer qu’elle n’est déployée que dans une seule région.

  • Si vous avez une table normale et que vous souhaitez la convertir en table globale tout en la gérant en CloudFormation : définissez la politique de suppression surRetain, supprimez la table de la pile, convertissez-la en table globale dans la console, puis importez la table globale en tant que nouvelle ressource dans la pile. Pour plus d'informations, consultez le AWS GitHub référentiel amazon-dynamodb-table-to- global-table-cdk.

  • La réplication entre comptes n’est pas prise en charge pour le moment.