Wie DynamoDB-Request-Routing funktioniert

Jeder Read oder Write, den du sendest, trifft zuerst eine Flotte zustandsloser Request Router. Ein Router hasht deinen Partition Key, bildet den Hash auf die Storage-Node ab, die die Daten dieses Keys besitzt, und leitet den Request dorthin weiter. Dieser eine Hop ist, warum ein Key-Lookup gleich viel kostet, ob die Tabelle tausend Items oder eine Milliarde hält.

Wie funktioniert das DynamoDB-Request-Routing?

DynamoDB routet jeden Request durch eine zustandslose Request-Router-Flotte, die deinen Partition Key hasht, den Hash auf die einzelne Storage-Node abbildet, die diese Partition besitzt, und den Read oder Write dorthin weiterleitet. Routing ist eine reine Funktion des Key-Hashes, sodass ein Lookup gleich viel kostet, egal ob die Tabelle tausend Items oder eine Milliarde hält.

• Der Request Router ist die Eingangstür. Es ist eine zustandslose Flotte, die deinen Request nimmt, den Partition Key hasht und ihn zur Storage-Node routet, die diese Partition hält — kein Scannen, kein Volltabellen-Wissen nötig.
• Der Partition Key entscheidet alles. Routing ist eine reine Funktion des Hashes des Partition Keys. Derselbe Key, dieselbe Node, jedes Mal — sodass GetItem O(1) ist, nicht O(Tabellengröße).
• Ein Primary, zwei Secondaries. Ein Write landet auf der Primary-Node der Partition, die zu zwei Secondaries über Availability Zones repliziert, bevor er dauerhaft ist.
• Schlechte Keys besiegen das Design. Ein Low-Cardinality- oder „heißer" Partition Key trichtert Traffic an eine Node — das Routing ist in Ordnung, dein Key ist das Problem.

Beginne mit dem Problem, das Routing löst

Von SQL kommend stellst du dir einen Query-Planner vor: Er liest Statistiken, wählt einen Index, scannt vielleicht. Die Kosten skalieren mit der Menge an Daten, die er berührt. Dieses Modell passt nicht zu einem Key-Value-Store, der in einstelligen Millisekunden bei jeder Größe antworten muss.

DynamoDBs Antwort ist, einen Single-Item-Lookup zu einer direkten Adresse zu machen, keiner Suche. Der Partition Key ist keine Spalte, auf der du filterst — er ist der Input zu einer Hash-Funktion, die berechnet, wo die Daten physisch leben. Keine Statistiken, kein Planner.

Das ist der Handel, den du akzeptierst, wenn du von relationalem Denken weggehst: Du gibst Ad-hoc-Query-Flexibilität auf und bekommst Adressierung in konstanter Zeit zurück.

Triff den Request Router

Wenn ein Request ankommt, geht er nicht direkt zum Storage. Er trifft einen Request Router — eine zustandslose, horizontal skalierte Flotte, die den ganzen Service frontet. (AWS re:Invent „DynamoDB Deep Dive"-Sessions beschreiben diese Frontend-Flotte.)

Der Router tut drei Dinge und hält keine eigenen Daten:

• Authentifiziert und autorisiert den Request gegen IAM.
• Hasht den Partition Key, um die Partition zu finden, die ihn besitzt.
• Leitet den Request an die Storage-Node für diese Partition weiter.

Weil Router zustandslos sind, fügt der Service unter Last mehr davon hinzu. Keiner von ihnen ist ein Bottleneck und keiner ein Single Point of Failure — dieselbe Eigenschaft, um die das Amazon-Dynamo-Paper von 2007 das ursprüngliche System herum baute.

Verfolge einen Read durch den Router

Nimm eine Telemetrie-Tabelle für eine Drohnenflotte. Items sind verschlüsselt nach DroneId (Partition Key) und ReadingTs (Sort Key), mit Attributen wie BatteryPct und AltitudeM.

Du fragst nach der letzten Messung für eine Drohne:

PK = "DRONE#A19F"
SK begins_with "2026-06-23"

Hier ist, was der Router damit tut. Der Einstieg unten verfolgt den Request oben nach unten — lies ihn als einen abwärts gerichteten Fluss.

Der Router hasht DRONE#A19F, bildet ihn auf die Partition ab, die diesen Key besitzt, und leitet den Read an die Primary-Storage-Node dieser Partition weiter, die das Item zurückgibt.

Die Schlüsselerkenntnis: Der Hash zeigt auf eine Partition von wie vielen auch immer die Tabelle hat. Der Router schaut nie auf andere Partitionen, sodass Drohnen — und Partitionen — hinzuzufügen diesen Lookup nicht verlangsamt.

Wisse, was eine Partition tatsächlich ist

Eine Partition ist eine Einheit von Speicher und Throughput. Jede ist gedeckelt (grob 10 GB und eine feste Scheibe Read-/Write-Kapazität), und DynamoDB splittet eine Partition, wenn sie eines der Limits überwächst. Jedes Item mit einem gegebenen Partition Key lebt auf derselben Partition, was eine Query über einen Partition Key billig macht.

Jede Partition ist über drei Storage-Nodes repliziert, verteilt über Availability Zones: eine Primary und zwei Secondaries.

Ein Write geht an die Primary, die zu den Secondaries repliziert, bevor sie Dauerhaftigkeit bestätigt. Ein stark konsistenter Read wird an die Primary geroutet, sodass er den letzten Write widerspiegelt. Ein letztendlich konsistenter Read kann von einer Secondary bedient werden, die noch nicht aufgeholt hat — halbe Kosten, möglicherweise veraltet.

Benenne das Footgun: ein heißer Partition Key

Routing ist nur so gut wie dein Partition Key. Der Hash verteilt Keys gleichmäßig, also wenn deine Keys hohe Kardinalität und gleichmäßigen Traffic haben, verteilt sich die Last über alle Nodes. Brich eine der Eigenschaften und du bekommst eine Hot Partition.

Sagen wir, du verschlüsselst diese Telemetrie nach Region statt DroneId. Jetzt teilt sich jede Drohne in us-east-1 einen Partition Key — sodass jeder ihrer Reads und Writes auf dieselbe Node hasht. Der Router macht seine Arbeit perfekt; du hast nur die ganze Flotte auf die Kapazität einer einzelnen Partition getrichtert.

Du kannst dem Router nicht beim Wählen einer Node zusehen, aber du kannst Keys designen, die gut routen. Wenn du eine Key-Bedingung im Expression Builder baust, ist der Partition Key, den du links von PK = … setzt, genau der Wert, den der Router hashen wird — diesen Wert High-Cardinality zu halten ist, was Reads auf getrennten Nodes hält.

Wie das zurück zu deinen Access Patterns führt

Request-Routing ist der Mechanismus, der die Single-Table-Design-Regeln nicht verhandelbar macht: Du modellierst rund um den Partition Key, weil der Partition Key die Adresse ist. Es ist auch, warum eine Query eine Scan schlägt — eine Query trifft eine Partition durch den Router, während ein Scan jede Partition der Reihe nach abläuft.

Secondary Indexes bekommen ihre eigenen Partitionen und ihr eigenes Routing: Ein GSI wird nach seinem eigenen Partition Key geroutet, unabhängig vom dem der Basistabelle, weshalb ein GSI heiß sein kann, selbst wenn die Tabelle es nicht ist.

Nächste Schritte

Designe Keys, die zu vielen Nodes routen, nicht einer. Skizziere die PK = …-Bedingung im Expression Builder, um genau zu sehen, welcher Wert gehasht wird, dann lade DynoTable herunter, um diese Queries gegen deine eigenen Tabellen zu fahren und zu beobachten, welche Partition Keys deinen Traffic tatsächlich tragen.