Je veux d'abord donner un petit aperçu de ce que j'essaie de résoudre. Mon service récupère fréquemment des messages de diverses sources telles qu'Instagram, Twitter, etc. et je veux stocker les messages dans un grand fichier JSON sur S3. Le nom de fichier serait quelque chose comme: {slideshowId}_feed.jsonMise à jour fréquente d'un gros fichier JSON sur Amazon S3 et conflit d'écriture potentiel
Mon site Web affichera les articles dans un diaporama, et le diaporama interrogera simplement le fichier S3 toutes les minutes pour obtenir les dernières données. Il peut même interroger un autre fichier tel que {slideshowId}_meta.json qui a horodatage à partir du moment où le fichier volumineux a été modifié afin d'économiser de la bande passante.
La raison pour laquelle je veux conserver les messages dans un seul fichier JSON est principalement d'économiser des coûts. Je pourrais avoir chaque source comme son propre fichier, par ex. {slideshowId}_twitter.json, {slideshowId}_instagram.json, etc., mais le diaporama devrait envoyer une requête GET à chaque source toutes les minutes, augmentant ainsi le coût. Nous parlons de milliers de diaporamas fonctionnant en même temps, donc le coût doit bien évoluer.
Maintenant, revenons à la question. Il peut y avoir plus d'une instance du service en cours d'exécution qui vérifie Instagram et d'autres sources pour de nouveaux messages, en fonction de combien j'ai besoin de redimensionner. Le problème avec cela est le risque d'un service écrasant le fichier S3 alors qu'un autre pourrait déjà écrire sur le fichier S3. Chaque service qui doit enregistrer des publications dans le fichier JSON doit d'abord OBTENIR le fichier, le traiter et vérifier que les nouveaux messages ne sont pas dupliqués dans le fichier JSON, puis stocker les messages nouveaux ou mis à jour.
que je pourrais avoir chaque service écrire les données à une file d'attente comme le simple service de file d'attente (SQS) et avoir un travailleur qui prend soin d'écrire les messages dans le fichier S3? J'ai pensé à utiliser AWS Kinesis, mais il traite seulement les données à partir des sources et les renvoie vers S3. J'ai besoin de traiter ce qui a été écrit dans le grand fichier JSON pour faire de la comptabilité.
j'ai eu une idée d'utiliser DynamoDB pour stocker les messages (essentiellement à faire la tenue de livres), et alors je aurais tout simplement la requête de service toutes les données nécessaires pour un diaporama unique de DynamoDB et le stocker à S3. De cette façon, les services enverraient simplement les messages à DynamoDB.
Il doit y avoir une façon intelligente de résoudre ce problème.
Je ne comprends pas pourquoi vous voulez utiliser s3. Pourquoi copiez-vous un fichier sur s3 et ensuite sur s3 sur votre site Web? Pourquoi ne pas créer dynamiquement le fichier à partir d'une base de données et utiliser la mise en cache locale? Juste semble un design bizarre, je ne vois pas ce que s3 ajoute – Vorsprung
si vous insistez pour avoir un gros fichier structuré sur S3 à tout moment, alors votre meilleur pari pour la mise à jour est d'exiger des instances de votre service pour acquérir une écriture verrouiller avant de mettre à jour le fichier. Si vous êtes ouvert à des suggestions sur l'ensemble de l'architecture, il pourrait y avoir une meilleure conception pour résoudre votre problème. – grepe
@Vorsprung C'est à peu près la stratégie que j'ai aujourd'hui, mais mon problème est que j'ai plus de 50 millions de requêtes par mois piquer mon API pour les données. L'API a un bon mécanisme de cache mais je manque aussi de connexions, donc j'ai besoin d'étendre l'API et d'augmenter le coût de mon infrastructure de façon exponentielle. La méthode S3 mettrait la charge sur Amazon et diminuerait considérablement le coût (0,004 $ pour 10 000 requêtes). Cela supprimerait également la dépendance à mon API. – raRaRa