Consignes générales pour les index secondaires dans DynamoDB

Amazon DynamoDB prend en charge deux types d'index secondaires :

• Index secondaires globaux (GSI) : index dotés d'une clé de partition et d'une clé de tri qui peuvent être différentes de celles de la table de base. Un index secondaire global est considéré comme « global », car les requêtes sur l'index peuvent couvrir toutes les données de la table de base, sur toutes les partitions. Un index secondaire global n'a pas de limitations de taille et possède ses propres paramètres de débit alloué pour les activités de lecture et d'écriture qui sont distincts de ceux de la table.

• Index secondaires locaux : index dotés de la même clé de partition que celle de la table de base, mais d'une clé de tri différente. Un index secondaire est « local » dans la mesure où la portée de chacune de ses partitions correspond à une partition de la table de base ayant la même valeur de clé de partition. Par conséquent, la taille totale des éléments indexés pour chaque valeur de clé de partition ne doit pas dépasser 10 Go. En outre, un index secondaire local partage les paramètres de débit alloué pour les activités de lecture et d'écriture avec la table qu'il indexe.

Chaque table dans DynamoDB peut comporter jusqu'à 20 index secondaires globaux (quota par défaut) et 5 index secondaires locaux.

Les index secondaires globaux sont souvent plus utiles que les index secondaires locaux. La décision de choisir un type d'index plutôt que l'autre peut aussi être dictée par les exigences de votre application. Pour une comparaison entre les index secondaires globaux et les index secondaires locaux, et pour plus d'informations sur la façon de choisir entre les deux, voir. Amélioration de l'accès aux données avec les index secondaires

Voici quelques principes généraux et modèles de conception à garder à l'esprit lorsque vous créez des index dans DynamoDB :

Utiliser les index efficacement

Réduisez au maximum le nombre d'index. Ne créez pas des index secondaires sur des attributs que vous n'interrogez pas souvent. Les index rarement utilisés contribuent à l'augmentation des coûts de stockage et d'E/S sans pourtant améliorer les performances des applications.

Choisir soigneusement les projections

Comme les index secondaires consomment du stockage et du débit alloué, vous devez maintenir la taille de l'index aussi réduite que possible. En outre, plus l'index est petit, meilleures sont les performances par rapport à l'interrogation de la table complète. Si vos requêtes ne renvoient généralement qu'un petit sous-ensemble d'attributs et que la taille totale de ces attributs est beaucoup plus petite que l'élément entier, projetez uniquement les attributs que vous demandez régulièrement.

Si vous prévoyez une importante activité d'écriture sur une table, par rapport aux lectures, respectez les bonnes pratiques suivantes :

• Pensez à projeter moins d'attributs pour réduire la taille des éléments écrits sur l'index. Cependant, ceci s'applique uniquement si la taille des attributs projetés serait sinon supérieure à une unité de d'écriture (1 Ko). Par exemple, si la taille d'une entrée d'index n'est que de 200 octets, DynamoDB l'arrondit à 1 Ko. En d'autres termes, aussi longtemps que les éléments de l'index sont petits, vous pouvez projeter plus d'attributs sans aucun coût supplémentaire.

• Évitez de projeter des attributs lorsque vous savez qu'ils sont rarement nécessaires dans des requêtes. Chaque fois que vous mettez à jour un attribut qui est projeté dans un index, les frais supplémentaires pour la mise à jour de l'index vous seront également facturés. Vous pouvez toujours récupérer les attributs non projetés dans une opération Query à un coût de débit alloué plus élevé, mais les coûts des requêtes peuvent être sensiblement plus bas que les coûts de mise à jour de l'index.

• Spécifiez ALL uniquement si vous voulez que vos requêtes retournent la totalité de l'élément de table trié sur une clé de tri différente. La projection de tous les attributs permet d'éliminer la nécessité des extractions de table, mais, dans la plupart des cas, cela double vos coûts de stockage et d'activité en écriture.

Trouvez un équilibre entre la nécessité de maintenir la taille de l'index aussi réduite que possible et celle de réduire au minimum les extractions, comme expliqué dans la section suivante.

Optimiser les requêtes fréquentes pour éviter les extractions

Pour obtenir les requêtes les plus rapides avec la plus faible latence possible, projetez tous les attributs que ces requêtes sont censées renvoyer. En particulier, si vous interrogez un index secondaire local pour des attributs non projetés, DynamoDB extrait automatiquement ces attributs de la table, ce qui nécessite de lire la totalité de l'élément à partir de la table. Cela donne lieu à une latence et des opérations d'E/S supplémentaires que vous pouvez éviter.

Gardez à l'esprit que les requêtes « occasionnelles » peuvent souvent se transformer en requêtes « essentielles ». S'il existe des attributs que vous ne prévoyez pas de projeter, car vous pensez ne les interroger que rarement, demandez-vous si les circonstances peuvent changer et si vous pourriez regretter ultérieurement de ne pas projeter ces attributs.

Pour plus d'informations sur les extractions de table, consultez Considérations relatives au débit alloué pour les index secondaires locaux.

Prendre en compte les limites de taille de la collection d'éléments lors de la création des index secondaires locaux

Une collection d'éléments regroupe tous les éléments d'une table et ses index secondaires locaux qui ont la même clé de partition. Aucune collection d'éléments ne peut pas dépasser 10 Go. Il se peut donc qu'une valeur de clé de partition particulière manque d'espace.

Lorsque vous ajoutez ou mettez à jour un élément de table, DynamoDB met à jour tous les index secondaires locaux concernés. Si les attributs indexés sont définis dans la table, la taille des index secondaires locaux augmente également.

Lorsque vous créez un index secondaire local, pensez à la quantité de données qui seront écrites dans celui-ci et à la quantité de ces éléments de données qui auront la même valeur de clé de partition. Si vous pensez que la somme des éléments de table et d'index d'une valeur de clé de partition particulière risque de dépasser 10 Go, interrogez-vous sur l'opportunité d'éviter de créer l'index.

Si vous ne pouvez pas éviter la création de l'index secondaire local, vous devez anticiper la taille limite de la collection d'éléments et prendre les mesures nécessaires avant qu'elle ne soit dépassée. Il est recommandé d'utiliser ce ReturnItemCollectionMetricsparamètre lorsque vous rédigez des articles pour surveiller et signaler les tailles de collection d'articles approchant la limite de 10 Go. Le dépassement de la taille maximale de la collection d'articles entraînera l'échec des tentatives d'écriture. Vous pouvez atténuer les problèmes liés à la taille des collections d'articles en surveillant la taille des collections d'articles et en vous alertant à ce sujet avant qu'ils n'affectent votre demande.

Note

Une fois créé, vous ne pouvez pas supprimer un index secondaire local.

Pour les stratégies sur l'utilisation au sein de la limite et la prise des mesures correctives, consultez Taille limite de collection d'éléments.