Triggers vs Service Broker vs dedicarted Windows Service для высокопроизводительной обработки асинхронной записи с помощью хранимой процедуры

57
6

обзор

Я работаю над веб-решением, которое получает много миллионов записей в день (1000 за раз) через веб-службу от нескольких клиентов одновременно.

Каждая запись должна храниться в базе данных и использовать сложный набор правил и руководств для определения того, как классифицировать каждую запись, в настоящее время это делается с помощью хранимой процедуры для максимальной скорости (запись может быть классифицирована примерно за 4 миллисекунды).

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

Основные приоритеты

Приоритет 1: Храните записи, в настоящее время это делается через объемную вставку и хорошо работает

Приоритет 2: классифицируйте каждую запись, это лучше всего делать асинхронно, т.е. Это не нужно делать немедленно (для каждой записи), однако это должно произойти своевременно и очень эффективно

Приоритет 3: Архивирование, это полностью зависит от требований клиентов, возможно, это необходимо сделать сразу после классификации или в пакетном режиме, и только на этом этапе необходимо подумать

Предлагаемые решения

Мое мышление развилось с тех пор, как я впервые начал этот проект

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

Я также размышлял над идеей триггеров для обработки каждой записи при обновлении, однако, поскольку я никогда не занимался триггерами, я не уверен, замедлит ли она массовые обновления (шаг 1), насколько они надежны или еще раз, если есть лучший подход

Наконец, я узнал о Service Broker, который, похоже, выделяет много ящиков в отношении асинхронной обработки, надежности и архивирования/перемещения (последний шаг), хотя я не уверен, что это усложняет проблему, если есть любые жертвы производительности, а также дополнительное покрытие котла и черный бокс стоят усилий

Обратите внимание: я обычно старался бы использовать каждый подход для себя, однако отладка времени разработки, анализ показателей и кривые обучения с подходами не делают это возможным, дополнительно его перевешивают к моменту, когда это может потребоваться, чтобы получить некоторые хорошо округленные мнения от сообщество stackoverflow

Спасибо за ваше время, и я ценю любые советы или помощь, которые люди могут мне дать в этом отношении

спросил(а) 2014-06-09T05:10:00+04:00 6 лет, 3 месяца назад
1
Решение
71

Триггеры синхронны и будут замедлять объемные вставки. Service Broker - хорошая технология для асинхронной обработки в T-SQL. Тем не менее, есть немного кривая обучения, и важно следовать шаблонам наилучшей практики (например, не "стрелять и забывать"). Убедитесь, что у вас есть несчастливые пути, поскольку обработка происходит в фоновом режиме.

ответил(а) 2014-06-09T06:11:00+04:00 6 лет, 3 месяца назад
57

Поскольку у вас высокий уровень ввода, я бы посоветовал для простого опроса, т.е. внешняя служба, которая постоянно опросает. Потому что из-за высокой скорости ввода он имеет высокий уровень успеха в каждом опросе. Хотя верно, что для этого требуется дополнительная услуга NT, с sll багажом (особенно с отказом при переключении на отказ и Db HA) и трудно сделать дроссель должным образом (слишком медленно, и он отстает, слишком агрессивный опрос и вызывает ненужную работу...), в конце концов, это тот факт, что он не вызывает лишнего ввода-вывода, который удаляет матер. Service Broker - это, прежде всего, распределенная технология, предназначенная для общения между хостами. В случае локального единства, когда вы действительно хотите, чтобы очередь не отправляла сообщения, SSB имеет много накладных расходов. И SSB имеет состояние в db, глагол SEND - это одна вставка и два обновления (мин!), А BEGIN DIALOG - как минимум 2 вставки. Если вы считаете наивную SEND за ввод входной записи, вы получаете много дополнительного ввода-вывода. Я также рекомендую читать http://rusanu.com/2010/03/26/using-tables-as-queues/

ответил(а) 2014-06-09T12:53:00+04:00 6 лет, 3 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема