L'adaptive capacity de DynamoDB

DynamoDB répartit ta table sur des partitions, mais ton trafic se répartit rarement de façon uniforme. La burst capacity et l'adaptive capacity sont les deux mécanismes automatiques qui empêchent une charge déséquilibrée de throttler — jusqu'à ce qu'elle atteigne une limite stricte.

Qu'est-ce que l'adaptive capacity de DynamoDB ?

L'adaptive capacity de DynamoDB est un mécanisme automatique qui réoriente le débit inutilisé vers une partition chaude pour qu'une clé déséquilibrée ne throttle pas pendant que le reste de la table reste inactif. Associée à la burst capacity, elle absorbe gratuitement les pics et les déséquilibres soutenus — mais elle ne peut pas pousser une seule clé au-delà du plafond de partition.

• La burst capacity te prête jusqu'à 5 minutes (300 secondes) de débit inutilisé pour traverser de courts pics. C'est un tampon, pas une fonctionnalité que tu règles.
• L'adaptive capacity augmente automatiquement le débit d'une partition « chaude » — en puisant dans la capacité inutilisée du reste de ta table — pour qu'une clé déséquilibrée ne throttle pas.
• Elle isolera même un item 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 chaude throttle quand même.

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 provisionnées comme on-demand. (AWS, Burst and adaptive capacity.)

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

La burst capacity absorbe le pic court

Chaque fois que tu n'utilises pas pleinement le débit d'une partition, DynamoDB met le reste en réserve. 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 débit 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 en arrière-plan. Considère-la comme un coussin pour le trafic en rafales — jamais comme une marge sur laquelle tu peux planifier.

L'adaptive capacity booste la partition chaude

La burst capacity gère les pics courts. L'adaptive capacity gère le déséquilibre soutenu. Quand une partition chauffe pendant que ses voisines sont inactives, DynamoDB déplace du débit vers la chaude — 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é VEHICLE#<id> (partition) et TS#<epoch> (tri). Une camionnette de livraison dans une zone de vente flash émet 10× les pings de n'importe quelle autre. Sa partition est chaude ; les partitions des 200 autres camionnettes sont presque inactives.

L'adaptive capacity le remarque et soulève le débit de cette partition, en puisant dans la capacité inutilisée des partitions froides. Pas de config, pas de coût, pas de mise en chauffe — depuis mai 2019, le boost est effectivement instantané. (AWS Database Blog, « How DynamoDB adaptive capacity accommodates uneven access patterns ».)

La partition de la camionnette chaude a besoin de 150 WCU mais sa part équitable de 100 WCU throttlerait ; l'adaptive capacity emprunte le WCU inactif des partitions froides pour la couvrir.

Isolation : quand un seul item est le problème

Le déséquilibre n'est pas toujours par clé — parfois c'est un seul item qui est brûlant. Si un trafic implacable martèle un item VEHICLE#HOT, le mécanisme split-for-heat de DynamoDB rééquilibre les partitions pour que l'item fréquemment accédé atterrisse seul.

Une fois isolée, la clé de ce seul item peut tirer le plafond de partition complet : 3 000 RCU et 1 000 WCU. C'est le toit absolu pour une seule clé — il n'y a aucun mécanisme au-dessus. (AWS, Key range throughput exceeded.)

Une mise en garde à épingler : l'adaptive capacity ne scindera pas une collection d'items sur plusieurs partitions quand la table a un Local Secondary Index. Un LSI lie la collection à une seule partition — vois GSI vs LSI pour comprendre pourquoi.

Quand l'adaptive capacity ne peut pas te sauver

C'est le piège. Les deux mécanismes déplacent du débit autour ; aucun n'en crée plus qu'une partition n'en 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 write sharding est la solution habituelle : ajoute un suffixe (VEHICLE#HOT#0 … #9) pour que les écritures s'éventent sur plusieurs partitions, puis fais reconverger les lectures.

Cette reconvergence est elle-même un access pattern à modéliser délibérément, de la même façon que tu planifierais un chemin de requête en single-table design — l'adaptive capacity achète du temps, pas un laissez-passer sur la conception des clés.

Vois ça sur ta propre table

L'adaptive capacity est invisible par conception, donc tu raisonnes dessus à travers un symptôme : quelles clés sont chaudes. Quand tu construis le chemin d'écriture shardé, le constructeur d'expressions génère la syntaxe PutItem et Query pour une clé suffixée.

Pour observer comment une clé se distribue réellement sur tes données, télécharge DynoTable et inspecte la répartition des partitions sur tes vraies tables avant de supposer que l'adaptive capacity a tout couvert. Pour le côté lecture du déséquilibre, vois Query vs Scan.