Single-table design dans DynamoDB

En venant du SQL, l'instinct est une table par entité : customers, orders, order_items. Dans DynamoDB, cet instinct est généralement faux. Une seule table qui stocke toutes les entités, distinguées par des préfixes de clé surchargés, te permet de récupérer un parent et ses enfants en un seul Query — sans jointures, sans N+1.

Qu'est-ce que le single-table design dans DynamoDB ?

Le single-table design stocke chaque entité — clients, commandes, lignes de commande — dans une seule table DynamoDB, distinguées par des préfixes de clé de partition et de clé de tri surchargés. Parce que les clés sont conçues autour de tes modes d'accès plutôt qu'autour de tes entités, un parent et tous ses enfants vivent dans une même collection d'items et reviennent en un seul Query — sans jointures, sans lectures N+1.

L'idée

Choisis des noms de clé génériques (PK, SK) et encode le type d'entité dans la valeur :

Désormais un seul Query PK = "CUSTOMER#42" renvoie le profil et chaque commande en une seule lecture facturée. SK begins_with "ORDER#" le restreint aux seules commandes.

Visuellement, les items surchargés s'empilent sous une même clé de partition en une seule collection d'items :

Une seule lecture de la partition renvoie le client et chaque commande ensemble.

GSI surchargés

La même astuce marche sur les index. Pose un GSI1PK/GSI1SK générique sur les items, et un seul GSI sert plusieurs modes d'accès selon ce que chaque item écrit dans ces attributs :

Désormais Query GSI1 WHERE GSI1PK = "STATUS#OPEN" liste les commandes ouvertes par date — un pattern que la table de base ne peut pas satisfaire. Une entité différente peut réutiliser GSI1 avec sa propre signification (p. ex. CATEGORY#books). Un index, de nombreuses requêtes.

Plusieurs-à-plusieurs : la liste d'adjacence

Pour les relations (un utilisateur dans plusieurs équipes, une équipe avec plusieurs utilisateurs), écris l'arête deux fois avec les ids permutés : PK=USER#1, SK=TEAM#9 et PK=TEAM#9, SK=USER#1. Interroger l'un ou l'autre côté liste l'autre — le substitut DynamoDB d'une table de jointure.

Quand ne pas faire de single-table

Ce n'est pas gratuit. Une table surchargée unique est plus difficile à raisonner, plus dure à faire évoluer, et hostile à l'analytique. Si tes modes d'accès sont réellement inconnus ou changent constamment, ou si les données sont surtout analytiques, des tables séparées (ou un autre magasin) peuvent être le choix plus sensé. Le single-table gagne quand les patterns sont connus et à fort volume.

Le coût de la mauvaise forme

Modéliser en tables séparées force un Scan ou une jointure côté client pour réassembler un client, et c'est le piège du Scan. Modélise d'abord les modes d'accès, puis conçois les clés pour que chacun devienne un Query. (Pour la question inter-entités ad hoc que tu n'as jamais modélisée, le SQL Workbench de DynoTable exécute le JOIN côté client — l'exploration n'a pas à attendre une re-modélisation.)

Esquisse la conception elle-même avec l'outil de Single-Table Design gratuit — il transforme ta liste de modes d'accès en plan PK/SK/GSI avec des items d'exemple et des indications de coût. Estime ce que ces items coûtent par lecture avec le calculateur de taille d'item et de capacité, et essaie DynoTable pour parcourir un schéma single-table et voir les collections surchargées côte à côte.