DynamoDB in absteigender Reihenfolge abfragen

Standardmäßig gibt eine DynamoDB-Query Items in aufsteigender Sort-Key-Reihenfolge zurück. Die meisten „gib mir die neuesten“-Zugriffsmuster wollen aber das Gegenteil — neueste zuerst. Der Schalter ist ein einzelner Boolean an der Query: ScanIndexForward. Setz ihn auf false und dieselbe Abfrage liest die Partition rückwärts.

Es ist ein einziger Parameter, aber er bringt Leute aus dem Tritt: Man verwechselt ihn leicht mit dem Sortieren der Ergebnisse im Nachhinein (was DynamoDB nicht tut), und der Name liest sich andersherum als das, was er steuert.

Wie frage ich DynamoDB in absteigender Reihenfolge ab?

Setze ScanIndexForward=false an der Query. Standardmäßig gibt DynamoDB Items in aufsteigender Sort-Key-Reihenfolge zurück; das Umlegen dieses einen Booleans liest die Partition rückwärts und liefert dir die neuesten zuerst, wenn dein Sort Key ein Zeitstempel oder eine Sequenz ist. Es ändert nur die Reihenfolge, nicht welche Items passen, und umgekehrte Lesevorgänge kosten exakt dasselbe wie vorwärts gerichtete.

• ScanIndexForward=true (Standard) → aufsteigende Sort-Key-Reihenfolge.
• ScanIndexForward=false → absteigende Reihenfolge — neueste zuerst, wenn dein Sort Key ein Zeitstempel oder eine Sequenz ist.
• Es beeinflusst nur die Reihenfolge, nicht welche Items passen — das entscheidet weiterhin die Key-Bedingung.
• Es ist gratis. Umgekehrte Reihenfolge kostet dasselbe wie vorwärts; DynamoDB liest die gespeicherte Reihenfolge der Partition so oder so.
• Nutze Limit dazu, um „die N neuesten“ in einem günstigen Lesevorgang zu bekommen.

Das Problem: „zeig mir die neuesten zuerst“

Angenommen, du betreibst ein Multiplayer-Leaderboard und speicherst die Score-Events jedes Spielers unter einem Partition Key, sortiert nach einem steigenden Zeitstempel:

PK: GAME#42   SK: SCORE#2026-06-27T10:00:00Z   points
PK: GAME#42   SK: SCORE#2026-06-27T10:05:00Z   points
PK: GAME#42   SK: SCORE#2026-06-27T10:09:00Z   points

Das Dashboard braucht die neuesten Scores. Eine schlichte Query auf GAME#42 gibt sie älteste-zuerst zurück, also wärst du versucht, alles zu lesen und in deiner App umzudrehen — verschwenderisch, und kaputt in dem Moment, in dem du Limit ergänzt. DynamoDB kann sie dir direkt neueste-zuerst zurückgeben.

Wie ScanIndexForward funktioniert

Items in einer Partition werden physisch nach Sort Key geordnet gespeichert. Eine Query läuft diese Reihenfolge ab; ScanIndexForward wählt nur die Richtung des Laufs:

• true (Standard) — beim niedrigsten Sort Key starten, aufwärts laufen (aufsteigend).
• false — beim höchsten Sort Key starten, abwärts laufen (absteigend).

Entscheidend: Das ist eine Eigenschaft des Lesevorgangs, nicht der Tabelle — dieselben Items, dieselbe Key-Bedingung, nur umgekehrt. Und weil DynamoDB nur eine Richtung über bereits sortierte Daten wählt, sind absteigende Lesevorgänge genau so günstig wie aufsteigende. Kombiniert mit Limit=10 bekommst du „die 10 neuesten Score-Events“ in einer einzigen Query zu minimalen Kosten.

Eine Feinheit: Wenn du rückwärts durch ein absteigendes Result Set blätterst, funktioniert der Cursor LastEvaluatedKey/ExclusiveStartKey weiterhin — halte nur ScanIndexForward=false über jede Seite derselben Abfrage konstant, sonst widersprechen sich Cursor-Richtung und Sortierung.

Die Abfrage in DynoTable bauen

Um die Key-Bedingung selbst zusammenzusetzen (und die passenden Attributnamen-/Wert-Maps zu sehen), nutze den DynamoDB Expression Builder. Für den gesamten Request — inklusive Index, Limit und ScanIndexForward — komponiert der Query Builder die Query und gibt ein lauffähiges Programm für SDK v3, CLI oder boto3 aus.

In DynoTable liest du einen Tab über einen gewählten Key und stellst die Sortierrichtung des Tabs mit einem Umschalter ein — ScanIndexForward musst du nicht von Hand schreiben. Leg ihn um, um die Ergebnisse mit den neuesten zuerst vorab zu sehen.

Fallstricke + nächste Schritte

• ScanIndexForward dreht um, es sortiert nicht nach einem beliebigen Attribut. Sortiert wird immer nach dem Sort Key — um nach etwas anderem zu sortieren, brauchst du dieses Attribut als Sort Key (oft über eine GSI).
• Lies nicht alles und dreh es dann in deiner App um — setz das Flag und ergänze Limit.
• Halte das Flag beim Blättern durch eine mehrseitige Abfrage konstant, sonst kämpft der Cursor gegen die Sortierung.
• Du willst numerisch neueste zuerst? Ein Sort Key vom Typ Number sortiert bereits numerisch. Nur wenn du Zahlen in einen String-Sort-Key eingebettet hast, musst du sie mit Nullen auffüllen, damit die lexikografische Reihenfolge passt.
• Verwandt: Sort-Key-Strategien und Paginierung.

Du willst die Ergebnisreihenfolge umlegen, ohne API-Parameter anzufassen? Lade DynoTable herunter und frage deine Tabellen direkt ab.

Zusammengesetzte und numerische Sort Keys

Die absteigende Reihenfolge folgt den Typregeln des Sort Keys, nicht deinem mentalen Modell von „neueste“:

Wenn „neueste“ etwas anderes bedeutet als der Sort Key — zum Beispiel Sortieren nach points innerhalb derselben Spielpartition —, brauchst du diese Metrik im Sort Key (oder auf einer GSI, deren Sort Key points ist), nicht eine Sortierung nach der Abfrage im Anwendungscode.

Limit bei absteigenden Lesevorgängen

Limit deckelt die ausgewerteten Items, nicht die nach einem Filter zurückgegebenen. Kombiniere ScanIndexForward=false mit Limit=10 auf einem zeitlich geordneten Sort Key, um die zehn neuesten Events in einem Partitions-Lesevorgang zu holen.

Beispielkosten: zehn Items zu je 2 KB in einer absteigenden Query berühren 20 KB → 3 letztendlich konsistente RCU (auf 4-KB-Blöcke gerundet). Die gesamte Partition mit 10.000 Events zu lesen, um sie im Anwendungscode umzudrehen, berührt ~20 MB → Tausende RCU für dasselbe UI-Widget. Modelliere deine Partitionsgröße mit dem Item-Size-Rechner, bevor du Limit wählst.

Paginierung bleibt richtungsgebunden

Wenn du mit ExclusiveStartKey blätterst, halte ScanIndexForward in jedem Request identisch. Das Flag zwischen Seiten umzulegen kehrt die Cursor-Semantik um — du kannst Zeilen überspringen oder doppelt bekommen.

Für APIs mit „mehr laden“ kodiere den LastEvaluatedKey undurchsichtig als base64; Clients sollten Sort-Key-Bestandteile nicht verändern. Token-Muster stehen in Paginierung.

PartiQL- und SDK-Parität

PartiQL-Abfragen über ExecuteStatement übernehmen dieselbe Ordnungssemantik über die zugrunde liegenden Query-Parameter, wenn der Executor auf einen Lesevorgang mit Key-Bedingung abbildet. Der Query Builder gibt Programme für SDK v3, CLI oder boto3 mit explizit verdrahtetem ScanIndexForward aus — hilfreich, wenn dein Team PartiQL-Ad-hoc-Abfragen mit produktivem SDK-Code mischt.

Zugriffsmuster mit absteigender Reihenfolge

• Activity-Feeds — SK ist ein ISO-Zeitstempel; absteigend + Limit liefert ein aktuelles Zeitfenster.
• Leaderboards — numerischer Sort Key score; absteigend holt die Top-Scores nach oben, wenn der Partition Key ein Spiel oder eine Saison abgrenzt.
• Audit-Verlauf — Sort Keys EVENT#<ts> im Append-only-Betrieb; absteigend zeigt die neuesten Events zuerst, ganz ohne GSI.

Wenn die UI zusätzlich die aufsteigende Historie braucht („älteste zuerst anzeigen“), vermeidet dieselbe Abfrage mit ScanIndexForward=true doppelte Daten oder zwei zu pflegende Indizes.

Probier den Umschalter an echten Daten

Verbinde DynoTable, öffne einen Query-Tab auf einer Partition mit zeitlich geordnetem Sort Key, leg zwischen aufsteigend und absteigend um und sieh zu, wie sich das Grid neu ordnet, ohne dass du API-Parameter bearbeitest. Vergleiche die verbrauchte Kapazität im Operations-Log — Vorwärts- und Rückwärts-Lesevorgänge sollten bei gleichem Limit übereinstimmen.