DynamoDB Adaptive Capacity
DynamoDB verteilt deine Tabelle über Partitionen, aber dein Traffic verteilt sich selten gleichmäßig. Burst Capacity und Adaptive Capacity sind die zwei automatischen Mechanismen, die einen schiefen Workload vom Throtteln abhalten — bis er auf ein hartes Limit trifft.
Was ist DynamoDB Adaptive Capacity?
DynamoDB Adaptive Capacity ist ein automatischer Mechanismus, der ungenutzten Throughput zu einer verschiebt, sodass ein schiefer Key nicht throttelt, während der Rest der Tabelle untätig liegt. Zusammen mit Burst Capacity fängt es Spitzen und anhaltende Schieflage kostenlos ab — kann einen einzelnen Key aber nicht über die Partitionsdecke hinausbringen.
- Burst Capacity leiht dir bis zu 5 Minuten (300 Sekunden) ungenutzten Throughputs, um kurze Spitzen auszureiten. Es ist ein Puffer, kein Feature, das du tunst.
- Adaptive Capacity hebt automatisch den Throughput für eine „heiße" Partition an — schöpfend aus der ungenutzten Kapazität des Rests deiner Tabelle — sodass ein schiefer Key nicht throttelt.
- Es wird sogar ein heißes Item isolieren, auf seine eigene Partition, und einem einzelnen Key bis zur Partitionsdecke von 3.000 RCU / 1.000 WCU geben.
- Es ist keine Lizenz, Key-Design zu ignorieren. Jenseits der Pro-Partition-Decke gibt es nichts mehr zu leihen — ein wirklich heißer Key throttelt trotzdem.
Kenne zuerst die Partitionsdecke
Jede Partition ist unabhängig gedeckelt: 3.000 Read Units und 1.000 Write Units pro Sekunde. Dieses Limit ist physisch, nicht provisioniert — es gilt sowohl auf provisionierten als auch auf On-Demand-Tabellen. (AWS, Burst and adaptive capacity.)
Von SQL kommend denkst du über die Gesamt-Serverlast nach. In DynamoDB ist die Einheit, die throttelt, die einzelne Partition, und ein schiefer Key kann schmelzen, während die Tabelle zu 90 % untätig liegt. Das ist die Lücke, die beide Mechanismen existieren, um sie zu schließen.
Burst Capacity absorbiert die kurze Spitze
Wann immer du den Throughput einer Partition nicht voll ausnutzt, bunkert DynamoDB den Rest. Bis zu 300 Sekunden dieser ungenutzten Kapazität werden in Reserve gehalten, und eine plötzliche Spitze kann sie schneller leeren, als es deine Pro-Sekunde-Rate normalerweise erlauben würde.
Es ist unsichtbar und automatisch. Du kannst es nicht dimensionieren, und DynamoDB gibt vielleicht still etwas davon für seine eigene Hintergrundarbeit aus. Behandle es als Polster für stoßartigen Traffic — nie als Spielraum, gegen den du planen kannst.
Adaptive Capacity boostet die Hot Partition
Burst Capacity behandelt kurze Spitzen. Adaptive Capacity behandelt anhaltende Schieflage. Wenn eine Partition heiß läuft, während ihre Nachbarn untätig sind, verschiebt DynamoDB Throughput zur heißen — bis zur Gesamtsumme der Tabelle und der Partitionsdecke.
Sagen wir, du betreibst eine Fleet-Telemetrie-Tabelle, verschlüsselt nach
VEHICLE#<id> (Partition) und TS#<epoch> (Sort). Ein Lieferwagen in einer
Flash-Sale-Zone gibt das 10-fache der Pings jedes anderen aus. Seine Partition ist
heiß; die Partitionen der anderen 200 Wagen liegen nahezu untätig.
Adaptive Capacity bemerkt das und hebt den Throughput dieser einen Partition, schöpfend aus der ungenutzten Kapazität der kalten Partitionen. Keine Config, keine Kosten, kein Warm-up — seit Mai 2019 ist der Boost praktisch sofortig. (AWS Database Blog, „How DynamoDB adaptive capacity accommodates uneven access patterns".)
Die Partition des heißen Wagens braucht 150 WCU, aber ihr gleicher Anteil von 100 WCU würde throtteln; Adaptive Capacity leiht die untätigen WCU von den kalten Partitionen, um das zu decken.
Isolation: wenn ein Item das Problem ist
Schieflage ist nicht immer pro Key — manchmal ist ein einzelnes Item weißglühend.
Wenn unaufhörlicher Traffic ein VEHICLE#HOT-Item treibt, rebalanciert
DynamoDBs Split-for-Heat die Partitionen so, dass das häufig zugegriffene Item
allein landet.
Einmal isoliert, kann der Key dieses einzelnen Items die volle Partitionsdecke: 3.000 RCU und 1.000 WCU ziehen. Das ist das absolute Dach für einen Key — es gibt keinen Mechanismus darüber. (AWS, Key range throughput exceeded.)
Ein Vorbehalt, der festzunageln ist: Adaptive Capacity splittet keine Item-Collection über Partitionen, wenn die Tabelle einen Local Secondary Index hat. Ein LSI bindet die Collection an eine Partition — siehe GSI vs LSI dafür, warum.
Wenn Adaptive Capacity dich nicht retten kann
Das ist die Falle. Beide Mechanismen verschieben Throughput herum; keiner erschafft mehr, als eine Partition physisch erlaubt.
| Szenario | Burst | Adaptive | Ergebnis |
|---|---|---|---|
| Kurze Spitze, Tabelle hat Spielraum | Deckt es ab | — | Kein Throttle |
| Anhaltende Schieflage, kalte Nachbarn | — | Boostet heiße | Kein Throttle |
| Ein Item, < 3K RCU / 1K WCU | — | Isoliert es | Kein Throttle |
| Ein Item, > Partitionsdecke | Schnell geleert | Am Dach | Throttled — Redesign nötig |
| Viele Keys heiß zugleich, Tabelle voll | Schnell geleert | Nichts untätig | Throttled — Redesign nötig |
Wenn ein einzelner Key legitim mehr als 1.000 Writes pro Sekunde braucht, rettet dich kein automatischer Mechanismus — du musst die Last über mehr Keys verteilen.
Write-Sharding ist die übliche Lösung: Hänge ein Suffix an
(VEHICLE#HOT#0 … #9), sodass Writes über Partitionen auffächern, dann fächere
Reads wieder ein.
Dieses Einfächern ist selbst ein Access Pattern, das bewusst zu modellieren ist, genauso wie du einen Query-Pfad in Single-Table-Design planen würdest — Adaptive Capacity kauft Zeit, keinen Freifahrtschein beim Key-Design.
Auf deiner eigenen Tabelle ansehen
Adaptive Capacity ist absichtlich unsichtbar, also denkst du darüber durch ein
Symptom nach: welche Keys heiß sind. Wenn du den gesharded Schreibpfad baust,
generiert der Expression Builder die
PutItem- und Query-Syntax für einen Key mit Suffix.
Um zu beobachten, wie ein Key tatsächlich über deine Daten verteilt, lade DynoTable herunter und inspiziere die Partitionsverteilung auf deinen echten Tabellen, bevor du annimmst, Adaptive Capacity habe es im Griff. Für die Read-Seite der Schieflage siehe Query vs Scan.