私はWFルールエンジンとNxBREを調べてきましたが、それは面白そうですが、実際のシナリオでどれだけうまく機能するかはわかりません。
私が念頭に置いているのは、1,000万から1億のファクトとルールを持つファクトベースのようなものです。
Object.Field <5000 AND Object.Field> 1000 AND IsProperty（Object.Field2）
私はC＃と.NETを使用しています。
編集：私は自分自身を明確にしていません（完全に私のせいです）:)私はRETEアルゴリズム自体を使用する独自のルール評価システムを持っています...それは非常に高速で、約10秒で1000万のファクトシナリオを評価できます。 ..比較における商用ソリューションの速度はどれくらいですか？
簡単な答えは、ルールの数がいくつかの（正確な値はわかりません）しきい値を超えると、ルールエンジンが命令型ソリューションよりも優れていると期待するということです。
ルール エンジンのルール部分は、条件とアクションのセットです。単一のルールは、if - then ステートメントと (ほぼ) 機能的に同等です。ルール エンジンの真の力は、エンジンの宣言的な性質によって発揮されます。
従来の命令型プログラムでは、ロジックを評価する方法をコーディングする必要があります。ルール エンジンを使用すると、評価されるステートメントの数が決定されます。私はJessやCLIPSなどのエンジンのみを使用しました。これらはrete アルゴリズムを使用して起動するルールを決定します。ルールエンジンが従来の命令型ソリューションよりもどれだけ効率的に実行されるかを左右するのは、ルール起動アルゴリズムの効率です。
Rete アルゴリズムは、高速化のためにメモリを犠牲にするように設計されています。LHS 側のパターンをルールにマッピングするノードのネットワークを維持します。Rete のパフォーマンスは、理論的にはシステム内のルールの数とは無関係であるため、ルールと事実が多いほど、rete ネットワークのパフォーマンスは命令型ソリューションよりも優れています。
あなたは多くの事実を計画しています。多数のルールを作成する場合は、メモリの問題が発生する可能性があります。
ルール エンジンに関する Martin Fowler の記事をご覧ください。これは優れた (非常に) 短い概要です。
Microsoft Business Rules Engine (MS-BRE) については、Jess & Drools と比較したパフォーマンスについて長い議論があります。提起されたいくつかの点は、これらの評価が難しい理由を強調しています。
「忠実な rete 実装ではないという噂」は、BizTalk Server に含まれるビジネス ルール エンジンが Rete アルゴリズムを正しく実装できないという主張に関する古い問題を指しています。ちなみに、主張は間違っていました。BRE は確かに Rete を実装しています。WF ルール エンジンは、BRE とはまったく異なるテクノロジです。Karl が言うように、WF ルール エンジンは、正しくても正しくなくても、Rete をまったく実装していません。これは、大まかに「シーケンシャル」エンジンと呼ぶことができるものの例です。これは、フォワード チェーンの形式を実装します。ただし、実際の問題はこれよりも少し複雑です。「前方」ビットは、エンジンが実行できる論理推論のタイプを指します。この用語は、実行時に関与するメカニズムについて実際には何も伝えていません。本当の問題は、エンジンがどれだけ推論できるかということです。はい、WF はフォワード チェーンが可能であり、推論も可能ですが、非常に限られた方法でしかありません。Rete エンジンはより強力な推論機能を提供しますが、これは実際には、「プロダクション」システムと呼ばれる特定のクラスのルール エンジンの最適化である Rete アルゴリズムの使用とは関係ありません。これは、プロダクション システムが「ファクト ベース」全体を推論できる方法に関係していますが、シーケンシャル WF ルール エンジンは、単一のファクトに相当する大まかな内容を直接推論することしかできません。フォワード チェーンを可能にする特定のランタイム メカニズムと、フォワード チェーン自体の論理プロセスを混同する人がいるために、問題が発生することがあります (結局のところ、これは非常に微妙な違いです)。WF の関連するメカニズムは、確かに限られた範囲で「フォワード」方式で推論するために使用できますが、その主な用途は、一連のルールを半宣言的な方法で表現できるようにすることです。つまり、ルールは任意のシーケンスで表現できます。これらのルール間の手続き上の依存関係に関係なく。これは、前方推論や、実際には前方連鎖の論理的プロセスとは何の関係もありません。
この問題は少し複雑で曖昧であり、MS の何人かがこれについて私に同意しないことは知っています (私たちは十分に議論してきました) が、それが私の見解です。
JBoss Droolsを使用し、平均的なサーバーで 2 つの JVM を実行して、1,500 のルールで 2,400 万のテストを 7 分間で実行しました。すべての組み合わせを実行すると、360 億以上のテストが実行され、ほとんどのテストには複数のロジックの選択肢があります。（たとえば、あなたの例には3つの選択肢があります。）
注意すべきことの 1 つは、WF ルール エンジンは実際には独自のパーサーを実装しているため、ルールを解釈するためにほとんど文字列の解析を行っているため、表現力が多少制限され、パフォーマンスに関する考慮事項があることです。実行時にコード (実行可能なアクション) に変換します。
you would also have to consider how the data is passed into your rule engine, like once the rules starting to fire , and some rules makes calls to a DB , then surely it will have performance issues. the best practice is to give all the data needed for rule execution at the start itself , though this has some cons too.