Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Planification de la capacité de débit pour les tables globales DynamoDB

Mode de mise au point
Planification de la capacité de débit pour les tables globales DynamoDB - Amazon DynamoDB

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.

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.

La migration du trafic d'une région vers une autre nécessite un examen attentif des paramètres de la table DynamoDB concernant la capacité.

Quelques considérations relatives à la gestion de la capacité d'écriture :

  • Une table globale doit être en mode à la demande ou provisionné avec Auto Scaling activé.

  • En cas de provisionnement avec Auto Scaling, les paramètres d'écriture (utilisation minimale, maximale et cible) sont répliqués entre les régions. Bien que les paramètres d'Auto Scaling soient synchronisés, la capacité d'écriture réellement provisionnée peut varier indépendamment entre les régions.

  • L'une des raisons pour lesquelles vous pouvez constater une capacité d'écriture allouée différente est due à la fonction de durée de vie. Lorsque vous activez la durée de vie dans DynamoDB, vous pouvez spécifier un nom d'attribut dont la valeur indique l'heure d'expiration de l'élément, au format d'époque Unix, en secondes. Passé ce délai, DynamoDB peut supprimer l'élément sans frais d'écriture. Avec les tables globales, vous configurez la durée de vie dans n'importe quelle région et ce paramètre est répliqué automatiquement dans les autres régions associées à la table globale. Lorsqu'un élément peut être supprimé par le biais d'une règle de durée de vie, ce travail peut être effectué dans n'importe quelle région. L'opération de suppression est effectuée sans consommer d'unités d'écriture sur la table source, mais les tables de réplicas obtiennent une écriture répliquée de cette opération de suppression et entraînent des coûts unitaires d'écriture répliqués.

  • Si vous utilisez Auto Scaling, assurez-vous que le paramètre de capacité d'écriture maximale provisionnée est suffisamment élevé pour gérer toutes les opérations d'écriture ainsi que toutes les opérations de suppression de la durée de vie potentielles. Auto Scaling ajuste chaque région en fonction de sa consommation d'écriture. Les tables à la demande n'ont pas de paramètre de capacité d'écriture maximale provisionnée, mais la limite de débit d'écriture maximal au niveau de la table indique la capacité d'écriture soutenue maximale autorisée par la table à la demande. La limite par défaut est de 40 000, mais elle peut être ajustée. Nous vous recommandons de la définir à un niveau suffisamment élevé pour gérer toutes les opérations d'écriture (y compris les opérations d'écriture de la durée de vie) dont la table à la demande peut avoir besoin. Cette valeur doit être la même dans toutes les régions participantes lorsque vous configurez des tables globales.

Quelques considérations relatives à la gestion de la capacité de lecture :

  • Les paramètres de gestion de la capacité de lecture peuvent différer entre les régions car il est supposé que les différentes régions peuvent avoir des modèles de lecture indépendants. La première fois que vous ajoutez un réplica global à une table, la capacité de la région source est propagée. Après sa création, vous pouvez ajuster les paramètres de capacité de lecture, qui ne sont pas transférés de l'autre côté.

  • Lorsque vous utilisez Auto Scaling de DynamoDB, veillez à ce que les paramètres de capacité de lecture maximale allouée soient suffisamment élevés pour gérer toutes les opérations de lecture dans toutes les régions. Au cours des opérations standard, la capacité de lecture peut être répartie entre les régions, mais lors du basculement, la table doit pouvoir s'adapter automatiquement à l'augmentation de la charge de travail de lecture. Les tables à la demande n'ont pas de paramètre de capacité de lecture maximale provisionnée, mais la limite de débit de lecture maximal au niveau de la table indique la capacité de lecture soutenue maximale autorisée par la table à la demande. La limite par défaut est de 40 000, mais elle peut être ajustée. Nous vous recommandons de la définir à un niveau suffisamment élevé pour gérer toutes les opérations de lecture dont la table pourrait avoir besoin si toutes les opérations de lecture devaient être acheminées vers cette région unique.

  • Si une table d'une région ne reçoit généralement pas de trafic de lecture mais qu'elle doit en absorber une grande partie après un basculement, vous pouvez augmenter la capacité de lecture allouée à la table, attendre la fin de la mise à jour de la table, puis la réapprovisionner. Vous pouvez laisser la table en mode provisionné ou la passer en mode à la demande. Cela permet de préchauffer la table pour qu'elle accepte un niveau de trafic de lecture plus élevé.

ARC propose des contrôles de préparation qui peuvent être utiles pour confirmer que les régions DynamoDB ont des paramètres de table et des quotas de compte similaires, que vous utilisiez Route 53 ou non pour acheminer les demandes. Ces contrôles de préparation peuvent également aider à ajuster les quotas au niveau du compte pour s'assurer qu'ils correspondent.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.