DynamoDB Adaptive Capacity: was sie leistet — und was nicht

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 Throttling abhalten — bis er auf ein hartes Limit trifft.

Was ist DynamoDB Adaptive Capacity?

DynamoDB Adaptive Capacity ist ein automatischer Mechanismus, der ungenutzten Durchsatz zu einer Hot Partition verschiebt, damit ein schiefer Schlüssel nicht drosselt, während der Rest der Tabelle brachliegt. Gepaart mit Burst Capacity fängt sie Spitzen und anhaltende Schieflage kostenlos ab — aber sie kann einen einzelnen Schlüssel nicht über die Partitionsobergrenze hinausschieben.

• Burst Capacity leiht dir bis zu 5 Minuten (300 Sekunden) ungenutzten Durchsatz, um kurze Spitzen zu überstehen. Es ist ein Puffer, keine Funktion, die du einstellst.
• Adaptive Capacity hebt automatisch den Durchsatz für eine „heiße" Partition an — indem sie aus der ungenutzten Kapazität des Rests deiner Tabelle schöpft — damit ein schiefer Schlüssel nicht drosselt.
• Sie isoliert sogar ein Hot Item auf seiner eigenen Partition und gibt einem einzelnen Schlüssel bis zur Partitionsobergrenze von 3.000 RCU / 1.000 WCU.
• Sie ist kein Freibrief, das Schlüsseldesign zu ignorieren. Jenseits der Obergrenze pro Partition gibt es nichts mehr zu leihen — ein wirklich heißer Schlüssel drosselt weiterhin.

Kenne zuerst die Partitionsobergrenze

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 Provisioned- als auch auf On-Demand-Tabellen. (AWS, Burst and adaptive capacity.)

Von SQL kommend denkst du über die gesamte Serverlast nach. In DynamoDB ist die Einheit, die drosselt, die einzelne Partition, und ein schiefer Schlüssel kann schmelzen, während die Tabelle zu 90 % brachliegt. Das ist die Lücke, die beide Mechanismen schließen sollen.

Burst Capacity fängt die kurze Spitze ab

Immer wenn du den Durchsatz einer Partition nicht vollständig nutzt, legt DynamoDB den Rest an. Bis zu 300 Sekunden dieser ungenutzten Kapazität werden in Reserve gehalten, und eine plötzliche Spitze kann sie schneller ableiten, als es deine Rate pro Sekunde normalerweise erlauben würde.

Sie ist unsichtbar und automatisch. Du kannst sie nicht dimensionieren, und DynamoDB gibt einen Teil davon vielleicht still für eigene Hintergrundarbeit aus. Behandle sie als Polster für sprunghaften Traffic — nie als Spielraum, mit dem du planen kannst.

Adaptive Capacity verstärkt die Hot Partition

Burst Capacity behandelt kurze Spitzen. Adaptive Capacity behandelt anhaltende Schieflage. Wenn eine Partition heiß läuft, während ihre Nachbarn brachliegen, verschiebt DynamoDB Durchsatz zur heißen — bis zur Gesamtsumme der Tabelle und zur Partitionsobergrenze.

Sagen wir, du betreibst eine Fahrzeug-Telemetrie-Tabelle mit den Schlüsseln VEHICLE#<id> (Partition) und TS#<epoch> (Sort). Ein Lieferwagen in einer Flash-Sale-Zone sendet das 10-Fache der Pings jedes anderen. Seine Partition ist heiß; die Partitionen der anderen 200 Fahrzeuge liegen nahezu brach.

Adaptive Capacity bemerkt das und hebt den Durchsatz dieser einen Partition an, indem sie aus der ungenutzten Kapazität der kalten Partitionen schöpft. Keine Konfiguration, keine Kosten, kein Aufwärmen — seit Mai 2019 ist der Schub praktisch sofort. (AWS Database Blog, „How DynamoDB adaptive capacity accommodates uneven access patterns".)

Die Partition des heißen Lieferwagens braucht 150 WCU, aber ihr gleichmäßiger Anteil von 100 WCU würde drosseln; Adaptive Capacity leiht sich die brachliegenden WCU von den kalten Partitionen, um das zu decken.

Isolation: wenn ein einzelnes Item das Problem ist

Schieflage ist nicht immer pro Schlüssel — manchmal ist ein einzelnes Item glühend heiß. Wenn unerbittlicher Traffic ein VEHICLE#HOT-Item antreibt, verteilt DynamoDBs Split-for-Heat die Partitionen neu, sodass das häufig aufgerufene Item allein landet.

Einmal isoliert, kann der Schlüssel dieses einzelnen Items die volle Partitionsobergrenze: 3.000 RCU und 1.000 WCU ziehen. Das ist die absolute Decke für einen Schlüssel — darüber gibt es keinen Mechanismus. (AWS, Key range throughput exceeded.)

Ein Vorbehalt, den man festhalten sollte: Adaptive Capacity spaltet 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, warum das so ist.

Wenn Adaptive Capacity dich nicht retten kann

Das ist die Falle. Beide Mechanismen verschieben Durchsatz herum; keiner erzeugt mehr, als eine Partition physisch erlaubt.

Wenn ein einzelner Schlüssel legitim mehr als 1.000 Schreibvorgänge pro Sekunde braucht, rettet dich kein automatischer Mechanismus — du musst die Last über mehr Schlüssel verteilen.

Write Sharding ist der übliche Fix: hänge ein Suffix an (VEHICLE#HOT#0 … #9), damit Schreibvorgänge über Partitionen ausfächern, und fächere die Lesevorgänge dann wieder ein.

Dieses Einfächern ist selbst ein Zugriffsmuster, das man bewusst modellieren muss, genauso wie du einen Query-Pfad in Single-Table-Design planen würdest — Adaptive Capacity kauft Zeit, keinen Freibrief beim Schlüsseldesign.

Sieh es auf deiner eigenen Tabelle

Adaptive Capacity ist per Design unsichtbar, also überlegst du über sie anhand eines Symptoms: welche Schlüssel heiß sind. Wenn du den Sharded-Write-Pfad baust, generiert der Expression Builder die PutItem- und Query-Syntax für einen suffixierten Schlüssel.

Um zu beobachten, wie ein Schlüssel sich tatsächlich über deine Daten verteilt, lade DynoTable herunter und führe ein GROUP BY über deinen Partition Key in der SQL Workbench aus, um zu sehen, wie sich Items pro Schlüssel stapeln, bevor du annimmst, dass Adaptive Capacity es im Griff hat. Für die Leseseite der Schieflage siehe Query vs. Scan.