SQL Server Service Broker contre RabbitMQ
Nous envisageons RabbitMQ pour mettre en file d'attente plusieurs milliers de tâches par minute, puis les traiter à partir de plus de 300 machines virtuelles. Nous avons une API Web de planification intelligente qui distribuera intelligemment (assez) les tâches de plus de 100 files d'attente aux machines virtuelles en fonction des besoins de l'entreprise. Nous savons que RabbitMQ est définitivement capable de gérer ce type de charge. Actuellement, nous interrogeons la base de données à chaque fois sur plusieurs tables, ce qui contribue à 30 à 40% de la charge de SQL Server. Au lieu de cela, nous pensions à mettre en place un déclencheur puis à pousser les données vers RabbitMQ (via une API d'échange intermédiaire) au fur et à mesure que les données arrivent. Je me rends compte que SQL Service Broker est également une option potentielle par rapport à RabbitMQ pour les files d'attente, donc j'ai quelques questions sur SQL Service Broker (SQL Server 2016 et versions ultérieures) auxquelles j'espère que vous pourrez répondre:
- Pouvons-nous stocker les données de file d'attente de manière durable, puis extraire des tâches de files d'attente spécifiques en fonction des besoins de l'entreprise? (Je suppose que oui, mais je confirme simplement.)
- Quelle est sa fiabilité pour plus de 100 files d'attente? Je me souviens que les anciennes versions de Service Broker étaient assez instables.
- Pouvons-nous créer de nouvelles files d'attente dynamiquement/par programme?
- Pouvons-nous créer des files d'attente à priorité minimale (c'est-à-dire que lorsque les tâches sont poussées dans la file d'attente, elles sont triées en fonction de la priorité)?
- Quel est l'impact en termes de performances et de charge? Au moins avec RabbitMQ, nous pouvons décharger la responsabilité de la gestion de la file d'attente sur un cluster RabbitMQ, laissant notre serveur SQL libre pour traiter d'autres requêtes.
- Est-il vrai que nous devons configurer une sorte de "conversation" entre les files d'attente pour que cela fonctionne?
- Y a-t-il d'autres différences/avantages/inconvénients dont nous devons être conscients lorsque l'on considère l'un par rapport à l'autre?
Pouvons-nous stocker les données de file d'attente de manière durable, puis extraire des tâches de files d'attente spécifiques en fonction des besoins de l'entreprise? (Je suppose que oui, mais je confirme simplement.)
Oui.
Quelle est sa fiabilité pour plus de 100 files d'attente? Je me souviens que les anciennes versions de Service Broker étaient assez instables.
Une file d'attente est une table. SEND est un encart. RECEIVE est une suppression. Il existe des fonctionnalités pour traiter les files d'attente à partir de SQL Server, mais vous pouvez toujours simplement utiliser des clients externes.
Voir par exemple https://code.msdn.Microsoft.com/Service-Broker-Message-e81c4316 pour un exemple de traitement d'une file d'attente à partir d'une application externe.
Pouvons-nous créer de nouvelles files d'attente dynamiquement/par programme?
Oui. Mais comme la création dynamique de tables, il a une mauvaise odeur de code.
Pouvons-nous créer des files d'attente à priorité minimale (c'est-à-dire que lorsque les tâches sont poussées dans la file d'attente, elles sont triées en fonction de la priorité)?
Oui.
https://docs.Microsoft.com/en-us/sql/t-sql/statements/create-broker-priority-transact-sql
Quel est l'impact en termes de performances et de charge?
Un SEND est une insertion à une seule ligne dans une table d'index cluster avec un seul index non cluster. Un RECEIVE est une suppression d'une ligne.
Est-il vrai que nous devons configurer une sorte de "conversation" entre les files d'attente pour que cela fonctionne?
Chaque ENVOI et RECEPTION s'inscrit dans le cadre d'une "conversation" qui est une session potentiellement longue durée entre deux "services". les conversations peuvent vivre éternellement et être réutilisées, et sont la source de beaucoup de confusion pour démarrer avec Service Broker.
Y a-t-il d'autres différences/avantages/inconvénients dont nous devons être conscients lorsque l'on considère l'un par rapport à l'autre?
Service Broker est assez complexe, car tous les messages sont envoyés sur des conversations duplex à longue durée de vie et vous devez les programmer en TSQL. Une fois que vous avez vérifié la conception et l'étrange dépannage, beaucoup de TSQL est passe-partout.
La meilleure chose à propos de Service Broker est que ce n'est pas un référentiel séparé et vos messages ont la même HA/DR et sauvegarde que vos autres données. Et il est trivial d'inscrire SEND ou RECEIVE dans une transaction impliquant d'autres données d'application.
Si vous ne voulez pas de messagerie dans la base de données, pensez à Azure Service Bus est beaucoup plus simple à utiliser, plus fonctionnel, est exploité pour vous dans le cloud et est capable de gérer ce niveau d'échelle assez facilement et à moindre coût.
De plus, pour de nombreux scénarios, vous pouvez simplement utiliser une simple table comme file d'attente. Voir par exemple http://rusanu.com/2010/03/26/using-tables-as-queues/ de Remus Rusanu, qui était auparavant un SQL de l'équipe produit SQL propriétaire de Service Broker . Vous n'obtenez pas de lectures bloquantes, mais si vos exigences de latence peuvent tolérer un lecteur dans une boucle d'interrogation, cela peut être une bonne option.
Je pensais que j'ajouterais mes 2 cents depuis que je travaille beaucoup avec SSB et RabbitMQ (RMQ).
Tout d'abord: je suis d'accord avec la plupart de ce que David dit dans son article. La seule chose avec laquelle je pourrais être en désaccord avec un peu est
"Once you grok the design, and the strange troubleshooting a lot of the TSQL
is boilerplate."
Sur mon lieu de travail, nous utilisons la SSB de manière intensive et nous avons beaucoup de processus qui l'utilisent. Nous avons commencé à utiliser SSB alors que SQL Server 2005 était encore en version bêta (donc il y a quelques années maintenant), mais nous sommes toujours "mordus" par le comportement de "boîte noire" de SSB de temps en temps.
Ainsi, ces dernières années - pour de nouveaux projets - nous avons commencé à utiliser RMQ. Tous nos traitements de données ont lieu dans des procédures stockées, il est donc facile de créer un "point de raccordement" dans la procédure et, dans ce "point de raccordement", d'envoyer des données via un assemblage SQLCLR à RMQ. Vous pouvez en savoir plus à ce sujet ici . La solution SQLCLR fonctionne extrêmement bien et nous envoyons des milliers de messages par seconde (nos bases de données sont OLTP 24/7 avec un débit très élevé).
Quoi qu'il en soit, dans mon esprit, le choix entre SSB et RMQ se résume à deux choses (je suppose que la source des données se trouve dans la base de données):
- Où se déroule le traitement des données après leur retrait de la file d'attente; dans la base de données ou un processus externe? S'il s'agit d'un processus externe, je pencherais pour RMQ. Je considérerais SSB comme une solution si le traitement se produit dans une autre base de données. Cependant, en raison de ses particularités, je pourrais plutôt envisager de créer un assemblage SQLCLR pub-sub. Cet assembly lirait les données de la ou des tables asynchrones et les enverrait à l'autre base de données pour traitement (nous l'avons également fait là où je travaille).
- Avez-vous besoin des capacités duplex que SSB vous offre? N'oubliez pas que SSB n'est pas tout à fait destiné à être un courtier de messages, mais est conçu pour (comme le dit David) les conversations duplex, qui sont potentiellement de longue durée. Si vous avez besoin des capacités duplex, SSB est (presque) une donnée.
J'espère que cela t'aides! Veuillez nous faire savoir ce que vous décidez.