traitement parallèle de file d'attente de la base de données

Question

Il y a un petit système, où une table de base de données sur la file d'attente MSSQL 2005. Plusieurs applications sont en train d'écrire à cette table, et une application est en train de lire et de traitement d'une manière FIFO.

je dois en faire un peu plus avancé pour être en mesure de créer un système distribué, où plusieurs applications de traitement peut fonctionner. Le résultat devrait être que l'application de traitement 2-10 devrait être capable de fonctionner et ils ne devraient pas interférer les uns les autres pendant le travail.

Mon idée est d'étendre la table de file d'attente avec une ligne indiquant qu'un processus travaille déjà là-dessus. L'application de traitement mettra d'abord à jour la table avec son idetifyer, puis demandera les enregistrements mis à jour.

donc quelque chose comme ceci:

start transaction 
update top(10) queue set processing = 'myid' where processing is null 
select * from processing where processing = 'myid' 
end transaction 

Après le traitement, il définit la colonne de traitement de la table à autre chose, comme « fini », ou autre chose.

J'ai trois questions à propos de cette approche.

Premièrement: cela peut-il fonctionner sous cette forme? Deuxièmement: si cela fonctionne, est-ce efficace? Avez-vous d'autres idées pour créer une telle distribution?

Troisième: En MSSQL le verrouillage est basée sur les lignes, mais après sont verrouillés une quantité de lignes, le verrou est étendu à toute la table. Ainsi, la deuxième application ne peut y accéder, jusqu'à ce que la première application ne libère pas la transaction. Quelle taille peut avoir la sélection (top x) pour ne pas verrouiller toute la table, ne créer que des verrous de ligne?

Answer 1

Cela fonctionne, mais vous trouverez probablement vous tomberez dans le blocage ou les blocages lorsque de plusieurs processus essaient de lire/mettre à jour les mêmes données. J'ai écrit une procédure pour faire exactement cela pour l'un de nos systèmes qui utilise une sémantique de verrouillage intéressante pour assurer que ce type de chose fonctionne sans blocage ou interblocage, described here.

Answer 2

Cette approche me semble raisonnable, et est similaire à celle que j'ai utilisée dans le passé - avec succès.

En outre, la ligne/tableau ne seront verrouillés pendant la mise à jour et les opérations de sélection ont lieu, alors je doute la ligne vs question de table est vraiment une considération importante. À moins que le coût de traitement de votre application soit si faible qu'il soit négligeable, je garderais la valeur «supérieure» faible - peut-être juste 1. Bien sûr, cela dépend entièrement des détails de votre application.

Ceci étant dit, je ne suis pas un DBA, et ainsi sera également être intéressé par plus des réponses d'experts

Answer 3

En ce qui concerne votre question sur le verrouillage. Vous pouvez utiliser une touche de verrouillage pour le forcer à verrouiller des lignes seulement

update mytable with (rowlock) set x=y where a=b 

Answer 4

Le plus gros problème avec cette approche est que vous augmentez le nombre de « mises à jour » à la table. Essayez ceci avec un seul processus consommant (mise à jour + suppression) et d'autres insérant des données dans la table et vous constaterez qu'environ un million d'enregistrements, il commence à s'effondrer.

Je préférerais avoir un consommateur pour la DB et utiliser les files d'attente de messages pour fournir des données de traitement à d'autres consommateurs.