Comment le débit d'Amazon DynamoDB est-il calculé et limité?
Est-ce en moyenne par seconde? Par minute? Par heure?
Par exemple .. si je paie pour 10 "unités de lecture" qui permettent 10 lectures hautement cohérentes par seconde, serai-je limité si j'essaye de faire 20 lectures en une seule seconde, même si c'était les 20 seules lectures qui se sont produites dans la dernière heure? La documentation d'Amazon et FAQ ne répondent à cette question critique nulle part que je pourrais trouver.
La seule réponse connexe que j'ai pu trouver dans le FAQ ignore complètement le problème du calcul de l'utilisation et du moment où la limitation peut se produire:
Q: Que se passe-t-il si mon application effectue plus de lectures ou d'écritures que ma capacité provisionnée?
A: Si votre application effectue plus de lectures/seconde ou d'écritures/seconde que la capacité de débit allouée de votre table ne le permet, les demandes au-dessus de votre capacité provisionnée seront limitées et vous recevrez 400 codes d'erreur. Par exemple, si vous avez demandé 1000 unités de capacité d'écriture et essayez de faire 1500 écritures/seconde d'éléments de 1 Ko, DynamoDB n'autorisera que 1000 écritures/seconde et vous recevrez le code d'erreur 400 sur vos demandes supplémentaires. Vous devez utiliser CloudWatch pour surveiller votre taux de requêtes afin de vous assurer que vous disposez toujours d'un débit provisionné suffisant pour atteindre le taux de requêtes dont vous avez besoin.
Le DynamoDB fournit une "capacité de rafale" qui permet des pics de quantité de données lues à partir de la table. Vous pouvez en savoir plus à ce sujet sous: http://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Bursting
En gros, c'est ce que @abjennings a remarqué - Il utilise une fenêtre de 5 minutes pour calculer la moyenne du nombre de lectures d'une table.
Il semble qu'ils suivent les écritures dans une fenêtre de cinq minutes et vous ralentissent lorsque votre moyenne des cinq dernières minutes dépasse votre débit provisionné.
J'ai fait quelques tests. J'ai créé une table de test avec un débit de 1 écriture/seconde. Si je n'y écris pas pendant un certain temps, puis que j'envoie un flux de demandes, Amazon semble en accepter environ 300 avant de commencer à ralentir.
La mise en garde, bien sûr, est que cela n'est indiqué dans aucune documentation officielle d'Amazon et pourrait changer à tout moment.
Si je paie pour 10 "unités de lecture", ce qui permet 10 lectures hautement cohérentes par seconde, serai-je limité si j'essaie de faire 20 lectures en une seule seconde, même si ce sont les 20 seules lectures qui se sont produites au cours de la dernière heure?
Oui, cela est dû au concept même de Amazon DynamoDB étant des performances rapides et prévisibles avec une évolutivité transparente - le FAQ est en fait déjà correctement (c'est-à-dire que vous devez prendre les opérations/seconde littéralement), bien que le calcul soit mieux illustré dans Provisioned Throughput in Amazon DynamoDB en effet:
Une unité de capacité d'écriture vous permet d'effectuer une écriture par seconde pour des éléments d'une taille allant jusqu'à 1 Ko . De même, une unité de capacité de lecture vous permet d'effectuer une lecture fortement cohérente par seconde (ou deux lectures éventuellement cohérentes par seconde) d'articles d'une taille allant jusqu'à 1 Ko. Les articles plus volumineux nécessiteront plus de capacité. Vous pouvez calculer le nombre d'unités de capacité de lecture et d'écriture dont vous avez besoin en estimant le nombre de lectures ou d'écritures que vous devez effectuer par seconde et en multipliant par la taille de vos éléments (arrondi au Ko le plus proche).
Unités de capacité requises pour les écritures = Nombre d'écritures d'article par seconde x taille de l'article (arrondi au Ko le plus proche)
Unités de capacité requises pour les lectures * = Nombre de lectures d'éléments par seconde x taille de l'élément (arrondi au Ko le plus proche) * Si vous utilisez des lectures finalement cohérentes, vous obtiendrez deux fois le débit en termes de lectures par seconde.
[c'est moi qui souligne]
Obtenir ces calculs pour des cas d'utilisation réels est cependant potentiellement complexe, assurez-vous de vérifier plus de détails, comme par exemple. les Directives de débit provisionné dans Amazon DynamoDB également en conséquence.
De AWS :
DynamoDB conserve actuellement jusqu'à cinq minutes (300 secondes) de capacité de lecture et d'écriture inutilisée
DynamoDB offre une certaine flexibilité dans le provisionnement du débit par partition. Lorsque vous n'utilisez pas pleinement le débit d'une partition, DynamoDB conserve une partie de votre capacité inutilisée pour des pics d'utilisation ultérieurs du débit. DynamoDB conserve actuellement jusqu'à cinq minutes (300 secondes) de capacité de lecture et d'écriture inutilisée. Lors d'une rafale occasionnelle d'activité de lecture ou d'écriture, ces unités de capacité supplémentaire peuvent être consommées très rapidement, voire plus rapidement que la capacité de débit provisionnée par seconde que vous avez définie pour votre table. Cependant, ne concevez pas votre application de façon à ce qu'elle dépende de la disponibilité permanente de la capacité de rafale: DynamoDB peut utiliser et utilise la capacité de rafale pour la maintenance en arrière-plan et d'autres tâches sans préavis.
Je suppose qu'ils ne le disent pas explicitement exprès. Il est probablement susceptible de changer/d'avoir des différences régionales/de dépendre de la position de la lune et des étoiles, ou la divulgation d'informations encouragerait les abus. Je ferais mes calculs sur la base du pire scénario.
Nous définissons notre 'write-limit' à 10 units/sec pour l'une des tables. Le graphique Cloudwatch ( voir image ) montre que nous l'avons dépassé d'une unité (11 writes/sec). Je suppose qu'il y a une petite marge de manœuvre (<= 10%). Encore une fois, je suppose juste ...