Wie DynamoDB-Partition-Keys funktionieren

Dein Partition Key ist keine Spalte — er 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 kriegt die Hitze ab.

Wie funktionieren DynamoDB-Partition-Keys?

DynamoDB jagt deinen Partition Key durch eine interne Hash-Funktion, und dieser Hash entscheidet, welche physische Partition das Item speichert. Der Key wird nicht sortiert oder indexiert wie eine SQL-Spalte — er ist eine Adresse. Wähle einen High-Cardinality-Key und die Last verteilt sich über viele Partitionen; wähle einen Low-Cardinality-Key und eine einzelne Partition bekommt die gesamte Hitze ab.

• Der Key wird gehasht, nicht sortiert. DynamoDB jagt deinen Partition Key durch einen internen Hash, um eine Partition zu wählen. Zwei benachbarte Werte landen nirgendwo nah beieinander auf der Platte.
• Eine Partition ist eine echte Speichereinheit. Jede deckelt bei etwa 10 GB, 3.000 Read Units/s und 1.000 Write Units/s. Dein Traffic wird geteilt durch die Anzahl der Partitionen, über die sich deine Keys verteilen.
• Hot Keys sind das Footgun. Trichtere die meisten Requests auf einen Partition-Key-Wert und du throttelst auf dieser Partition, während der Rest der Tabelle untätig liegt.
• High-Cardinality-Keys gewinnen. Je mehr verschiedene, gleichmäßig getroffene Key-Werte du hast, desto mehr Partitionen absorbieren die Last.

Beginne damit, was der Key tatsächlich tut

Von SQL kommend ist ein Primary Key eine sortierte, indexierte Spalte, auf der du JOIN und ORDER BY machst. In DynamoDB tut der Partition Key (manchmal Hash Key genannt) etwas anderes: Er entscheidet Platzierung.

DynamoDB füttert den Partition Key in eine interne Hash-Funktion. Die Ausgabe bildet auf einen Keyspace ab, und der Keyspace ist in Bereiche zerschnitten — jeder Bereich von einer physischen Partition besessen. Diese Partition ist echter Speicher auf einer echten Node.

Also beantwortet der Partition Key eine Frage: welche Maschine hält dieses Item? Der Sort Key, falls du einen hast, ordnet Items nur innerhalb dieser Maschine. Er spielt bei der Platzierung keine Rolle.

Verfolge einen Write durch den Hash

Sagen wir, du betreibst eine SaaS, die Gerätemessungen aufnimmt. Deine Tabelle SensorReadings verwendet einen Partition Key deviceId und einen Sort Key readingTs. Du schreibst eine Messung für deviceId = "vac-7741".

Hier ist der Pfad, den dieser Write nimmt — von deinem Key bis zur Platte, auf der er landet:

Der Write 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 nach readingTs geordnet.

Was zu verinnerlichen ist: "vac-7741" und "vac-7742" sind ein Zeichen voneinander entfernt, aber ihre Hashes sind unverwandt. Sie leben fast sicher auf verschiedenen Partitionen. Es gibt kein „in der Nähe" im Partition-Keyspace.

Das ist die Consistent-Hashing-Idee, die DynamoDB vom ursprünglichen Design erbte — das Amazon-Dynamo-Paper von 2007 („Dynamo: Amazon's Highly Available Key-value Store") verteilte Keys über Nodes durch Hashing genau so, dass keine einzelne Node zum Bottleneck wurde.

Respektiere die harten Limits der Partition

Eine physische Partition ist endlich. Laut dem AWS DynamoDB Developer Guide hält jede bis zu etwa:

Wenn eine Partition über 10 GB füllt oder dein provisionierter Throughput mehr Raum braucht, splittet DynamoDB sie — der Keyspace-Bereich wird geteilt und Items verteilen sich über mehr Partitionen. Das ist automatisch; du triggerst es nicht.

Der Haken: Ein Split verteilt Items nach ihrem Hash. Wenn jeder heiße Request einen einzelnen Partition-Key-Wert anvisiert, hilft Splitten nicht — all dieser Traffic hasht weiterhin auf denselben Punkt. Du kannst die Last eines einzelnen Keys nicht über Partitionen splitten.

Benenne die Falle: die Hot Partition

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

Konkretes Versagen: Du stellst SensorReadings auf einen Partition Key region um, mit Werten wie "us-east", "eu-west". Drei Regionen bedeuten drei Key-Werte bedeuten — höchstens — drei Partitionen, die echte Arbeit leisten. Knall "us-east" mit Reads und es throttelt bei 3.000 RCU, während die gesamte provisionierte Kapazität der Tabelle ungenutzt liegt.

Die Adaptive Capacity von DynamoDB mildert das — sie kann ungenutzten Throughput zu einer beschäftigten Partition verschieben und einen einzelnen sehr-heißen Key auf seine eigene Partition isolieren. AWS hat das in den re:Invent-„Advanced Design Patterns for DynamoDB"-Deep-Dive-Sessions detailliert. Aber Adaptive Capacity kauft Zeit, keine Immunität: Sie kann die Last eines einzelnen Keys nicht unterteilen. Designe für Verteilung; verlass dich nicht auf das Sicherheitsnetz.

Wähle einen High-Cardinality-Key

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

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

Von SQL kommend würdest du gerne eine status-Spalte indexieren und darauf filtern. Als DynamoDB-Partition-Key ist das eine Falle — er kann nicht verteilen. Halte Low-Cardinality-Attribute als Filter oder als Sort Key eines Secondary Index, nie als das, was die Platzierung entscheidet.

Wenn ein natürlich guter Key trotzdem schief liegt — eine Handvoll Wal-Mandanten, die den Rest überholen — füge ein Suffix hinzu, um einen logischen Wert über N Partitionen aufzufächern, z. B. tenantId#3 für einen gesharded Schreibpfad. Du re-aggregierst beim Read.

Um Items innerhalb einer Partition zu zielen, sobald dein Key verteilt ist, schreibst du eine KeyConditionExpression auf dem Sort Key. Du kannst eine gegen dein eigenes Schema im DynamoDB Expression Builder zusammenstellen, 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 einzelnen Partition — eine Query, kein Scan. Der Partition Key fixiert die Maschine; die Sort-Key-Bedingung schränkt 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 verteilt. Kardinalität zuerst, Query-Bequemlichkeit zweitens.
• Nimm nicht an, dass die Gesamtkapazität der Tabelle pro Key dir gehört. Throughput ist pro Partition; ein heißer Wert kann throtteln, während die Tabelle untätig aussieht.
• Bekämpfe keinen Split. Er ist automatisch und Hash-getrieben — deine Aufgabe ist, ihm genug verschiedene Keys zu geben, um sich zu verteilen.

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

Lade DynoTable herunter, um deine echten Partitionen und Key-Verteilung zu durchsuchen und einen Hot Key zu erkennen, bevor er dich nachts weckt.