1- Dépassement du débit de la plage de clés (partitions critiques) - Amazon DynamoDB
Mesures d’atténuation du dépassement du débit de la plage de clésTechniques courantes de diagnostic et de surveillanceProcédures de résolutionRessources supplémentaires

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.

1- Dépassement du débit de la plage de clés (partitions critiques)

Amazon DynamoDB impose des limites de débit spécifiques au niveau de la partition pour les tables et les index secondaires globaux (GSI). Chaque partition possède un nombre maximum d'unités de capacité de lecture (RCUs) et d'unités de capacité d'écriture (WCUs) par seconde. Lorsque les partitions reçoivent un trafic concentré qui dépasse ces limites, elles sont soumises à une limitation tandis que les autres opérations peuvent rester sous-utilisées, ce qui crée des « partitions critiques ». La limitation au niveau des partitions de DynamoDB fonctionne indépendamment pour les lectures et les écritures : une partition peut limiter les lectures alors que les écritures se poursuivent normalement, ou vice versa. Cette limitation peut se produire même lorsque votre table ou votre GSI dispose d’une capacité globale suffisante. Ressources supplémentaires :

Lorsque des partitions individuelles dépassent leurs limites de débit, DynamoDB renvoie le type de raison de limitation KeyRangeThroughputExceeded dans l’exception correspondante. Les informations indiquent qu’une partition connaît un trafic élevé et précisent quel type d’opération (lecture ou écriture) est à l’origine du problème.

Mesures d’atténuation du dépassement du débit de la plage de clés

Cette section fournit des conseils de résolution pour les scénarios de limitation au niveau des partitions. Avant d’utiliser ce guide, assurez-vous d’avoir identifié les raisons spécifiques de la limitation liées à la gestion des exceptions par votre application et d’avoir déterminé l’Amazon Resource Name (ARN) de la ressource concernée. Pour en savoir plus sur la façon de déterminer les raisons de la limitation et d’identifier des ressources limitées, consultez Cadre de diagnostic des limitations DynamoDB.

Avant de vous lancer dans des scénarios de limitation spécifiques, vérifiez si le problème se résout automatiquement :

  • DynamoDB s'adapte souvent aux partitions chaudes grâce à son mécanisme automatique. split-for-heat Si vous constatez des événements de limitation qui s’arrêtent après un court laps de temps, votre table s’est peut-être déjà adaptée en fragmentant la partition critique. Lorsque les partitions sont fragmentées, chaque nouvelle partition gère une plus petite partie de l’espace de clés, ce qui permet de répartir la charge de manière plus uniforme. Dans de nombreux cas, aucune autre action n’est nécessaire, car DynamoDB a automatiquement résolu le problème.

    Pour plus d'informations sur le split-for-heatmécanisme, consultezRessources supplémentaires.

Si la limitation persiste, reportez-vous aux scénarios spécifiques ci-dessous pour connaître les options de correction ciblées :

TableReadKeyRangeThroughputExceeded

Quand cela se produit

Le taux de consommation d’une ou de plusieurs partitions de votre table DynamoDB dépasse la limite de débit de lecture de la partition. Cette limitation a lieu quelle que soit la capacité totale allouée de votre table et affecte à la fois les tables provisionnées et à la demande. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Options de correction

Envisagez les étapes suivantes pour gérer les problèmes de limitation :

Pour le mode provisionné et le mode à la demande :

  • Capacité de préchauffage : si la limitation persiste, vérifiez si votre table est limitée par sa capacité Présentation du débit chaud DynamoDB. Utilisez un débit à chaud ou augmentez la capacité de lecture provisionnée à l’avance pour faire face aux augmentations de trafic attendues. L’augmentation du débit à chaud améliore la capacité de la table à gérer les pics de trafic soudains avant que la limitation ne se produise. Au fil du temps, si le débit réel se rapproche régulièrement des niveaux de débit critiques, DynamoDB peut diviser les partitions occupées en fonction des modèles d’utilisation observés.

  • Identifiez les clés critiques : si la table ne l’a pas résolu automatiquement et que le débit à chaud est élevé ou si l’augmentation du débit n’a pas aidé, vous devez identifier les clés critiques spécifiques. Utilisez Identifier les touches de raccourci à l'aide de CloudWatch Contributor Insights pour déterminer si certaines valeurs de clé de partition sont critiques. Il s’agit de la première étape à suivre pour cibler efficacement les efforts d’atténuation. Notez que l’identification n’est pas toujours simple, en particulier dans le cas de partitions dynamiques (où différentes partitions deviennent critiques au fil du temps) ou lorsque la limitation est déclenchée par des opérations telles que des analyses. Pour ces scénarios complexes, vous devrez peut-être analyser les modèles d’accès de votre application et les mettre en corrélation avec le moment où les événements de limitation ont eu lieu.

  • En fonction de votre cas d'utilisation, envisagez d'utiliser des lectures à terme cohérentes : passez d'une lecture très cohérente à une lecture finalement cohérente, qui consomme la moitié de votre capacité de lecture effective RCUs et peut immédiatement doubler votre capacité de lecture effective. Pour connaître les bonnes pratiques relatives à la mise en œuvre de la lecture cohérente à terme afin de réduire la consommation de la capacité de lecture, consultez Cohérence en lecture DynamoDB.

  • Améliorez la conception des clés de partition : comme solution à long terme, envisagez Amélioration de la conception des clés de partition pour répartir l’accès de manière plus uniforme entre les partitions. Cette approche apporte souvent la solution la plus complète aux problèmes de partition critique en s’attaquant à la cause racine. Cependant, elle nécessite une planification minutieuse, car elle implique d’importants défis en matière de migration.

TableWriteKeyRangeThroughputExceeded

Quand cela se produit

Le taux de consommation d’une ou de plusieurs partitions de votre table DynamoDB dépasse la limite de débit d’écriture de la partition. Cette limitation a lieu quelle que soit la capacité totale allouée de votre table et affecte à la fois les tables provisionnées et à la demande. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Options de correction

Envisagez les étapes suivantes pour gérer les problèmes de limitation :

Pour le mode provisionné et le mode à la demande :

  • Capacité de préchauffage : si la limitation persiste, vérifiez si votre table est limitée par sa capacité Présentation du débit chaud DynamoDB. Utilisez un débit à chaud ou augmentez la capacité d’écriture provisionnée à l’avance pour faire face aux augmentations de trafic attendues. L’augmentation du débit à chaud améliore la capacité de la table à gérer les pics de trafic soudains avant que la limitation ne se produise. Au fil du temps, si le débit réel se rapproche régulièrement des niveaux de débit critiques, DynamoDB peut diviser les partitions occupées en fonction des modèles d’utilisation observés.

  • Identifiez les clés critiques : si la table ne l’a pas résolu automatiquement et que le débit à chaud est élevé ou si l’augmentation du débit n’a pas aidé, vous devez identifier les clés critiques spécifiques. Utilisez Identifier les touches de raccourci à l'aide de CloudWatch Contributor Insights pour déterminer si certaines valeurs de clé de partition sont critiques. Il s’agit de la première étape à suivre pour cibler efficacement les efforts d’atténuation. Tenez compte de ces modèles courants :

    • Si la même clé de partition apparaît fréquemment dans vos données de limitation, cela indique une clé critique concentrée.

    • Si vous ne voyez pas de clés répétées mais que vous écrivez des données de manière ordonnée (par exemple, des horodatages séquentiels ou des opérations basées sur une analyse, qui suivent l’ordre de l’espace de clés), vous avez probablement des partitions critiques dynamiques où les différentes clés deviendront critiques au fil du temps lorsque vos écritures passeront par l’espace de clés.

    Notez que la limitation de l’écriture peut également se produire avec des opérations telles que BatchWriteItem ou avec des transactions qui affectent plusieurs éléments simultanément. Lorsque des éléments individuels d’une demande BatchWriteItem sont limités, DynamoDB ne propage pas ces erreurs de limitation dans le code de l’application. DynamoDB renvoie plutôt des informations sur les éléments non traités dans la réponse. Votre application devra les gérer en réessayant de traiter ces éléments spécifiques. Pour les transactions, l’ensemble de l’opération échoue avec une exception TransactionCanceledException si un élément quelconque est limité. Pour ces scénarios complexes, vous devrez peut-être analyser les modèles d’écriture et les flux de travail d’ingestion de données de votre application, les mettre en corrélation avec le moment où les événements de limitation ont lieu et mettre en œuvre des stratégies appropriées de gestion des nouvelles tentatives.

  • Améliorez la conception des clés de partition : comme solution à long terme, envisagez Amélioration de la conception des clés de partition pour répartir l’accès de manière plus uniforme entre les partitions. Cette approche apporte souvent la solution la plus complète aux problèmes de partition critique en s’attaquant à la cause racine. Cependant, elle nécessite une planification minutieuse, car elle implique d’importants défis en matière de migration.

IndexReadKeyRangeThroughputExceeded

Quand cela se produit

Le taux de consommation d’une ou de plusieurs partitions de votre GSI DynamoDB dépasse la limite de débit de lecture de la partition. Cette limitation a lieu quelle que soit la capacité totale allouée de votre GSI et affecte à la fois les tables provisionnées et à la demande. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Options de correction

Envisagez les étapes suivantes pour gérer les problèmes de limitation :

  • Capacité de préchauffage : si la limitation persiste, vérifiez si votre GSI est limité par sa capacité Présentation du débit chaud DynamoDB. Utilisez un débit à chaud ou augmentez la capacité de lecture provisionnée à l’avance pour faire face aux augmentations de trafic attendues. L’augmentation du débit à chaud améliore la capacité du GSI à gérer les pics de trafic soudains avant que la limitation ne se produise. Au fil du temps, si le débit réel se rapproche régulièrement des niveaux de débit critiques, DynamoDB peut diviser les partitions occupées en fonction des modèles d’utilisation observés.

  • Identifiez les clés critiques : si le GSI ne l’a pas résolu automatiquement et que le débit à chaud est élevé ou si l’augmentation du débit n’a pas aidé, vous devez identifier les clés critiques spécifiques. Utilisez Identifier les touches de raccourci à l'aide de CloudWatch Contributor Insights pour déterminer si certaines valeurs de clé de partition sont critiques. Il s’agit de la première étape à suivre pour cibler efficacement les efforts d’atténuation. Notez que pour GSIs, la distribution des clés de partition peut différer considérablement de celle de votre table de base, ce qui crée différents modèles de touches de raccourci.

  • Modifiez la conception des clés de partition GSI : déterminez si la conception des clés de votre GSI ne crée pas de points critiques artificiels (tels que des indicateurs d’état, des clés de date uniquement ou des attributs booléens) qui concentrent les lectures sur un petit nombre de partitions. Envisagez d’utiliser des clés composites qui combinent l’attribut de faible cardinalité avec un attribut de cardinalité élevée (par exemple, ACTIVE#customer123 au lieu de simplement ACTIVE) ou d’appliquer des techniques Utilisation du partitionnement d’écriture pour une répartition équitable des charges de travail dans votre table DynamoDB aux éléments de la table de base qui affectent la distribution des GSI afin de répartir les écritures entre plusieurs partitions. Bien que l’interrogation de données fragmentées nécessite une logique d’application supplémentaire pour agréger les résultats, cette approche empêche la limitation en répartissant les modèles d’accès de manière plus uniforme.

IndexWriteKeyRangeThroughputExceeded

Quand cela se produit

Le taux de consommation d’une ou de plusieurs partitions de votre GSI DynamoDB dépasse la limite de débit d’écriture de la partition. Cette limitation a lieu quelle que soit la capacité totale allouée de votre GSI et affecte à la fois les tables provisionnées et à la demande. Vous pouvez surveiller les CloudWatch métriques Techniques courantes de diagnostic et de surveillance pour analyser votre événement de régulation.

Options de correction

Envisagez les étapes suivantes pour gérer les problèmes de limitation :

  • Modifiez les clé de partition des GSI : passez en revue la conception des clés de partition de votre GSI pour vérifier qu’elle a une cardinalité (unicité) suffisante pour répartir les écritures de manière uniforme. L’une des causes fréquentes de la limitation de l’écriture dans un GSI est l’utilisation d’attributs à faible cardinalité comme clés de partition du GSI (tels que des indicateurs d’état avec seulement quelques valeurs possibles). Même lorsque votre table de base possède des clés de partition bien distribuées, votre GSI peut rencontrer des partitions critiques si sa clé de partition concentre les écritures sur un petit nombre de valeurs. Par exemple, si 80 % de vos éléments ont le statut actif, cela crée une partition critique sévère dans un GSI basé sur le statut. Envisagez d’utiliser des clés composites qui combinent l’attribut de faible cardinalité avec un attribut de cardinalité élevée (par exemple, ACTIVE#customer123 au lieu de simplement ACTIVE) ou d’appliquer des techniques Utilisation du partitionnement d’écriture pour une répartition équitable des charges de travail dans votre table DynamoDB aux éléments de la table de base qui affectent la distribution des GSI afin de répartir les écritures entre plusieurs partitions. Bien que l’interrogation de données fragmentées nécessite une logique d’application supplémentaire pour agréger les résultats, cette approche empêche la limitation en répartissant les modèles d’accès de manière plus uniforme.

  • Capacité de préchauffage : vérifiez si votre GSI est limité par sa capacité Présentation du débit chaud DynamoDB. Utilisez un débit à chaud ou augmentez la capacité de lecture provisionnée à l’avance pour faire face aux augmentations de trafic attendues. L’augmentation du débit à chaud améliore la capacité du GSI à gérer les pics de trafic soudains avant que la limitation ne se produise. Au fil du temps, si le débit réel se rapproche régulièrement des niveaux de débit critiques, DynamoDB peut diviser les partitions occupées en fonction des modèles d’utilisation observés.

  • Optimisez les projections GSI : appliquez Optimisation des projections des GSI des techniques pour réduire le volume d'écriture à GSIs. La projection d’un nombre réduit d’attributs peut limiter considérablement la capacité d’écriture consommée par chaque mise à jour du GSI.

Techniques courantes de diagnostic et de surveillance

Lors du dépannage de la régulation au niveau des partitions, plusieurs CloudWatch indicateurs peuvent aider à identifier les partitions chaudes et à en confirmer la cause première.

CloudWatch Indicateurs essentiels

Surveillez ces métriques clés pour diagnostiquer la limitation au niveau des partitions :

Procédures de résolution

Identifier les touches de raccourci à l'aide de CloudWatch Contributor Insights

Utilisez cette procédure pour identifier les clés de partition qui sont à l’origine de la limitation.

  1. Activez CloudWatch Contributor Insights sur votre table ou GSI pour suivre les touches les plus limitées. Envisagez de CloudWatch laisser Contributor Insights activé en permanence pour les alertes de régulation en temps réel en utilisant le mode touches limitées. Ce mode se concentre exclusivement sur les demandes limitées en traitant uniquement les événements lorsque la limitation se produit. Cette surveillance ciblée est un moyen rentable d’avoir une visibilité continue sur les problèmes de limitation.

  2. Identifiez les clés qui sont à l’origine des problèmes de partition critique.

  3. (Si le mode clés consultées et limitées est activé) Analysez les modèles d’accès au fil du temps pour déterminer si les clés critiques sont constantes ou apparaissent pendant des périodes spécifiques.

Amélioration de la conception des clés de partition

Utilisez cette approche lorsque vous pouvez modifier le schéma de votre table afin de mieux répartir le trafic entre les partitions. Lorsque cela est possible, il s’agit de la solution à long terme la plus efficace pour les problèmes de partition critique. Idéalement, la conception des clés de partition doit être examinée de près lors de la phase initiale de conception de la table.

La modification de la conception des clés de partition représente une altération fondamentale de votre modèle de données, qui a un impact sur l’ensemble de votre écosystème d’applications. Avant de procéder avec cette approche, prenez connaissance de ces limites majeures :

  • Complexité de la migration des données : la modification de la conception des clés de partition nécessite la migration de toutes les données existantes, ce qui peut s’avérer fastidieux en termes de ressources et de temps pour les grandes tables.

  • Modifications du code de l’application : tout le code de l’application qui lit ou écrit dans la table doit être mis à jour afin de pouvoir utiliser la nouvelle structure de clés.

  • Impact sur la production : la migration vers une nouvelle conception de clés implique souvent une durée d’indisponibilité ou des stratégies complexes de double écriture pendant la transition.

Pour obtenir des conseils et des principes complets sur la conception des clés de partition, consultez Bonnes pratiques pour la conception et l’utilisation performantes de clés de partition dans DynamoDB et Conception des clés de partition de manière à répartir votre charge de travail dans DynamoDB.

Optimisation des projections des GSI

Passez en revue les modèles de requête de votre application pour déterminer exactement quels attributs doivent être disponibles lorsque vous interrogez le GSI, et limitez vos projections à ces seuls attributs. Lorsque vous mettez à jour des attributs qui ne sont pas projetés dans un GSI, aucune opération d’écriture n’est effectuée sur ce GSI, ce qui réduit la consommation du débit d’écriture pendant les mises à jour. Cette stratégie de projection ciblée optimise à la fois les performances et les coûts tout en répondant aux exigences de votre application en matière de requêtes. Notez que la projection d’un nombre réduit d’attributs limite la consommation de la capacité d’écriture, mais peut nécessiter des lectures supplémentaires de la table de base.

Pour plus d’informations sur les stratégies de projection efficaces, consultez Best Practices for Using Secondary Indexes in DynamoDB.

Ressources supplémentaires

Les articles de blog suivants fournissent des exemples concrets et des détails pratiques sur les concepts abordés dans ce guide :