Outil de Single-Table Design DynamoDB
Saisis tes entités et la manière dont tu as besoin de les lire — le planificateur suggère des modèles de clés PK/SK préfixées par l’entité, prévisualise les collections d’items et n’ajoute un GSI que là où la table de base ne peut pas servir un motif.
Des motifs d’accès à un schéma de clés
Le single-table design part des lectures, pas des entités : au lieu de normaliser des tables et de faire des jointures au moment de la requête, tu listes chaque manière dont l’application a besoin de récupérer des données — obtenir un utilisateur par ID, lister les commandes d’un utilisateur des plus récentes aux plus anciennes, trouver un compte par e-mail — et tu façonnes les clés pour que chacune soit un simple GetItem ou une simple Query. Chaque motif auquel la table de base ne peut pas répondre te coûte un index, et ce compromis devrait être visible avant que tu ne crées la table.
Ce planificateur rend le compromis explicite. Il applique les règles single-table standard de façon déterministe — clés composites préfixées par l’entité, collections d’items pour les motifs un-à-plusieurs, GSI inversés ou restreints à un attribut pour le reste — et lorsqu’un motif ne peut pas être servi proprement, il le dit au lieu de faire semblant. La table d’items d’exemple montre comment les lignes obtenues se placent réellement côte à côte au sein d’une partition.
La sortie est un simple document JSON CreateTable avec des attributs de clé génériques typés en chaîne — rien de spécifique à un outil à défaire plus tard — plus des indications de coût qui réutilisent exactement l’arrondi de 4 KB en lecture / 1 KB en écriture qu’emploient nos calculateurs de tarifs et de taille d’item.
Tu débutes avec ces concepts, ou tu n’es pas sûr que l’approche convienne à ta charge de travail ? Notre guide du single-table design explique l’idée à partir des premiers principes, et quand NE PAS l’utiliser en couvre honnêtement les contre-arguments. Une fois le schéma défini, compose la requête concrète dans le Générateur de requêtes DynamoDB ou estime la facture mensuelle complète avec le Calculateur de tarifs DynamoDB.
Questions fréquentes
Qu’est-ce que le single-table design dans DynamoDB ?
Une approche de modélisation où tous les types d’entités d’une application partagent une seule table dotée d’attributs de clé de partition et de tri génériques (PK/SK). Les items liés partagent une clé de partition, si bien qu’une seule Query les récupère ensemble — la conception est guidée par tes motifs d’accès plutôt que par des formes d’entités normalisées.
Comment ce planificateur décide-t-il de la conception des clés ?
Avec des règles fixes et publiées — déterministes, pas génératives. Chaque entité commence comme la racine de sa propre collection d’items avec des clés préfixées par l’entité ; le premier motif de type « lister les enfants » déplace l’enfant dans la partition de son parent via une clé de tri composite ; les recherches par d’autres attributs, les seconds parents et les motifs « tout lister » deviennent des suggestions de GSI ; et un motif que les règles ne peuvent pas servir proprement est marqué comme non pris en charge au lieu de recevoir une conception inventée.
Quand un motif d’accès nécessite-t-il un index secondaire global ?
Lorsque la disposition des clés de la table de base ne peut pas y répondre : récupérer un enfant réhébergé par son propre ID, lister les mêmes items sous un second parent, trouver un item par un attribut non-clé comme un e-mail, ou lister tous les items d’un type. Chacun de ces cas re-clé les mêmes données, ce que seul un index peut faire — le planificateur en suggère un par forme de clé et le réutilise pour les motifs qui partagent cette forme.
Comment les GSI influencent-ils le coût de DynamoDB ?
Chaque GSI maintient sa propre copie projetée des items qu’il couvre, si bien que chaque écriture dans la table consomme aussi de la capacité d’écriture sur chaque GSI qui projette l’item, et le stockage est facturé par copie. La carte de coût affiche une estimation pour la table de base et une autre incluant la réplication d’écriture des GSI, avec le même arrondi de 4 KB en lecture / 1 KB en écriture que nos calculateurs de tarifs et de taille d’item.
Le planificateur envoie-t-il mon modèle de données quelque part ?
Non. La page est statique et la conception est calculée entièrement dans ton navigateur — les noms d’entités, les attributs ID et les motifs d’accès n’atteignent jamais de serveur. La seule façon pour une conception de quitter la page est l’URL « Copier le lien », qui l’encode dans le lien pour que le partage reste un acte délibéré.