1

データを保存/処理するためのバックエンドを構築する最も効率的な方法を探しています。基本的に、データはサーバーに送信され、解析されてからデータベースに保存されます。次に、データベース内の他のデータに基づいて何らかの処理が行われ、電子メールまたは SMS を介してアラートが発生します。

プラットフォームは .NET で、DB は SQL Server 2005 または 2008 です。

いえ

  1. 温度センサーは、4 バイトのデータをサーバーに送信します。
  2. サーバーはデータを実際の値、たとえば 20 に変換します。
  3. その後、値は SQL サーバー db に保存されます。
  4. 次に、値は、そのセンサーに設定された境界 (0 ～ 50) を持つテーブル内の行に対してチェックされます。
  5. 範囲外の場合、アラートが発生します。（SMSまたはメールで送信されます。）

これはすべて非常に簡単に思えますが、理想的なシナリオはすべてが「リアルタイム」で発生し、1秒あたり数百または数千のリクエストになる可能性があることを考えると、それを行うための最良の方法を探しています. 私は、SQL 2005/08 の「新しい」機能のいくつか (Service Broker、CLR 統合、トリガーなど、経験がほとんどない) を活用したいと考えていました。

ステップ 1 と 2 はすでに完了しています。

キューイングするトランザクションの数を考慮して、サービス ブローカーまたは MSMQ を使用するのが賢明でしょうか? 境界データを調べる必要がある場合、どの時点でアラート データを処理すればよいですか? データをどのように処理したいかについていくつかのアイデアがありますが、使用するのに最適なテクノロジー/方法論がわかりません。

私の考えは (ステップ 3 から)、データをサービス ブローカーに送信し、サービス ブローカーが CLR プロシージャを呼び出して、データの「ビジネス ロジック」を処理することです。または、トリガーを使用してデータを Service Broker に追加し、データを処理しますか? Service Broker は CLR プロシージャを直接呼び出すことができますか? ポーリングではなくイベント駆動型のデータを処理したい場合、Service Broker を使用することは正しい考えでしょうか?

Service Broker で見た例から、データを受信するにはコードが必要であるように見えますが、実際にやりたいことは、データをキューに追加し、キューを自動的に空にすることです (アラート データを次のように処理します)。そうします）。

標準のストアド プロシージャを使用してこれらすべてを行うこともできますが、ビジネス ロジックが例よりもはるかに複雑になるため、ストアド プロシージャの使用は最小限に抑え、代わりに CLR 統合を使用したいと考えています。

サービス ブローカーがキューイングとスレッド化を処理することを考えると、CLR プロシージャを呼び出してアラート データを処理し、SMS や電子メールを送信するのに適していると思いました。

光を見せてください！ありがとう！

4

3 に答える 3

3

dportas と SPE109 は、フル機能のイベント監視ソリューションが実現可能かどうかについて、適切なアドバイスを提供しています。

ただし、あなたが提起した Service Broker に関する特定の質問に答えることができます。

  • Service Broker は、指定したデータ レートを処理できます。Microsoft の Service Broker の中心人物の 1 人である Remus Rusanu は、安価なコモディティ ハードウェアで 1 秒あたり 1000 イベントをはるかに超えるメッセージ スループットを達成しました。
  • バッチ プロセスを使用して Service Broker に送信するか、トリガーを使用するかは、主に好みの問題であり、それがワークフローにどのように適合するかです。どちらのアプローチでも機能します。
  • Service Broker を使用する場合は、内部アクティベーション プロシージャ (標準の SQL ストアド プロシージャ) または外部アクティベーター (別のプロセス) のいずれかを使用できます。外部アクティベーションの経験はありませんが、内部アクティベーションの場合は、特定のキューにメッセージが入ったときに Service Broker が呼び出す SQL プロシージャを作成する必要があります。そのプロシージャは、CLR プロシージャを呼び出して、受信したメッセージ データに対して操作を実行できます。

より基本的な質問は次のとおりです。「標準」のアプローチ (データを DB に保存し、それを毎秒ポーリングし、受信したイベントをバッチ処理する) では提供されない Service Broker の機能は何ですか?

Service Broker は、メッセージの永続性と順序付けが必要な場合、SQL Server インスタンス間で通信している場合、またはそのメカニズムを利用して多くの作業を実行できる場合に最適です。この場合、問題のステートメントを考えると、持続性と順序付けが特に重要であるようには思えません。データを監視し、境界条件に違反したときにアラートをスローしたいと考えています。メッセージが処理される順序に依存関係がない限り、ポーリングされたバッチ プロセスは、Service Broker のセットアップ オーバーヘッドなしで、より簡単にジョブを完了できると思います。

于 2011-06-30T12:46:00.633 に答える
2

複合イベント処理ソリューションの分野を見てみましょう。OsiSoft (PI システム)、Streambase、Oracle などの主要な製品があります。Microsoft には Streaminsight がありますが、これは第 1 世代の製品であり、配信やサポートの永続性を保証するものではありません。

于 2011-06-30T09:40:12.623 に答える
0

Streaminsight http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspxを参照してください。私はそれについてあまり知っているとは言えませんが、Allan Mitchell と Streaminsight をグーグルで検索したり、SQLIS.com を見たりすると、彼はそれを使用して多数のデモ ビデオを作成しました。

于 2011-06-30T09:29:50.570 に答える