【问题标题】:Out of Core Rules Engine超出核心规则引擎
【发布时间】:2011-09-12 19:12:16
【问题描述】:

是否有运行out of core 的生产规则系统的实现?

我已经检查了像 CLIPSJess 这样的开源实现,但它们只在内存中运行,因此在处理大量事实和规则时它们往往会崩溃或强制进行大量磁盘交换(例如在数十亿/万亿)。

我正在考虑使用 Django 的 ORM 将一个简单的规则引擎(例如 Pychinko)移植到 SQL 后端。但是,支持 CLIPS 中的功能级别将非常重要,我不想重新发明轮子。

有没有其他方法可以扩展生产规则系统?

【问题讨论】:

  • “是否有任何替代方案可以扩展生产规则系统?”是的,更多内存!
  • 给一个算法一些额外的内存并修复它一天。将算法更改为不使用 RAM 并永久修复。
  • 我的评论当然是开玩笑的。我只是不知道你的问题的答案。
  • 愚蠢的问题,但是您到底是如何管理/定义数十亿和/或数万亿条规则的呢?

标签: python machine-learning rules rule-engine


【解决方案1】:

您可以查看JENA 和类似的 RDF 规则引擎,这些引擎设计用于处理非常大的事实数据库。

【讨论】:

  • Jena 将其规则存储在内存中。据我所知,所有 RDF 规则引擎都是一样的。大型事实数据库!= 超出核心规则。
【解决方案2】:

这不是对您问题的直接答案,但它可能会为您提供针对问题的攻击线。

早在 80 年代和 90 年代,我们部署了一个信息检索系统,该系统允许大量常规查询。具体来说,我们的系统具有 64MB 内存(当时是buttload)每天接收超过一百万条消息,并对该流应用 10,000 到 100,00 多个常设查询。

如果我们所做的只是针对最近的文档迭代地应用每个常设查询,我们将是死肉。我们所做的是执行一种inversion 的查询,特别是在查询中识别must havemay have 项。然后,我们使用文档中的术语列表来查找那些有任何成功机会的查询。客户学会了创建具有强大差异化的查询,因此,有时只需对 10 或 20 个查询进行全面评估。

我不知道您的数据集,也不知道您的规则是什么样的,但您可以尝试类似的方法。

【讨论】:

    猜你喜欢
    • 2017-11-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-12-26
    • 2010-10-23
    • 2017-11-10
    • 1970-01-01
    相关资源
    最近更新 更多