私は実際に1つを完了しましたが、よく研究された、おそらく学術的なアルゴリズムと私のものを比較したいと思いました。直接または組み合わせて私の特定のニーズを解決する統計オブジェクトのライブラリがあるかもしれません。
私のシステム（OpenSourceを使用する予定です）には、NetFlowデータのストリームがあります。データベースに保存してSQL関数を使用するよりも、データベースのないシステムを使用して一連の統計を維持し、新しいフローごとに更新し、1秒あたり（またはそれ以上）にスクロールすることを好みます。
私のソリューションには、秒、分、時間、日、週などを表すサイズ[60、59、23、6、...]のジャグ配列を効果的に作成するためのuintの単一配列が含まれます。
各スロットには、その時間の合計バイト数が含まれています。したがって、60秒後、1分間の統計がAvg（seconds）として作成されます。もちろん、これは比較的時間スケールで継続します。
単に数千秒の増分があるのではなく、次の理由によるものです。
- メモリの制約と、より多くの統計ノードを持つ可能性。と
- ユーザーへの理想的なプレゼンテーション
...タイムスケールをロールアップします。
フローが統計の階層内の複数のノード（WANリンク、IPアドレス、宛先アドレス、SourcePort-DestinationPort）に適用される可能性があることを考えると、デルタを1回計算して（GenerateDelta）、アクティブであるすべてのノードに適用するだけです。これはフローメタデータと一致します。
次の潜在的なケースでは、特定のノードの統計が「スクロール」されます。
- 読み取り/表示時（HTTP \ JSON AJAXリクエスト経由）
- デルタが適用されているとき（関連するフローのため）
- 単にn秒ごと（nは通常1）
全体として、時間の経過とともに（秒、分などで）実行中の合計を維持するための十分に確立されたアルゴリズムがある可能性があります。しかし、それに失敗すると、私のコードのより小さなサブセクションで比較するための適切なアルゴリズムもあるかもしれません：
- GenerateDelta-これは、統計配列のスロット全体の期間でフローを分解および平均化するために固有であるため、可能性は低いです。
- スクロール-秒しかない場合、これはもちろん簡単ですが、私のソリューションでは、60秒を60秒ごとに新しい分の合計に結合する必要があります。
レスポンダーが独自のアルゴリズムを提案することを望んでいません。私はすでに（ほぼ）すべてのアルゴリズムを問題なく完了し、多くのパフォーマンスを考慮しています。そして、私がオープンソースとして公開し終えたときに、他の人が私のアルゴリズムを見ることができるでしょう。
私が見たいのは、比較のための「十分に確立された」アルゴリズムです。おそらく私のものは良くなるでしょう、おそらく私のものは悪くなるでしょう。グーグルはこの種の質問が得意ではありません、私はあなたの助けが必要です。
ありがとう！