Drools，查阅大量历史记录的最佳做法是什么

如何解决Drools，查阅大量历史记录的最佳做法是什么

您好，我遇到了以下问题，我想知道 Drools 是否为我提供了处理它的选项。

我有一个 200k 的工单，我想将它与过去 30 天 (900k) 的所有工单进行比较，并确定是否满足一组条件。

问题是应用 DROOLS 的最佳方法是什么：

1- 我必须从 BD 获取最近 30 个带有服务的工单，然后将其提供给 Drools 进行比较。

2- 规则 (DRL) 内是否有任何方法可以获取该客户最近 30 天的工单。

解决方法

我会使用数据库来提取您应用自定义逻辑所需的最少信息，并最终编写一系列规则来应用您的业务领域。

数据库提取数据的速度肯定会更快，但如果您需要由非技术用户编写这些规则，或者您有很多业务逻辑，您可能会发现使用 DRL 编写业务逻辑有一些优势。

,

类似于 spark + HBase + java streams
我们有一个非常有趣的项目来重写大约 40 条驻留在 Oracle DB 深处的 SQL 规则，并将其作为可爱的 DSL 规则暴露给业务部门。
生产者正在扫描当天事务 ID 的 HBase 索引，并将该批次通过 Kafka 传递到集群火花处理应用程序，该应用程序对每个执行规则执行任何所需的历史查找（在该流上运行规则）并将结果发送到消费者应用程序它将结果持久化回 Oracle。生产者和处理器应用在使用 4 台机器（每台 40 个 CPU）的 Spark 集群上运行，消费者是顺序 Spring 应用。
原始 SQL 规则是大约 50-100 行业务噩梦，整个批处理在工作日开始前在 Oracle DB 上执行大约 20-40 分钟。我们做了 7-8 分钟。在结果表中产生完全相同的输出。分布式团队~项目期间平均7人，一年左右完成。
我们面临的问题：每条规则都令人头疼，因为每条业务规则逻辑都非常依赖于数据结构。您必须在生成历史数据时预先填充索引表（Oracle 通常为您做的工作）。您必须以流的形式处理数据，因为数据量是 TB。
为什么可能：HBase get by id 操作非常快。代码在数据所在的位置传输，而不是像传统应用程序那样（任何 map-reduce 集群解决方案的主要想法）。高并行度和巨大的处理能力可以完成它们的工作。您始终处理数据流，而不依赖于任何扫描结果的大小。
在实践中，我们有规则来过滤不相关的事务，然后在 drools 中使用 java 方法，然后阻止正在进行实际历史扫描和处理的块。那个java历史查找方法被表示为具有业务意义的DSL语句。历史查询的结果直接发送给消费者，或者您可以在该数据流之上编写另一条规则。