DynamoDB Sort-Key-Strategien: 3 Muster und wann du welches nutzt

Ein DynamoDB-Primärschlüssel besteht aus einem oder zwei Attributen: einem Partition Key allein oder einem Partition Key plus einem Sort Key. Der Partition Key entscheidet, welche physische Partition ein Item hält.

Der Sort Key entscheidet die Ordnung der Items innerhalb dieser Partition — und diese Ordnung ist es, die Query mächtig macht.

Wähle den falschen Sort Key und du kannst zwar noch Daten schreiben, verlierst aber Bereichs-Reads, Ordnung und mehrere Zugriffsmuster aus einer Collection.

Aus SQL kommend, würdest du nachträglich zu einem ORDER BY oder einem Sekundärindex greifen. In DynamoDB backst du die Ordnung von vornherein in den Key ein, oder du bekommst sie nicht.

Wie funktionieren DynamoDB-Sort-Keys?

Ein DynamoDB-Sort-Key ordnet Items innerhalb einer Partition, sodass Query Bereichs-Reads machen kann — >=, between, begins_with — statt ein Item nach dem anderen abzurufen. String-Sort-Keys ordnen nach UTF-8-Bytes (Numbers ordnen numerisch), also entwirf einen String-Key (einen ISO-8601-Zeitstempel, eine mit Nullen aufgefüllte Zahl) so, dass die Byte-Ordnung der Ordnung entspricht, in der du lesen willst.

• Der Sort Key ist dein Index innerhalb der Partition. Er ordnet die Item-Collection auf der Platte, sodass Query Bereichs-Reads machen kann (>=, between, begins_with) statt eines einzelnen GetItem.
• String-Sort-Keys ordnen nach UTF-8-Bytes (Numbers ordnen numerisch). Entwirf einen String-Key so, dass die Byte-Ordnung der Ordnung entspricht, in der du lesen willst — einen ISO-8601- Zeitstempel, eine mit Nullen aufgefüllte Zahl, nie eine rohe UUID oder 6/23/2026.
• Ein gut geformter Sort Key bedient viele Zugriffsmuster. Ein zusammengesetzter Key (EVT#<timestamp>) ist ein Präfix und ein Bereich zugleich — kein GSI nötig.
• Die Richtung ist kostenlos. ScanIndexForward = false liest bei gleichen Kosten neueste-zuerst; speichere keine umgekehrten Zeitstempel, um das vorzutäuschen.

Warum der Sort Key der Hebel ist

Ohne Sort Key ist jedes Item in einer Partition nur über seinen vollständigen Primärschlüssel adressierbar — ein GetItem bestenfalls. Füge einen Sort Key hinzu und DynamoDB speichert Items nach ihm innerhalb der Partition sortiert, was Query freischaltet.

Das bedeutet Bereichsbedingungen (>=, between), Präfix-Matching (begins_with) und ein ScanIndexForward-Flag, um aufsteigend oder absteigend zu lesen.

Laut dem AWS-DynamoDB-Developer-Guide bilden alle Items, die sich einen Partition Key teilen, eine Item-Collection, auf der Platte nach dem Sort Key geordnet.

Der Sort Key ist also nicht nur ein zweiter Identifikator. Er ist der Index, gegen den du innerhalb einer Partition abfragst.

Diese Ordnung ist die Byte-Ordnung des kodierten Sort Keys: Strings vergleichen sich nach UTF-8- Bytes, Zahlen vergleichen sich numerisch. Diese eine Tatsache treibt fast jede Strategie unten an.

Wenn Bereichsabfragen etwas bedeuten sollen, muss die Byte-Ordnung der Ordnung entsprechen, in der du lesen willst.

Strategie 1: mach den Sort Key sortierbar

Der häufigste Fehler ist ein Sort Key, der nicht sinnvoll geordnet ist. Eine zufällige UUID gibt dir Eindeutigkeit, aber keine nützliche Bereichsabfrage — „gib mir die letzten 20" wird unmöglich, weil die Byte-Ordnung willkürlich ist.

Kodiere stattdessen den Wert, nach dem du sortierst und filterst, in den Sort Key hinein, in einer Repräsentation, deren Byte-Ordnung ihrer logischen Ordnung entspricht. Für Zeitstempel heißt das ein lexikografisch sortierbares Format: ein ISO-8601-String oder ein mit Nullen aufgefüllter Epoch-Wert.

ISO-8601 wurde so entworfen, dass der String-Vergleich dem chronologischen Vergleich entspricht — genau das, was eine Bereichsabfrage braucht. Vermeide Formate wie 6/23/2026; sie sortieren falsch, sobald der Monat umschlägt.

Wenn du nach Zahlen sortierst (einem Versionszähler, einem Score), verwende DynamoDBs nativen Number-Typ statt eines Strings, sodass 42 nach 9 sortiert statt davor.

Wenn eine Zahl innerhalb eines zusammengesetzten String-Sort-Keys leben muss, fülle sie auf eine feste Breite mit Nullen auf.

Strategie 2: zusammengesetzte Sort Keys für Hierarchie

Ein Sort Key kann eine Hierarchie kodieren, indem er Segmente mit einem Trennzeichen verkettet, am häufigsten #. Eine einzige begins_with-Bedingung wählt dann einen ganzen Teilbaum:

begins_with(SK, "EVENT#2026-06#") gibt nur die Events vom Juni zurück; das breitere begins_with(SK, "EVENT#") gibt alle davon zurück.

Die Segmentordnung ist eine Design-Entscheidung. Grob-zu-fein (Jahr → Monat → Tag) hält verwandte Items zusammenhängend, sodass ein Bereichs-Read eine günstige Query bleibt statt eines Streuens über die Partition.

Strategie 3: steuere die Richtung mit ScanIndexForward

DynamoDB speichert Items in aufsteigender Sort-Key-Ordnung und liest sie standardmäßig so. Um neueste-zuerst zu lesen — die natürliche Ordnung für einen Activity-Feed — setze ScanIndexForward = false auf die Query.

Das ist ein Read-Zeit-Flag, keine Schema-Entscheidung: dieselbe Collection bedient beide Richtungen bei gleichen Kosten. Invertiere deine Zeitstempel nicht (speichere keinen "Reverse Epoch"), nur um absteigende Reads zu bekommen.

Eine Item-Collection, einmal in aufsteigender Ordnung gespeichert, in beide Richtungen gelesen:

Dieselben Items, dieselbe Partition, dieselben Kosten — nur die Leserichtung unterscheidet sich.

Durchgearbeitetes Beispiel: ein akteurbezogenes Audit-Log

Angenommen, du zeichnest zeitgestempelte Events auf, die von Akteuren erzeugt werden — Benutzer, Services, API- Keys — in einem SaaS-Produkt, und du hast zwei Reads:

1. Den Activity-Stream für einen Akteur, neuestes Event zuerst.
2. Die Events eines Akteurs innerhalb eines Zeitfensters (z. B. "alles zwischen den zwei Deploys"), für eine Untersuchung.

Beide Reads sind auf einen einzigen Akteur bezogen, also ist der Akteur der Partition Key und die Event-Zeit der Sort Key. Verwende generische Key-Namen, sodass dieselbe Tabelle später auch andere Entitäten halten kann:

Das EVT#-Präfix plus ein ISO-8601-Zeitstempel ergibt einen sortierbaren Sort Key. Read 1 ist Query PK = "ACTOR#u_8814" mit ScanIndexForward = false für neueste-zuerst. Read 2 grenzt dieselbe Partition mit einer between-Bedingung auf dem Sort Key ein:

Query
PK = "ACTOR#u_8814"
AND SK BETWEEN "EVT#2026-06-23T00:00:00Z"
AND "EVT#2026-06-23T23:59:59Z"

Eine Collection, zwei Zugriffsmuster, kein GSI — weil der Sort Key sowohl ein Präfix (EVT#) als auch ein Bereich (der Zeitstempel) ist. Der absteigende Read und der Fenster-Read sind die gleichen Items in derselben Ordnung; nur die Parameter unterscheiden sich.

Wenn du diese Key-Bedingung von Hand baust, ist es leicht, die between-Grenzen oder das Escaping reservierter Wörter auf Attributnamen zu verpatzen.

Der DynamoDB Expression Builder generiert die KeyConditionExpression, die ExpressionAttributeNames und die ExpressionAttributeValues für eine begins_with- oder between-Sort-Key-Bedingung.

Kopiere sie direkt in deinen SDK-Aufruf, statt zur Laufzeit Escaping zu debuggen.

In DynoTable umsetzen

Einen Sort Key zu entwerfen ist iterativ: Schreibe ein paar repräsentative Items, führe die Bereichs- Query aus und prüfe, ob die Zeilen in der erwarteten Ordnung zurückkommen. Das gegen eine Live-Tabelle in einer GUI zu tun, schlägt das Hin-und-her durch Code.

Flippe die Sortierrichtung, ziehe die between-Grenzen enger und beobachte, wie sich die zurückgegebene Collection ändert, ohne eine Zeile Code zu schreiben — der schnellste Weg, ein Sort-Key-Design zu bestätigen, bevor du dich darauf festlegst.

Fallstricke und nächste Schritte

• Sort Keys müssen innerhalb einer Partition eindeutig sein. Wenn zwei Events sich einen Zeitstempel teilen können, hänge einen Disambiguator (eine Sequenznummer oder kurze ID) an den Sort Key an, sodass das Composite eindeutig bleibt.
• Eine heiße Partition lässt sich nicht wegsortieren. Wenn ein Akteur weit mehr Events als der Rest produziert, wird der Sort Key dich nicht retten — du brauchst ein Partition-Key- Design, das die Last verteilt. Siehe Single-Table-Design.
• Eine zweite Sortierordnung braucht einen zweiten Index. Der Sort Key der Basistabelle gibt eine Ordnung. Um dieselben Items anders zu ordnen (sagen wir nach Event-Typ), füge einen GSI mit einem anderen Sort Key hinzu — und wäge dabei die Trade-offs zwischen lokalem und globalem Sekundärindex ab.
• Greif nicht zum Scan, um „später zu sortieren". Client-seitig nach einem Scan zu sortieren liest die ganze Tabelle und wirft die Ordnung weg; das ist die Scan-Fußfalle. Schiebe die Ordnung stattdessen in den Sort Key.

Sobald die Key-Bedingung stimmt, probiere DynoTable aus, um die Collection zu modellieren, die aufsteigenden und absteigenden Queries nebeneinander laufen zu lassen und deine Sort-Key-Strategie gegen echte Daten zu verifizieren, bevor sie in Produktion geht.