私は100k以上の一意の入力を受け入れるアプリケーションに取り組んでいます-簡単にするために、各入力が浮動小数点値（a、b、c ...など）であると仮定します-ただし、文字列などでもかまいません。アプリケーションには多くのルールがあります/これらの入力に関連するイベント/トリガー。
例1:
Rule[(a > b) and (c <= d)] --> [execute EventX]
定義 1:上記のルールは次のように述べています。
例 2:
Rule[x != x.prev] --> [execute EventZ]
定義 2:上記のルールは次のように述べています。値の更新後、入力 'x' の現在の値が以前の値と等しくない (値が変更された) EventZ を実行する
私が見つけたのは、入力の数が増加し、ルールの数が増加するにつれて、「特定の」ルールを評価し、イベントをトリガーする必要があるかどうかを判断するために必要な計算の総量が制御不能になっていることです-Throwingより速く、より多くのハードウェアを問題に使用しても、期待どおりにスケーリングされません。
現時点では、新しい入力が更新されるたびに、関連する入力/変数が、変数をそれを含むルールにマップするハッシュ テーブルで検索されます。その後、これらの各ルールが評価され、結果が true またはアクション可能である場合、関連するイベントが非同期でトリガーされます。
この問題は複雑なイベント処理の領域にあります。残念ながら、この領域のアーキテクチャのほとんどは、上で説明したのと同じデッドヘッド アプローチを使用しています。おそらく、物事が評価/再評価される頻度に関連するいくつかの改良が加えられています。アイデアは、ほぼリアルタイムで反応できるシステムを持つことです。いくつかの状況では、少数の入力がアクティブなルールの 95% 以上に存在するため、ルールと入力を複数のノードに分散することもうまく機能していないようです。
この問題、データ/構造、またはアルゴリズムを解決するためのより良い方法を知っている仲間のSO'erがそこにいることを望んでいました。
私が念頭に置いている単純なアイデアは、従属論理推論のリストを構築できるということです。
そのような2つのルールがある場合:
Rule[a < b] --> [exec E1]
Rule[b >= a] --> [exec E2]
次に、「a」または「b」のいずれかの更新で両方の評価が必要になることはありませんが、そのような論理推論構造の構築は非常に複雑でエラーが発生しやすく、完全かつ厳密にテストするのが難しいことがわかりました。
入力は、株価、温度センサーなどを表す可能性があります。
さらに注意してください。入力の一部は時間的に制約されています。つまり、ルールでは、変数の状態が一定時間特定の位置/状態にある必要がある場合があります (例: 過去 30 秒間の MSFT の価格 > 20 ドル)。現在、これは 0 または 1 /false または true のいずれかの値を持つ「表現変数」(ファサード) を使用して実現されています (変数の値は別のメカニズムによって決定され、通常はトリガーされたルールの結果です) ）。
また、ほぼリアルタイムの制約と 1 秒あたりに生成されるデータ量のために、トリガーとストアド プロシージャを備えた DB を使用するオプションは問題外であることに注意してください。