Bonjour,
Je tombe sur une application qui met à jour un elasticsearch en fonction des changement opéré sur la db opérationnelle qui est mysql. Les objets à mettre a jour sont assez gros, avec autour de 150 attributs.
Il y a un truc qui me parait bizarre et qui est peut-être à améliorer. On utilise une queue dans laquelle on notifie un update, mais l'objet mis a jour est mis sur une db redis au lieu d'être envoyé sur la queue.
Une queue n'est-elle pas habituellement utilisée pour gérer de gros volumes de données?
Je crois qu'il y avait des problèmes de performances. Mais alors ne vaut-il pas mieux donner plus de ressources a la queue pour éviter de rendre l architecture plus compliquée?
# elasticsearch
Posté par _kaos_ . Évalué à 1.
Salut,
Et si ton problème ne venait pas de là ?
Pour le reste, j'ai rien compris de qui faisait quoi au final, mais dans elasticsearch les updates sont à bannir.
source
Matricule 23415
[^] # Re: elasticsearch
Posté par j_m . Évalué à 2.
C'est sur que si on pouvait faire rentrer les objet json aussi vite qu'on les génère à partir de mysql il n'y aurait pas besoin de queue.
Et si mysql répondait assez vite sur des requêtes full texte et geographiques alors on n'aurait pas même besoin de elasticsearch.
On a quelques idées pour limiter les mises à jours elasticsearch en sortant l'un ou l'autre éléments. Mais l'essentiel de nos objets sont irréductiblements gros.
C'est peut-être la voie à suivre, quand même… On perdrait en fonctionnalités.
# Queue
Posté par claudex . Évalué à 3.
Je dirais que la première chose à faire, c'est d'abord de savoir pourquoi l'architecture est telle qu'elle est. Ça peut être pour de bonnes raisons, des raisons historiques (des raisons qui étaient bonnes lors de la mise en place) ou de mauvaises raisons. Si c'est dans les deux derniers cas. Effectivement, ça peut être changé.
Mais je dirais qu'il faudrait d'abord être sûr de pourquoi c'est comme ça (et si on ne retrouve plus les traces, alors, on envisage de changer, au pire, ça permettra de trouver les raisons de pourquoi c'est comme ça).
Pourquoi ne pas utiliser le système de queue de redis directement ?
C'est quoi le système de queuing utilisé ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Queue
Posté par j_m . Évalué à 2.
C'est SQS d'amazon. J'ai appris depuis qu'elle n'acceptait qu'un assez petit payload dans le message, genre 250 kb. Ca pourrait être l'explication.
Visiblement chez amazon, ils considèrent qu'une queue n'est pas faite pour transmettre des gros objets.
[^] # Re: Queue
Posté par claudex . Évalué à 4.
Et donc, pourquoi ne pas utiliser directement le système de queue de redis, vu que redis est déjà utilisé ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Queue
Posté par j_m . Évalué à 2.
Je vais regarder ca. Ca me semble être une bonne piste.
[^] # Re: Queue
Posté par j_m . Évalué à 2. Dernière modification le 16 août 2017 à 21:32.
Finalement je crois que le mieux sera de compresser mes objets pour les faire entrer dans la queue SQS.
Je n'y avais pas pensé. Mais apparement les gens font ça.
[^] # Re: Queue
Posté par claudex . Évalué à 3.
Fait quand même attention à ce qu'ils ne grossissent pas trop avec le temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Bonjour
Posté par Marotte ⛧ . Évalué à 3.
Cette queue appartient à quel logiciel ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.