MSMQ v Таблица базы данных

Question

Существующий процесс изменяет поле статуса записи бронирования в таблице в ответ на ввод пользователя.

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

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

Это наше программное обеспечение, которое добавляет и обновляет записи в таблице.

Это новая часть работы (служба Windows), которая будет выполнять асинхронную обработку. Это должно быть "всегда".

Answer 1

Есть несколько причин, которые обсуждались здесь на форуме Fog Creek: http://discuss.fogcreek.com/joelonsoftware5/default.asp?cmd=show&ixPost=173704&ixReplies=5

Основным преимуществом является то, что MSMQ все еще можно использовать, когда между компьютерами имеется прерывистое соединение (с использованием механизма хранения и пересылки на локальном компьютере). Что касается приложения, оно доставило сообщение в MSMQ, хотя MSMQ, возможно, доставит сообщение позже.

Вы можете вставить запись в таблицу только тогда, когда вы можете подключиться к базе данных.

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

Answer 2

Если скорость, с которой создаются записи о бронировании, низкая, второй процесс периодически проверяется на наличие новых бронирований.

Если вы уже не используете MSMQ, его внедрение просто дает вам дополнительный компонент платформы для поддержки.

Если база данных сильно загружена, или вы получаете много конфликтов блокировки, когда два процесса читают и записывают в одну и ту же область таблицы заказов, рассмотрите возможность введения MSMQ.

Answer 3

Мне также нравится этот ответ от le dorfier в предыдущем обсуждении :

Сначала я использовал таблицы, затем рефакторинг в полноценную очередь сообщений, когда (и если) есть причина - что тривиально если ваш дизайн разумный.

Спасибо, ребята, за все ответы. Самый полезный.

Answer 4

С помощью MSMQ вы также можете очень легко перенести работу на другой сервер, изменив расположение очереди на другой машине, а не на сервере db.

Кстати, в SQL Server 2005 очередь встроена в БД. Его называют SQL Server Service Broker. Смотри: http://msdn.microsoft.com/en-us/library/ms345108.aspx

Answer 5

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

Answer 6

Также см. предыдущее обсуждение .

Answer 7

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

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

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

Когда к базе данных обращались через приличное интернет-соединение, вставка строки в базу данных была в 6 раз медленнее, чем запись в MSMQ.

Итак:

Локальная база данных - БД работает быстрее, в противном случае MSMQ.

Answer 8

Помимо ответа Митча, некоторые другие сценарии: 1. у каждого вашего сообщения есть своя дата исполнения, чтобы инициировать действие, это также можно сделать с помощью MQ, но в этом случае я предпочитаю хранить его в db, так как оно более управляемо; 2. подписчик должен отфильтровать сообщение и затем обработать его часть, это также может быть сделано с помощью LINQ, в зависимости от того, насколько сложен фильтр, подход db лучше, потому что я могу использовать linq to EF, чтобы легко выполнять сложные запросы; 3. Для развертывания я хочу полностью автоматизированный процесс развертывания, чтобы БД была для меня лучшим выбором. Я не большой поклонник ручных настроек.

Answer 9

Service Broker был введен в SQL 2005 и предназначен для очень быстрой обработки сообщений, поскольку этот процесс относительно прост (я полагаю, его корни были в триггерах). Если вас беспокоит масштабируемость, в SQL 2008 они выпустили независимый исполняемый файл обработки, чтобы отделить обработку от SQL Server (в стандартном компоненте Service Broker все контролируется экземплярами SQL Server).

Я бы определенно подумал об использовании Service Broker поверх MSMQ, но это зависит от ваших ресурсов разработки SQL / DBA и их знаний.

Answer 10

Я бы, наверное, пошел с MSMQ или ActiveMQ сам. Я бы посоветовал (предполагая, что вы рассматриваете MSMQ, вы используете Windows с технологией MS), изучая WCF, или если вы используете MS-SQL 2005+ с триггером, который вызывает код .net для запуска вашей обработки.