SqlDependency против SQLCLR вызова WebService

У меня есть настольное приложение, которое должно быть уведомлено о любом изменении таблицы. Итак, я нашел только два решения, которые хорошо подходят для моего случая: SqlDependency и SQLCLR. (Я хотел бы знать, есть ли лучше в стеке.NET) Я построил обе структуры и заставил их работать. Я могу только сравнить длительность простого ответа от SQL Server к клиенту.

SqlDependency

Продолжительность: от 100 мс до 4 с

SQLCLR

Продолжительность: от 10 мс до 150 мс

Мне бы хотелось, чтобы эта структура могла обрабатывать высокоскоростные уведомления *, я прочитал несколько SO и сообщений в блоге (например, здесь), а также получил предупреждение от коллеги о том, что при массовых запросах SqlDependency может работать неправильно. Здесь MS предлагает что-то, чего я не получил, что может стать еще одним решением моей проблемы.

*: Не все время, а на сезон; 50-200 запросов в секунду на 1-2 сервера.

На основании высокого уровня уведомлений и параллельно с производительностью, с какими из этих двух я должен продолжать или есть другой вариант?

Источник

1 ответ

Решение

Ни SqlDependency (т. е. уведомления о запросах) или SQLCLR (т. е. вызов веб-службы через триггер) будет работать для этого объема трафика (50–200 запросов в секунду). И на самом деле, оба варианта довольно опасны на таких объемах.

Рекомендации, приведенные на обеих связанных страницах (одна на SoftwareEngineering.StackExchange.com и в статье TechNet), являются намного лучшими вариантами. Рекомендация о лучшем способе получения push-уведомлений на сервер из базы данных ms sql (т. Е. Настраиваемой таблицы очередей, которая опрашивается каждые несколько секунд) очень похожа на вариант № 1 статьи TechNet " Планирование уведомлений" (в котором для обработки обрабатывается Service Broker). очереди).

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

  • Сервисный Брокер
    • Pro: Существующая (и проверенная) инфраструктура (может масштабироваться и привязываться к транзакциям)
    • Против: не всегда легко настраивать или администрировать / отлаживать, не может легко объединить 200 отдельных событий за 1 секунду в одно сообщение (по-прежнему будет 1 сообщение на каждое событие триггера)
  • Полностью настраиваемая очередь
    • Pro: может объединять много одновременных событий триггера в одно "сообщение" клиенту (т. Е. Служба опроса отслеживает любые изменения, произошедшие с момента последнего опроса), может использовать отслеживание изменений / сбор данных изменений в качестве источника "что изменилось", так что вы можете не нужно строить таблицу очередей.
    • Против: Он настолько масштабируем, насколько вы в состоянии его сделать (может быть столь же хорошим или лучше, чем Service Broker, но в значительной степени зависит от ваших навыков и опыта для достижения этой цели), требует тщательного тестирования пограничных случаев, чтобы убедиться в очереди обработка не пропускает или не учитывает события дважды.

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

Некоторая документация для начала:

Источник
Другие вопросы по тегам