Quel est l’avantage d’utiliser le céleri avec Rabbitmq sur Redis, MongoDB ou Django ORM)

Question

Y a-t-il un avantage de vitesse, avantage de fonctionnalités ?

Aussi, à l’aide de Django ORM (mysql), il est beaucoup plus lent que l’utilisation de rabbitmq, mongodb ou redis ?

Im actuellement hébergement sur webfaction et l’installation d’erland et le lapin est aussi bien compliquée et de commentaires, j’ai lu prend un peu de ram, donc juste la course céleri avec base de données serait une option plus intelligente ? Pourquoi ou pourquoi pas ?

Answer 1

Tout dépend de ce que vous voulez l'utiliser pour.

RabbitMQ est la solution recommandée, il est largement déployé, testé et prend en charge toutes les fonctionnalités. Avec une configuration optimisée, vous pouvez traiter jusqu'à 15000 persistante des tâches/s avec un seul processus. RabbitMQ est également livré avec la gestion et le suivi des solutions (divulgation complète: je travaille avec le RabbitMQ équipe de VMware, et je suis le Céleri chef de projet).

Redis est également une option populaire, il prend en charge presque toutes les fonctionnalités, mais il n'est pas très durable dans sa configuration par défaut, si le Redis serveur est terminée brusquement, vous pouvez, au pire, de perdre des minutes de données (http://redis.io/topics/persistence). Même avec append-only mode il y a un risque de perte de données si le celeryd instance est brutalement tué: c'est parce que le Redis ne supporte pas de message de remerciements. Nous travaillons sur un correctif à imiter, mais qui auront un impact sur les performances de beaucoup (dans le temps moyen que vous devez définir CELERYD_PREFETCH_MULTIPLIER=1 afin de minimiser l'impact d'un tel scénario de perte de données).

Les pilotes de base de données ont été faites à l'origine pour des fins de test uniquement, mais ils sont utilisés dans la production de néanmoins. Les pilotes de base de données ne prend pas en charge les événements et de diffusion, de sorte que le Céleri surveiller et de commandes de contrôle à distance (celeryctl) ne fonctionnera pas. Il peut fonctionner assez bien pour les petits déploiements, mais si jamais vous avez besoin d'ajouter plus de celeryd cas, vous devez en choisir une autre option. Malheureusement, les bases de données ne sont généralement pas adapté pour ce genre de travail (même si postgres 9 est livré avec de nouvelles fonctionnalités qui le rend "plus adapté", que l'on peut éventuellement prendre en charge).

MongoDB je n'ai pas eu beaucoup d'expérience avec moi, mais je sais que le Céleri backend est utilisé et est activement maintenu (il vient de récemment pris en charge la surveillance et le contrôle à distance de soutien). Je l'imaginer, cependant, qu'il a les mêmes problèmes de la longévité comme mentionné ci-dessus avec le Redis.

En outre, il ya un soutien pour l'utilisation d'Amazon SQS, Beanstalk, CouchDB. Ces backends ne prennent pas en charge le suivi et commandes de contrôle à distance.

En bref; Si ne pas perdre de tâches est essentiel, vous devriez être à l'aide de RabbitMQ. La principale base de données est OK avec le bas de la tâche de volumes et d'un ou peut-être deux celeryd instances.

Answer 2

Cela dépend si vous voulez vous compliquer la pile et de l'ampleur des tâches.

Le céleri a été initialement construit avec RabbitMQ de soutien et plus tard ajouté le support pour le Redis, CouchDB, MongoDB et base de données SQL backends. RabbitMQ est extrêmement efficace, mais peut-être plus que vous avez besoin et que @jpic mentionne redis est facile à installer et rapide.

Donc le choix se résume à la préférence - ce que vous êtes satisfait de la gestion / configuration / gestion? J'ai choisi mongoDB que mon courtier dans mon dernier endroit que j'étais déjà en utilisant mongoDB - de sorte qu'il est simple à configurer. Si nous n'étions pas à l'utiliser alors que j'aurais choisi un autre courtier qui était simple et facile à installer et à gérer.

La bonne nouvelle est que si vous choisissez l'orm de la base de données et de trouver qu'il n'est pas à l'échelle, puis changer de courtier est trivial et avec un peu de coût de migration, vous pouvez passer à quelque chose de plus performant.

Answer 3

J'utilise Redis pour ces raisons:

1. Facile à installer, permet d'installer à partir de votre distribution linux package manager et windows compatible pour le développement

2. Léger, il ne prend que de 0,50 MO une fois installé, selon mon gestionnaire de paquets (contre 70 mo pour MongoDB !)

3. Ultra-rapide, parce que ses données à vie dans la mémoire (mieux que la base de données/ORM de django), il prend des instantanés de la persistance

Aussi, vous pouvez utiliser votre Redis base de données pour d'autres choses

Answer 4

RabbitMQ est extrêmement efficace, largement déployé et testé message broker, mais peut frapper les performances, si à l'écoute pour plus de durabilité et de la fiabilité. C'est plus ciblée vers le service de messagerie d'entreprise avec le routage avancé exigences.

Redis est rapide, léger et rapide courtier mais ne prend Pas en charge la fiabilité de la livraison, par conséquent, peut être choisi pour des applications où l' dans le cas où le système se termine, la perte de l'information sur les tâches pour une quelques minutes n'est Pas critique.

L'utilisation de Redis, si: Vous êtes à la recherche de lumière et rapidement déployable solution. Fiable la livraison d'un message n'est Pas la priorité pour vous.

Utiliser RabbitMQ, si: Perdre les informations au sujet de la tâche est très critique. Besoin d'une solution qui a un meilleur soutien et de l'aide sur le web. La demande a progressé de Routage exigences.

Answer 5

Full Disclosure: je travaille pour Iron.io.

Si vous voulez éviter la configuration et la gestion de votre courtier entièrement, vous pouvez toujours utiliser IronMQ comme votre courtier. Cela fonctionne de manière assez similaire au courtier RabbitMQ, en termes de performances, mais sans avoir à configurer ou gérer un serveur RabbitMQ.