3- Limites de compte dépassées - Amazon DynamoDB
La limite du compte a dépassé les mesures d'atténuationDiagnostic et surveillance communsProcédures de résolution

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.

3- Limites de compte dépassées

Les tables à la demande ne disposent pas de niveaux de capacité provisionnés à gérer, mais DynamoDB applique des limites de débit au niveau du compte afin d'empêcher une exécution incontrôlée et de garantir une utilisation équitable des ressources pour tous les clients. Ces limites de compte par table servent de garanties ajustables, définies pour chaque combinaison de compte et de région. Lorsque votre taux de consommation en lecture ou en écriture dépasse ces limites, DynamoDB renvoie AccountLimitExceeded un type de motif de limitation dans l'exception de limitation. Les limites de compte par défaut par table s'appliquent automatiquement lorsque les tables ne disposent pas de paramètres de débit maximal personnalisés configurés. Vous pouvez éventuellement configurer des paramètres de débit maximal pour un meilleur contrôle des coûts et une meilleure prévisibilité, ou demander des augmentations de quotas via la Quotas dans Amazon DynamoDB console si les exigences de votre application dépassent les limites par défaut.

La limite du compte a dépassé les mesures d'atténuation

Cette section fournit des conseils de résolution pour les scénarios de limitation des limites de compte. Avant d'utiliser ce guide, assurez-vous d'avoir identifié les raisons spécifiques de la limitation liées à la gestion des exceptions par votre application et d'avoir déterminé le nom de ressource Amazon (ARN) de la ressource affectée. Pour plus d'informations sur la recherche des raisons de la limitation et l'identification des ressources limitées, voir. Cadre de diagnostic de la limitation DynamoDB

Avant de vous lancer dans des scénarios de régulation spécifiques, déterminez d'abord si une action est réellement nécessaire :

  • Évaluez l'impact sur les performances : vérifiez si votre application répond toujours à ses exigences de performances malgré le ralentissement. De nombreuses applications fonctionnent avec succès aux limites du compte ou presque, en particulier lors d'opérations en masse ou de migrations de données.

  • Passez en revue les modèles de limitation : si la régulation est intermittente et que votre application gère les nouvelles tentatives de manière efficace, les limites actuelles peuvent être suffisantes pour votre charge de travail.

Si votre application fonctionne de manière acceptable même lorsque les limites du compte sont parfois atteintes, vous pouvez choisir de simplement suivre la situation plutôt que de mettre en œuvre des modifications immédiates.

Si vous déterminez que la régulation est à l'origine de problèmes de performances ou de fiabilité inacceptables, sélectionnez une raison de régulation spécifique ci-dessous pour trouver les options d'atténuation recommandées :

TableReadAccountLimitExceeded

Quand cela se produit

La consommation de lecture de votre table a dépassé le quota de débit de lecture par table au niveau du compte pour votre région. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.

Approche de résolution

Pour résoudre ce problème de limitation, procédez comme suit :

  • Demande d'augmentation du quota :

    Demandez une augmentation de la limite de débit de lecture par table (code de quota CBE56 L-CF0). Pour connaître les étapes détaillées de soumission de la demande, consultez la section Demande d'augmentation du quota par table.

TableWriteAccountLimitExceeded

Quand cela se produit

La consommation d'écriture de votre table a dépassé le quota de débit d'écriture par table au niveau du compte pour votre région. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.

Approche de résolution

Pour résoudre ce problème de limitation, procédez comme suit :

  • Demande d'augmentation du quota : demandez une augmentation de la limite de débit d'écriture par table (code de quota L-AB614373). Pour connaître les étapes détaillées de soumission de la demande, consultez la section Demande d'augmentation du quota par table.

IndexReadAccountLimitExceeded

Quand cela se produit

Les opérations de lecture dirigées vers un index secondaire global (GSI) consomment plus de débit que le quota de lecture par table de votre compte ne le permet dans votre région actuelle. AWS Le quota de débit de lecture par table au niveau du compte s'applique collectivement à une table et à toutes ses composantes combinées. GSIs Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs pour analyser votre événement de régulation.

Approche de résolution

Choisissez la résolution appropriée en fonction de la répartition des capacités de votre compte :

IndexWriteAccountLimitExceeded

Quand cela se produit

Les opérations d'écriture dans votre table de base génèrent des mises à jour correspondantes d'un GSI qui dépassent collectivement le quota de débit d'écriture par table au niveau du compte pour votre région. AWS Chaque écriture dans un élément de table de base contenant des attributs indexés par un GSI déclenche une opération d'écriture correspondante sur ce GSI. Ces opérations d'écriture combinées sont prises en compte dans votre quota de débit d'écriture par table. Vous pouvez surveiller les CloudWatch métriques Diagnostic et surveillance communs afin d'analyser les modèles et le calendrier de ces événements de régulation et d'identifier les opérations à l'origine de l'activité d'écriture GSI excessive.

Approche de résolution

Choisissez la résolution appropriée en fonction de la répartition des capacités de votre compte :

  • Demande d'augmentation du quota : demandez une augmentation de la limite de débit d'écriture par table (code de quota L-AB614373) afin de répondre à l'augmentation du trafic d'écriture GSI provenant des opérations de table de base. Le quota de débit d'écriture par table s'applique à l'ensemble de la table, y compris à l'ensemble de celle-ci. GSIs Pour connaître les étapes détaillées de soumission de la demande, consultez la section Demande d'augmentation du quota par table.

  • Optimisation des projections GSI : passez en revue les projections et la conception GSI afin de réduire le volume d'écriture à. GSIs

Diagnostic et surveillance communs

Lorsque vous résolvez les problèmes liés au dépassement de la limite du compte, plusieurs CloudWatch indicateurs peuvent vous aider à déterminer si vous atteignez des limites par table ou à l'échelle du compte et à comprendre vos modèles de distribution de capacité.

CloudWatch Indicateurs essentiels

Surveillez ces indicateurs clés pour diagnostiquer la limitation des limites du compte :

Procédures de résolution

Demande d'augmentation du quota par table

Si vos applications doivent fonctionner au-delà des limites de débit par table actuelles, vous devez soumettre une demande d'augmentation de quota en suivant la procédure ci-dessous. Chaque table DynamoDB de AWS votre compte (ainsi que toutes les tables GSIs associées) est soumise à ces quotas de débit dans une région spécifique. Ces quotas représentent la capacité maximale de lecture ou d'écriture que chaque table individuelle et sa batterie GSIs peuvent consommer collectivement, et ils s'appliquent indépendamment à chaque table plutôt que sous forme d'agrégat pour toutes les tables de votre compte.

Vous pouvez éventuellement définir des limites inférieures par table ou par GSI en configurant leurs paramètres de débit maximal à la demande.

  1. Identifiez le quota spécifique qui doit être augmenté :

    • Limite de débit de lecture par table (code de quota L-CF0CBE56) : 40 000 par défaut par table RCUs

    • Limite de débit d'écriture par table (code de quota L-AB614373) : 40 000 WCUs par défaut par table

  2. Utilisez la console AWS Service Quotas pour demander une augmentation :

    • Accédez au service DynamoDB dans Service Quotas

    • Trouvez le quota approprié à l'aide du code de quota

    • Demandez une augmentation en fonction de votre pic d'utilisation prévu

  3. Justifiez l'augmentation, notamment :

    • Schémas d'utilisation actuels et exigences de trafic en période de pointe

    • Justification commerciale de l'augmentation de capacité

    • Calendrier indiquant quand l'augmentation de la capacité est nécessaire

Note

Le traitement des augmentations de quotas prend généralement 24 à 48 heures. Planifiez vos demandes en conséquence et envisagez des stratégies d'atténuation temporaires en attendant leur approbation.

Optimisation des projections et de la conception du GSI

Optimisez les projections et la conception de votre indice secondaire global (GSI) afin de réduire la consommation de capacité et d'améliorer les performances.

Stratégies de projection sélectives

Si vos requêtes ne doivent accéder qu'à quelques attributs, la projection de ces attributs réduit la quantité de données écrites dans le GSI lorsque les éléments de la table de base changent. Pour plus de détails sur les types de projection, voir Projections pour les indices secondaires globaux.

  1. Analyser les modèles de requêtes : passez en revue les modèles de requêtes de votre application pour identifier les attributs réellement accessibles via le GSI.

  2. Utiliser des projections sélectives : uniquement les attributs de projet réellement nécessaires dans les requêtes pour réduire le volume d'écriture.

  3. Remarque KEYS_ONLY : si vos requêtes ne nécessitent que les attributs clés, utilisez la KEYS_ONLY projection pour minimiser le volume d'écriture.

  4. Équilibrez les compromis entre lecture et écriture : la projection d'un nombre réduit d'attributs réduit la consommation de capacité d'écriture mais peut nécessiter des lectures supplémentaires de la table de base.

Implémentation de Sparse GSI

Sparse GSIs contient uniquement les éléments dotés de l'attribut indexé, plutôt que tous les éléments de votre table de base. Cela réduit la densité des partitions et améliore les performances lorsque vous interrogez fréquemment des sous-ensembles de données spécifiques.

  1. Conception GSIs qui inclut uniquement des éléments dotés de valeurs d'attributs spécifiques.

  2. Implémentez l'indexation conditionnelle en définissant l'attribut de clé de partition GSI uniquement sur les éléments qui doivent être indexés.

  3. Utilisez des clés composites en mode sparse GSIs (par exemple, status #timestamp) pour mieux répartir le trafic au sein du sous-ensemble d'éléments indexés.

Pour plus d'informations sur la mise en œuvre de ces stratégies, consultez Bonnes pratiques d'utilisation des index secondaires dans DynamoDB.