处理大量规则（条件和约束）CEP 系统答案

【问题标题】：Dealing with massive number of Rules (conditions and constraints) CEP systems处理大量规则（条件和约束）CEP 系统
【发布时间】：2012-04-16 01:48:23
【问题描述】：

我正在开发一个接受 100k+ 唯一输入的应用程序——为简单起见，我们假设每个输入都是浮点值（a、b、c...等）——尽管它们也可以是字符串等。应用程序有许多与这些输入相关的规则/事件/触发器。

示例 1：

Rule[(a > b) and (c <= d)] --> [execute EventX]

定义1： 上面的规则说：当输入'a'的值大于'b'的值并且输入'c'的值小于或等于' d' 执行 EventX

示例 2：

Rule[x != x.prev] --> [execute EventZ]

定义2： 上面的规则说：如果在一个值更新之后，如果输入'x'的当前值不等于它之前的值（值已经改变了）。执行 EventZ

我发现随着输入数量的增加以及规则数量的增加，评估“特定”规则并确定是否应该触发事件所需的总计算量正在减少控制 - 在问题上投入更快和更多的硬件并没有按预期扩展。

目前，在每次新的输入更新时，都会在哈希表中查找关联的输入/变量，该哈希表将变量映射到包含它的规则。随后对这些规则中的每一个进行评估，如果结果为真或可操作，则异步触发相关事件。

这个问题属于复杂事件处理领域，不幸的是，该领域中的大多数架构都使用上述相同的死机方法 - 可能对评估/重新评估事物的频率进行了一些改进。我们的想法是拥有一个可以近乎实时地做出反应的系统。将规则和输入分布在多个节点上似乎也效果不佳，因为在某些情况下，超过 95% 的活动规则中存在少数输入。

我希望是否有任何其他 SO'ers 知道解决此问题的更好方法、数据/结构或算法。

我想到的一个简单想法是可以构建一个依赖逻辑推理的列表。

如果有两条规则是这样的：

Rule[a < b] --> [exec E1]
Rule[b >= a] --> [exec E2]

那么“a”或“b”的更新不应该需要对两者进行评估，但我发现构建这样的逻辑推理结构非常复杂且容易出错，并且难以完全和严格地测试。

输入可以代表股票价格、温度传感器等。

进一步注意，一些输入是暂时受限的，这意味着该规则可能要求变量的状态在一段时间内处于特定位置/状态（例如：MSFT 的价格 > 20 美元最后30 秒），目前这是通过使用值为 0 或 1 /false 或 true 的“表示变量”（外观）来完成的（变量的值由单独的机制确定，这通常是规则被触发）。

还应注意，由于近乎实时的限制和每秒产生的数据量，使用带有触发器和存储过程的数据库的选项是不可能的。

【问题讨论】：

您是否对此进行了分析以确定瓶颈在哪里？是在选择需要评估的规则吗？还是在事件的实际评估和触发中？
@JimMischel：规则的评估将花费特定的时间 - 诀窍是对给定的一组输入更新执行最少/最少数量的评估。简而言之，是的，我们已经分析了代码，这显然不是与代码相关的效率问题（过多的副本、冗余的 oop 结构等），请注意问题中，我提到事件是异步触发的，他们不是有问题的瓶颈。
你还没有说是的瓶颈。仅仅因为您异步触发事件并不意味着它们不是问题。你是说对规则的评估是问题吗？您确定问题是由于对冗余规则的评估造成的？

标签： c++ algorithm data-structures rule-engine complex-event-processing

【解决方案1】：

几个想法。

如果您的规则的条件是连词，请为每个未满足的条件维护一个未满足的项。仅将规则放在该术语的检查列表中。如果该术语得到满足，请扫描其他术语以确定是否触发了条件或存在另一个未满足的术语。（我想我是在 SAT 求解器的背景下了解到这个技巧的。）

如果您有 10 interval tree 而不是散列快速找到对 x 的更新将变得不满意的满意术语和即将更新的不满意术语变得满意。（完全搜索 O(log n)，加上每个返回结果的 O(1)。）如果一次考虑一个变量会产生太多虚假命中，则存在多维泛化，但维护成本会更高。

如果您没有类似的术语（例如，a

【讨论】：

一些非常有趣的想法，我有一个问题，打破基于连词的规则的问题是你最终会得到更多的表达式来评估，至少在它们的原始形式中，很长复杂的表达式可能很容易被短路——当你分解表达式时，你就会失去这种能力。

【解决方案2】：

尝试分解常用表达式，对它们进行分组和缓存：这可能会加快速度，尤其是那些最常用的表达式，因此性能可能会提高。

这是否可行，取决于您在表达逻辑时必须使用的语言。我看到您的流程可以建模为电子表格的可能性，其中计算是数据驱动程序。 WRT 单元格引用的一种拓扑类型的公式足以进行基本评估，但事情很快就会变得复杂......

在 C++ 中，您可以尝试使用模板表达式来解决您的逻辑问题。为您的语言建模的助手可能是 Boost.proto

ETALIS 在 Prolog 中执行 CEPS。

我（还）没有尝试过（唉），但我相信它非常好。并且肯定会实现您所追求的，甚至更多。

在 SWI-Prolog 中运行，应该是可访问的，易于设置和操作，SWI-Prolog C++ 接口对于实际数据交换非常方便。

【讨论】：

etalis 等人有同样的问题，我不是要求另一个解决这个问题的软件包，我要求的是可以用来解决这个问题的新想法/策略有效率的。此外，我不确定像 proto 这样的编译时解决方案与这里的相关性。
您似乎已经尝试过这些替代方案！我对此表示赞赏。但我相当确定 ETALIS 不会使用你一开始引用的这种脑死亡策略......并且分解代码是一种元语言优化，不太容易做到正确......
因式分解需要对规则与输入/变量进行依赖分析，这种依赖分析的问题是循环依赖的问题，以及发现互斥状态的问题。

【解决方案3】：

在多个节点上分配规则和输入似乎并不也可以很好地工作，因为在某些情况下，少数输入存在于超过 95% 的活动规则。

分发规则，并将输入提供给所有机器。然后您可以线性扩展规则的数量...如果您在 LAN 上，您可以将事件/输入作为多播发送，因此网络流量不会增加。

【讨论】：