Sql Service Broker, CLR Integration, запускает проблему с сервером

Question

Я ищу наиболее эффективный способ создания бэкэнда для хранения / обработки данных. В основном, данные отправляются на сервер, анализируются и сохраняются в БД. Затем выполняется некоторая обработка, основанная на других данных в БД, а затем генерируются оповещения по электронной почте или по смс.

Платформа - .NET, а БД - SQL Server 2005 или, возможно, 2008.

* 1005 Т.е. *

1. Датчик температуры отправляет на сервер 4 байта данных.
2. Сервер преобразует данные в реальное значение, скажем, 20.
3. Затем значение сохраняется на БД SQL-сервера.
4. Затем значение проверяется по строке в таблице, для которой установлены границы для этого датчика, т.е. 0-50
5. Если за пределами границ выдается предупреждение. (Отправлено через SMS или по электронной почте.)

Все это кажется довольно простым, но я ищу лучший способ сделать это, учитывая, что идеальный сценарий состоит в том, что все это происходит в «реальном времени», и это могут быть потенциально 100 или 1000 запросов в секунду. Я хотел использовать некоторые из «новых» функций SQL 2005/08, таких как Service Broker, интеграция CLR, триггеры и т. Д., С которыми у меня мало опыта.

Шаги 1 и 2 уже выполнены.

Было бы разумно использовать Service Broker или MSMQ, учитывая количество транзакций для постановки в очередь? В какой момент я обрабатываю данные оповещения, учитывая, что мне нужно проверить данные границы? У меня есть некоторые идеи о том, как бы я хотел обработать данные, но не уверен в том, какую технологию / методологию использовать.

Моя идея состоит в том, чтобы (начиная с шага 3) передать данные брокеру служб, который, в свою очередь, вызывает процедуру CLR для обработки «бизнес-логики» данных. Или я использую триггер, чтобы добавить данные в Service Broker для обработки данных? Может ли сервисный брокер напрямую вызывать процедуру CLR? Является ли использование сервисного брокера даже правильной идеей, учитывая, что я хочу обрабатывать данные в большей степени на основе событий, чем на опрос?

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

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

Учитывая, что компонент Service Broker обрабатывает очереди и потоки, я подумал, что это может быть хорошим кандидатом для вызова процедуры CLR для обработки данных оповещения и отправки смс или электронной почты?

Пожалуйста, покажи мне свет! Спасибо!

Answer 1

dportas и SPE109 дали хороший совет, если для вас выполнимо полнофункциональное решение для мониторинга событий.

Я могу ответить на конкретные вопросы о Service Broker, которые вы подняли, однако:

• Service Broker может обрабатывать указанные вами скорости передачи данных.Ремус Русану (Remus Rusanu), один из основных разработчиков Service Broker в Microsoft, достиг с пропускной способностью сообщений, намного превышающей 1000 событий в секунду, на дешевом аппаратном оборудовании.
• Используете ли вы пакетный процесс для отправки в Service Broker или триггерв основном вопрос предпочтений и того, как он вписывается в ваш рабочий процесс.Любой подход может работать.
• Если вы используете Service Broker, вы можете использовать либо внутреннюю процедуру активации (стандартная хранимая процедура SQL), либо внешний активатор (отдельный процесс).У меня нет опыта работы с внешней активацией, но для внутренней активации вы должны написать процедуру SQL, которую Service Broker затем будет вызывать при поступлении сообщений в данную очередь.Эта процедура может вызывать процедуры CLR для выполнения операций над полученными данными сообщения.

Более фундаментальный вопрос: что дает Service Broker такой «стандартный» подход (сохранение данных в БД,затем опрашивать его каждую секунду и пакетно обрабатывать поступившие события) не так ли?

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

Answer 2

Взгляните на область решений для комплексной обработки событий.Существуют лидирующие предложения от OsiSoft (система PI), Streambase, Oracle и других.У Microsoft есть Streaminsight, хотя это продукт первого поколения, и он не гарантирует доставку или постоянную поддержку.

Answer 3

Звучит так, что вы, возможно, захотите взглянуть на Streaminsight http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx. Не могу сказать, что знаю слишком много об этом, но если вы гуглите Аллана Митчелла и Streaminsight или загляните на SQLIS.com, он имеетсделал несколько демонстрационных видео, используя его.