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.
Compréhension de la limitation d’écriture et de la contre-pression des index secondaires globaux (GSI) dans DynamoDB
La limitation de contre-pression des GSI représente l’un des scénarios de limitation les plus complexes de DynamoDB, car elle crée une relation indirecte entre les opérations d’écriture et la limitation : votre application écrit dans une table de base mais subit une limitation en raison de contraintes de capacité sur un ou plusieurs index.
Compréhension de la limitation de contre-pression des GSI
Quand vous écrivez dans une table DynamoDB, tous les index secondaires globaux (GSI) de cette table sont mis à jour de manière asynchrone, à l’aide d’un modèle de cohérence à terme. Si un des GSI ne dispose pas d’une capacité suffisante pour gérer ces mises à jour, DynamoDB limite les écritures dans la table de base afin de garantir la cohérence des données. C’est ce qu’on appelle la contre-pression de GSI. Pour plus d’informations sur le fonctionnement des GSI, consultez Utilisation d’index secondaires globaux dans DynamoDB.
Contrairement à la limitation directe des tables où la ressource à laquelle on accède est également la ressource à l’origine de la limitation, la contre-pression des GSI crée une dépendance entre la table de base et ses index. Même si la table de base dispose d’une grande capacité, les écritures sont limitées si un des GSI associés ne peut pas gérer le volume de mise à jour. Il est particulièrement important de comprendre cette relation, car les contraintes au niveau de la partition s’appliquent indépendamment à la fois à la table de base et à chacun des GSI, chacun ayant sa propre structure de partition et des limites de débit correspondantes.
Le partitionnement de GSI est basé sur la clé de partition des GSI, qui est souvent différente de la clé de partition de la table de base. Même si l’accès à la table de base est parfaitement réparti entre les partitions, les mises à jour de GSI peuvent tout de même se concentrer sur des partitions spécifiques, créant ainsi des points chauds dans les GSI. Pour connaître les bonnes pratiques générales relatives à la conception des clés de partition pour les tables et les GSI, consultez DynamoDB partition key design.
Par exemple, si la table de base utilise customerId comme clé de partition (répartie uniformément) mais que les GSI utilisent status comme clé de partition (avec des valeurs possibles limitées telles que « actif », « en attente », « fermé »), les mises à jour d’éléments dont les valeurs de statut sont populaires peuvent créer des partitions critiques de GSI, même lorsque l’accès à la table de base est équilibré. Cela crée un scénario particulièrement difficile dans lequel votre application peut subir une limitation en raison de partitions critiques de GSI, même si la table de base et les GSI disposent d’une capacité globale suffisante et que le modèle d’accès à la table de base semble bien distribué.
Même si l’exception de limitation pointe vers les GSI (via ResourceArn), l’opération réelle qui fait l’objet d’une limitation est l’écriture dans la table de base. Cela peut être source de confusion, car votre application écrit dans la table de base mais reçoit une exception concernant les GSI.
Types de limitation de GSI
La limitation de contre-pression des GSI se manifeste par différents types d’exception en fonction de la contrainte de capacité spécifique :
-
Dépassement de la capacité provisionnée de GSI : survient lorsque les GSI ne disposent pas d’unités de capacité d’écriture suffisantes pour gérer les mises à jour à partir des opérations de la table de base. Cela produit une
ProvisionedThroughputExceededExceptionavec la raison IndexWriteProvisionedThroughputExceeded, et leResourceArnindique directement que les GSI spécifiques sont confrontés à des contraintes de capacité. -
Dépassement du débit maximal à la demande de GSI : survient lorsque les opérations d’écriture de GSI dépassent les limites maximales configurées sur les tables à la demande. Cela produit une
ThrottlingExceptionavec la raison IndexWriteMaxOnDemandThroughputExceeded, qui identifie les GSI spécifiques avec des restrictions de débit configurées. -
Dépassement des limites de partition de GSI : se produit lorsque des partitions de GSI individuelles dépassent leurs limites de débit (partitions critiques), même si la capacité de GSI globale semble suffisante. Cela génère une
ThrottlingExceptionavec la raison IndexWriteKeyRangeThroughputExceeded, ce qui indique des problèmes de partition chaudes sur le GSI spécifique identifié dans leResourceArn. Cela est particulièrement important, car la distribution des partitions de GSI peut différer considérablement de la distribution des partitions de la table de base, ce qui crée des points chauds dans les GSI même lorsque l’accès à la table de base est réparti de manière uniforme. -
Dépassement des limites de compte de GSI : se déclenche lorsque les opérations d’écriture dans un GSI spécifique dépassent les limites de débit régionales par table (ou un GSI individuel dans cette table) définies au niveau du compte. DynamoDB renvoie une
ThrottlingExceptionavec la raison IndexWriteAccountLimitExceeded, pointant vers le GSI qui a poussé son utilisation au-delà des limites du compte. Cette limitation se produit indépendamment pour chaque GSI qui dépasse la limite. Pour en savoir plus sur les quotas de service par table, par compte et par région, consultez Quotas dans Amazon DynamoDB.
