DynamoDB Physical Partitions

Eine physische Partition ist die Einheit, auf der DynamoDB deine Daten tatsächlich speichert: eine Scheibe SSD, repliziert über Availability Zones, die eine Scheibe deines Keyspace hält. Deine Tabelle ist ein logisches Ding. Partitionen sind, wo die Bytes — und die Throughput-Limits — wirklich leben.

Wie funktionieren DynamoDB-Partitionen?

DynamoDB speichert deine Tabelle auf physischen Partitionen — SSD-Scheiben, die über Availability Zones repliziert werden. Jede deckt bei ~10 GB, 3.000 Read Units/s und 1.000 Write Units/s. Der Hash deines entscheidet, auf welcher Partition ein Item landet, und DynamoDB splittet Partitionen automatisch, wenn sie wachsen oder heiß werden.

Jede Partition deckelt bei ~10 GB Speicher, 3.000 Read Units/s und 1.000 Write Units/s. Diese Grenzen sind pro Partition, nicht pro Tabelle.
Der Hash deines Partition Keys wählt die Partition. Items mit demselben Key landen zusammen; ein Hot Key bedeutet eine Hot Partition.
DynamoDB splittet Partitionen für dich — bei Größe und bei anhaltender Hitze — aber es kann keinen Key beheben, der allen Traffic an einen Ort trichtert.
Throttling mit Kapazität im Überfluss ist das Anzeichen. Ein ProvisionedThroughputExceeded-Fehler, während deine Tabelle bei 5 % Auslastung liegt, bedeutet, dass eine einzelne Partition ausgereizt ist.

Wie ein Item seine Partition findet

DynamoDB füttert deinen Partition-Key-Wert durch eine interne Hash-Funktion. Die Hash-Ausgabe wählt die physische Partition. Derselbe Key rein, dieselbe Partition raus — jedes Mal.

Von SQL kommend gibt es kein Analogon. Es gibt keinen Index-B-Baum, den du tunst, keinen Shard-Key, den du von Hand zuweist. Die Platzierung ist ein Hash, den du nicht kontrollierst und nie siehst.

Items, die sich einen Partition Key teilen, bilden eine Item-Collection, zusammen gespeichert und nach Sort Key sortiert. Das ist es, was eine Query auf einem Key billig macht — sie liest einen zusammenhängenden Lauf auf einer Partition. (Siehe Query vs Scan.)

Nimm einen Match-Event-Store für ein Spiel. Die Tabellen-Keys sind arenaId (Partition) und eventKey (Sort):

# Item
arenaId    = "ARENA#7f3a"
eventKey   = "EVT#1719100800#a91c"
playerTag  = "Nightjar"
dmgDealt   = 412

Jedes Event für Arena 7f3a hasht auf dieselbe Partition und stapelt sich in Sort-Key-Reihenfolge. Großartig für „lies die Timeline dieses Matches". Eine Belastung, wenn diese eine Arena den ganzen Traffic bekommt.

Die drei Decken, die jede Partition durchsetzt

Eine einzelne Partition ist darauf ausgelegt, höchstens zu liefern:

Limit	Pro Partition	Gezählt als
Speicher	~10 GB	rohe Item-Bytes
Read-Kapazität	3.000 Read Units/s	1 RU = ein stark konsistenter 4-KB-Read
Write-Kapazität	1.000 Write Units/s	1 WU = ein 1-KB-Write

Quelle: der AWS-Guide Best practices for designing partition keys.

Die Item-Größe skaliert die Rechnung. Ein 20-KB-Item kostet 5 Read Units pro stark konsistentem Read, also bedient eine Partition ~600 solcher Reads/s, bevor sie throttelt — nicht 3.000. Runde Write-Kosten pro 1 KB auf, Read-Kosten pro 4 KB.

Die Falle: Das sind Partitions-Limits, keine Tabellen-Limits. Deine Tabelle kann für 40.000 WCU provisioniert sein und trotzdem throtteln, weil all die Writes eine Partition hämmern, die bei 1.000 die Spitze erreicht.

Wie Partitionen splitten

DynamoDB fügt Partitionen automatisch in zwei Fällen hinzu. Du führst nie ein Kommando aus.

Split bei Größe. Wenn eine Partition Richtung ~10 GB füllt, splittet DynamoDB ihren Keyspace-Bereich in zwei und verschiebt die Hälfte der Items auf eine neue Partition. Speicher wächst transparent; deine Reads und Writes laufen die ganze Zeit weiter.

Split bei Hitze. Wenn eine Partition anhaltenden Traffic nahe ihrer Throughput-Decke nimmt, splittet DynamoDB den heißen Key-Bereich, sodass jede Hälfte auf ihrer eigenen Partition landet. AWS nennt das den Split-for-Heat-Mechanismus. Kurze Throttling-Bursts, die von selbst aufhören, bedeuten meist, dass gerade ein Split passiert ist.

Splitten verschafft Raum über viele Keys, aber die unterste Node ist der Haken: Ein Split teilt einen Key-Bereich, nie einen einzelnen Key.

Warum ein Hot Key den Splitter schlägt

Hier ist das Footgun. Splitten verteilt Bereiche von Partition Keys neu. Wenn sich dein Traffic auf einen Key-Wert konzentriert, hasht jeder Request auf dieselbe Partition, und es bleibt kein Bereich zum Teilen.

Wenn Arena 7f3a ein Turnierfinale ist, das 4.000 Writes/s zieht, während jede andere Arena untätig ist, throttelst du bei 1.000 — und ein Split kann nicht helfen, weil alle 4.000 sich einen Key teilen. Der neuere KeyRangeThroughputExceeded-Throttle-Grund benennt genau das: der Key-Bereich einer Partition, nicht die Tabelle, ist über seinem Limit.

Die Lösung steckt im Datenmodell, nicht im Kapazitäts-Schieberegler. Write-Sharde den Hot Key: Hänge ein kleines Suffix an, sodass sich eine logische Arena über N physische Partitionen verteilt.

arenaId = "ARENA#7f3a#3"   # shard 0..9, chosen per write

Reads fächern dann über die Shards auf und mergen client-seitig. Du kannst die Key-Formen und die Query für jeden Shard mit dem DynamoDB Expression Builder prototypisieren, bevor du eine Zeile Anwendungscode anfasst.

Eine Nuance: die LSI-Ausnahme

Es gibt einen Fall, in dem Speicher doch pro Partition Key gedeckelt ist. Ohne einen Local Secondary Index splittet eine Item-Collection automatisch über so viele Partitionen, wie sie braucht — Milliarden Sort-Key-Werte sind in Ordnung.

Füge einen LSI hinzu, und die ganze Collection für einen Partition Key muss in eine einzelne 10-GB-Partition passen, weil der LSI sie teilt. Das ist die Pro-PK-Klippe, abgedeckt in GSI vs LSI — ein weiterer Grund, warum die meisten Teams zu GSIs greifen.

Designen, damit Partitionen kühl bleiben

Der Hebel, den du tatsächlich kontrollierst, ist der Partition Key. Wähle einen mit vielen verschiedenen Werten relativ zur Zeilenanzahl, sodass sich der Traffic gleichmäßig verteilt. (Mehr Patterns in Single-Table-Design.)

High-Cardinality-Key. Ein Per-User- oder Per-Tenant-Key schlägt einen Per-Day- oder Per-Status-Key, den alle gleichzeitig hämmern.
Achte auf bekannte Hot Keys. Ein „aktuelles Turnier"- oder „heute"-Wert ist ein Konzentrationsrisiko, bevor du ausrollst, nicht danach.
Sharde den unvermeidbaren Hot Key. Wenn ein Key überdimensionalen Traffic nehmen muss, ist ein Suffix der Standard-Notausgang.

Throttling mit Kapazität im Überfluss ist dein Signal, dass eine Partition heiß ist. Inspiziere die betroffenen Items und probe ein gesharded Key-Layout in DynoTable — richte es auf deine eigene Tabelle, finde den überlasteten Key und modelliere die Lösung, bevor sie dich nachts weckt.