Wie Partition Keys in DynamoDB funktionieren

Dein Partition Key ist eine Adresse. DynamoDB hasht diesen Key, und der Hash entscheidet, welche physische Maschine das Item speichert. Wähle den Key gut, und die Last verteilt sich; wähle ihn schlecht, und ein Server nimmt die ganze Hitze.

Wie funktionieren Partition Keys in DynamoDB?

DynamoDB schickt deinen Partition Key durch eine interne Hash-Funktion, und dieser Hash entscheidet, welche physische Partition das Item speichert. Der Hash entscheidet die Platzierung; der Key ist nicht sortiert oder indiziert wie eine SQL-Spalte. Wähle einen Key mit hoher Kardinalität, und die Last verteilt sich über viele Partitionen; wähle einen mit geringer, und eine einzige Partition nimmt die ganze Hitze.

• Der Key wird gehasht, nicht sortiert. DynamoDB schickt deinen Partition Key durch einen internen Hash, um eine Partition zu wählen. Zwei benachbarte Werte landen auf der Platte nirgends in der Nähe voneinander.
• Eine Partition ist eine echte Speichereinheit. Jede endet bei etwa 10 GB, 3.000 Read Units/Sek. und 1.000 Write Units/Sek. Dein Traffic wird durch die Anzahl der Partitionen geteilt, über die sich deine Keys verteilen.
• Hot Keys sind das Footgun. Trichtere die meisten Anfragen auf einen Partition-Key-Wert, und du drosselst auf dieser Partition, während der Rest der Tabelle ungenutzt bleibt.
• Keys mit hoher Kardinalität gewinnen. Je mehr verschiedene, gleichmäßig getroffene Key-Werte du hast, desto mehr Partitionen nehmen die Last auf.

Beginne damit, was der Key eigentlich tut

Aus der SQL-Welt ist ein Primärschlüssel eine sortierte, indizierte Spalte, über die du JOIN und ORDER BY machst. In DynamoDB tut der Partition Key (manchmal Hash Key genannt) etwas anderes: Er entscheidet die Platzierung.

DynamoDB gibt den Partition Key in eine interne Hash-Funktion. Die Ausgabe bildet auf einen Keyspace ab, und der Keyspace ist in Bereiche geschnitten — jeder Bereich gehört einer physischen Partition. Diese Partition ist echter Speicher auf einem echten Knoten.

Der Partition Key beantwortet also eine Frage: Welche Maschine hält dieses Item? Der Sort Key, falls du einen hast, ordnet die Items nur innerhalb dieser Maschine. Mit der Platzierung hat er nichts zu tun.

Einen Schreibvorgang durch den Hash verfolgen

Angenommen, du betreibst ein SaaS, das Gerätemesswerte einsammelt. Deine Tabelle SensorReadings nutzt den Partition Key deviceId und den Sort Key readingTs. Du schreibst einen Messwert für deviceId = "vac-7741".

Den Weg, den dieser Schreibvorgang nimmt — von deinem Key bis zur Platte, auf der er landet:

Der Schreibvorgang für vac-7741 wird auf einen Punkt im Keyspace gehasht, dieser Punkt fällt in den Bereich von P2, und das Item landet auf P2 — dort geordnet nach readingTs.

Was du verinnerlichen solltest: "vac-7741" und "vac-7742" unterscheiden sich um ein Zeichen, ihre Hashes haben aber nichts miteinander zu tun. Sie liegen mit ziemlicher Sicherheit auf verschiedenen Partitionen. Ein „in der Nähe“ gibt es im Partitions-Keyspace nicht.

Das ist die Idee des Consistent Hashing, die DynamoDB aus dem ursprünglichen Entwurf geerbt hat — das Amazon-Dynamo-Paper von 2007 („Dynamo: Amazon's Highly Available Key-value Store“) verteilte Keys per Hashing über Knoten, genau damit kein einzelner Knoten zum Flaschenhals wird.

Füge unten eine Liste von Partition-Key-Werten ein, um zu sehen, wie ein Hash sie über Buckets streut. Ein Satz mit hoher Kardinalität verteilt sich gleichmäßig; wiederhole einen Wert, und alles stapelt sich in einem einzigen Bucket — die heiße Partition, um die es im nächsten Abschnitt geht.

Das ist ein Lehr-Hash für die Intuition, nicht der echte interne Hash von DynamoDB — die tatsächliche Funktion, der Keyspace und die Partitionsgrenzen sind AWS-Interna. Nutze ihn, um ein Gefühl für Streuung und Schieflage zu entwickeln, nicht um vorherzusagen, auf welcher physischen Partition ein Key landet.

Respektiere die harten Grenzen der Partition

Eine physische Partition ist endlich. Laut dem AWS DynamoDB Developer Guide fasst jede ungefähr:

Füllt sich eine Partition über 10 GB hinaus, oder braucht dein provisionierter Durchsatz mehr Luft, teilt DynamoDB sie — der Keyspace-Bereich wird aufgeteilt und die Items verteilen sich über mehr Partitionen. Das passiert automatisch; du löst es nicht aus.

Eine Teilung kann die Item Collection eines Partition Keys an einer Sort-Key-Grenze zerlegen, die Last eines vielbeschäftigten Keys kann sich also über mehr Partitionen verteilen. Was das Teilen nicht retten kann, ist ein einzelnes heißes Item, ein immer weiter steigender Sort Key oder eine Tabelle mit einem LSI — die nageln die Collection auf eine Partition fest.

Die Falle beim Namen nennen: die heiße Partition

Eine heiße Partition ist das klassische Footgun. Sie entsteht, wenn ein Partition-Key-Wert (oder eine winzige Menge davon) einen unverhältnismäßigen Anteil des Traffics aufnimmt.

Konkreter Fehlschlag: Du stellst SensorReadings auf den Partition Key region um, mit Werten wie "us-east", "eu-west". Drei Regionen heißt drei Key-Werte heißt — höchstens — drei Partitionen, die echte Arbeit tun. Hämmere Lesevorgänge auf "us-east", und es drosselt bei 3.000 RCU, während die gesamte provisionierte Kapazität der Tabelle ungenutzt liegt.

Die Adaptive Capacity von DynamoDB federt das ab — sie kann ungenutzten Durchsatz zu einer beschäftigten Partition verschieben und einen einzelnen sehr heißen Key auf eine eigene Partition isolieren. AWS hat das in den re:Invent-Deep-Dive-Sessions „Advanced Design Patterns for DynamoDB“ ausgeführt. Aber Adaptive Capacity kauft Zeit, keine Immunität: Ein einzelnes heißes Item, ein immer weiter steigender Sort Key oder ein LSI deckelt einen Key weiterhin auf eine einzige Partition. Entwirf für Streuung; verlass dich nicht auf das Sicherheitsnetz.

Wähle einen Key mit hoher Kardinalität

Die Lösung ist Kardinalität — die Anzahl verschiedener Key-Werte und wie gleichmäßig der Traffic sie trifft.

• Geringe Kardinalität (region, status, true/false): wenige Partitionen, der Traffic konzentriert sich, du drosselst früh.
• Hohe Kardinalität (deviceId, userId, eine Bestell-ID): viele Werte, die über viele Partitionen hashen, die Last verteilt sich, der Spielraum wächst.

Aus der SQL-Welt würdest du bereitwillig eine Spalte status indizieren und darauf filtern. Als DynamoDB-Partition-Key ist das eine Falle — er kann nicht streuen. Behalte Attribute mit geringer Kardinalität als Filter oder als Sort Key eines Secondary Index, niemals als das, was die Platzierung entscheidet.

Wenn ein von Natur aus guter Key trotzdem schief liegt — eine Handvoll Wal-Mandanten hängt den Rest ab —, häng ein Suffix an, um einen logischen Wert über N Partitionen aufzufächern, z. B. tenantId#3 für einen geshardeten Schreibpfad. Beim Lesen aggregierst du wieder zusammen.

Um Items innerhalb einer Partition zu treffen, sobald dein Key gestreut ist, schreibst du eine KeyConditionExpression auf den Sort Key. Du kannst eine gegen dein eigenes Schema im DynamoDB Expression Builder zusammenbauen, bevor du sie in Code verdrahtest:

deviceId = "vac-7741" AND readingTs BETWEEN "2026-06-01" AND "2026-06-30"

Das liest das Juni-Fenster eines Geräts aus einer einzigen Partition — eine Query, kein Scan. Der Partition Key nagelt die Maschine fest; die Sort-Key-Bedingung grenzt die Zeilen ein.

Fallstricke und nächste Schritte

• Wähle einen Key nicht danach, was sich in SQL gut liest. Wähle ihn danach, was streut. Kardinalität zuerst, Abfragekomfort danach.
• Nimm nicht an, die Gesamtkapazität der Tabelle stünde dir je Key zur Verfügung. Durchsatz ist partitionsweise; ein heißer Wert kann drosseln, während die Tabelle untätig wirkt.
• Kämpfe nicht gegen eine Teilung. Sie ist automatisch und hash-getrieben — deine Aufgabe ist es, ihr genug verschiedene Keys zum Verteilen zu geben.

Sobald dein Key sauber streut, sind die nächsten Entscheidungen, wie du Items innerhalb einer Partition anordnest — siehe Single-Table-Design — und wann ein Secondary Index das richtige Werkzeug für ein zweites Zugriffsmuster ist.

Lade DynoTable herunter und lass im SQL Workbench ein GROUP BY über deinen Partition Key laufen, um zu sehen, welche Keys Items anhäufen, bevor einer zur heißen Partition wird.