DynamoDB Hot Partitions

DynamoDB verteilt deine Daten über viele physische Partitionen, jede mit ihrem eigenen Anteil am Durchsatz. Eine Hot Partition entsteht, wenn ein Key weit mehr Lese- oder Schreibvorgänge anzieht, als sein Anteil bedienen kann — Anfragen an diesen Key throtteln also, während der Rest der Tabelle untätig bleibt.

Was ist eine DynamoDB Hot Partition?

Eine DynamoDB Hot Partition entsteht, wenn ein Partition Key weit mehr Lese- oder Schreibvorgänge aufnimmt, als sein Anteil am Durchsatz bedienen kann — Anfragen an diesen Key throtteln also, während der Rest der Tabelle untätig bleibt. Die Ursache ist das Key-Design — ein Promi-Item, ein Key mit geringer Kardinalität, das heutige Datum —, nicht die Tabellengröße. Die Kur ist das Verteilen von Schreibvorgängen.

Die Ursache ist das Key-Design, nicht die Tabellengröße. Ein Partition Key, der Traffic konzentriert — ein Promi-User, ein status="OPEN"-Flag, das heutige Datum — ist die Falle.
Adaptive Capacity hilft, ist aber keine Lösung. DynamoDB verteilt Last automatisch um, doch ein einzelnes Item oder ein einzelner Key kann immer noch überschreiten, was eine Partition bedienen kann.
Die Kur ist das Verteilen von Schreibvorgängen. Füge dem Key Entropie hinzu (Write Sharding) oder verlege den heißen Lesepfad auf ein besser verteiltes Zugriffsmuster.
Aus SQL kommend hat das kein Äquivalent. Eine relationale Tabelle kennt kein „der Indexwert einer Zeile ist zu beliebt" — DynamoDBs flaches Durchsatz-pro-Key-Modell schon.

Warum es Partitionen überhaupt gibt

DynamoDB ist der produktive Erbe des Amazon-Dynamo-Papers von 2007, das das Einzelknoten-SQL-Modell gegen ein partitioniertes, horizontal skaliertes tauschte. Daten werden über einen Hash des Partition Keys auf physische Speicherknoten verteilt.

Jede Partition hält eine begrenzte Datenmenge und bedient einen begrenzten Durchsatz. AWS dokumentiert eine harte Obergrenze von 3.000 Read Units und 1.000 Write Units pro Partition und Sekunde (AWS — Partitionsverhalten).

Diese Obergrenze ist die ganze Geschichte. Der bereitgestellte Durchsatz deiner Tabelle ist die Summe über alle Partitionen — aber ein einzelner Key landet immer nur auf einer Partition.

Benenne die Falle: Traffic, der sich auf einem Key staut

Durchsatz wird nur dann gleichmäßig geteilt, wenn deine Zugriffe gleichmäßig über die Keys verteilt sind. Sobald ein Key unverhältnismäßig viel Traffic bekommt, throttelt er allein, während die Gesamtkapazität der Tabelle ungenutzt bleibt.

Klassische Hot-Key-Formen:

Ein Promi-Item — ein User, ein Produkt oder ein Mandant, den alle lesen.
Ein Partition Key mit geringer Kardinalität — status, country, type. Wenige verschiedene Werte bedeuten wenige Partitionen, die die ganze Arbeit machen.
Ein zeitlich gebündelter Key — PK = "2026-06-23". Jeder Schreibvorgang von heute hämmert auf eine Partition; die von gestern ist für immer kalt.

Aus SQL kommend würde nichts davon eine Rolle spielen. Ein B-Tree-Index auf einem beliebten Wert ist in Ordnung. In DynamoDB ist der beliebte Wert die Einheit der physischen Platzierung, also wird Beliebtheit zur Durchsatz-Klippe.

Ein durchgespieltes Beispiel: das Promi-Leaderboard

Angenommen, du betreibst ein globales Gaming-Leaderboard. Die Scores liegen in einer Tabelle, die so verschlüsselt ist:

PK = "BOARD#global"
SK = "PLAYER#<playerId>"

Lesevorgänge holen die Top N nach Score; Schreibvorgänge erhöhen den currentScore eines Spielers nach jedem Match. Jede Zeile im globalen Board teilt sich einen Partition Key — BOARD#global — also landet jeder Lese- und Schreibvorgang auf einer einzigen Partition.

Füge einen Streamer mit zwei Millionen Live-Zuschauern hinzu, die den Refresh-Button auf ihren eigenen Rang hämmern, und diese eine Partition kippt über 3.000 Read Units. Du bekommst eine ProvisionedThroughputExceededException auf dem globalen Board, während jedes andere Board in der Tabelle untätig ist.

Der Footgun ist der BOARD#global-Kollaps: Du hast ein einzelnes logisches Board als einen einzelnen physischen Key modelliert.

Schreibvorgänge verteilen: den Key sharden

Die Lösung ist, Kardinalität herzustellen. Hänge ein Shard-Suffix an den Partition Key an, damit ein logisches Board über N physische Partitionen auffächert:

PK = "BOARD#global#<shard>"  -- shard = playerId mod 10
SK = "PLAYER#<playerId>"

Schreibvorgänge streuen jetzt über zehn Partitionen statt über eine — zehnmal so viel Schreibspielraum. Der Preis: Ein Lesevorgang über das ganze Board muss alle zehn Shards treffen und zusammenführen, weil kein einzelner Query Shard-Grenzen überspannt. Du tauschst Lese-Einfachheit gegen Schreibverteilung.

AWS nennt das Write Sharding und empfiehlt es genau für Keys mit hoher Geschwindigkeit und geringer Kardinalität (AWS — Write Sharding einsetzen).

Das ist derselbe Key-Overloading-Instinkt hinter dem Single-Table-Design — du formst den Key für das Zugriffsmuster, nicht dafür, wie die Daten „natürlich" liegen.

Lass Adaptive Capacity den einfachen Teil übernehmen

DynamoDB liefert Adaptive Capacity, behandelt in der re:Invent-2018-Session „Amazon DynamoDB Under the Hood" (DAT401). Sie verteilt den Durchsatz einer Tabelle kontinuierlich zu den Partitionen unter Last und wird einen dauerhaft heißen Key auf eine eigene Partition isolieren (Key-Level-Isolation, AWS — Bursting & Adaptive Capacity).

Es ist sofort verfügbar und kostenlos — aber durch die Physik begrenzt. Adaptive Capacity kann Last zwischen Keys verschieben; sie kann einen einzelnen Key nicht über die Pro-Partition-Obergrenze hinaus drücken. Ein echter Promi-Key throttelt trotzdem. Sharding ist das, was dich über diese Wand bringt.

Hier ist der Entscheidungspfad, sobald du Throttles auf einem ausgelasteten Key siehst:

Die meisten Hot Partitions lösen sich entweder zu „den Key sharden" oder „lass Adaptive Capacity es absorbieren" auf — das Diagramm zeigt nur, auf welchem Zweig du bist.

Diagnostiziere es, bevor du neu designst

Du kannst nicht reparieren, was du nicht siehst. Throttling zeigt sich als ProvisionedThroughputExceededException (Provisioned) oder als ThrottledRequests und der Pro-Partition-ThrottleCount in CloudWatch (AWS — CloudWatch-Metriken).

Kombiniere das mit CloudWatch Contributor Insights für DynamoDB, das deine meistgenutzten Keys direkt rankt — der schnellste Weg, einen Promi-Key namentlich zu bestätigen (AWS — Contributor Insights).

Wenn du den gesharddeten Lesepfad testest, baust du die KeyConditionExpression für jeden Shard von Hand. Erstelle sie ohne Tippfehler mit dem DynamoDB Expression Builder — er gibt die exakte PK = :pk AND begins_with(SK, :sk)-Form pro Shard aus.

Fallstricke, die du vermeiden solltest

Automatisch hochzählende oder monotone Keys. Sequenzielle IDs und Timestamps als Partition Key leiten aufeinanderfolgende Schreibvorgänge auf dieselbe Partition. Füge ein Hash-Präfix hinzu.
Den leselastigen Pfad unnötig sharden. Wenn Lesevorgänge dominieren und das Item klein ist, schlägt ein Cache oder ein GSI mit einem besser verteilten Key oft die Scatter-Gather-Lesekosten des Shardings.
Eine Hot Partition mit einem langsamen Scan verwechseln. Ein Scan ist langsam, weil er alles liest; eine Hot Partition throttelt, weil ein Key überlastet ist. Unterschiedliche Probleme — siehe Query vs. Scan.

Nächste Schritte

Skizziere die gesharddeten Keys, dann beweise den Lesepfad an echten Daten. Baue die Pro-Shard-Bedingungen im DynamoDB Expression Builder und lade DynoTable herunter, um sie gegen deine eigenen Tabellen auszuführen und zu beobachten, welche Partitionen tatsächlich die Last tragen.