S3 Consistance éventuelle: les parties de fichiers sont perdues sur PUT avec écrasement

Question

J'utilise Amazon S3 pour stocker une grande quantité de fichiers texte.
Mon logiciel est en Java et j'utilise le SDK S3 officiel.
En dehors de créer/supprimer/récupérer /, j'ai souvent besoin de ajouter nouveau contenu aux fichiers.

S3 ne supporte pas append, j'ai donc mis en œuvre une opération append que, fondamentalement:
- avec un S3 GET, obtient les métadonnées du fichier de S3
- avec un S3 GET, télécharge le fichier entier dans une copie locale
- effectue l'ajout à la copie locale
- avec un S3 PUT, télécharge le fichier local sur S3 en écrasant l'ancien.

Les ajouts ne sont jamais effectués simultanément.
J'ai testé le logiciel, et jusqu'à présent cela semble fonctionner correctement.

Et voici mon problème: dans les scénarios où les ajouts sont très très fréquents, lorsque j'effectue des ajouts, de grandes parties de mes fichiers sont perdues. Cela pourrait-il dépendre de la cohérence éventuelle de S3 sur les PUT d'écrasement?

Merci pour votre aide!

Answer 1

Oui, c'est possible. La cohérence éventuelle signifie que le prochain GET d'un objet peut ou ne peut pas renvoyer les résultats du dernier PUT lorsqu'un objet a été remplacé.

Activez la gestion des versions de compartiment et vous devriez être capable d'identifier facilement ce qui se passe dans ces événements en capturant et en enregistrant l'ID de version de l'objet chaque fois que vous le téléchargez ou le téléchargez.

Si la dernière version téléchargée n'est pas celle que vous avez téléchargée par la suite, c'est un signe de cohérence éventuelle à l'origine du problème. D'autre part, si vous gérez activement votre téléchargement en demandant spécifiquement la dernière version en utilisant son dernier ID de version connu (que vous devez capturer lorsque vous PUT l'objet, et stockez quelque part qui offre des lectures fortement cohérentes , comme DynamoDB ou RDS), vous pouvez toujours demander explicitement la dernière version lorsque vous le téléchargez.

Des demandes explicites pour une version spécifique d'un objet résolvent le problème car elles n'ont pas de limitations de cohérence - une version spécifiée donnée d'un objet existe ou non. Le problème de cohérence est lié à la récupération implicite de la "dernière" version d'un objet. Si la réplique d'index spécifique qui parvient à traiter votre requête n'a pas encore pris connaissance de la dernière version, elle servira une version antérieure.

Cela est vrai que le contrôle de version soit activé ou non, car l'écrasement d'un objet n'est pas réellement un écrasement, même dans un compartiment non versionné. C'est un index de stockage + mise à jour du nouvel emplacement de stockage interne + purge de l'ancienne opération de stockage. Ceci n'est pas documenté mais les écrasements atomiques et le modèle de cohérence dictent que cela doit nécessairement être le cas.