0

ビジネス シナリオ:

Constructionがあると想像してください。建設は、新しい建物、橋などである可能性があります。建設ヤードでは、さまざまな物理的および環境の変化が発生する可能性があります。これらの変化は、たとえば温度の変化である可能性があります。

建設ヤードからさまざまな種類のデータを収集するクライアント向けのアプリケーションを構築し、後で次のことを行いました。

  1. 時間の変化のグラフを表示する
  2. 建設管理者やその他の意思決定者に洞察、アラート、通知を提供する

現在のステータス：

アプリケーションが構築され、機能しています。

  1. 広告。1 - すべてのデータが収集され、チャートで視覚化されます
  2. 広告。2 -このモジュールの適切な設計についてはまだ首を絞めているところです

問題：

WCF サービスとソケット プロセスを使用してデータを収集する異常データ通知モジュールを適切に設計するにはどうすればよいですか?

全体的なアーキテクチャ設計:

建築デザイン

パズルの主要なピースは 4 つあります。

  1. バックエンド データベース - SQL Server 2008 (Azure SQL)
  2. フロントエンド Web アプリケーション - ASP.NET MVC 3 (WebRole for Azure)。
  3. データを送信する ZigBee デバイスによって呼び出される WCF 4.0 サービス (WebRole for Azure)。
  4. 設定された頻度でソケット IP (Azure の WorkerRole) を使用して Rfid リーダーを呼び出す Windows プロセス。

データベースには、Rfid 読み取り用と ZigBee 読み取り用の 2 つの個別のテーブルがあります。結果を格納するテーブルは、パフォーマンスのために意図的に非正規化されています。複数のインデックスによるクエリとグループ化が高速化されています。フロントエンドアプリケーションでのデータアクセスにEntity FrameworkとLinq with Projectionを使用しており、うまく機能しています。

異常データ通知モジュール:

通知モジュールの機能要件は次のとおりです。

  1. 次の場合に、特定の建設ヤードの通知サブスクライバーに SMS と電子メールを送信します。
  2. 測定データの値がしきい値を超えている x 発生回数
  3. パラメータ: 最小値、最大値、しきい値、繰り返し回数、繰り返し時間ウィンドウ、センサー タイプ

たとえば、特定の建設ヤードの通知/アラートを追加しました。このアラートは次のように構成されています。

  • 最小値 = -5
  • 最大値 = 40
  • しきい値 = 5
  • 繰り返し回数 = 5
  • 繰り返し時間枠 = 5 分
  • センサータイプ = 温度

そのため、ZigBee WCF または Rfid Windows プロセスがデータを取得すると、通知/アラートをトリガーできます。例えば：

  • 日付: 2012-08-19 10:00 値: 30 OK
  • 日付: 2012-08-19 10:01 値: 28 OK
  • 日付: 2012-08-19 10:02 値: 40 OK (まだ最大値 + しきい値未満)
  • 日付: 2012-08-19 10:03 値: 41 OK (まだ最大値 + しきい値未満)
  • 日付: 2012-08-19 10:04 値: 39 OK
  • 日付: 2012-08-19 10:05 値: 46 OK (しきい値を超え、繰り返し回数 1)
  • 日付: 2012-08-19 10:06 値: 39 OK
  • 日付: 2012-08-19 10:07 値: 38 OK
  • 日付: 2012-08-19 10:08 値: 39 OK
  • 日付: 2012-08-19 10:09 値: 38 OK
  • 日付: 2012-08-19 10:10 値: 39 OK
  • 日付: 2012-08-19 10:11 値: 38 OK (最後の異常発生 > 繰り返し時間ウィンドウ、繰り返し回数 0)
  • 日付: 2012-08-19 10:12 値: 41 OK (まだ最大値 + しきい値未満)
  • 日付: 2012-08-19 10:13 値: 46 OK (しきい値を超え、繰り返し回数 1)
  • 日付: 2012-08-19 10:14 値: 47 OK (しきい値以上、繰り返し回数 2)
  • 日付: 2012-08-19 10:15 値: 46 OK (しきい値を超え、繰り返し回数 3)
  • 日付: 2012-08-19 10:16 値: 47 OK (しきい値を超え、繰り返し回数 4)
  • 日付: 2012-08-19 10:17 値: 46 OK (しきい値を超え、繰り返しカウント 5) -> ALERT!

アーキテクチャ設計要件:

すべてのロジックはビジネス レイヤー内にある必要があります。つまり、ストアド プロシージャもトリガーも使用できません。

考えられる解決策 1:

最初に考えたのは、ZigBee と Rfid サービスの両方にモジュール ロジックをアタッチすることでしたが、これはパフォーマンス ジャムを引き起こす可能性があります。Service のすべてのリクエストの最終チェックのために DB を呼び出すと、デッドロックで終了する可能性のある多くのコンピューティング トランザクションが生成されます。ここで WCF Queue メカニズムを使用できますが、それでもこの問題を解決できるメリットはありません。

このソリューションの推奨事項は大歓迎です。

考えられる解決策 2:

2 番目のアイデアは、構成された頻度でバックグラウンド スキャン データベースを実行する別の Windows プロセスをデプロイすることでした。「しきい値を超えた」場合は、この情報を別の「キャッシュ」テーブルに保存し、データベースのこの行に特定のチェックが行われたことを「マーク」します。通知/アラート。そのため、後でスキャンに追加されません。

これは次のことを意味します。

  1. 別の「キャッシュ」テーブル
  2. 「スキャナー」を 30 分の頻度で構成した場合の通知/アラートの配信遅延
  3. 「特定の通知」の行を「マーク」する何らかの方法で、単純に Bool フラグを追加することはできません。その結果、多くの定義された通知 (建設ヤードの 3 ～ 4 の通知) の計算に 1 行の読み取りが取り込まれる可能性があるためです。
  4. いくつの「プロセス」、「バックグラウンド ワーカー」が同時に動作する必要がありますか? 既存の通知構成と同じか、またはそれらすべてに対して 1 つの単一で、スタックを操作しますか?

このソリューションの推奨事項は大歓迎です。

結論：

この種の問題を処理するアイデア、経験、既存のソリューション (dll)、パターンを知っている場合は、私たちと共有してください。

4

2 に答える 2

0

「何かアイデアがあれば」とおっしゃいましたので、どうぞ。うまくいけば、ベースから外れません..

グラフと説明から、各アプリ/データ レシーバーがデータベースに直接書き込みを行っているように思えます。レシーバーがデータをプッシュし、フロントエンドがアラート仕様を送信する専用アプリケーションの背後にデータベースを配置すると、データがデータベースに保存されているときにアラート情報をリアルタイムで更新できます。つまり、各アラートの状態を保存し、新しい「興味深い」値が発生すると更新します。この方法では、データをマークする必要はありません。継続的に更新されるのはアラートです。アラートが最終的にトリガーされると、非同期プロセスを起動して、そのアラートの通知を送信します。

これは、メッセージングを使用したサガのアイデアに似ています。

于 2012-08-19T20:58:00.450 に答える
0

Windows Azure Service BusTopicsには、注目すべき別のソリューションがあります。そして、実際にはセンサー/デバイスからのデータについて話しているので、MSDN Magazine の Clemens Vasters の記事を読むことをお勧めします: Using Windows Azure Service Bus for ... Things!

ここに画像の説明を入力

オンで、データベースに非正規化して保存することについて話している. 代わりに Table Storage を使用しないのはなぜですか?

于 2012-08-19T20:01:38.780 に答える