DynamoDB limité sur une clé chaude malgré la capacité

En bref — Ta table a beaucoup de RCU/WCU inutilisés au total, mais tu es quand même limité parce qu'une seule clé de partition est chaude. Chaque partition physique est conçue pour fournir un maximum de 3 000 unités de lecture et 1 000 unités d'écriture par seconde, quelle que soit la capacité de la table. Le trafic accumulé sur une clé épuise cette partition unique. Étale les requêtes sur davantage de clés de partition distinctes (write-sharding) pour corriger.

Ce que ça signifie

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.

DynamoDB répartit une table sur de nombreuses partitions physiques, et la capacité d'une table est divisée entre elles. Une partition individuelle est conçue pour fournir au plus 3 000 unités de lecture et 1 000 unités d'écriture par seconde — dans les deux modes de capacité. Si ton schéma d'accès concentre le trafic sur une clé de partition, la partition de cette clé atteint son propre plafond et est limitée — même si les métriques à l'échelle de la table semblent sous-utilisées (les champs ThrottlingReason de l'erreur, par ex. TableReadKeyRangeThroughputExceeded, nomment la limite exacte atteinte). La capacité adaptative aide, mais elle ne peut pas sauver une clé réellement déséquilibrée.

Pourquoi ça arrive

Clé de partition à faible cardinalité — un drapeau de statut, un booléen, une « date du jour », ou un locataire unique qui reçoit l'essentiel du trafic.
Un élément viral / vedette — une clé de partition populaire (un produit en tendance, un utilisateur en vogue) attire une charge disproportionnée.
Série temporelle avec une clé « aujourd'hui » — chaque écriture atterrit sur la même clé de partition basée sur la date.
Une clé séquentielle ou monotone de sorte que les écritures se regroupent sur la partition la plus récente.
Un GSI avec une clé de partition à faible cardinalité, qui limite les écritures de la table de base.

Comment le corriger

Augmente la cardinalité de la clé. Conçois la clé de partition pour que les requêtes s'étalent sur de nombreuses valeurs — c'est le correctif le plus efficace.
Write-sharde la clé chaude. Ajoute un suffixe (USER#42#1…USER#42#N) pour qu'une entité logique s'étale sur plusieurs partitions ; répartis les lectures sur les shards.
Ajoute de l'aléatoire ou un suffixe calculé aux clés de série temporelle pour que les écritures « du jour » n'entrent pas toutes en collision.
Mets en cache les lectures chaudes (DAX ou un cache applicatif) pour décharger la pression de lecture sur la partition chaude.
Conserve des nouvelles tentatives à backoff exponentiel — cette erreur est réessayable et le SDK applique un backoff par défaut.
Corrige les clés de GSI à faible cardinalité — un GSI limité limite la table de base.

Tu veux inspecter la distribution des clés pendant que tu remanies ? L'application de bureau DynoTable te permet de filtrer et de trier par clé de partition pour qu'une clé surchargée soit évidente avant que tu re-partitionnes.

Vérifie la taille dans DynoTable

Repère la clé de partition chaude — ouvre la table avec ⌘K, trie par clé de partition, et cherche la clé qui porte bien plus d'éléments que ses voisines. Filtre sur cette clé et inspecte les schémas d'écriture avant de re-sharder.

Modélise des suffixes de write-shard dans le Query Builder et estime le trafic de réessais avec le calculateur de tarifs. Change de profil avec ⌘P ; vois Se connecter à AWS et Installation.

Sources

Best practices for designing partition keys (vérifié le 2026-07-13)
Troubleshooting throttling in Amazon DynamoDB (vérifié le 2026-07-13)

FAQ

Pourquoi DynamoDB me limite-t-il alors que la table a de la capacité disponible ? Parce qu'une seule clé de partition est chaude. Chaque partition physique a un plafond d'environ 3 000 unités de lecture et 1 000 unités d'écriture par seconde quelle que soit la capacité au niveau de la table, si bien que le trafic accumulé sur une clé épuise cette partition unique pendant que les métriques à l'échelle de la table semblent sous-utilisées.

Comment corriger une partition chaude dans DynamoDB ? Augmente la cardinalité de la clé de partition pour que les requêtes s'étalent sur de nombreuses valeurs, write-sharde la clé chaude avec un suffixe, ajoute un suffixe calculé aux clés de série temporelle, et mets en cache les lectures chaudes. Les nouvelles tentatives à backoff exponentiel aident à passer les courts pics mais ne corrigent pas une clé déséquilibrée.

Erreurs liées

ProvisionedThroughputExceededException — l'erreur de limitation générale et les correctifs de capacité.
ThrottlingException — limites de débit du compte / du plan de contrôle.
Apprends : Partitions chaudes · Comment fonctionnent les clés de partition

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.