Index secondaires globaux et index secondaires locaux

La clé primaire de DynamoDB définit l’unique chemin de requête efficace d’une table. Si vous devez interroger les éléments à l’aide d’un autre attribut — par exemple, trouver toutes les commandes d’un identifiant de produit alors que la clé de partition de la table est CustomerId — vous devriez effectuer un Scan coûteux sans index secondaire.

Les index secondaires résolvent ce problème en conservant une copie distincte des données, automatiquement mise à jour et structurée autour d’une autre clé. DynamoDB propose deux types d’index : les Global Secondary Indexes (GSI) et les Local Secondary Indexes (LSI), qui présentent chacun des compromis différents.

Un Global Secondary Index vous permet de définir une clé de partition complètement différente de celle de la table de base, ainsi qu’éventuellement une clé de tri différente. Le GSI est véritablement global : il couvre toutes les partitions de la table de base. Vous pouvez interroger un GSI pour trouver des éléments à l’aide de n’importe quel attribut défini comme clé de partition du GSI.

Les GSI disposent de leur propre débit provisionné (ou héritent du mode à la demande), indépendamment de la table de base. Vous pouvez créer jusqu’à 20 GSI par table et ajouter ou supprimer des GSI à tout moment sur une table existante.

Un Local Secondary Index partage la même clé de partition que la table de base, mais utilise une clé de tri différente. Les LSI sont dits « locaux » car ils interrogent uniquement une seule partition, c’est-à-dire les éléments ayant la même clé de partition. Cela fait des LSI une solution idéale pour interroger les commandes d’un client donné, triées selon différents attributs.

Les LSI doivent être définis lors de la création de la table : vous ne pouvez pas les ajouter ni les supprimer ultérieurement. Chaque table peut comporter jusqu’à 5 LSI. Les LSI partagent la capacité provisionnée de la table de base (sans débit distinct) et sont soumis à la limite de stockage de 10 Go par clé de partition pour l’ensemble constitué des données de la table de base et des LSI.

Voici une comparaison côte à côte pour faciliter la préparation à l’examen :

• Clé de partition : la GSI peut être différente de celle de la table de base ; la LSI doit être identique à celle de la table de base
• Clé de tri : les deux prennent en charge une clé de tri différente de celle de la table de base
• Moment de création : la GSI peut être créée à tout moment ; la LSI uniquement lors de la création de la table
• Débit : la GSI dispose de son propre débit ; la LSI partage celui de la table de base
• Cohérence : les lectures d’une GSI sont uniquement à cohérence éventuelle ; les lectures d’une LSI peuvent être fortement cohérentes
• Limites : jusqu’à 20 GSI ; jusqu’à 5 LSI par table

Lors de la création d’un index, vous choisissez les attributs qui sont projetés (copiés) dans celui-ci :

• KEYS_ONLY : uniquement la clé primaire de la table de base et la clé de l’index — index le plus petit, nécessitant des appels supplémentaires à GetItem pour les attributs qui ne sont pas des clés
• INCLUDE : les attributs de clé ainsi qu’une liste précise d’attributs supplémentaires que vous indiquez — compromis entre la taille et le mode d’accès
• ALL : tous les attributs sont projetés dans l’index — solution la plus flexible, avec des coûts de stockage et d’écriture plus élevés

Choisissez le type de projection en fonction des attributs réellement nécessaires à vos requêtes. Une projection excessive gaspille des unités de capacité d’écriture à chaque écriture ; une projection insuffisante impose des appels supplémentaires à GetItem pour récupérer les attributs absents de l’index.

L’interrogation d’une GSI utilise la même API Query, mais précise le paramètre --index-name. La requête s’exécute sur le schéma de clés de la GSI, et non sur celui de la table de base. Les requêtes sur une GSI sont toujours à cohérence éventuelle : la GSI est mise à jour de manière asynchrone après les écritures dans la table de base, ce qui entraîne un bref délai.

Si un élément de la table de base ne possède pas l’attribut correspondant à la clé de partition de la GSI, il n’est pas inclus dans la GSI (modèle d’index clairsemé). Il s’agit d’une technique puissante pour indexer uniquement un sous-ensemble d’éléments, par exemple toutes les commandes dont le statut est PENDING si la clé de partition de la GSI est Status.

Un index clairsemé exploite le fait que DynamoDB ne projette des éléments dans une GSI que s’ils possèdent une valeur pour la clé de partition de la GSI. En définissant la clé de partition de la GSI sur un attribut présent uniquement sur certains éléments, vous créez un index limité à ce sous-ensemble.

Exemple : dans une table Orders, seules les commandes non expédiées possèdent un attribut PendingShipmentDate. Une GSI sur PendingShipmentDate contient donc naturellement uniquement les commandes non expédiées, ce qui en fait un moyen très efficace d’interroger toutes les commandes en attente sans analyser la table entière.

La surcharge de GSI est une technique avancée de conception avec table unique, dans laquelle vous stockez différents types d’entités dans une même table et utilisez un attribut de clé GSI générique (par exemple GSI1PK et GSI1SK), renseigné selon différents modèles en fonction du type d’élément. Chaque type d’entité dispose ainsi de son propre chemin d’interrogation efficace au moyen d’une seule GSI.

Exemple : pour les éléments User, définissez GSI1PK = 'COUNTRY#US' et GSI1SK = username ; pour les éléments Order, définissez GSI1PK = 'STATUS#PENDING' et GSI1SK = orderDate. L’interrogation de la GSI avec le préfixe approprié récupère efficacement le type d’entité ciblé.

La limitation du débit d’une GSI se produit indépendamment de celle de la table de base. Si les unités de capacité d’écriture provisionnées pour la GSI sont trop faibles, les écritures concernant des éléments projetés dans la GSI seront limitées, même si la table de base dispose d’une capacité largement suffisante. Surveillez séparément ConsumedWriteCapacityUnits et ThrottledRequests pour chaque GSI.

Une erreur courante consiste à provisionner la GSI avec une capacité inférieure à celle de la table de base, puis à subir une limitation lorsque le rythme d’écriture de la GSI augmente soudainement. Utilisez la mise à l’échelle automatique sur les GSI ou choisissez le mode à la demande pour éviter ce problème.

Principes de décision pour l’examen SAA-C03 :

• Vous devez interroger les données selon un attribut complètement différent → GSI
• Vous devez interroger les données au sein de la même partition, mais selon un ordre différent, et vous le savez au moment de la création → LSI
• Vous avez besoin de lectures fortement cohérentes sur une autre clé de tri → LSI (seule option, puisque les GSI offrent une cohérence éventuelle)
• Vous avez dix modèles d’interrogation distincts ou plus → envisagez une conception avec table unique et surcharge de GSI plutôt que de nombreuses tables séparées
• Vous devez seulement récupérer tous les éléments à des fins d’analyse → réévaluez la pertinence de DynamoDB comme base de données

Vous pouvez supprimer une GSI à tout moment sans affecter la table de base. Lorsque vous ajoutez une nouvelle GSI à une table existante, DynamoDB remplit initialement l’index de manière asynchrone en analysant la table de base ; cette opération peut prendre de quelques minutes à plusieurs heures pour les grandes tables. Pendant ce remplissage initial, la table de base reste entièrement disponible pour les lectures et les écritures.

Vous pouvez surveiller la progression du remplissage initial dans la console ou via l’API DescribeTable, en vérifiant le champ IndexStatus de l’index : sa valeur est CREATING pendant le remplissage initial et ACTIVE une fois celui-ci terminé. N’interrogez pas la GSI tant qu’elle n’est pas ACTIVE.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les GSI fournissent d’autres clés de partition et peuvent être ajoutées à tout moment, que les LSI partagent la clé de partition de base et doivent être définies lors de la création, et que les types de projection déterminent les attributs copiés dans l’index. Les GSI prennent en charge les modèles d’index clairsemé et de surcharge, qui offrent une grande flexibilité pour les interrogations avancées. Nous allons maintenant découvrir DynamoDB Streams et les Global Tables.