Description de l'environnement

Nous utilisons DynamoDB et Lambda dans notre code, le Lambda écrit des éléments dans DynamoDB directement (ce qui signifie pas via des déclencheurs ou d'autres actions asynchrones), et peu de temps après, un autre Lambda essaie de lire l'élément (via get pas scan ce qui signifie que c'est le plus rapide).

Notre code utilise Python 3.6 (bien qu'il ne soit pas vraiment pertinent pour la question).

Problème

Il semble que parfois le deuxième Lambda ne trouve pas l'élément, nous savons que l'écriture est réussie et nous pouvons voir les éléments dans la DynamoDB.

Question

La question est de savoir quel est le temps maximum entre un PutItem et garanti GetItem ?

Doit-il être résolu avec une boucle de réessai (de préférence pas) ?

Existe-t-il également une différence entre appeler BatchWriteItem avec un seul item et appeler PutItem?

1
Uriya Harpeness 1 nov. 2020 à 12:21

1 réponse

Meilleure réponse

Basé sur les commentaires.

Le problème semble être lié à la la cohérence de lecture de GetItem. Par défaut, GetItem utilise des lectures cohérentes à terme :

Lorsque vous lisez des données à partir d'une table DynamoDB, la réponse peut ne pas refléter les résultats d'une opération d'écriture récemment terminée.

Pour surmonter la limitation du mode à terme cohérent, des lectures fortement cohérentes peuvent être utilisées :

DynamoDB renvoie une réponse avec les données les plus récentes

Veuillez noter que les lectures fortement cohérentes coûtent deux fois que les lectures finalement cohérentes. Il existe également d'autres limitations aux lectures fortement cohérentes, décrites dans les documents liés.

L'alternative pourrait être l'utilisation de retard exponentiel lorsque en utilisant des lectures cohérentes à terme, jusqu'à ce que GetItem réussisse.

1
Marcin 1 nov. 2020 à 10:22