Параллельная обработка очереди базы данных

Question

Существует небольшая система, в которой таблица базы данных является очередью на MSSQL 2005. Несколько приложений пишут в эту таблицу, а одно приложение читает и обрабатывает в режиме FIFO.

Я должен сделать его немного более продвинутым, чтобы создать распределенную систему, в которой могут работать несколько приложений обработки. В результате должно получиться, что обрабатывающее приложение 2-10 должно работать, и оно не должно мешать друг другу во время работы.

Моя идея - расширить таблицу очередей строкой, показывающей, что над ней уже работает процесс. Приложение обработки сначала обновит таблицу своим idetifyer, а затем запросит обновленные записи.

Так что-то вроде этого:

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

После обработки он устанавливает в столбце обработки таблицы что-то еще, например, «выполнено» или что-то еще.

У меня есть три вопроса об этом подходе.

Во-первых: это может работать в этой форме?

Второе: если это работает, эффективно ли это? У вас есть другие идеи по созданию такого дистрибутива?

В-третьих: в MSSQL блокировка основана на строках, но после блокировки количества строк блокировка распространяется на всю таблицу. Таким образом, второе приложение не может получить к нему доступ, пока первое приложение не освободит транзакцию. Насколько большим может быть выделение (top x), чтобы не блокировать всю таблицу, а только создавать блокировки строк?

Answer 1

Это будет работать, но вы, вероятно, обнаружите, что вы столкнетесь с блокировками или взаимоблокировками, когда несколько процессов пытаются прочитать или обновить одни и те же данные. Я написал процедуру, чтобы сделать именно это для одной из наших систем, которая использует некоторую интересную семантику блокировки, чтобы гарантировать, что этот тип работает без блокировок или взаимоблокировок, , описанных здесь .

Answer 2

Самая большая проблема с этим подходом состоит в том, что вы увеличиваете количество «обновлений» в таблице. Попробуйте сделать это, используя только один процесс (update + delete) и другие, вставляющие данные в таблицу, и вы обнаружите, что примерно при миллионе записей он начинает разрушаться.

Я бы предпочел иметь одного потребителя для БД и использовать очереди сообщений для доставки данных обработки другим потребителям.

Answer 3

По вашему вопросу о блокировке. Вы можете использовать подсказку о блокировке, чтобы заставить ее блокировать только строки

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

Answer 4

Этот подход кажется мне разумным и похож на тот, который я использовал в прошлом - успешно.

Кроме того, строка / таблица будет заблокирована только во время выполнения операций обновления и выбора, поэтому я сомневаюсь, что вопрос «строка против таблицы» действительно важен.

Если только затраты на обработку вашего приложения не будут настолько низкими, чтобы их можно было пренебречь, я бы оставил верхнее значение низким - возможно, всего 1. Конечно, это полностью зависит от деталей вашего приложения.

Сказав все это, я не администратор баз данных, и поэтому мне также будут интересны дополнительные ответы экспертов