«Il n'y a pas de question idiote, seulement une réponse idiote»
Réponse courte : Passe à PostgreSQL en plus du broker
Réponse longue : Pour commencer, les broker de messages ne sont pas fait pour traiter des messages de grosse taille. Par exemple par défaut Kafka est configuré pour des messages de 1Mo maximum. En clair ils transportent des lettres, pas des colis. Pour contourner cette problématique tu peux juste avoir un pointeur vers un stockage de masse.
Ensuite le broker n'est pas là pour stoker les messages, seulement les faire transiter. Il peux les stoker temporairement sur disque au cas ou ton système crash et que tu veuilles absolument ne pas perdre aucun message. Il faut le voir comme un postier, il fait le lien entre l'expéditeur et le destinataire, ni plus ni moins.
Les broker sont adapté pour des système «réactif», donc qui vont réagir à des évènements que l'on va leur transmettre, donc très unidirectionnel. L'expéditeur du message n'attend pas de réponse, si ce n'est celle du broker qui lui dit qu'il a bien pris en charge le message, pas plus.
Donc pour «lire» des données ce n'est pas terrible. Au mieux tu vas emmètre un message pour qu'un autre système émettent un autre messages qui contiendra les données (ou un pointeur) vers ce que tu souhaites. Du point de vu du broker, il n'a fait que transiter des messages. Mais je ne te conseillerais pas ce genre de fonctionnement. Si tu as des données a lire autant aller les chercher directement à la sources.
De ce que je comprend ton modèle travail sur des données collecté sur un temps certain, pas en «live». Donc pour ton archi je verrais bien quelque chose comme ça :
stations météo => broker de messages => BDD => modèle manteau neigeux
=> panneau d'affichage temps réel
=> ce que tu veux d'autre...
Bien sûr tu peux avoir plein de sources de données différentes qui pointent toutes vers le broker.
Bon c'est une analyse sur 2 lignes d'explications ;-)
[^] # Re: Broker de messages
Posté par Mimoza . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 4.
«Il n'y a pas de question idiote, seulement une réponse idiote»
Réponse courte : Passe à PostgreSQL en plus du broker
Réponse longue : Pour commencer, les broker de messages ne sont pas fait pour traiter des messages de grosse taille. Par exemple par défaut Kafka est configuré pour des messages de 1Mo maximum. En clair ils transportent des lettres, pas des colis. Pour contourner cette problématique tu peux juste avoir un pointeur vers un stockage de masse.
Ensuite le broker n'est pas là pour stoker les messages, seulement les faire transiter. Il peux les stoker temporairement sur disque au cas ou ton système crash et que tu veuilles absolument ne pas perdre aucun message. Il faut le voir comme un postier, il fait le lien entre l'expéditeur et le destinataire, ni plus ni moins.
Les broker sont adapté pour des système «réactif», donc qui vont réagir à des évènements que l'on va leur transmettre, donc très unidirectionnel. L'expéditeur du message n'attend pas de réponse, si ce n'est celle du broker qui lui dit qu'il a bien pris en charge le message, pas plus.
Donc pour «lire» des données ce n'est pas terrible. Au mieux tu vas emmètre un message pour qu'un autre système émettent un autre messages qui contiendra les données (ou un pointeur) vers ce que tu souhaites. Du point de vu du broker, il n'a fait que transiter des messages. Mais je ne te conseillerais pas ce genre de fonctionnement. Si tu as des données a lire autant aller les chercher directement à la sources.
De ce que je comprend ton modèle travail sur des données collecté sur un temps certain, pas en «live». Donc pour ton archi je verrais bien quelque chose comme ça :
Bien sûr tu peux avoir plein de sources de données différentes qui pointent toutes vers le broker.
Bon c'est une analyse sur 2 lignes d'explications ;-)