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 d'une table DynamoDB correspond au schéma de traitement des commandes relationnel illustré dans Modélisation relationnelle. Elle respecte le Modèle de conception de liste adjacente, méthode couramment utilisée pour représenter les structures de données relationnelles dans DynamoDB.

Le modèle de conception nécessite que vous définissiez un ensemble de types d'entités qui coïncident généralement avec les différentes tables du schéma relationnel. Les éléments d'entité sont ensuite ajoutés à la table à l'aide d'une clé primaire composée (partition et tri). La clé de partition de ces éléments d'entité est l'attribut qui identifie de façon unique l'élément et qui est appelé PK de manière générique sur tous les éléments. L'attribut de la clé de tri contient une valeur d'attribut que vous pouvez utiliser pour un index inversé ou un index secondaire global. Il est appelé SK de manière générique.

Vous définissez les entités suivantes, qui prennent en charge le schéma relationnel de saisie des commandes.

Une fois ces éléments d'entité ajoutés à la table, vous pouvez définir leurs relations en ajoutant des éléments de bord aux partitions des éléments d'entité. La table suivante illustre cette étape.

Dans cet exemple, les partitions Employee, Order et Product Entity de la table disposent d'éléments supplémentaires contenant des pointeurs vers d'autres éléments d'entité de la table. Définissez ensuite quelques index secondaires globaux (GSIs) pour prendre en charge tous les modèles d'accès définis précédemment. Les éléments d'entité n'utilisent pas tous le même type de valeur pour l'attribut de la clé primaire ou l'attribut de la clé de tri. La seule obligation est que les attributs de la clé primaire et de la clé de tri présents soient insérés dans la table.

Le fait que certaines de ces entités utilisent des noms propres et d'autres utilisent d'autres entités IDs comme valeurs de clé de tri permet au même index secondaire global de prendre en charge plusieurs types de requêtes. Cette technique est appelée surcharge d'index secondaire global (GSI). Elle permet de dépasser la limite par défaut de 20 index secondaires globaux pour les tables contenant plusieurs types d'éléments. Ceci est illustré par GSI 1 dans le diagramme suivant :

GSI 2 est conçu pour prendre en charge un schéma d'accès aux applications assez courant, qui consiste à obtenir tous les éléments de la table ayant un état spécifique. Dans le cas d'une grande table dont la répartition des éléments est inégale en termes d'états disponibles, ce modèle d'accès peut entraîner une forte activité, sauf si les éléments sont répartis sur plusieurs partitions logiques pouvant être interrogées en parallèle. Ce modèle de conception s'appelle write sharding.

Pour obtenir ceci pour GSI 2, l'application ajoute l'attribut de la clé primaire de GSI 2 à chaque élément Order. Elle le remplit avec un nombre aléatoire compris dans une plage de 0 à N, où N peut être calculé de façon générique à l'aide de la formule suivante, sauf s'il existe une raison spécifique de faire autrement.

ItemsPerRCU = 4KB / AvgItemSize

PartitionMaxReadRate = 3K * ItemsPerRCU

N = MaxRequiredIO / PartitionMaxReadRate

Supposons par exemple que vous souhaitez obtenir les résultats suivants :

Pour cette table, le calcul du facteur N se présenterait comme suit :

ItemsPerRCU = 4KB / 250B = 16

PartitionMaxReadRate = 3K * 16 = 48K

N = (0.2 * 3M) / 48K = 13

Dans ce cas, vous devez répartir toutes les commandes sur au moins 13 partitions logiques sur GSI 2 afin de garantir que la lecture de tous les éléments Order dont l'état est OPEN n'entraîne pas de surchauffe de la partition sur la couche du stockage physique. Il est recommandé d'augmenter ce nombre en prévision d'éventuelles anomalies dans l'ensemble de données. Il est donc préférable d'utiliser N = 15. Comme mentionné précédemment, vous le faites en ajoutant la valeur aléatoire de 0 à N à l'attribut PK GSI 2 de chaque registre Order et OrderItem inséré sur la table.

Cette répartition suppose que le modèle d'accès qui nécessite le rassemblement de toutes les factures dont l'état est OPEN a lieu de manière occasionnelle, afin que vous puissiez utiliser la capacité de transmission en mode rafale pour satisfaire la demande. Vous pouvez interroger l'index secondaire global suivant à l'aide d'une condition de clé de tri State et Date Range pour générer un sous-ensemble ou l'ensemble des Orders d'un état donné.

Dans cet exemple, les éléments sont répartis de manière aléatoire sur 15 partitions logiques. Cette structure fonctionne, car le modèle d'accès nécessite qu'un grand nombre d'éléments soient récupérés. Ainsi, il est peu probable qu'aucun des 15 threads renvoie des jeux de résultats vides, ce qui pourrait représenter un gaspillage de capacité. Une requête utilise toujours une unité de capacité de lecture (RCU, read capacity unit) ou une unité de capacité d'écriture (WCU, write capacity unit), même si rien n'est renvoyé ou si aucune donnée n'est écrite.

Si le modèle d'accès nécessite une requête très rapide sur cet index secondaire global qui renvoie un ensemble de résultats fragmenté, il est probablement préférable d'utiliser un algorithme de hachage pour répartir les éléments plutôt qu'un modèle aléatoire. Dans ce cas, vous pouvez sélectionner un attribut connu lorsque la requête est exécutée au moment du runtime, et hacher cet attribut dans un espace de clé 0 à 14 lors de l'insertion des éléments. Ils peuvent ainsi être lus de manière efficace à partir de l'index secondaire global.

Enfin, vous pouvez réexaminer les modèles d'accès définis précédemment. Voici la liste des modèles d'accès et des conditions de requête à utiliser avec la nouvelle version DynamoDB de l'application pour les accueillir.