Gestion de paramètres sur des tables à capacité allouée DynamoDB

Lorsque vous créez une table approvisionnée dans Amazon DynamoDB, vous devez spécifier sa capacité de débit approvisionné. Il s'agit du volume d'activité de lecture et d'écriture que la table peut prendre en charge. DynamoDB utilise ces informations pour réserver des ressources système suffisantes pour répondre à vos exigences de débit.

Note

À la place, vous pouvez créer une table en mode à la demande pour ne pas avoir à gérer de paramètres de capacité pour les serveurs, le stockage ou le débit. DynamoDB s'adapte instantanément à vos charges de travail à mesure qu'elles augmentent ou diminuent jusqu'à tout niveau de trafic précédemment atteint. Si le niveau de trafic d'une charge de travail atteint un nouveau pic, DynamoDB s'adapte rapidement afin de prendre en charge cette charge de travail. Pour de plus amples informations, veuillez consulter Mode de capacité à la demande.

Vous pouvez aussi activer la scalabilité automatique de DynamoDB pour gérer la capacité de débit de votre table. Toutefois, vous devez toujours fournir des paramètres initiaux pour la capacité de lecture et de écriture lorsque vous créez la table. La scalabilité automatique de DynamoDB utilise les paramètres initiaux comme point de départ, puis les ajuste de manière dynamique en fonction des exigences de votre application. Pour de plus amples informations, veuillez consulter Gestion automatique de la capacité de débit avec la scalabilité automatique de DynamoDB.

À mesure que les exigences de données et d'accès de votre application changent, vous pouvez avoir besoin d'ajuster les paramètres de débit de votre table. Si vous utilisez la scalabilité automatique de DynamoDB, les paramètres de débit sont automatiquement ajustés en fonction des charges de travail réelles. Vous pouvez aussi utiliser l'opération UpdateTable pour ajuster manuellement la capacité de débit de votre table. Vous pouvez décider de procéder de la sorte si vous devez charger en masse des données à partir d'un magasin de données existant dans votre nouvelle table DynamoDB. Vous pouvez créer la table avec un paramètre de débit en écriture élevé, puis diminuer ce paramètre une fois que le chargement en masse des données est terminé.

Vous spécifiez les exigences de débit en termes d'unités de capacité, c'est-à-dire le volume de données que votre application doit lire ou écrire par seconde. Si nécessaire, vous pouvez modifier ces paramètres ultérieurement, ou activer la scalabilité automatique de DynamoDB.

Unités de capacité de lecture

Une unité de capacité de lecture équivaut à une lecture fortement cohérente par seconde ou deux lectures éventuellement cohérentes par seconde pour un élément d'une taille pouvant atteindre 4 Ko.

Note

Pour en savoir plus sur les modèles de cohérence de lecture dans DynamoDB, consultez Cohérence en lecture.

Par exemple, supposons que vous créez une table avec 10 unités de capacité de lexture approvisionnée. Cela vous permet d'exécuter 10 lectures cohérentes fortes par seconde, ou 20 lectures éventuellement cohérentes par seconde, pour des éléments d'une taille pouvant atteindre 4 Ko.

La lecture d'un élément d'une taille supérieure à 4 Ko consomme davantage d'unités de capacité de lecture. Par exemple, une lecture fortement cohérente d'un élément d'une taille de 8 Ko (4 Ko x 2) consomme 2 unités de capacité de lecture. Une lecture éventuellement cohérente sur ce même élément consomme seulement une unité de capacité de lecture.

Les tailles d'élément pour les lectures sont arrondies au multiple de 4 Ko supérieur. Par exemple, la lecture d'un élément d'une taille de 3 500 octets consomme le même débit que la lecture d'un élément d'une taille de 4 Ko.

Consommation des unités de capacité pour les opérations de lecture

La section suivante décrit comment les opérations de lecture DynamoDB consomment des unités de capacité de lecture :

• GetItem – Lit un élément unique d'une table. Pour déterminer le nombre d'unités de capacité que l'opération GetItem va consommer, arrondissez la taille de l'élément au multiple de 4 Ko supérieur. Si vous avez spécifié une lecture cohérente forte, il s'agit du nombre d'unités de capacité requises. Pour une lecture éventuellement cohérente (valeur par défaut), divisez ce nombre par deux.

  Par exemple, si vous lisez un élément d'une taille de 3,5 Ko, mise à l'échelle arrondit sa taille à 4 Ko. Si vous lisez un élément de 10 Ko, DynamoDB arrondit sa taille à 12 Ko.

• BatchGetItem – Lit jusqu'à 100 éléments à partir d'une ou de plusieurs tables. DynamoDB traitant chaque élément du lot comme une demande GetItem individuelle, DynamoDB arrondit la taille de chaque élément au multiple de 4 Ko supérieur, puis calcule la taille totale. Le résultat n'est pas nécessairement le même que la taille totale de tous les éléments. Par exemple, si BatchGetItem lit un élément de 1,5 Ko et un élément de 6,5 Ko, la taille que DynamoDB calcule est de 12 Ko (4 Ko + 8 Ko), non de 8 Ko (1,5 Ko + 6,5 Ko).

• Query – Lit plusieurs éléments ayant la même valeur de clé de partition. Tous les éléments renvoyés sont traités comme une seule opération de lecture, dans laquelle DynamoDB calcule la taille totale de tous les éléments, puis l'arrondit au multiple de 4 Ko supérieur. Par exemple, supposons que votre requête renvoie 10 éléments dont la taille combinée est de 40,8 Ko. DynamoDB arrondit la taille d'élément pour l'opération à 44 Ko. Si une requête renvoie 1 500 éléments de 64 octets chacun, la taille cumulée est de 96 Ko.

• Scan – Lit tous les éléments d'une table. DynamoDB prend en compte la taille des données évaluées, et non celle des données renvoyées par le scan.

Si vous effectuez une opération de lecture sur un élément qui n'existe pas, DynamoDB continue à consommer un débit de lecture approvisionné. Une demande de lecture fortement cohérente utilise une unité de capacité de lecture, tandis qu'une demande de lecture éventuellement cohérente utilise la moitié d'une unité de capacité de lecture.

Pour toute opération qui renvoie des éléments, vous pouvez demander un sous-ensemble d'attributs à extraire. Cependant, agir ainsi n'a aucun impct sur les calculs de taille d'élément. En outre, Query et Scan peuvent renvoyer des nombres d'éléments au lieu de valeurs d'attribut. L'obtention du nombre d'éléments utilise le même nombre d'unités de capacité de lecture et est soumise aux mêmes calculs de taille des éléments. En effet, DynamoDB doit lire chacun des éléments pour incrémenter le nombre.

Opération de lecture et cohérence en lecture

Les calculs précédents supposent des demandes de lecture fortement cohérentes. Pour une demande de lecture éventuellement cohérente (eventually consistent), l'opération utilise seulement la moitié des unités de capacité. Pour une lecture éventuellement cohérente, si la taille totale des éléments est de 80 ko, l'opération utilise seulement 10 unités de capacité.

Unités de capacité d'écriture

Une unité de capacité d'écriture équivaut à une écriture par seconde pour un élément d'une taille pouvant atteindre 1 Ko.

Par exemple, supposons que vous créez une table avec 10 unités de capacité d'écriture approvisionnée. Cela vous permet d'exécuter 10 écritures par seconde pour des éléments d'une taille pouvant atteindre 1 Ko par seconde.

Les tailles d'élément pour les écritures sont arrondies au multiple de 1 Ko supérieur. Par exemple, l'écriture d'un élément de 500 octets consomme le même débit que l'écriture d'un élément de 1Ko.

Consommation des unités de capacité pour les opérations d'écriture

La section suivante décrit comment les opérations d'écriture DynamoDB consomment des unités de capacité d'écriture :

• PutItem – Ecrit un élément unique dans une table. Si un élément avec la même clé primaire existe dans la table, l'opération remplace l'élément. Pour calculer la consommation de débit approvisionné, la taille d'élément qui compte est la plus grande des deux.

• UpdateItem – Modifie un élément unique dans la table. DynamoDB prend en compte la taille de l'élément tel qu'il apparaît avant et après la mise à jour. Le débit approvisionné consommé reflète la plus grande de ces tailles d'élément. Même si vous mettez à jour simplement un sous-ensemble d'attributs de l'élément, DynamoDB utiliseUpdateItem toujours la totalité du volume de débit approvisionné (la plus importante des tailles d'élément « avant » et « après »).

• DeleteItem – Supprime un élément unique d'une table. La consommation de débit approvisionné est basée sur la taille de l'élément supprimé.

• BatchWriteItem – Ecrit jusqu'à 25 éléments dans une ou plusieurs tables. DynamoDB traite chaque élément du lot comme une demande PutItem ou DeleteItem individuelle (les mises à jour ne sont pas prises en charge). Par conséquent, DynamoDB arrondit la taille de chaque élément à la limite de 1 Ko supérieure, puis calcule la taille totale. Le résultat n'est pas nécessairement le même que la taille totale de tous les éléments. Par exemple, si BatchWriteItem écrit un élément de 500 octets et un élément de 3,5 Ko, la taille que DynamoDB calcule est de 5 Ko (1 Ko + 4 Ko), non de 4 Ko (500 octets + 3,5 Ko).

Pour les opérations PutItem, UpdateItem, et DeleteItem, DynamoDB arrondit la taille de l'élément à la limite de 1 Ko supérieure. Par exemple, si vous insérez ou supprimez un élément de 1,6 Ko, DynamoDB arrondit la taille de l'élément à 2 Ko.

PutItem, UpdateItem et DeleteItem permettent des écritures conditionnelles, dans lesquelles vous spécifiez une expression qui doit évaluer la valeur true pour que l'opération réussisse. Si le résultat de l'expression est false, DynamoDB continue à consommer des unités de capacité d'écriture de la table. La quantité consommée dépend de la taille de l'élément (qu'il s'agisse d'un élément existant dans la table ou d'un nouvel élément que vous essayez de créer ou de mettre à jour). Par exemple, si un élément existant est de 300 Ko et que le nouvel élément que vous essayez de créer ou de mettre à jour est de 310 Ko, les unités de capacité d'écriture consommées sont de 310 Ko.

Limitation des demandes et capacité de débordement

Si votre application effectue des opérations de lecture ou d'écriture à un débit supérieur à ce que votre table peut prendre en charge, DynamoDB commence à limiter ces demandes. Quand DynamoDB limite une opération de lecture ou d'écriture, un code ProvisionedThroughputExceededException est renvoyé à l'appelant. L'application peut alors effectuer les actions appropriées comme, par exemple, attendre un petit moment avant de soumettre à nouveau la demande.

Note

Nous vous recommandons d'utiliser les AWS SDK pour le développement de logiciels. Les kits SDK AWS fournissant une prise en charge intégrée des nouvelles tentatives de demandes limitées, vous n'avez pas besoin d'écrire cette logique vous-même. Pour de plus amples informations, veuillez consulter Nouvelles tentatives après erreur et backoff exponentiel.

La console DynamoDB affiche les métriques CloudWatch Amazon relatives à vos tables, afin que vous puissiez surveiller les demandes de lecture et d'écriture limitées. En cas de limitation excessive, vous devrez envisager d'augmenter les paramètres de débit provisionné pour votre table.

Dans certains cas, DynamoDB consomme la Capacité de débordement pour gérer les lectures ou écritures excédentaires par rapport aux paramètres de débit de votre table. La capacité de transmission en mode rafale permet de satisfaire les demandes inattendues en lecture ou en écriture, alors qu'elles seraient sinon limitées. Pour de plus amples informations, veuillez consulter Utilisation efficace de la capacité de débordement.

Limitation des demandes et capacité adaptative

DynamoDB distribue automatiquement vos données sur des partitions, qui sont stockées sur plusieurs serveurs dans AWS le cloud (pour plus d'informations, voir). Partitions et distribution des données Il n'est pas toujours possible de répartir les activités de lecture et d'écriture uniformément. Lorsque l'accès aux données est déséquilibré, une partition « en surchauffe » peut recevoir un volume de lectures et d'écritures bien supérieur à celui des autres partitions. La capacité adaptative fonctionne en augmentant automatiquement la capacité de débit des partitions qui reçoivent le plus de trafic. Pour de plus amples informations, veuillez consulter Présentation de la capacité adaptative de DynamoDB.

Choix des paramètres de débit initial

Chaque application a des exigences spécifiques pour la lecture et l'écriture dans une base de données. Lorsque vous déterminez les paramètres de débit initial pour une table DynamoDB, prenez les entrées suivantes en considération :

• Tailles des éléments. Certains éléments sont d'une taille suffisamment petite pour être lus ou écrits par une seule unité de capacité. Les éléments plus volumineux exigent plusieurs unités de capacité. En évaluant la taille des éléments qui figureront dans votre table, vous pouvez spécifier les paramètres de débit provisionné qui conviennent pour votre table.

• Débits de demandes de lecture et d'écriture attendus. En plus de la taille des éléments, vous devez estimer le nombre d'opérations de lecture et d'écriture par seconde dont vous aurez besoin.

• Exigences de cohérence en lecture. Les unités de capacité de lecture sont basées sur des opérations de lecture fortement cohérentes et utilisent deux fois plus de ressources de base de données que les lectures éventuellement cohérentes. Vous devez déterminer si votre application requière des lectures cohérentes fortes, ou si elle peut assouplir cette exigence et exécuter des lectures éventuellement cohérentes à la place. (Par défaut, les opérations de lecture dans DynamoDB sont éventuellement cohérentes. Au besoin, vous pouvez demander des lectures cohérentes fortes pour ces opérations.)

Par exemple, supposons que vous vouliez lire 80 éléments d'une table par seconde. Les éléments ont une taille de 3 Ko et vous voulez des lectures cohérentes fortes. Dans ce scénario, chaque lecture nécessite une unité de capacité de lecture approvisionnée. Pour déterminer ce nombre, vous divisez la taille d'élément de l'opération par 4 Ko, puis arrondissez au nombre entier le plus proche, comme dans l'exemple suivant :

• 3 Ko / 4 Ko = 0,75, ou 1 unité de capacité de lecture

Pour ce scénario, vous devez définir le débit de lecture approvisionné de la table sur 80 unités de capacité de lecture :

• 1 unité de capacité de lecture par élément x 80 lectures par seconde = 80 unités de capacité de lecture

Supposons à présent que vous vouliez écrire 100 éléments par seconde sur votre table et que les éléments aient une taille de 512 octets. Dans ce scénario, chaque écriture nécessite une unité de capacité d'écriture approvisionnée. Pour déterminer ce nombre, vous divisez la taille d'élément de l'opération par 1 Ko, puis arrondissez au nombre entier le plus proche :

• 512 octets / 1 Ko = 0,5, ou 1

Dans ce scénario, vous voulez définir le débit d'écriture approvisionné de la table sur 100 unités de capacité d'écriture :

• 1 unité de capacité d'écriture par élément x 100 écritures par seconde = 100 unités de capacité d'écriture

Note

Pour des recommandations sur le débit provisionné et des rubriques connexes, voir Bonnes pratiques de création et d'utilisation de clés de partition de façon performante.

Modification des paramètres de débit

Si vous avez activé la scalabilité automatique de DynamoDB pour une table, sa capacité de débit est ajustée de manière dynamique en fonction de l'utilisation réelle. Aucune intervention manuelle n'est requise.

Vous pouvez modifier les paramètres de débit provisionné de votre table à l'aide de l'opération AWS Management Console ou. UpdateTable Pour plus d'informations sur les augmentations et réductions de débit par jour, consultez Quotas de service, de compte et de table dans Amazon DynamoDB.

Résolution des problèmes de limitation

Pour résoudre les problèmes qui semblent être liés à la limitation, il est tout d'abord important de vérifier si la limitation provient de DynamoDB ou de l'application.

Vous trouverez ci-dessous quelques scénarios courants et les étapes possibles pour les résoudre.

La table DynamoDB semble disposer d'une capacité allouée suffisante, mais les demandes sont limitées.

Cela peut se produire lorsque le débit est inférieur à la moyenne par minute, mais qu'il dépasse la quantité disponible par seconde. DynamoDB communique uniquement les métriques CloudWatch au niveau des minutes, qui sont ensuite calculées sous la forme de la somme d'une minute et moyennées. Mais DynamoDB applique lui-même des limites de débit par seconde. Par conséquent, si une trop grande partie de ce débit se produit dans une petite partie de cette minute, par exemple quelques secondes ou moins, les demandes pour le reste de cette minute peuvent être limitées. Par exemple, si nous avons alloué 60 WCU sur une table, celle-ci peut effectuer 3 600 écritures en 1 minute. Mais si les 3 600 demandes WCU sont reçues dans la même seconde, le reste de la minute sera limité.

L'un des moyens de résoudre ce scénario peut être d'ajouter des instabilités et un retour en arrière exponentiel aux appels d'API. Pour plus d'informations, consultez le billet de blog sur le retour en arrière exponentiel et l'instabilité.

La mise à l'échelle automatique est activée, mais les tables sont toujours limitées.

Cela peut se produire lors de pics soudains de trafic. Le dimensionnement automatique peut être déclenché lorsque deux points de données dépassent la valeur d'utilisation cible configurée en une minute. Par conséquent, une mise à l'échelle automatique peut avoir lieu car la capacité consommée est supérieure à l'utilisation cible pendant deux minutes régulières. Mais si les pointes sont espacées de plus d'une minute, il est possible que le dimensionnement automatique ne soit pas déclenché. De même, un événement de réduction peut être déclenché lorsque 15 points de données consécutifs sont en dessous de l'utilisation cible. Dans les deux cas, après le déclenchement de l'autoscaling, un UpdateTableappel est invoqué. La mise à jour de la capacité allouée pour la table ou l'index peut ensuite prendre plusieurs minutes. Pendant cette période, toutes les demandes dépassant la capacité précédemment allouée aux tables seront limitées.

En résumé, la mise à l'échelle automatique nécessite des points de données consécutifs où la valeur d'utilisation cible est dépassée pour augmenter la taille d'une table DynamoDB. Pour cette raison, la mise à l'échelle automatique n'est pas recommandée comme étant une solution pour gérer des pics de charge de travail. Pour plus de détails, consultez la documentation sur la mise à l'échelle automatique.

Les tables ont un mode de capacité « à la demande », mais sont toujours limitées.

Pour les tables à la demande, DynamoDB alloue automatiquement davantage de capacité à mesure que votre volume de trafic augmente. Tant que l'accès est réparti uniformément entre les partitions et que la table ne dépasse pas le double de son pic de trafic précédent, l'ensemble de la table ne sera pas limitée. Cette limitation peut cependant se produire si le débit dépasse le double du pic précédent dans les même 30 minutes. Reportez-vous à la section OnDemand Mise à l'échelle pour plus d'informations.

Un raccourci clavier peut être à l'origine de problèmes de limitation.

Dans DynamoDB, une clé de partition dont la cardinalité n'est pas élevée peut donner lieu à de nombreuses demandes qui ne ciblent que quelques partitions. Le fait qu'une « partition critique » dépasse les limites par partition de 3 000 RCU ou de 1 000 WCU par seconde peut entraîner une limitation. L'outil de diagnostic CloudWatch Contributor Insights peut aider à résoudre ce problème en fournissant des graphiques CCI pour les modèles d'accès aux éléments de chaque table. Vous pouvez surveiller en permanence les clés d'accès les plus fréquemment utilisées dans vos tables DynamoDB et les autres tendances du trafic. Pour en savoir plus sur CloudWatch Contributor Insights, consultez CCI. Pour obtenir des informations spécifiques sur le choix du raccourci clavier approprié, consultez Choix du raccourci clavier approprié.

Utilisation de CloudWatch métriques pour étudier la régulation

Vous trouverez ci-dessous quelques métriques DynamoDB à surveiller lors d'événements de limitation, afin de vous aider à identifier les opérations qui génèrent des demandes limitées et à identifier les problèmes racines.

1. ThrottledRequests

• Une demande limitée peut contenir plusieurs événements limités. Ainsi, les événements peuvent être plus pertinents à examiner.

  Par exemple, la mise à jour d'un élément d'une table ayant des index secondaires globaux génère plusieurs événements : une écriture dans la table et une écriture dans chaque index. Même si un ou plusieurs de ces événements sont limités, il n'y en aura qu'un. ThrottledRequest

2. ReadThrottleEvents

• Surveillez les demandes dépassant le RCU alloué pour une table ou un index secondaire global.

3. WriteThrottleEvents

• Surveillez les demandes qui dépassent le nombre de WCU allouées pour une table ou un index secondaire global.

4. OnlineIndexConsumedWriteCapacity

• Faites attention au nombre de WCU consommées lors de l'ajout d'un nouvel index secondaire global à une table. Notez que ConsumedWriteCapacityUnits pour un index secondaire global n'inclut pas le nombre de WCU consommées lors de la création de l'index.

• Si vous avez choisi un nombre de WCU trop faible pour un index secondaire global, l'activité d'écriture entrante pendant la phase de remplissage peut être limitée.

5. OnlineIndexThrottleEvents

• Vérifiez le nombre d'événements de limitation d'écriture qui se produisent lors de l'ajout d'un nouvel index secondaire global à une table.

• Si vous trouvez que le nombre de WCU est trop faible qu'il est limité, vous pouvez mettre à jour le nombre de WCU d'un index secondaire global même pendant le remplissage.

6. Provisioned Read/Write

• Affichez le nombre d'unités de capacité de lecture ou d'écriture allouées qui ont été consommées durant la période spécifiée, pour une table ou un index secondaire global spécifié.

• Notez que la dimension TableName renvoie ProvisionedReadCapacityUnits pour la table uniquement par défaut. Pour afficher le nombre d'unités de capacité de lecture ou d'écriture allouées pour un index secondaire global, vous devez spécifier TableName et GlobalSecondaryIndexName.

7. Consumed Read/Write

• Affichez le nombre d'unités de capacité de lecture ou d'écriture qui ont été consommées durant la période spécifiée.

Pour plus d'informations sur les métriques CloudWatch DynamoDB, consultez la section Mesures et dimensions.