Comment interroger DynamoDB en ordre décroissant

Par défaut, un Query DynamoDB renvoie les items dans l'ordre croissant de la clé de tri. Mais la plupart des modes d'accès « donne-moi le plus récent » veulent l'inverse — le plus récent d'abord. Le bouton est un seul booléen sur le Query : ScanIndexForward. Mets-le à false et la même requête lit la partition à l'envers.

C'est un seul paramètre, mais il fait trébucher les gens parce qu'il est facile de le confondre avec le tri des résultats après coup (ce que DynamoDB ne fait pas) et parce que le nom se lit à l'envers de ce qu'il contrôle.

Comment interroger DynamoDB en ordre décroissant ?

Mets ScanIndexForward=false sur le Query. Par défaut, DynamoDB renvoie les items dans l'ordre croissant de la clé de tri ; retourner ce seul booléen lit la partition à l'envers, te donnant les résultats du plus récent au plus ancien quand ta clé de tri est un horodatage ou une séquence. Cela change seulement l'ordre, pas les items qui correspondent, et les lectures inversées coûtent exactement la même chose que les lectures dans le sens normal.

• ScanIndexForward=true (défaut) → ordre croissant de la clé de tri.
• ScanIndexForward=false → ordre décroissant — le plus récent d'abord quand ta clé de tri est un horodatage ou une séquence.
• Cela n'affecte que l'ordre, pas les items qui correspondent — c'est toujours la condition de clé qui décide de cela.
• C'est gratuit. L'ordre inversé coûte la même chose que le sens normal ; DynamoDB lit l'ordre stocké de la partition dans les deux cas.
• Utilise Limit avec pour obtenir « les N plus récents » en une seule lecture peu coûteuse.

Le problème : « montre-moi le plus récent d'abord »

Disons que tu gères un classement multijoueur et que tu stockes les événements de score de chaque joueur sous une seule clé de partition, triés par un horodatage croissant :

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

Le tableau de bord a besoin des scores les plus récents. Un simple Query sur GAME#42 les renvoie du plus ancien au plus récent, tu serais donc tenté de tout lire et de l'inverser dans ton application — gaspilleur, et cassé dès que tu ajoutes Limit. DynamoDB peut te les rendre du plus récent au plus ancien directement.

Comment fonctionne ScanIndexForward

Les items d'une partition sont physiquement stockés triés par clé de tri. Un Query parcourt cet ordre ; ScanIndexForward choisit juste la direction du parcours :

• true (défaut) — commence à la plus basse clé de tri, remonte (croissant).
• false — commence à la plus haute clé de tri, descend (décroissant).

Chose cruciale, c'est une propriété de la lecture, pas de la table — les mêmes items, la même condition de clé, juste inversés. Et comme DynamoDB ne fait que choisir une direction sur des données déjà triées, les lectures décroissantes sont exactement aussi peu coûteuses que les croissantes. Associe-le à Limit=10 et tu obtiens « les 10 événements de score les plus récents » en une seule requête à coût minimal.

Une subtilité : quand tu pagines à rebours dans un ensemble de résultats décroissant, le curseur LastEvaluatedKey/ExclusiveStartKey fonctionne toujours — garde simplement ScanIndexForward=false cohérent sur chaque page de la même requête, sinon la direction du curseur et l'ordre ne s'accordent pas.

Construire la requête dans DynoTable

Pour assembler la condition de clé elle-même (et voir les tables de noms/valeurs d'attributs correspondantes), utilise le générateur d'expressions DynamoDB. Pour la requête complète — index, Limit et ScanIndexForward compris — le générateur de requêtes compose la Query et émet un programme SDK v3, CLI ou boto3 exécutable.

Dans DynoTable, tu lis un onglet via une clé choisie et tu définis la direction de tri sur l'onglet avec une bascule — sans avoir à écrire ScanIndexForward à la main. Retourne-la pour prévisualiser les résultats du plus récent au plus ancien.

Pièges + étapes suivantes

• ScanIndexForward inverse, il ne trie pas par un attribut arbitraire. L'ordre est toujours par clé de tri — pour trier par autre chose, il te faut cet attribut en tant que clé de tri (souvent via un GSI).
• Ne fais pas tout-lire-puis-inverser dans ton application — pose le flag et ajoute Limit.
• Garde le flag cohérent pendant la pagination d'une requête multi-pages, sinon le curseur se bat avec l'ordre.
• Tu veux du numérique du plus récent d'abord ? Une clé de tri de type Number se trie déjà numériquement. Seulement si tu as embarqué des nombres dans une clé de tri de type chaîne as-tu besoin de les compléter avec des zéros pour que l'ordre lexicographique corresponde.
• Voir aussi : stratégies de clé de tri et pagination.

Tu veux inverser l'ordre des résultats sans toucher aux paramètres de l'API ? Télécharge DynoTable et interroge tes tables directement.

Clés de tri composites et numériques

L'ordre décroissant suit les règles de type de clé de tri, pas ton modèle mental de « le plus récent » :

Si « le plus récent » signifie autre chose que la clé de tri — par exemple trier par points dans la même partition de jeu — tu as besoin de cette métrique dans la clé de tri (ou sur un GSI dont la clé de tri est points), pas d'un tri post-requête dans le code applicatif.

Limit avec des lectures décroissantes

Limit plafonne les items évalués, pas les items renvoyés après un filtre. Couple ScanIndexForward=false avec Limit=10 sur une clé de tri ordonnée dans le temps pour récupérer les dix événements les plus récents en une lecture de partition.

Exemple de coût : dix items de 2 Ko dans un Query décroissant touchent 20 Ko → 3 RCU à cohérence à terme (arrondi aux blocs de 4 Ko). Lire toute la partition de 10 000 événements pour inverser dans le code applicatif touche ~20 Mo → des milliers de RCU pour le même widget UI. Modélise la taille de ta partition avec le calculateur de taille d'item avant de choisir Limit.

La pagination reste directionnelle

Quand tu pages avec ExclusiveStartKey, garde ScanIndexForward identique sur chaque requête. Basculer le drapeau entre les pages inverse la sémantique du curseur — tu peux sauter ou dupliquer des lignes.

Pour les API qui exposent « charger plus », encode en base64 le LastEvaluatedKey de façon opaque ; les clients ne doivent pas muter les composants de clé de tri. Voir pagination pour les motifs de token.

Parité PartiQL et SDK

Les requêtes PartiQL ExecuteStatement acceptent la même sémantique d'ordre via les paramètres Query sous-jacents quand l'exécuteur mappe vers une lecture à condition de clé. Le query builder émet des programmes SDK v3, CLI ou boto3 avec ScanIndexForward câblé explicitement — utile quand ton équipe mélange des requêtes PartiQL ad hoc et du code SDK de production.

Modes d'accès qui utilisent l'ordre décroissant

• Flux d'activité — SK est un timestamp ISO ; décroissant + Limit donne une fenêtre récente.
• Classements — clé de tri numérique score ; décroissant fait remonter les meilleurs scores quand la clé de partition scope un jeu ou une saison.
• Queue d'audit — clés de tri append-only EVENT#<ts> ; décroissant montre les événements les plus récents d'abord sans GSI.

Quand l'UI a aussi besoin d'un historique croissant (« montrer le plus ancien d'abord »), la même requête avec ScanIndexForward=true évite de dupliquer les données ou de maintenir deux index.

Essayer la bascule sur de vraies données

Connecte DynoTable, ouvre un onglet de requête sur une partition avec une clé de tri ordonnée dans le temps, bascule croissant/décroissant, et regarde la grille se réordonner sans éditer les paramètres API. Compare la capacité consommée dans le journal d'opérations — lectures avant et arrière sur le même Limit devraient matcher.