Использование SQLDependency против периодического опроса таблицы (влияние производительности)

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

Во время тестирования мы заметили, что производительность sql db забивалась службой уведомлений sqldependency. Мы уменьшили количество таблиц, которые мы использовали sqldependency, и заметили большой прирост производительности. Итак, мы думали, что мы просто закончили использовать его, и мы двинулись дальше. Теперь мы сводим всего к нескольким таблицам.

Позже мы обнаружили, что мы не можем уменьшить уровень доступа к безопасности для имени пользователя, которое установит зависимость. Мы могли бы иметь более одной строки соединения для каждого db (один для зависимости и один для остальной части приложения), но с множественным зеркалированием db и db, это боль (из точки зрения администратора и разработки приложения sql db)

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

Нам не нужно "мгновенное" уведомление о том, что данные были изменены. Если бы мы знали в течение 1 секунды, это было бы достаточно быстро.
С небольшим повторным факторингом мы можем получить его до 1 таблицы и опросить эту таблицу раз в секунду.

Кто-нибудь видит недостаток в этой логике?

Будет ли опрос одной таблицы раз в секунду вызывать более или менее нагрузку на db, чем SQLDependency?

У кого-то была проблема с производительностью с SQLDependency?

Ответ 1

Я смею попробовать ответить на ваш вопрос. Но я не уверен, что вы получите ответ, на который вы надеялись...

Я помню еще в начале 90-х, когда Borland продвинул эту грандиозную новую функцию "обратных вызовов" в своей базе данных Interbase, которая предоставила оповещения вызывающего абонента (Delphi) "через некоторые очень элегантные новые технологии, где promises было сделано, что база данных может быть" активной".

Это было позже известно как " трата теории времени.

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

Итак, языки программирования для спасения. Вернее, идея сервис-ориентированной архитектуры (SOA). Многие путают SOA для "Webservices", который действительно был включен в эту новую концепцию.

Но если вы посмотрите шаблон дизайна Fiefdom/Emissary (или шаблон Master/Agent, переименованный, чтобы сделать его более крутым и профессиональным), вы обнаружите, что основная идея имеет исключительный контроль над своими ресурсами (чтение баз данных) и что все вызовы проходят через один единственный адаптер данных.

Очевидно, что такая конструкция вообще не работает с триггерами и какими-либо структурами обратного вызова.

Но я думаю, вы должны пересмотреть весь свой дизайн. Если вы выполняете все действия и все вызовы через один "DataLayer", возможно, используя Entity Framework, и, возможно, сверху на том, что механизм кэширования вам не нужно будет полагаться на вашу базу данных, чтобы пересылать сообщения, поддерживающие цепочку продуктов.

Чтобы показать, как странные вещи могут появиться, когда они будут "ориентированы на базу данных", вот крайний фактический живой пример того, как не отправлять электронное письмо, написанное давно давным-давно, кодером, я был не так впечатлен с:

Факт 1: Сервер Sql может отправлять электронные письма.

Факт 2: Asp3 coder не знает, как и как это можно сделать в VbScript.

Asp3: прочитайте адрес электронной почты в текстовом поле, отправьте на com + layer

Com +: возьмите адрес электронной почты и перейдите на datalayer

Datalayer: возьмите адрес электронной почты и перейдите в хранимую процедуру

Sproc: возьмите адрес электронной почты и перейдите в функцию sql

: делать странные вещи подстроки, чтобы проверить, что адрес электронной почты @. в этом. return true или false.

Sproc: возвращает набор записей с одним столбцом и одной строкой, содержащей 1 или 0

Datalayer: вернуть таблицу как есть.

Com +: преобразовать первый столбец и строку со значением 1 или 0 в значение true или false

Asp3: если true, отправьте адрес электронной почты с темой электронной почты и текстом электронной почты на com +

Com +: отправляет точную информацию в datalayer

Datalayer: вызывает хранимую процедуру.

Sproc: вызывает sql-функцию...

Функция

: использует почтовый агент sql server для отправки электронной почты

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