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.

Bonnes pratiques de gestion des relations « plusieurs-à-plusieurs » dans les tables DynamoDB

Les listes adjacentes constituent un schéma de conception utile pour la modélisation de relations plusieurs à plusieurs dans Amazon DynamoDB. Plus généralement, elles fournissent une manière de représenter des données de graphique (nœuds et arcs) dans DynamoDB.

Modèle de conception de liste adjacente

Lorsque des entités d’une application ont une relation plusieurs à plusieurs entre elles, la relation peut être modélisée sous forme de liste adjacente. Dans ce modèle, toutes les entités de niveau supérieur (soit les nœuds dans le modèle de graphique) sont représentées à l’aide de la clé de partition. Toute relation avec d’autres entités (arcs dans un graphique) est représentée comme un élément de la partition via la définition de l’ID d’entité cible (nœud cible) en tant que valeur de la clé de tri.

Parmi les avantages de ce modèle, on peut citer la duplication minimale des données et les modèles de requête simplifiés pour la recherche de toutes les entités (nœuds) liées à une entité cible (disposant d’un arc vers un nœud cible).

Un système de facturation dans lequel les factures contiennent plusieurs notes constitue un exemple concret pour lequel ce modèle s’avère utile. Une note peut appartenir à plusieurs factures. Dans cet exemple, la clé de partition est InvoiceID ou BillID. Les partitions BillID ont tous les attributs spécifiques aux notes. Les partitions InvoiceID ont un élément qui stocke les attributs spécifiques à la facture, et un élément pour chaque BillID qui se regroupe dans la facture.

Le schéma se présente comme suit :

En utilisant le schéma précédent, vous pouvez voir que toutes les notes d’une facture peuvent être interrogées à l’aide de la clé primaire sur la table. Pour rechercher toutes les factures contenant une partie d’une note, créez un index secondaire global sur la clé de tri de la table.

Les projections pour l’index secondaire global se présentent comme suit :

Modèle de graphique matérialisé

De nombreuses applications doivent comprendre les classements entre pairs, les relations entre les entités et l'état des entités voisines. Si votre application utilise ces types de flux de travail de style graphique, considérez le modèle de conception de schéma suivant.

À titre d'exemple concret, considérez une application de réseau social. Dans cette application, les personnes entretiennent des relations avec d'autres personnes, possèdent des compétences, vivent dans des lieux et ont des dates associées (telles que les dates de naissance). Chaque personne est un nœud dans le graphique. Les liens entre les gens, comme les amitiés, sont des limites. Les associations entre les personnes et leurs attributs (compétences, lieux, dates) sont également des limites.

Grâce au modèle graphique matérialisé, vous pouvez stocker à la fois des nœuds et des arêtes dans une seule table DynamoDB et parcourir les relations de manière efficace. Les diagrammes suivants montrent comment modéliser ce graphique de réseau social. Le premier diagramme montre la structure de la table principale. Les diagrammes suivants présentent les projections de l'indice secondaire mondial.

Le tableau utilise la structure de clés suivante :

Les éléments d’arc contiennent les attributs Target et Type. Elles constituent la clé composite « TypeTarget » qui identifie les éléments de la table principale et du deuxième index secondaire global. Par exemple, « Person-1  est ami avec Person-2 » produitType=Friend,Target=Person-2, etTypeTarget=Friend-Person-2.

Le premier index secondaire global est construit en fonction de l’attribut Data. Cet attribut utilise la surcharge globale de l'index secondaire pour indexer plusieurs types d'attributs au sein d'un même index :

Vous pouvez utiliser cet index secondaire mondial unique pour rechercher toutes les personnes nées à une date précise, toutes les personnes d'un lieu ou toutes les personnes possédant une compétence spécifique.

Le deuxième index secondaire global utilise TypeTarget comme clé de partition pour les recherches inversées. Par exemple, vous pouvez trouver toutes les personnes qui s'inscrivent Person-2 comme amis en effectuant une requête sur. TypeTarget=Friend-Person-2

Lorsque vous insérez des éléments dans le tableau, vous pouvez utiliser une stratégie de partitionnement intelligente pour distribuer des ensembles d'éléments comportant de grandes agrégations (date de naissance, compétence) sur autant de partitions logiques des index secondaires globaux que nécessaire pour éviter les problèmes courants. read/write

Grâce à cette combinaison de modèles de conception, vous obtenez une banque de données solide pour des flux de travail graphiques en temps réel très efficaces. Vous pouvez l'utiliser pour créer des requêtes d'agrégation d'états et de bords d'entités voisines hautes performances pour les moteurs de recommandation, les applications de réseaux sociaux, le classement des nœuds, les agrégations de sous-arbres et d'autres cas d'utilisation courants de graphiques.

Si votre cas d’utilisation n’est pas sensible à la cohérence des données en temps réel, vous pouvez utiliser un processus Amazon EMR planifié pour remplir les arcs avec des regroupements récapitulatifs de graphique pour vos flux de travail. Si votre application n’a pas besoin de connaître immédiatement le moment où un arc est ajouté au graphique, vous pouvez utiliser un processus planifié pour regrouper les résultats.

Pour conserver un certain niveau de cohérence, la conception peut inclure Amazon DynamoDB Streams et AWS Lambda pour le traitement des mises à jour d’arc. Elle peut aussi utiliser une tâche Amazon EMR pour valider les résultats à intervalles réguliers. Le diagramme suivant illustre cette approche. Elle est généralement utilisée dans des applications de réseau social, où le coût d’une requête en temps réel est élevé, et où le besoin de connaître de manière immédiate les mises à jour utilisateur individuelles est faible.

Les applications de gestion de service ITSM et de sécurité ont généralement besoin de répondre en temps réel aux modifications de l’état d’une entité composées de regroupements d’arcs complexe. Ces applications nécessitent un système pouvant prendre en charge des regroupements en temps réel de plusieurs nœuds présentant des relations de deuxième ou de troisième niveau, ou des traversées d’arcs complexes. Si votre cas d’utilisation nécessite des types de flux de travail de requêtes de graphique en temps réel, nous vous recommandons d’envisager l’utilisation d’Amazon Neptune pour la gestion de ces flux de travail.