2016-06-01 3 views
-2

100クライアントから30秒ごとにデータを受信し、データをデータベースに格納するC#.netアプリケーションを実行します。データは各クライアントの2つのパラメータ用です。私は時間ごとに各クライアントのために、各パラメータの合計を決定し、その結果に基づいて決定を下す必要があります。決定アルゴリズムは、1時間分のデータをスライディングウィンドウ形式で決定することになります。私の最初の考えは、キーがクライアントIPであり、値が稼働中の合計であるこれらの100のクライアントの辞書を保持することです。しかし、1)私のアプリが1時間または分59の途中で再起動した場合、それらのすべての暖かい稼働合計が失われます。 2)より多くのクライアントがデータを送信し始めると、辞書はより多くのメモリを消費する、3)将来2つのパラメータが100になると、辞書はさらに大きくなる4)実行中の合計値は常に1時間分最近のデータを反映する簡単。受信ストリームから時間の経過とともに値を計算する最も良い方法は何ですか

私は考慮すべきアプローチがありますか?ベストプラクティス?デザインパターン?

+2

これは非常に幅広いですが、ここでは2つのセントがあります:データベースにデータを格納し、クライアントのIPが非常に悪い考え方です.2つの異なるクライアントが同じ外部IPを持つことができますナット、他)。 2の場合、クライアント側でGUIDを生成してクライアントに格納すると、クライアントが接続してそのIDを送信すると、同じマシン上に複数のクライアントを持つことができるように、各クライアントを明白に識別します。 – Gusman

+0

ありがとうございます。 IPは私が同意した悪い考えです。私はGUIDを使用します。データベースの格納に関しては、着信データが到着したときに格納します。意思決定ロジックは、保存前のデータで実行されます。または、意思決定ロジックをデータベースから定期的に取り除くことを意味し、保存しましたか?私はそれを回避しようとしていたので、DBの読み取りと定数書き込みでうまく動作しない可能性があります。 – sOltan

+0

はい、私は格納されたデータの間隔でそれを実行することを意味しました。パフォーマンスについては、クライアント数は100、クライアント数は2番目に多いと思われます。実際のdbは、毎秒何千もの書き込みをサポートするのに十分速く動作するので、トランザクションの量に応じて、十分に速くてもいなくてもよい。 – Gusman

答えて

0

非常に広いが、私は構造を定義しようとします:

  1. は、順次8バイトの整数、UIDと各クライアントを識別します。 GUIDではなく、順次GUIDでもありません。 4バイト整数はオプションですが、私は8バイトに固執します。シードから100,000。

  2. 連続した8バイトの整数、CIDを持つユーザからの各コールを識別します。 GUIDではなく、順次GUIDでもありません。 4バイト整数はオプションですが、私は8バイトに固執します。私はCIDとして1970-01-01T00:00:00から数マイクロ秒を要します。

  3. すべてのデータをアーカイブデータベーステーブルREPORT_ARCHIVEに格納します.UID + CIDは複合PKです。クラスタテーブルをCIDハッシュで作成すると、1つ1つのファイル/複数の録画ファイルが1つのファイルにまとまってしまいます。

  4. 運用データベーステーブルREPORT_OPERの最後のN個のレコードを保存します(Nは時間枠に依存し、設定値にする必要があります).UID + CIDは複合PKです。 UIDハッシュのクラスタ(8-16ファイル)。

  5. あなたが着信するすべてのデータを、キューのようなメモリ構造でパイプラインします。非同期処理エージェントは、キューからレコードを取得する必要があります。 DBチャンク(SQLサーバーとOracleのサポート)を使用してチャンクを集め、DBに保存します。 REPORT_OPERテーブルに保存し、INSERTのトリガを設定してREPORT_OPERからREPORT_ARCHIVEにデータをプッシュします。

  6. REPORT_OPER(総計など)に対してすべての作業クエリを実行すると、分析はREPORT_ARCHIVEで実行されます。

  7. 最後のXレポートのSUMのようなものは、UIDをキーとしてメモリ内のSUMをConcurrentDictionaryにキャッシュします。重要:インサートコール(30秒間隔でのユーザコール)ではなく、要求に応じたコール(管理者は合計を求める)。そのためには、SLAに合意する必要があります。これは、報告された合計に受け入れられる遅延です。クライアントがリアルタイムに近い状態を望む場合、キャッシュヒット/ミスを計算するためにコールの頻度をネゴシエートします。

幸運。

関連する問題