我正在开发一个接受 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'的当前值不等于它之前的值（值已经改变了）。执行事件Z
我发现随着输入数量的增加以及规则数量的增加，评估“特定”规则并确定是否应触发事件所需的总计算量正在失控 - 投掷问题上更快和更多的硬件没有按预期扩展。
目前，在每次新的输入更新时，都会在哈希表中查找相关的输入/变量，该哈希表将变量映射到包含它的规则。随后对这些规则中的每一个进行评估，如果结果为真或可操作，则异步触发相关事件。
这个问题属于复杂事件处理领域，不幸的是，该领域中的大多数架构都使用上述相同的死机方法 - 可能对评估/重新评估事物的频率进行了一些改进。我们的想法是拥有一个可以近乎实时地做出反应的系统。将规则和输入分布在多个节点上似乎也效果不佳，因为在某些情况下，超过 95% 的活动规则中存在少数输入。
我希望如果那里有任何 SO'ers，知道更好的方法来解决这个问题，数据/结构或算法。
我想到的一个简单想法是可以构建一个依赖逻辑推理的列表。
如果有两个这样的规则：
Rule[a < b] --> [exec E1]
Rule[b >= a] --> [exec E2]
然后对“a”或“b”的更新不应该需要对两者进行评估，但我发现构建这样的逻辑推理结构非常复杂且容易出错，并且难以完全和严格地测试。
输入可以代表股票价格、温度传感器等。
进一步说明，一些输入是暂时受限的，这意味着该规则可能要求变量的状态在一段时间内处于特定位置/状态（例如：MSFT 的价格在过去 30 秒内 > 20 美元），目前，这是通过使用值为 0 或 1 /false 或 true 的“表示变量”（外观）来完成的（变量的值由单独的机制确定，这通常是触发规则的结果）。
还应该注意的是，由于近乎实时的限制和每秒产生的数据量，使用带有触发器和存储过程的数据库的选项是不可能的。