Comprendre la régulation d'écriture et la contre-pression de l'index secondaire global (GSI) dans DynamoDB

La régulation par contre-pression GSI représente l'un des scénarios de régulation les plus complexes de DynamoDB car elle crée une relation indirecte entre les opérations d'écriture et la régulation : votre application écrit dans une table de base mais subit une régulation en raison de contraintes de capacité sur un ou plusieurs index.

Comprendre la régulation de la contre-pression GSI

Lorsque vous écrivez dans une table DynamoDB, tous les index secondaires globaux GSIs () de cette table sont mis à jour de manière asynchrone à l'aide d'un modèle finalement cohérent. Si un 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 GSI. Pour plus d'informations sur le GSIs fonctionnement, voir Index secondaires globaux dans DynamoDB.

Contrairement à la régulation directe des tables où la ressource à laquelle on accède est également la ressource à l'origine de la régulation, la contre-pression GSI crée une dépendance entre la table de base et ses index. Même si votre table de base dispose d'une capacité suffisante, les écritures seront limitées si un GSI associé 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 à chaque GSI, chacune ayant sa propre structure de partition et les limites de débit correspondantes.

Le partitionnement GSI est basé sur la clé de partition du GSI, qui est souvent différente de la clé de partition de la table de base. Même si l'accès à votre table de base est parfaitement réparti entre les partitions, vos mises à jour du GSI peuvent tout de même se concentrer sur des partitions spécifiques, créant ainsi des points chauds dans le GSI. Pour connaître les meilleures pratiques générales relatives à la conception des clés de partition pour les deux tables GSIs, voir Conception des clés de partition DynamoDB.

Par exemple, si votre table de base est utilisée customerId comme clé de partition (répartie uniformément) mais que votre GSI l'utilise 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 d'état sont populaires peuvent créer des partitions GSI actives, 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 être ralentie en raison de partitions dynamiques GSI, même si la table de base et le 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 le GSI (viaResourceArn), l'opération réelle de régulation 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 le GSI.

Types de régulation GSI

La régulation de la contre-pression GSI se manifeste par différents types d'exceptions en fonction de la contrainte de capacité spécifique :

• Dépassement de la capacité allouée par le GSI : survient lorsque le GSI ne dispose 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 ProvisionedThroughputExceededException raison IndexWriteProvisionedThroughputExceeded, et cela ResourceArn indique directement que le GSI spécifique est confronté à des contraintes de capacité.

• Dépassement du débit maximal GSI à la demande : survient lorsque les opérations d'écriture GSI dépassent les limites maximales configurées sur les tables à la demande. Cela produit une raison IndexWriteMaxOnDemandThroughputExceeded, ThrottlingException à savoir identifier le GSI spécifique avec des restrictions de débit configurées.

• Limites de partition GSI dépassées : cela se produit lorsque des partitions GSI individuelles dépassent leurs limites de débit (partitions chaudes), même si la capacité GSI globale semble suffisante. Cela génère un ThrottlingException motif IndexWriteKeyRangeThroughputExceeded, indiquant les problèmes de partition chauds sur le GSI spécifique identifié dans leResourceArn. Cela est particulièrement important car la distribution des partitions GSI peut différer considérablement de la distribution des partitions de la table de base, ce qui crée des points chauds dans le GSI même lorsque l'accès à la table de base est réparti de manière uniforme.

• Limites du compte GSI dépassées : déclencheurs lorsque les opérations d'écriture dans un GSI spécifique dépassent les limites de débit régionales par table (ou tout GSI individuel dans ce tableau) définies au niveau du compte. DynamoDB renvoie ThrottlingException un avec la IndexWriteAccountLimitExceededraison, pointant vers le GSI qui a poussé son utilisation au-delà des limites du compte. Cette régulation se produit indépendamment pour chaque GSI qui dépasse la limite. Pour plus d'informations sur les quotas de service par table, par compte, par région, voir. Quotas dans Amazon DynamoDB