How well does Rule Engines work?
I've looked at the WF Rules Engine and NxBRE and it seems interesting, but I'm not sure how much it will work in real-world scenarios.
What I mean is something like a fact base of 10 to 100 million facts and rules such as:
Object.Field <5000 AND Object.Field> 1000 AND IsProperty (Object.Field2)
I am using C # and .NET.
Edit: I don't explain (entirely my fault) :) I have my own rule scoring system that uses the RETE algorithm itself ... it's pretty fast, it can estimate 10 million scenario facts in about 10 seconds ... how fast is commercial solutions in comaparison?
source to share
Short answer: I would expect the rules engine to outperform the imperative decision once the number of rules exceeds the threshold (I don't know the exact value).
The rules part of the rule engine specifies conditions and actions. The only rule is (almost) functionally equivalent to the if-then statement. The real power of the rule engine shines through the declarative nature of the engine.
In a traditional imperative program, you have to code how the logic is evaluated. When using the rules engine, it determines how many of your operators are evaluated. I've only used engines like Jess or CLIPS that use the rete algorithm to figure out which rules should fire. This is the efficiency of your rules triggering algorithm, which will control how efficiently your rules engine will perform over a traditional imperative decision.
The Rete algorithm is designed to sacrifice memory to increase speed. It maintains a network of nodes matching LHS patterns to rules. The more rules and facts you have, the better your network will outperform your imperative decision, since Rete's performance is theoretically independent of the number of rules in the system.
You are planning a lot of facts. If you plan on having a lot of rules, you may run into memory problems.
Take a look at Martin Fowler's article on engine rules . This is a good and (very) short overview.
There is a lengthy discussion on Microsoft Business Rules Engine (MS-BRE) and its performance compared to Jess and Drools. Some of the questions raised highlight why these assessments are difficult.
source to share
The "rumor that this is not a valid rete implementation" refers to an age-old problem with the claim that the business rules engine included in BizTalk Server failed to correctly implement the Rete algorithm. By the way, the statement was wrong. BRE certainly implements Rete. The WF rules engine is a completely different technology for BRE. As Carl says, WF's rule engine doesn't implement Rete at all, right or wrong. This is an example of what can be roughly called a "sequential" engine. It implements the form of a forward chain. However, the real problems are a little more complicated than that. The forward bit is the type of logic that the engine can do. This term doesn't really tell you anything about the mechanisms involved at runtime. The real problem ishow good is an engine for reasoning. Yes, WF can forward the chain, and yes, that can be the reason, but only in very limited ways. The Rete engine offers stronger reasoning, but it really has nothing to do with using the Rete algorithm, which is really just an optimization for a certain class of rules called a "production" system. This has to do with how a manufacturing system can reason on a whole "fact base", whereas a WF sequential rule engine can only reason on the rough equivalent of a single fact. Problems sometimes arise because people confuse a certain run-time mechanism that allows chaining to be chained with the logical process of straight chaining (and it's a pretty subtle distinction after all).The corresponding mechanism in WF can certainly be used to reason in "forward" order to a limited extent, but its main use is to allow sequential rules in a semi-declarative manner, i.e. Rules can be expressed in any sequence regardless of the procedural dependencies between these rules. This has nothing to do with forward reasoning, or indeed the obscure process of a straight chain.This has nothing to do with forward reasoning, or indeed the obscure process of a straight chain.This has nothing to do with forward reasoning, or indeed the obscure process of a straight chain.
The problem is a bit tricky and obscure, and I know some of the MS guys disagree with me on this (we've discussed this quite often), but I accept that.
source to share
One thing to be aware of is that the WF rules engine is that it actually implements its own parser and, as a result, is somewhat limited in its expressiveness and has performance considerations as it pretty much does the syntactic parsing strings interpret rules in code (executable actions) at runtime.
source to share
We ran 24 million tests of 1500 rules in seven minutes using JBoss Drools with two JVMs running on good midrange servers. That's over thirty-six billion tests that will run if you run each combination, and most tests have multiple logical variations in them. (For example, your example has three options.)
source to share
you will also need to consider how the data is passed into your rules engine, for example, once the rules start to fire and some rules make calls to the DB, then it will certainly have performance issues. the best practice is to provide all the data necessary to comply with the rule at the outset, although this also has some disadvantages.
source to share