Collections d'items DynamoDB

Une collection d'items est l'ensemble de tous les items d'une table (ou d'un index) qui partagent la même valeur de clé de partition. Ce n'est pas une fonctionnalité que tu actives — c'est une propriété émergente de ton schéma de clés.

Dès l'instant où deux items portent la même clé de partition, ils forment une collection, et cette collection devient l'unité que DynamoDB te laisse lire ensemble en un seul Query.

Fais-le correctement et tes lectures reviennent en un seul aller-retour. Rate-le et tu es coincé avec un Scan.

Qu'est-ce qu'une collection d'items DynamoDB ?

Une collection d'items DynamoDB est l'ensemble de tous les items qui partagent la même valeur de clé de partition, stockés ensemble et triés par clé de tri. Ce n'est pas une fonctionnalité que tu actives — elle émerge de ton schéma de clés. La collection est l'unité qu'un seul Query lit efficacement, alors qu'un Scan parcourt chaque partition.

• Une collection, c'est juste « même clé de partition ». Deux items ou plus avec la même valeur de clé de partition sont stockés ensemble, triés par clé de tri.
• C'est l'unité d'un Query efficace. Query lit une collection ; Scan parcourt chaque partition. C'est toute l'histoire de la performance.
• Pas de clé de tri, pas de collection. Une table à clé de partition seule contient un item par clé — rien à collecter.
• Deux limites mordent : le plafond de 10 GB par collection quand un LSI existe, et les partitions surchargées venant des clés à faible cardinalité.

Le problème : lire des items liés ensemble

Disons que tu gères une flotte de véhicules, chacun diffusant de la télémétrie — vitesse, température du liquide de refroidissement, niveau de carburant — toutes les quelques secondes. La lecture dominante est « donne-moi les relevés récents du véhicule V-7741 ».

Quand tu viens du SQL, tu indexerais une colonne vehicle_id et laisserais le planificateur faire le travail. Un simple magasin clé-valeur n'a pas ce luxe.

Il traite chaque relevé comme un enregistrement isolé, donc cette question signifie scanner toute la table et filtrer. Lent, coûteux, et pire à mesure que la flotte grandit.

La réponse de DynamoDB est de faire de « tous les relevés d'un véhicule » une chose physiquement groupée et adressable directement. Ce groupement est la collection d'items.

Ce qu'est réellement une collection

DynamoDB stocke les items dans des partitions, et route chaque item vers une partition en hachant sa clé de partition. Chaque item avec la même valeur de clé de partition est stocké ensemble et trié par clé de tri. Ils démarrent sur une partition, mais sans LSI DynamoDB peut diviser une collection grande ou surchargée entre partitions à une frontière de clé de tri ; seul un LSI épingle la collection entière à une seule partition (c'est pourquoi le plafond de 10 GB ci-dessous est propre aux LSI).

Le Developer Guide d'AWS le nomme exactement : les items qui partagent une valeur de clé de partition sont une collection d'items, stockés ensemble et ordonnés par clé de tri.

C'est la même idée que celle introduite par l'article Amazon Dynamo de 2007 — le hachage cohérent pour assigner des clés aux nœuds — étendue avec une dimension de tri pour que les items liés soient adjacents sur le disque.

Parce qu'ils sont adjacents et ordonnés, DynamoDB renvoie une suite contiguë d'entre eux en un seul seek. C'est pourquoi Query est bon marché et Scan ne l'est pas : Query lit une seule collection ; Scan parcourt chaque partition.

Pour former une collection, il te faut une clé primaire composite — une clé de partition et une clé de tri. Une table avec une clé de partition seule a exactement un item par valeur de clé, donc il n'y a rien à collecter.

Notre exemple concret : véhicule → relevés de télémétrie

Modélise le flux de télémétrie avec une clé composite. La clé de partition identifie le véhicule ; la clé de tri est le timestamp du relevé, ce qui garde les relevés dans l'ordre temporel (ascendant par défaut ; passe ScanIndexForward=false pour du plus-récent-d'abord).

Deux collections vivent ici — une par véhicule. L'item META (métadonnées du véhicule) et tous les relevés de V-7741 forment une collection ; les items de V-7742 en forment une autre.

Note l'astuce : donne aux métadonnées une clé de tri (META) qui se trie avant n'importe quelle valeur TS#..., et un seul Query sur PK = "VEH#V-7741" renvoie le profil du véhicule et ses relevés ensemble.

C'est le pattern parent-et-enfants au cœur du single-table design.

Chaque boîte en pointillés est une collection d'items : même clé de partition, items triés par clé de tri. Un Query lit exactement une boîte.

Interroger une collection

Parce que la collection est triée par clé de tri, tu obtiens des lectures par plage gratuitement. Pour extraire les relevés enregistrés dans une fenêtre de dix minutes pour un véhicule, tu bornes la clé de tri :

# Query
KeyConditionExpression   vehicleId = :v AND recordedAt BETWEEN :from AND :to
ScanIndexForward         false        # newest first

La condition de clé te restreint à une seule collection (vehicleId = :v) puis à une tranche contiguë de celle-ci (recordedAt BETWEEN ...). DynamoDB ne lit que ces items et ne te facture qu'eux. Tu veux juste les métadonnées ? recordedAt = "META" récupère le seul item META.

Construire ces conditions de clé et expressions de projection à la main est délicat. L' Expression Builder DynamoDB génère la KeyConditionExpression, les ExpressionAttributeNames et les ExpressionAttributeValues pour toi, pour que les détails de mots réservés et de placeholders ne te mordent pas.

Collections sur les index

Un index secondaire a son propre schéma de clés, donc il forme ses propres collections d'items.

Ajoute un index secondaire global avec depotCode (partition) et recordedAt (tri) comme clés, et « tous les relevés du dépôt DEP-LON-3, plus récents d'abord » devient un seul Query contre la collection de cet index — une lecture que la table de base ne peut pas servir.

C'est pourquoi le type d'index importe : il gouverne quelles collections tu peux former et comment elles se comportent. Voir GSI vs LSI pour l'arbitrage.

Une distinction nette : un index secondaire local (LSI) partage la clé de partition de la table de base, donc sa collection est physiquement liée à la collection d'items de base — et ce lien crée une limite dure, ci-dessous.

Les limites qui mordent

Les collections d'items sont puissantes, mais deux contraintes décident comment tu façonnes les clés :

• La limite LSI de 10 GB. Quand une table a un ou plusieurs index secondaires locaux, une seule collection d'items — les items de base plus leurs projections LSI pour une clé de partition — ne peut pas dépasser 10 GB. Dépasse-la et les écritures qui font grossir la collection commencent à échouer avec ItemCollectionSizeLimitExceededException. Une table sans LSI n'a pas ce plafond par collection. C'est exactement pourquoi un flux non borné et toujours croissant (une télémétrie qui ne s'arrête jamais) convient mal à un LSI : la collection ne fait que grossir. Un GSI obtient ses propres partitions, donc il contourne la limite.
• Partitions surchargées. Une collection vit dans une partition, et une seule partition a un débit fini. Si un véhicule (ou un depotCode) attire une part de trafic follement disproportionnée, tu peux surchauffer cette partition alors même que la table dans son ensemble est bien en dessous de son débit provisionné. La capacité adaptative — présentée dans les deep-dives re:Invent « Advanced Design Patterns for DynamoDB » d'AWS — isole et dope les clés surchargées automatiquement, mais elle ne peut pas sauver une clé sans aucune répartition. Choisis des clés de partition à cardinalité élevée pour que le trafic se déploie sur de nombreuses collections.

Vois-le dans DynoTable

Le moyen le plus rapide de développer l'intuition des collections est d'en regarder une. Dans DynoTable, interroger une clé de partition affiche la collection entière comme une liste contiguë, ordonnée par clé de tri — l'item META se trouve juste devant ses relevés horodatés, à l'écran, sans reconstruction mentale nécessaire.

Pièges et étapes suivantes

• Pas de clé de tri, pas de collection. Une table à clé de partition seule ne peut pas grouper des items liés. Si tu as besoin de lire des items ensemble, il te faut une clé composite.
• Ne laisse pas une collection LSI grossir sans borne. Les flux en append-only appartiennent à un GSI (ou à une clé de partition regroupée par temps), pas à un LSI, à cause du plafond de 10 GB.
• Répartis tes clés de partition. Une collection n'est aussi scalable que la partition où elle vit. Les clés de partition à faible cardinalité créent des points chauds.
• Vise Query, pas Scan. Les collections existent pour que tu puisses lire des items liés avec un seul Query ciblé ; retomber sur un Scan jette cet avantage — voir Query vs Scan.

Esquisse ton propre schéma de clés, exécute un Query contre une vraie clé de partition, et regarde la collection revenir ordonnée. Télécharge DynoTable et explore les collections de tes tables directement.