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.

Utilisation d'index secondaires globaux dans DynamoDB

Certaines applications peuvent avoir besoin d'exécuter de nombreux types de requêtes, à l'aide de divers attributs comme critères de requête. Pour prendre en charge ces exigences, vous pouvez créer un ou plusieurs index secondaires globaux et émettre des demandes Query sur ces index dans Amazon DynamoDB.

Étape 6 : Utiliser un index secondaire global

À des fins d'illustration, considérons une table nommée GameScores qui assure le suivi des utilisateurs et enregistre les scores d'une application de jeux pour appareils mobiles. Chaque élément dans GameScores est identifié par une clé de partition (UserId) et une clé de tri (GameTitle). Le schéma suivant illustre la façon dont les éléments de la table seront organisés. (Tous les attributs ne sont pas affichés.)

Supposons maintenant que vous vouliez écrire une application de classement pour afficher les meilleurs scores de chaque partie. Une requête ayant spécifié les attributs clé (UserId et GameTitle) serait très efficace. Cependant, si l'application a besoin d'extraire les données depuis GameScores en fonction de GameTitle uniquement, elle nécessiterait l'utilisation d'une opération Scan. Lorsque plusieurs éléments sont ajoutés à la table, les analyses de toutes les données deviennent lentes et inefficaces. Cela rend difficile la réponse aux questions suivantes :

Afin d'accélérer les requêtes sur des attributs autres que de clé, vous pouvez créer un index secondaire global. Un index secondaire global contient une sélection d'attributs de la table de base, mais ils sont organisés selon une clé primaire différente de celle de la table. La clé d'index n'a pas besoin d'avoir l'un des attributs de clé de la table. Elle n'a même pas besoin d'avoir le même schéma de clé qu'une table.

Par exemple, vous pouvez créer un index secondaire global nommé GameTitleIndex, avec une clé de partition GameTitle et une clé de tri TopScore. Comme les attributs de la clé primaire de la table de base sont toujours projetés sur un index, l'attribut UserId est également présent. Le schéma suivant illustre ce à quoi l'index GameTitleIndex doit ressembler.

Maintenant, vous pouvez interroger GameTitleIndex et obtenir facilement les scores de Meteor Blasters. Les résultats sont triés sur les valeurs de la clé de tri, TopScore. Si vous définissez le paramètre ScanIndexForward sur la valeur false, les résultats sont retournés par ordre décroissant, de telle sorte que le meilleur score est retourné en premier.

Chaque index secondaire global doit avoir une clé de partition et peut avoir une clé de tri facultative. Le schéma de la clé d'index peut être différent de celui de la table de base. Vous pouvez disposer d'une table avec une clé primaire simple (clé de partition), et créer un index secondaire global avec une clé primaire composite (clé de partition et clé de tri), ou inversement. Les attributs de clé d'index peuvent se composer de n'importe lequel des attributs String, Number ou Binary de niveau supérieur de la table de base. Les autres types scalaires, types de document et types d'ensemble ne sont pas autorisés.

Vous pouvez projeter d'autres attributs de table de base sur l'index si vous le souhaitez. Lorsque vous interrogez l'index, DynamoDB peut extraire ces attributs projetés de façon efficace. Cependant, les interrogations d'index secondaire global ne peuvent pas extraire d'attributs de la table de base. Par exemple, si vous interrogez GameTitleIndex comme illustré dans le diagramme précédent, la requête ne peut pas accéder aux attributs non-clé autres que TopScore (même si les attributs de clé GameTitle et UserId sont automatiquement projetés).

Dans une table DynamoDB, chaque valeur de clé doit être unique. En revanche, les valeurs de clé dans un index secondaire global n'ont pas besoin d'être uniques. À des fins d'illustration, supposons qu'un jeu nommé Comet Quest soit particulièrement difficile, avec de nombreux utilisateurs qui tentent en vain d'obtenir un score supérieur à zéro. Les quelques données suivantes représentent ce comportement.

Lorsque de l'ajout de ces données à la table GameScores, DynamoDB les propage vers GameTitleIndex. Si nous interrogeons alors l'index à l'aide de Comet Quest pour GameTitle et de 0 pour TopScore, les données suivantes sont renvoyées.

Seuls les éléments avec les valeurs de clé spécifiée apparaissent dans la réponse. Au sein de cet ensemble de données, les éléments ne figurent dans aucun ordre particulier.

Un index secondaire global ne suit que les éléments de données où ses attributs clés existent réellement. Par exemple, supposons que vous ayez ajouté un nouvel élément à la table GameScores, mais que vous n'ayez fourni que les attributs de clé primaires requis.

Étant donné que vous n'avez pas spécifié l'attribut TopScore, DynamoDB ne propage pas cet élément vers GameTitleIndex. Par conséquent, si vous interrogiez GameScores pour tous les éléments Comet Quest, vous obtiendriez les quatre éléments suivants.

Une requête similaire sur GameTitleIndex renvoie toujours trois éléments, plutôt que quatre. Cela est dû au fait que l'élément avec TopScore non existant n'est pas propagé sur l'index.

Projections d'attribut

Une projection est l'ensemble d'attributs copié à partir d'une table dans un index secondaire. Les clés de partition et de tri de la table sont toujours projetées dans l'index. Vous pouvez projeter d'autres attributs en fonction des exigences de requête de votre application. Lorsque vous interrogez un index, Amazon DynamoDB peut accéder à n'importe quel attribut dans la projection, comme s'il se trouvait dans une table.

Lorsque vous créez un index secondaire, vous devez spécifier les attributs qui seront projetés dans celui-ci. Pour cela, DynamoDB propose trois options :

Dans le précédent diagramme, GameTitleIndex n'a qu'un seul attribut projeté : UserId. Par conséquent, si une application peut déterminer efficacement le UserId des joueurs avec les scores les plus élevés pour chaque jeu à l'aide de GameTitle et de TopScore dans des requêtes, elle peut déterminer efficacement le taux le plus élevé de victoires par rapport au nombre de défaites pour ces joueurs. Pour ce faire, elle doit exécuter une requête supplémentaire sur la table de base afin d'extraire les victoires et les défaites pour chacun des joueurs aux scores les plus élevés. Une façon plus efficace de prendre en charge les requêtes sur ces données serait de projeter ces attributs de la table de base vers l'index secondaire global, comme illustré dans ce diagramme.

Comme les attributs non clés Wins etLosses sont projetés dans l'index, une application peut déterminer le rapport entre le nombre de victoires et le nombre de défaites de n'importe quel jeu, ou pour toute combinaison d'ID d'utilisateur et de jeu.

Lorsque vous choisissez les attributs à projeter sur un index secondaire global, vous devez prendre en compte le compromis entre les coûts de débit approvisionné et les coûts de stockage :

Lecture de données à partir d'un index secondaire global

Vous pouvez extraire des éléments d'un index secondaire global à l'aide des opérations Query et Scan. Vous ne pouvez pas utiliser les opérations GetItem et BatchGetItem sur un index secondaire global.

Interrogation d'un index secondaire global

Vous pouvez utiliser l'opération Query pour accéder à un ou plusieurs éléments dans un index secondaire global. La requête doit spécifier le nom de la table de base et le nom de l'index que vous souhaitez utiliser, les attributs à renvoyer dans les résultats de la requête, ainsi que toutes les conditions de requête que vous souhaitez appliquer. DynamoDB peut renvoyer les résultats dans l'ordre croissant ou décroissant.

Prenez en compte les données suivantes retournées à partir d'une opération Query qui demande les données de jeu pour une application de classement.

{
    "TableName": "GameScores",
    "IndexName": "GameTitleIndex",
    "KeyConditionExpression": "GameTitle = :v_title",
    "ExpressionAttributeValues": {
        ":v_title": {"S": "Meteor Blasters"}
    },
    "ProjectionExpression": "UserId, TopScore",
    "ScanIndexForward": false
}

Dans cette requête :

Interrogation d'un index secondaire global

Vous pouvez utiliser l'opération Scan pour extraire toutes les données d'un index secondaire global. Vous devez fournir le nom de la table de base et le nom de l'index dans la demande. Avec une opération Scan, DynamoDB lit toutes les données de l'index et les renvoie à l'application. Vous pouvez également demander que seules quelques données soient retournées, et que les données restantes soient ignorées. Pour ce faire, utilisez le paramètre FilterExpression de l'opération Scan. Pour de plus amples informations, veuillez consulter Filtrer les expressions pour l'opération d'analyse.

Synchronisation des données entre les tables et les index secondaires globaux

DynamoDB synchronise automatiquement chaque index secondaire global avec sa table de base. Quand une application écrit ou supprime des éléments dans une table, tout index secondaire global sur cette table est mis à jour de manière asynchrone, à l'aide d'un modèle éventuellement cohérent. Les applications n'écrivent jamais directement sur un index. Cependant, il est important de comprendre les implications de la façon dont DynamoDB gère ces index.

Les index secondaires globaux héritent du mode de capacité en lecture/écriture de la table de base. Pour de plus amples informations, veuillez consulter Considérations relatives au changement de mode de capacité dans DynamoDB.

Lorsque vous créez un index secondaire global, vous spécifiez un ou plusieurs attributs de clé d'index et leurs types de données. Cela signifie que chaque fois que vous écrivez un élément sur la table de base, les types de données de ces attributs doivent correspondre aux types de données du schéma de la clé d'index. Dans le cas de GameTitleIndex, la clé de partition GameTitle de l'index est définie comme type de données String. La clé de tri TopScore de l'index est de type Number. Si vous essayez d'ajouter un élément à la table GameScores et spécifiez un type de données différent pour GameTitle ou pour TopScore, DynamoDB renvoie une ValidationException en raison de la discordance des types de données.

Lorsque vous insérez ou supprimez des éléments dans une table, les index secondaires globaux sont mis à jour selon une façon éventuellement cohérente. Les modifications apportées aux données de la table sont propagées sur les index secondaires globaux en une fraction de seconde, dans des conditions normales. Cependant, dans certains scénarios de défaillance peu probables, les retards de propagation peuvent être plus longs. Pour cette raison, vos applications ont besoin d'anticiper et de gérer les situations où une requête sur un index secondaire global renvoie des résultats qui ne sont pas à jour.

Si vous écrivez un élément dans une table, vous n'avez pas à spécifier les attributs pour une clé de tri d'index secondaire global. Si vous utilisez GameTitleIndex comme exemple, vous n'avez pas besoin de spécifier une valeur pour l'attribut TopScore pour pouvoir écrire un nouvel élément sur la table GameScores. Dans ce cas, DynamoDB n'écrit aucune donnée dans l'index pour cet élément particulier.

Une table avec de nombreux index secondaires globaux s'expose à des coûts plus élevés pour l'activité d'écriture qu'une table ayant moins d'index. Pour de plus amples informations, veuillez consulter Considérations sur le débit alloué pour les index secondaires globaux.

Classes de tables avec index secondaire global

Un index secondaire global utilisera toujours la même classe de tables que sa table de base. Chaque fois qu'un nouvel index secondaire global est ajouté à une table, le nouvel index utilise la même classe de tables que sa table de base. Lorsque la classe de tables d'une table est mise à jour, tous les index secondaires globaux associés sont également mis à jour.

Considérations sur le débit alloué pour les index secondaires globaux

Lorsque vous créez un index secondaire global sur une table en mode approvisionné, vous devez spécifier des unités de capacité de lecture et d'écriture pour la charge de travail prévue sur cet index. Les paramètres de débit approvisionné d'un index secondaire global sont distincts de ceux de sa table de base. Une opération Query sur un index secondaire global consomme les unités de capacité de lecture de l'index, pas de la table de base. Lorsque vous insérez ou supprimez des éléments dans une table, les index secondaires globaux sont également mis à jour. Ces mises à jour d'index consomment des unités de capacité d'écriture à partir de l'index, et non à partir de la table de base.

Par exemple, si vous exécutez une opération Query sur un index secondaire global et dépassez sa capacité de lecture approvisionnée, votre demande est limitée. Si vous exécutez une activité d'écriture massive sur la table, alors qu'un index secondaire global sur celle-ci a une capacité d'écriture insuffisante, l'activité d'écriture sur la table est limitée.

Afin de modifier les paramètres de débit approvisionné pour un index secondaire global, utilisez l'opération DescribeTable. Des informations détaillées sur tous les index secondaires globaux de la table sont retournées.

Unités de capacité de lecture

Les index secondaires globaux prennent en charge les lectures éventuellement cohérentes ; chacune d'elles utilise la moitié d'une unité de capacité en lecture. Cela signifie qu'une interrogation d'index secondaire global peut extraire jusqu'à 2 x 4 Ko = 8 Ko par unité de capacité de lecture.

Pour les interrogations d'index secondaire global, DynamoDB calcule l'activité de lecture approvisionnée de la même façon que pour les interrogations de tables. La seule différence est que le calcul est basé sur les tailles des entrées d'index, plutôt que sur la taille de l'élément de la table de base. Le nombre d'unités de capacité en lecture est la somme des tailles de tous les attributs projetés de tous les éléments renvoyés. Le résultat est ensuite arrondi à la limite de 4 Ko suivante. Pour plus d'informations sur la façon dont DynamoDB calcule l'utilisation du débit approvisionné, consultez Mode de capacité provisionnée DynamoDB.

La taille maximum des résultats renvoyés par une opération Query est de 1 Mo. Cela inclut les tailles de tous les noms et valeurs d'attribut à travers l'ensemble des éléments retournés.

Par exemple, considérons un index secondaire global où chaque élément contient 2 000 octets de données. Supposons à présent que vous effectuez une opération Query sur cet index et que la KeyConditionExpression de la requête renvoie huit éléments. La taille totale des éléments correspondants est de 2 000 octets x 8 éléments = 16 000 octets. Ce résultat est ensuite arrondi à la limite de 4 Ko la plus proche. Les interrogations d'index secondaire global étant éventuellement cohérentes, le coût total est de 0,5 x (16 Ko / 4 Ko), soit 2 unités de capacité de lecture.

Unités de capacité d'écriture

Lors de l'ajout, de la mise à jour ou de la suppression d'un élément dans une table, si l'opération affecte un index secondaire global, celui-ci consomme les unités de capacité d'écriture approvisionnée à cette fin. Le coût total du débit alloué pour une écriture se compose de la somme des unités de capacité en écriture utilisées par l'écriture sur la table de base et de celles utilisées par la mise à jour des index secondaires globaux. Notez que, si une écriture dans une table ne requiert de mise à jour d'index secondaire global, aucune capacité d'écriture n'est consommée à partir de l'index.

Pour qu'une écriture de table réussisse, les paramètres de débit provisionnés de la table et de tous ses index secondaires globaux doivent avoir une capacité d'écriture suffisante pour accueillir l'écriture. Sinon, l'écriture dans la table est limitée.

Le coût d'écriture d'un élément dans un index secondaire global dépend de plusieurs facteurs :

Tous ces facteurs partent du principe que la taille de chaque élément dans l'index est inférieure ou égale à la taille d'élément de 1 Ko pour le calcul des unités de capacité d'écriture. Les plus grandes entrées d'index nécessitent des unités de capacité en écriture supplémentaires. Vous pouvez réduire vos coûts d'écriture en considérant les attributs que vos requêtes ont besoin de retourner et en projetant uniquement ces attributs dans l'index.

Considérations relatives au stockage pour les index secondaires globaux

Quand une application écrit un élément dans une table, DynamoDB copie automatiquement le sous-ensemble approprié d'attributs vers les index secondaires globaux où ces attributs doivent apparaître. Votre AWS compte est débité pour le stockage de l'article dans la table de base ainsi que pour le stockage des attributs dans les index secondaires globaux de cette table.

La quantité d'espace utilisée par un élément de l'index est la somme des éléments suivants :

Afin d'estimer les exigences de stockage pour un index secondaire global, vous pouvez évaluer la taille moyenne d'un élément de l'index, puis la multiplier par le nombre d'éléments de la table de base ayant les attributs de clé d'index secondaire global.

Si une table contient un élément dans lequel un attribut particulier n'est pas défini, tandis que cet attribut est défini en tant que clé de partition ou de tri d'index, DynamoDB n'écrit aucune donnée pour cet élément dans l'index.