1- Débit de la plage clé dépassé (partitions chaudes) - Amazon DynamoDB
Le débit de la gamme clé a dépassé les mesures d'atténuationDiagnostic et surveillance communsProcé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ébit de la plage clé dépassé (partitions chaudes)

Amazon DynamoDB applique des limites de débit spécifiques au niveau de la partition pour la table et pour l'index secondaire global (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 régulation tandis que les autres opérations peuvent rester sous-utilisées, ce qui crée des « partitions chaudes ». La régulation 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. Ce ralentissement peut se produire même lorsque votre table ou votre GSI dispose d'une capacité globale suffisante. Pour en savoir plus sur :

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

Le débit de la gamme clé a dépassé les mesures d'atténuation

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é le nom de ressource Amazon (ARN) de la ressource affectée. Pour plus d'informations sur la recherche des raisons de la limitation et l'identification des ressources limitées, voir. Cadre de diagnostic de la limitation DynamoDB

Avant de vous lancer dans des scénarios de régulation spécifiques, vérifiez d'abord 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 régulation qui s'arrêtent après un court laps de temps, votre table s'est peut-être déjà adaptée en divisant la partition chaude. Lorsque les partitions se divisent, chaque nouvelle partition gère une plus petite partie de l'espace-clavier, 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 le ralentissement persiste, reportez-vous aux scénarios de régulation 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 se produit 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 Diagnostic et surveillance communs pour analyser votre événement de régulation.

Options de remédiation

Envisagez les étapes suivantes pour faire face à vos problèmes d'étranglement :

Pour les modes provisionné et à la demande :

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

  • Identifiez vos touches de raccourci : si le tableau ne s'est pas résolu automatiquement et que votre débit de démarrage est élevé ou si l'augmentation de ce débit n'a pas aidé, vous devez identifier des touches de raccourci spécifiques. Identifier les touches de raccourci à l'aide de CloudWatch Contributor InsightsÀ utiliser pour déterminer si certaines valeurs de clé de partition sont chaudes. Il s'agit d'une première étape pour cibler efficacement vos 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 chaudes au fil du temps) ou lorsque la régulation est déclenchée par des opérations telles que des scans. Pour ces scénarios complexes, vous devrez peut-être analyser les modèles d'accès de votre application et les corréler avec le calendrier des événements de limitation.

  • 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 meilleures pratiques relatives à la mise en œuvre à terme de lectures cohérentes afin de réduire la consommation de capacité de lecture, voirCohérence de lecture DynamoDB.

  • Améliorez la conception des clés de partition : comme solution à long terme, envisagez Améliorer la conception des clés de partition de répartir l'accès de manière plus uniforme entre les partitions. Cette approche fournit souvent la solution la plus complète aux problèmes de partition chauds en s'attaquant à la cause première. 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 se produit 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 Diagnostic et surveillance communs pour analyser votre événement de régulation.

Options de remédiation

Envisagez les étapes suivantes pour faire face à vos problèmes d'étranglement :

Pour les modes provisionné et à la demande :

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

  • Identifiez vos touches de raccourci : si le tableau ne s'est pas résolu automatiquement et que votre débit de démarrage est élevé ou si l'augmentation de ce débit n'a pas aidé, vous devez identifier des touches de raccourci spécifiques. Identifier les touches de raccourci à l'aide de CloudWatch Contributor InsightsÀ utiliser pour déterminer si certaines valeurs de clé de partition sont chaudes. Il s'agit d'une première étape pour cibler efficacement vos 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 régulation, cela indique un raccourci clavier concentré.

    • Si vous ne voyez pas de touches 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 le scan qui suivent l'ordre des touches), vous avez probablement des partitions dynamiques où les différentes touches deviennent chaudes au fil du temps lorsque vos écritures se déplacent dans l'espace-clavier.

    Notez que la limitation de l'écriture peut également se produire avec des opérations telles que BatchWriteItem des transactions qui affectent plusieurs éléments simultanément. Lorsque des éléments individuels d'une BatchWriteItem demande sont limités, DynamoDB ne propage pas ces erreurs de régulation dans le code de l'application. DynamoDB renvoie plutôt des informations sur les éléments non traités de la réponse, que votre application doit gérer en réessayant ces éléments spécifiques. Pour les transactions, l'ensemble de l'opération échoue et un élément est soumis à un TransactionCanceledException ralentissement si un élément est soumis à un ralentissement. 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 corréler avec le calendrier des événements de limitation et mettre en œuvre des stratégies de gestion des nouvelles tentatives appropriées.

  • Améliorez la conception des clés de partition : comme solution à long terme, envisagez Améliorer la conception des clés de partition de répartir l'accès de manière plus uniforme entre les partitions. Cette approche fournit souvent la solution la plus complète aux problèmes de partition chauds en s'attaquant à la cause première. 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 DynamoDB GSI dépasse la limite de débit de lecture de la partition. Cette limitation se produit 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 Diagnostic et surveillance communs pour analyser votre événement de régulation.

Options de remédiation

Envisagez les étapes suivantes pour faire face à vos problèmes d'étranglement :

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

  • Identifiez vos touches de raccourci : si le GSI ne l'a pas résolu automatiquement et que votre débit de démarrage est élevé ou si l'augmentation de ce débit n'a pas aidé, vous devez identifier des touches de raccourci spécifiques. Identifier les touches de raccourci à l'aide de CloudWatch Contributor InsightsÀ utiliser pour déterminer si certaines valeurs de clé de partition sont chaudes. Il s'agit d'une première étape pour cibler efficacement vos 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.

  • Reconception des clés de partition GSI : déterminez si la conception de votre clé GSI ne crée pas de points chauds 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 aux éléments de la table de base Utilisation du partitionnement d'écriture pour répartir les charges de travail de manière uniforme dans votre table DynamoDB des techniques qui affectent la distribution GSI afin de répartir les écritures sur 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 évite 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 DynamoDB GSI dépasse la limite de débit d'écriture de la partition. Cette limitation se produit 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 Diagnostic et surveillance communs pour analyser votre événement de régulation.

Options de remédiation

Envisagez les étapes suivantes pour faire face à vos problèmes d'étranglement :

  • Reconception de la clé de partition GSI : passez en revue la conception de votre clé de partition GSI pour vérifier qu'elle possède une cardinalité suffisante (unicité) pour répartir les écritures de manière uniforme. L'une des causes fréquentes de la limitation de l'écriture GSI est l'utilisation d'attributs à faible cardinalité comme clés de partition 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 toujours rencontrer des partitions chaudes si sa clé de partition concentre les écritures sur un petit nombre de valeurs. Par exemple, si 80 % de vos articles ont le statut « actif », cela crée une partition active importante 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 aux éléments de la table de base Utilisation du partitionnement d'écriture pour répartir les charges de travail de manière uniforme dans votre table DynamoDB des techniques qui affectent la distribution GSI afin de répartir les écritures sur 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 évite 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 Comprendre le débit chaud de DynamoDB capacité. Utilisez un débit optimal ou augmentez la capacité de lecture allouée à l'avance pour faire face aux augmentations de trafic attendues. L'augmentation du débit à chaud améliore la capacité de votre GSI à gérer les pics de trafic soudains avant que la régulation ne se produise. Au fil du temps, si votre débit réel se rapproche régulièrement des niveaux de débit habituels, DynamoDB peut diviser les partitions occupées en fonction des modèles d'utilisation observés.

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

Diagnostic et surveillance communs

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 indicateurs clés pour diagnostiquer la régulation 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 à l'origine de la régulation.

  1. Activez CloudWatch Contributor Insights sur votre table ou GSI pour suivre les touches les plus limitées. Pensez à activer en permanence CloudWatch Contributor Insights 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 régulation se produit. Cette surveillance ciblée est un moyen rentable de maintenir une visibilité continue sur les problèmes de régulation.

  2. Identifiez les clés à l'origine des problèmes de partition chauds.

  3. (Si le mode touches accessibles et limitées est activé dans son intégralité) Analysez les modèles d'accès au fil du temps pour déterminer si les touches de raccourci sont cohérentes ou apparaissent pendant des périodes spécifiques.

Améliorer 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. Dans la mesure du possible, il s'agit de la solution à long terme la plus efficace pour les problèmes de partition chauds. Idéalement, la conception de la clé de partition doit être soigneusement étudiée lors de la phase initiale de conception de la table.

La refonte des clés de partition représente une modification 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 à cette approche, considérez attentivement ces limites importantes :

  • Complexité de la migration des données : la refonte 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 d'application : tout le code d'application qui lit ou écrit dans la table doit être mis à jour pour utiliser la nouvelle structure de clé.

  • Impact sur la production : la migration vers une nouvelle conception de clé nécessite souvent des temps d'arrêt 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, voir Bonnes pratiques pour concevoir et utiliser efficacement des clés de partition dans DynamoDB etConception de clés de partition pour répartir votre charge de travail dans DynamoDB.

Optimisation des projections 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 de débit d'écriture lors des 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 réduit la consommation de 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 la section Meilleures pratiques d'utilisation des index secondaires dans DynamoDB.

Ressources supplémentaires

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