规则引擎的性能如何？
我一直在查看WF规则引擎和NxBRE 看起来很有趣，但我不确定它在现实生活场景中的表现如何。
我想到的是一个事实库，包含 10 到 1 亿个事实和规则，例如：
Object.Field < >第5000章 5000 1000 AND IsProperty(Object.Field2)
我正在使用 C# 和 .NET。
编辑：我还没说清楚（完全是我的错）:)我有自己的规则评估系统，它使用RETE算法本身......它相当快，它可以评估1000万个大约 10 秒内的事实场景...比较商业解决方案的速度有多快？
I've been having a look at WF Rules Engine and NxBRE and it seems interesting but I'm unsure of how well it will perform in real life scenarios.
The one I have in mind is something like a fact base with between 10 and 100 million facts and rules like:
Object.Field < 5000 AND Object.Field > 1000 AND IsProperty(Object.Field2)
I'm using C# and .NET.
Edit: I haven't make myself clear (totally my fault) :) I have my own rule evaluation system that uses the RETE algorithm itself ... it is quite fast, it can evaluate the 10 million fact scenario in about 10 seconds... how fast are comercial solutions in comaparison?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
简而言之，一旦规则数量超过某个阈值（我不知道确切的值），我希望规则引擎的性能优于命令式解决方案。
规则引擎的规则部分是一组条件和操作。单个规则在功能上（几乎）等同于 if - then 语句。由于引擎的声明性，规则引擎的真正威力得以体现。
在传统的命令式程序中，您必须编写如何评估逻辑的代码。使用规则引擎时，它决定评估有多少语句。我只使用过 Jess 或 CLIPS ，它使用 rete 算法 来确定要触发的规则。规则触发算法的效率将决定规则引擎的执行效率比传统命令式解决方案高出多少。
Rete 算法旨在牺牲内存以提高速度。它维护一个将 LHS 侧模式映射到规则的节点网络。更多规则&您掌握的事实越多，您的 rete 网络的性能就越优于您的命令式解决方案，因为理论上，Rete 性能与系统中的规则数量无关。
你正在计划很多事实。如果您打算制定很多规则，则可能会遇到内存问题。
请参阅 Martin Fowler 关于规则引擎的文章。这是一个很好且（非常）简短的概述。
有一个冗长的讨论 在 Microsoft 业务规则引擎 (MS-BRE) 上及其与 Jess & 的性能比较流口水了。提出的一些观点强调了为什么这些评估是困难的。
The short answer is I would expect a rules engine to outperform an imperative solution once the number of rules exceeds some (I don't know the exact value) threshold value.
The rules part of a rules engine is set of conditions and actions. A single rule is (nearly) functionally equivalent to an if - then statement. The real power of a rules engine shines through due to the declarative nature of the engine.
In a traditional imperative program, you have to code how the logic is evaluated. When using a rules engine, it determines how many of your statements are evaluated. I have only used engines like Jess or CLIPS, which use a rete algorithm to figure out which rules to fire. It is the efficiency of your rules firing algorithm that is going to drive how much more efficient your rules engine will perform over a traditional imperative solution.
The Rete algorithm is designed to sacrifice memory for increased speed. It maintains a network of nodes mapping LHS side patterns to rules. The more rules & facts you have, the better your rete network will outperform your imperative solution, because Rete performance is theoretically independent of the number of rules in the system.
You are planning on a lot of facts. If you plan to have a lot of rules, you may run into memory problems.
Take a look at Martin Fowler's article on rules engines. It's a good and (very) short overview.
There is a lengthy discussion on the Microsoft Business Rules Engine (MS-BRE) adn it's performance compared with Jess & Drools. Several of the points raised underscore why these evaluations are hard.
“关于它不是忠实的 rete 实现的谣言”指的是一个古老的问题，该问题涉及 BizTalk Server 中包含的业务规则引擎无法正确实现 Rete 算法的说法。顺便说一下，这个说法是不正确的。 BRE 当然实现了 Rete。 WF 规则引擎是与 BRE 完全不同的技术。正如 Karl 所说，WF 规则引擎根本没有实现 Rete，无论是正确还是错误。这是一个可以宽松地称为“顺序”引擎的示例。它实现了一种前向链接的形式。然而，真正的问题比这更复杂一些。 “前向”位指的是引擎可以执行的逻辑推理类型。该术语并没有真正告诉您有关运行时所涉及的机制的任何信息。真正的问题在于引擎的推理能力如何。是的，WF 可以前向链，也可以推理，但只能以非常有限的方式进行。 Rete 引擎提供了更强的推理能力，但这实际上与 Rete 算法的使用无关，Rete 算法实际上只是对称为“生产”系统的某一类规则引擎的优化。它与生产系统对整个“事实库”进行推理的方式有关，而顺序 WF 规则引擎只能直接对单个事实的粗略等价物进行推理。有时会出现问题，因为人们混淆了支持前向链接的特定运行时机制与前向链接本身的逻辑过程（毕竟，这是一个非常微妙的区别）。 WF中的相关机制当然可以在有限的范围内以“前向”方式进行推理，但其主要用途是允许以半声明方式表达顺序规则——即规则可以以任何顺序表达无论这些规则之间的程序依赖性如何。这与前向推理或前向链接的局部过程无关。
这个问题有点复杂和晦涩，我知道 MS 的一些人在这一点上不同意我的观点（我们已经讨论过很多次了），但这就是我的看法。
The "rumor that it's not a faithful rete implementation" refers to an ancient issue concerning a claim that the Business Rule Engine included with BizTalk Server fails to implement the Rete algorithm correctly. The claim was incorrect, by the way. The BRE certainly does implement Rete. The WF rules engine is a totally different technology to the BRE. As Karl says, the WF rules engine does not implement Rete at all, either correctly or incorrectly. It is an example of what can loosely be termed a 'sequential' engine. It implements a form of forward chaining. However, the real issues are a bit more complex than this. The 'forward' bit refers to the type of logical reasoning that an engine can do. The term is not really telling you anything about the mechanisms involved at runtime. The real issue is about how good an engine is at reasoning. Yes, WF can forward-chain, and yes it can reason, but only in quite limited ways. A Rete engine offers stronger reasoning capabilities BUT this is actually nothing to do with the use of the Rete algorithm which is really just an optimisation for a certain class of rule engine called a 'production' system. It is to do with the way a production system can reason over a whole 'fact base' whereas the sequential WF rule engine can only directly reason over the rough equivalent of a single fact. Problems sometimes arise because people confuse a particular runtime mechanism that enables forward chaining with the logical process of forward chaining itself (and after all, that is quite a subtle distinction). The relevant mechanism in WF can certainly be used to reason in a 'forward' manner to a limited extent, but its primary use is to allow sequential rules to be expressed in a semi-declarative fashion - i.e., rules can be expressed in any sequence regardless of the procedural dependencies between those rules. That has nothing to do with forward reasoning or, indeed, the loical process of forward chaining.
The issue is a little complex and obscure, and I know some of the guys at MS don't agree with me on this (we've discussed it often enough), but that's my take on it.
我们使用 JBoss Drools 有两个 JVM，运行在非常普通的服务器上。如果运行每种组合，则需要运行超过 360 亿个测试，并且大多数测试都有多种逻辑选择。 （例如，您的示例有三个选择。）
We ran 24 million tests through 1500 rules in seven minutes using JBoss Drools with two JVMs running on pretty darn average servers. That's more than thirty six billion tests to be run if you ran every combination, and most tests have multiple logic choices in them. (Your example has three choices, for example.)
需要注意的一件事是，WF 规则引擎实际上实现了自己的解析器，因此其表达能力受到一定限制，并且确实有性能考虑，因为它几乎是在进行字符串解析来解释规则在运行时转换为代码（可执行操作）。
One thing to be very 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 does have performance considerations since it is pretty much doing string parsing to interpret the rules into code (executable actions) at runtime.
您还必须考虑数据如何传递到规则引擎中，例如一旦规则开始触发，并且某些规则调用数据库，那么肯定会出现性能问题。最佳实践是在开始时提供规则执行所需的所有数据，尽管这也有一些缺点。
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.