Pourquoi mon analyse DynamoDB est-elle si rapide avec une seule unité de capacité de lecture provisionnée ?
J'ai créé un tableau avec 1346 éléments, chaque élément ayant une taille inférieure à 4 Ko. J'ai provisionné 1 unité de capacité de lecture, donc je m'attends à ce qu'en moyenne 1 élément soit lu par seconde. Cependant, une simple analyse des 1346 éléments revient presque immédiatement.
Qu'est-ce que j'oublie ici?
Réponses
Cela est probablement dû à la capacité de rafale dans laquelle vous gagnez votre capacité sur une période de 300 secondes à utiliser pour des actions extensibles (telles que l'analyse d'une table entière).
Cela signifierait que si vous utilisiez tous ces crédits, d'autres interactions en souffriraient car elles n'auraient pas suffisamment de capacité à leur disposition.
Vous pouvez voir la quantité de WCU/RCU consommée via les métriques CloudWatch ou dans l'interface DynamoDB elle-même (via l'onglet Métriques).
Vous ne donnez pas de taille pour vos entrées sauf pour dire "chaque élément étant inférieur à 4 Ko". Combien moins ?
1 RCU prendra en charge 2 lectures cohérentes à terme par seconde d'éléments jusqu'à 4 Ko.
Autrement dit, avec 1 RCU et éventuellement des lectures cohérentes, vous pouvez lire 8 Ko de données par seconde.
Si vos enregistrements font 4 Ko, vous obtenez 2 enregistrements/sec
1 Ko, 8/sec
512B, 16/sec
256B, 32/sec
Ainsi, la capacité "rafale" déjà mentionnée vous a permis d'utiliser 55 RCU. Mais la petite taille de vos enregistrements a permis à cette 55 RCU de renvoyer les données "presque immédiatement"
Il y a deux choses qui jouent en votre faveur ici - la première est qu'une Scanopération nécessite beaucoup moins de RCU que vous ne le pensiez pour les petits objets. L'autre chose est la "capacité de rafale". Je vais essayer d'expliquer les deux :
La page de tarification DynamoDB indique que "Pour les éléments d'une taille maximale de 4 Ko, un RCU peut effectuer deux demandes de lecture cohérentes à terme par seconde.". Cela suggère que même si l'élément a une taille de 10 octets, il en coûte la moitié d'une RCU pour le lire avec une éventuelle cohérence. Cependant, bien qu'ils ne l'indiquent nulle part, ce coût n'est vrai queGetItem pour une opération de récupération d'un seul élément. Dans un Scanou Query, il s'avère que vous ne payez pas séparément pour chaque article individuel. Au lieu de cela, ces opérations analysent les données stockées sur le disque de manière séquentielle et vous payez pour la quantité de données ainsi lues. Si vous avez 1 000 petits éléments et que la taille totale que DynamoDB devait lire à partir du disque était de 80 Ko, vous paierez 80 Ko/4 Ko/2, ou 10 RCU, et non 500 RCU.
Cela explique pourquoi vous avez lu 1346 éléments et mesuré seulement 55 RCU, et non 1346/2 = 673.
La deuxième chose qui joue en votre faveur est que DynamoDB a la capacité de "capacité en rafale", décrite ici :
DynamoDB conserve actuellement jusqu'à 5 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émentaires peuvent être consommées rapidement, même plus rapidement que la capacité de débit provisionné par seconde que vous avez définie pour votre table.
Ainsi, si votre base de données existait depuis 5 minutes avant votre demande, DynamoDB a enregistré pour vous 300 RCU, que vous pouvez utiliser très rapidement. Étant donné que 300 RCU représentent bien plus que ce dont vous aviez besoin pour votre analyse (55), votre analyse s'est déroulée très rapidement, sans limitation.
Lorsque vous effectuez une requête, le décompte RCU s'applique à la quantité de données lues sans tenir compte du nombre d'éléments lus. Donc, si vos éléments sont petits, disons quelques octets chacun, ils peuvent facilement être interrogés à l'intérieur d'un seul RCU de 4 Ko.
Ceci est particulièrement utile lors de la lecture de nombreux éléments à partir de DynamoDB également. Il n'est pas immédiatement évident que l'interrogation de nombreux petits éléments est beaucoup moins chère et plus efficace que BatchGetting.