Pourquoi avons-nous besoin de courtiers comme RabbitMQ sur une firebase database comme PostgreSQL?

Je suis nouveau dans les courtiers de messages comme RabbitMQ, que nous pouvons utiliser pour créer des files d’attente de tâches / messages pour un système de planification comme Celery .

Maintenant, voici la question:

  • Je peux créer une table dans PostgreSQL qui peut être ajoutée à de nouvelles tâches et consommée par le programme consommateur comme Celery.

  • Pourquoi diable voudrais-je installer une toute nouvelle technologie pour cela comme RabbitMQ?

Maintenant, je pense que la mise à l’échelle ne peut pas être la solution puisque notre firebase database comme PostgreSQL peut fonctionner dans un environnement dissortingbué.

J’ai cherché sur Google quels étaient les problèmes posés par la firebase database pour le problème particulier et j’ai trouvé:

  • interrogation en gardant la firebase database occupée et peu performante
  • locking de la table -> encore peu performant
  • des millions de lignes de tâche -> à nouveau, l’interrogation est peu performante

Maintenant, comment RabbitMQ ou tout autre courtier comme celui-ci résout-il ces problèmes?

En outre, j’ai découvert que le protocole AMQP est ce qu’il suit. Qu’est-ce qui est génial dans ça?

Redis peut-il également être utilisé comme courtier de messages? Je trouve cela plus analogue à memcache que RabbitMQ.

S’il vous plaît jeter un peu de lumière là-dessus!

Les files d’attente de Rabbit résident en mémoire et seront donc beaucoup plus rapides que l’implémentation dans une firebase database. Une (bonne) queue de messages dédiée devrait également fournir des fonctionnalités essentielles liées à la mise en queue, telles que la limitation / le contrôle du stream et la possibilité de choisir différents algorithmes de routage, pour ne nommer que ceux-là. En fonction de la taille de votre projet, vous pouvez également souhaiter que le composant de transmission des messages soit distinct de votre firebase database, de sorte que si un composant subit une charge importante, il ne soit pas nécessaire d’empêcher le fonctionnement de l’autre.

En ce qui concerne les problèmes que vous avez mentionnés:

  • interroger la firebase database pour la rendre souple et peu performante : Grâce à Rabbitmq, les producteurs peuvent transmettre des mises à jour aux consommateurs, ce qui est beaucoup plus performant que le sondage. Les données sont simplement envoyées au consommateur quand il le faut, éliminant ainsi le besoin de contrôles inutiles.

  • locking de la table -> encore peu performant: il n’y a pas de table à verrouiller: P

  • des millions de lignes de tâche -> à nouveau, l’interrogation est peu performante: comme mentionné ci-dessus, Rabbitmq fonctionnera plus rapidement car il stocke la RAM et fournit un contrôle de stream. Si nécessaire, il peut également utiliser le disque pour stocker temporairement des messages s’il est à court de RAM. Après 2.0, Rabbit a considérablement amélioré son utilisation de la RAM. Les options de regroupement sont également disponibles.

En ce qui concerne l’AMQP, je dirais qu’une fonctionnalité vraiment intéressante est l’échange, et la possibilité qu’il soit acheminé vers d’autres échanges. Cela vous donne plus de flexibilité et vous permet de créer un large éventail de typologies de routage élaborées qui peuvent s’avérer très utiles lors de la mise à l’échelle. Pour un bon exemple, voir:

http://soffr.miximages.com/postgresql/routing-topology.png

et: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Enfin, en ce qui concerne les redis, oui, il peut être utilisé comme courtier de messages et peut être efficace. Cependant, Rabbitmq a plus de fonctions de mise en queue de messages que redis, car rabbitmq a été conçu dès le départ pour constituer une queue de messages dédiée complète au niveau de l’entreprise. Redis d’autre part a été créé pour être un magasin clé-valeur en mémoire (bien qu’il fasse beaucoup plus que cela maintenant, il est même appelé un couteau suisse). Pourtant, j’ai lu / entendu de nombreuses personnes obtenir de bons résultats avec Redis pour des projets de petite taille, mais je n’en ai pas beaucoup entendu parler dans des applications plus importantes.

Voici un exemple d’utilisation de redis dans une implémentation de chat longue durée: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

PostgreSQL 9.5 intègre SELECT ... FOR UPDATE ... SKIP LOCKED . Cela simplifie et facilite la mise en œuvre de systèmes de queue de travail. Vous n’avez peut-être plus besoin d’un système de queue externe, car il est désormais simple d’extraire les lignes ‘n’ qu’aucune autre session n’a verrouillée et de les garder verrouillées jusqu’à ce que vous validiez le travail. Il fonctionne même avec des transactions en deux phases pour lesquelles une coordination externe est requirejse.

Les systèmes de queue externes restnt utiles, offrant des fonctionnalités prêtes à l’emploi, des performances éprouvées, une intégration avec d’autres systèmes, des options de mise à l’échelle horizontale et de fédération, etc. Néanmoins, vous n’en avez plus vraiment besoin.

Versions plus anciennes

Vous n’avez pas besoin de tels outils, mais en utiliser un peut vous simplifier la vie. Faire la mise en queue dans la firebase database semble facile, mais vous découvrirez en pratique que des files d’attente concurrentes hautes performances et fiables sont vraiment difficiles à faire dans une firebase database relationnelle.

C’est pourquoi des outils tels que PGQ existent.

Vous pouvez vous débarrasser de l’interrogation dans PostgreSQL en utilisant LISTEN et NOTIFY , mais cela ne résoudra pas le problème de la dissortingbution fiable des entrées en haut de la queue à un seul consommateur tout en conservant un fonctionnement hautement simultané et en ne bloquant pas les insertions. Toutes les solutions simples et évidentes qui, à votre avis, vont résoudre ce problème ne le sont pas réellement et ont tendance à dégénérer en versions moins efficaces de la récupération de files d’attente à un seul opérateur.

Si vous n’avez pas besoin de récupération de queue multi-travailleurs très simultanée, l’utilisation d’une table de queue unique dans PostgreSQL est tout à fait raisonnable.