Sql Service Broker, интеграция CLR, запускает проблему с сервером
Я ищу наиболее эффективный способ создания бэкэнда для хранения / обработки данных. В основном, данные отправляются на сервер, анализируются и сохраняются в БД. Затем выполняется некоторая обработка, основанная на других данных в БД, а затем генерируются оповещения по электронной почте или смс.
Платформа -.NET, а БД - SQL Server 2005 или, возможно, 2008.
Т.е.
- Датчик температуры отправляет 4 байта данных на сервер.
- Сервер преобразует данные в реальное значение, скажем, 20.
- Затем значение сохраняется на БД SQL-сервера.
- Затем значение проверяется по строке в таблице, для которой установлены границы этого датчика, т.е. 0-50
- Если за пределами границ предупреждение. (Отправлено через 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 для обработки данных оповещения и отправки смс или электронной почты?
Пожалуйста, покажи мне свет! Спасибо!
3 ответа
Похоже, вы можете захотеть взглянуть на Streaminsight http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx. Я не могу сказать, что знаю слишком много об этом, но если вы гуглили Аллана Митчелла и Streaminsight или заглянули на SQLIS.com, он сделал несколько демонстрационных видео, используя их.
dportas и SPE109 дали хороший совет, если для вас выполнимо полнофункциональное решение для мониторинга событий.
Я могу ответить на конкретные вопросы о Service Broker, которые вы подняли, однако:
- Компонент Service Broker может обрабатывать указанные вами скорости передачи данных. Ремус Русану, один из основных сотрудников Service Broker в Microsoft, достиг с пропускной способностью сообщений, намного превышающей 1000 событий в секунду, с помощью дешевого аппаратного оборудования.
- Используете ли вы пакетный процесс для отправки в Service Broker или триггер, во многом вопрос предпочтения и того, как он вписывается в ваш рабочий процесс. Любой подход может работать.
- Если вы используете Service Broker, вы можете использовать либо внутреннюю процедуру активации (стандартная хранимая процедура SQL), либо внешний активатор (отдельный процесс). У меня нет опыта работы с внешней активацией, но для внутренней активации вы должны написать процедуру SQL, которую Service Broker затем будет вызывать при поступлении сообщений в заданную очередь. Эта процедура может вызывать процедуры CLR для выполнения операций с полученными данными сообщения.
Более фундаментальный вопрос: что дает вам Service Broker, чего не делает "стандартный" подход (сохранять данные в БД, затем опрашивать их каждую секунду и пакетно обрабатывать поступившие события)?
Компонент Service Broker отлично подходит для тех случаев, когда вам нужны постоянство и упорядоченность сообщений, когда вы обмениваетесь данными между экземплярами SQL Server или когда вы можете использовать его механизмы для выполнения большей части вашей работы за вас. В этом случае, с учетом вашей постановки проблемы, не похоже, что постоянство и упорядоченность особенно важны. Вы хотите следить за данными и выдавать оповещения, когда они нарушают граничные условия. Если нет зависимости от порядка обработки сообщений, я бы подумал, что процесс пакетного опроса будет выполнять работу проще и без накладных расходов на установку Service Broker.
Взгляните на область решений для комплексной обработки событий. Существуют лидирующие предложения от OsiSoft (система PI), Streambase, Oracle и других. У Microsoft есть Streaminsight, хотя это продукт первого поколения, и он не гарантирует доставку и поддержку.