Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exemple de modélisation des données relationnelles dans DynamoDB

Cet exemple décrit comment modéliser des données relationnelles dans Amazon DynamoDB. La conception de la table DynamoDB correspond au schéma de saisie d'ordre relationnel illustré dans. Modélisation relationnelle Cette conception utilise plusieurs tables spécialisées plutôt qu'une seule liste de contiguïté, fournissant des limites opérationnelles claires tout en tirant parti de la stratégie GSIs pour répondre efficacement à tous les modèles d'accès.

L'approche de conception utilise des principes axés sur les agrégats, regroupant les données en fonction des modèles d'accès plutôt que des limites d'entités rigides. Les principales décisions de conception incluent l'utilisation de tables distinctes pour les entités présentant une faible corrélation d'accès, l'intégration des données associées lorsqu'elles sont toujours consultées ensemble et l'utilisation de collections d'articles pour identifier les relations.

Les tables suivantes et les index qui les accompagnent prennent en charge le schéma de saisie des ordres relationnels :

Design de table pour employés

La table Employee stocke les informations sur les employés sous la forme d'une seule entité par élément, optimisée pour les recherches directes avec les employés et prenant en charge plusieurs modèles de requêtes grâce à la stratégie GSIs. Ce tableau illustre le principe de conception de tables distinctes pour les entités présentant des caractéristiques opérationnelles indépendantes et une faible corrélation d'accès entre entités.

La table utilise une clé de partition simple (employee_id) sans clé de tri, car chaque employé est une entité distincte. Quatre GSIs permettent d'effectuer des requêtes efficaces à l'aide de différents attributs :

Conception de la table client

La table Customer conserve les informations sur les clients grâce à la dénormalisation stratégique de account_rep_id afin de permettre des requêtes efficaces aux représentants du compte. Ce choix de conception permet de substituer une légère charge de stockage aux performances des requêtes, éliminant ainsi le besoin de joindre les données du client et du représentant du compte.

Le tableau prend en charge plusieurs numéros de téléphone par client à l'aide d'un attribut de liste, ce qui démontre la flexibilité du schéma de DynamoDB. Le GSI unique permet des flux de travail représentatifs des comptes :

Conception de la table de commande

Le tableau des commandes utilise le partitionnement vertical avec des éléments distincts pour les en-têtes de commande et les articles de commande. Cette conception permet des requêtes efficaces basées sur les produits tout en conservant tous les composants de la commande dans la même partition pour un accès efficace. Chaque commande est composée de plusieurs articles :

Le tableau inclut une dénormalisation stratégique de account_rep_id (reproduit à partir de la table Customer) afin de permettre aux représentants du compte de poser des requêtes directes sans avoir à consulter les clients. Pour les scénarios d'écriture à haut débit, les commandes OPEN incluent le statut et les attributs de partition pour permettre le partitionnement des écritures sur plusieurs partitions.

Quatre GSIs prennent en charge différents modèles de requêtes avec des projections optimisées :

Conception de la table des produits

La table Product utilise le modèle de collecte d'articles pour stocker à la fois les métadonnées du produit et les données d'inventaire dans la même partition. Cette conception tire parti de la relation d'identification entre les produits et le stock : l'inventaire ne peut exister sans un produit parent. L'utilisation de PK=Product_ID avec SK=Product_ID pour les métadonnées du produit et SK=Warehouse_ID pour les articles en stock élimine le besoin d'une table d'inventaire et d'un GSI séparés, réduisant ainsi les coûts d'environ 50 %.

Ce modèle permet des requêtes efficaces à la fois pour l'inventaire individuel de l'entrepôt (GetItem avec clé composite) et pour l'ensemble de l'inventaire de l'entrepôt pour un produit (requête sur la clé de partition). L'attribut total_inventory de l'élément de métadonnées du produit fournit une agrégation dénormalisée pour des recherches rapides de l'inventaire total.

Chaque table est conçue avec des index secondaires globaux spécifiques (GSIs) pour prendre en charge efficacement les modèles d'accès requis. La conception utilise des principes axés sur les agrégats avec une dénormalisation stratégique et une indexation éparse pour optimiser à la fois les performances et les coûts.

Les principales optimisations de conception incluent :

Enfin, vous pouvez réexaminer les modèles d’accès définis précédemment. Le tableau suivant montre comment chaque modèle d'accès est pris en charge efficacement à l'aide de la conception multi-tables avec Strategic GSIs. Chaque modèle utilise des recherches de touches directes ou des requêtes GSI uniques, ce qui permet d'éviter des analyses coûteuses et de fournir des performances constantes à toutes les échelles.