Adaptive Capacity DynamoDB : ce qu'elle fait, et ce qu'elle ne fait pas

DynamoDB répartit ta table sur des partitions, mais ton trafic se répartit rarement de façon uniforme. La capacité en rafale et la capacité adaptative sont les deux mécanismes automatiques qui empêchent une charge déséquilibrée de subir un throttling — jusqu'à ce qu'elle atteigne une limite dure.

Qu'est-ce que la capacité adaptative de DynamoDB ?

La capacité adaptative de DynamoDB est un mécanisme automatique qui déplace du débit inutilisé vers une partition à chaud, pour qu'une clé déséquilibrée ne subisse pas de throttling pendant que le reste de la table reste inactif. Couplée à la capacité en rafale, elle absorbe les pics et le déséquilibre soutenu gratuitement — mais elle ne peut pas pousser une seule clé au-delà du plafond de partition.

• La capacité en rafale te prête jusqu'à 5 minutes (300 secondes) de débit inutilisé pour encaisser de courts pics. C'est un tampon, pas une fonctionnalité que tu règles.
• La capacité adaptative augmente automatiquement le débit d'une partition « à chaud » — en puisant dans la capacité inutilisée du reste de ta table — pour qu'une clé déséquilibrée ne subisse pas de throttling.
• Elle isolera même un élément à chaud sur sa propre partition, donnant à une seule clé jusqu'au plafond de partition de 3 000 RCU / 1 000 WCU.
• Ce n'est pas un permis d'ignorer la conception des clés. Passé le plafond par partition, il n'y a plus rien à emprunter — une clé vraiment à chaud subit quand même un throttling.

Connais d'abord le plafond de partition

Chaque partition est plafonnée indépendamment : 3 000 unités de lecture et 1 000 unités d'écriture par seconde. Cette limite est physique, pas provisionnée — elle tient sur les tables en mode provisionné comme à la demande. (AWS, Capacité en rafale et adaptative.)

Venant de SQL, tu raisonnes en charge serveur totale. Dans DynamoDB, l'unité qui subit le throttling est la partition unique, et une clé déséquilibrée peut fondre pendant que la table est à 90 % inactive. C'est l'écart que les deux mécanismes existent pour combler.

La capacité en rafale absorbe le pic court

Chaque fois que tu n'utilises pas pleinement le débit d'une partition, DynamoDB met de côté le reliquat. Jusqu'à 300 secondes de cette capacité inutilisée sont gardées en réserve, et un pic soudain peut la drainer plus vite que ton taux par seconde ne le permettrait normalement.

C'est invisible et automatique. Tu ne peux pas la dimensionner, et DynamoDB peut en dépenser discrètement une partie pour son propre travail d'arrière-plan. Traite-la comme un coussin pour du trafic en rafales — jamais comme une marge que tu peux planifier.

La capacité adaptative dope la partition à chaud

La capacité en rafale gère les pics courts. La capacité adaptative gère le déséquilibre soutenu. Quand une partition tourne à chaud alors que ses voisines sont inactives, DynamoDB déplace du débit vers celle à chaud — jusqu'au total de la table et au plafond de partition.

Disons que tu exploites une table de télémétrie de flotte à clés VEHICLE#<id> (partition) et TS#<epoch> (tri). Une camionnette de livraison dans une zone de vente flash émet 10× plus de pings que n'importe quelle autre. Sa partition est à chaud ; les partitions des 200 autres camionnettes restent quasi inactives.

La capacité adaptative le remarque et relève le débit de cette seule partition, en puisant dans la capacité inutilisée des partitions froides. Aucune config, aucun coût, aucune montée en température — depuis mai 2019, le boost est quasi instantané. (AWS Database Blog, « How DynamoDB adaptive capacity accommodates uneven access patterns ».)

La partition de la camionnette à chaud a besoin de 150 WCU mais sa part équitable de 100 WCU subirait un throttling ; la capacité adaptative emprunte les WCU inactifs des partitions froides pour la couvrir.

Isolation : quand un seul élément est le problème

Le déséquilibre n'est pas toujours par clé — parfois un seul élément est brûlant. Si un trafic incessant sollicite un élément VEHICLE#HOT, le split-for-heat de DynamoDB rééquilibre les partitions pour que l'élément fréquemment accédé atterrisse seul.

Une fois isolée, la clé de ce seul élément peut tirer le plein plafond de partition : 3 000 RCU et 1 000 WCU. C'est le toit absolu pour une clé — il n'existe aucun mécanisme au-dessus. (AWS, Débit de plage de clés dépassé.)

Une réserve à épingler : la capacité adaptative ne scindera pas une collection d'éléments entre partitions quand la table a un index secondaire local. Un LSI lie la collection à une seule partition — voir GSI vs LSI pour comprendre pourquoi.

Quand la capacité adaptative ne peut pas te sauver

C'est le piège. Les deux mécanismes déplacent du débit autour ; aucun ne crée plus que ce qu'une partition permet physiquement.

Si une seule clé a légitimement besoin de plus de 1 000 écritures par seconde, aucun mécanisme automatique ne te sauve — tu dois répartir la charge sur plus de clés.

Le sharding d'écriture est le correctif habituel : ajoute un suffixe (VEHICLE#HOT#0 … #9) pour que les écritures se ventilent sur plusieurs partitions, puis regroupe les lectures à la relecture.

Ce regroupement est lui-même un pattern d'accès à modéliser délibérément, de la même façon que tu planifierais un chemin de requête dans single-table design — la capacité adaptative achète du temps, pas un laissez-passer sur la conception des clés.

Vois-le sur ta propre table

La capacité adaptative est invisible par conception, donc tu raisonnes à son sujet via un seul symptôme : quelles clés sont à chaud. Quand tu construis le chemin d'écriture shardé, l'Expression Builder génère la syntaxe PutItem et Query pour une clé suffixée.

Pour observer comment une clé se distribue réellement dans tes données, télécharge DynoTable et lance un GROUP BY sur ta clé de partition dans le SQL Workbench pour voir comment les éléments s'accumulent par clé avant de présumer que la capacité adaptative gère la situation. Pour le côté lecture du déséquilibre, voir Query vs Scan.