Drools 引擎和数据库的区别 [英] Difference between Drools engine and Database

问题描述

我正在浏览 Drools 文档，发现它没有做任何有趣的事情/解决任何问题(可能是我错了).

I was going through Drools documentation and found it is not doing anything interesting / solving any problems (May be I'm wrong).

在 drools 中，我们将业务规则(在 .drl 文件中)指定为，例如，

In drools we specify the business rules (in .drl file) as, for example,

  when "type = jewellery" then setDiscount(25%)
  when "type = KidDress" then setDiscount(30%) 

1. 以上与使用数据库的区别是什么?

1. What is the difference between the above vs using database?

我总是可以公开自定义 API，从中可以指定业务规则，我可以直接将其存储在 RDBMS 中.如果需要，我可以正式构建一个示例 UI(在 1-2 天内)，它与公开的 API 集成.如果我公开 CRUD 操作，这也将允许业务人员轻松添加/更新/删除规则.

I can ALWAYS expose custom API's from which business rules can be specified and I can directly store it in RDBMS. Formally if required, I can build a sample UI (in 1-2 days) which integrates with exposed APIs. This will also allow business people's to easily add/update/delete rules If I expose CRUD operations.

对于我解释的这么简单的事情，Drools 解决了什么问题?我在 g-search 的任何文档/官方文档中都找不到.

For something as simple as I explained, what problem is Drools solving? I cannot find in any documentation from g-search / in official documentation.

有人可以帮忙吗?

推荐答案

与 Karol 的回答相反，我也使用了 Drools，但我对它们的体验非常好.文档中的用例是有意简化的，但 Drools 还可以比数据库更有效地处理更复杂的用例.我知道这是一个事实，因为我使用约 140 万条规则维护的服务已转换为使用数据库(使用您提供的相同参数).从平均 30-100 毫秒响应查询，到需要 750 毫秒到超过 2 分钟的响应时间(我不知道多长时间，因为我们在 2 分钟后就超时了我们的查询.)

In contrast to Karol's answer, I also used Drools but I had an excellent experience with them. The use cases in the documentation are intentionally simplified, but Drools can also handle much more complex use cases more efficiently than a database. I know this for a fact, because a service that I maintained with ~ 1.4 million rules was converted to using a database (using the same arguments you presented). It went from averaging 30-100 ms to respond to a query, to taking 750ms to over 2 minutes to respond (how much longer I do not know because we timed out our queries after 2 minutes.)

这样做的原因是 Drools 允许我们实现跌倒"逻辑.在这种情况下，我的 140 万条规则用于确定住院患者是否需要其保险授权才能在医院完成手术.规则范围从非常普遍到非常具体；如果两个规则匹配输入数据，我们倾向于更具体的规则.如果特定医院或医院+保险组合具有自定义规则，则应用特殊用例.我们传递了我们所知道的关于患者的所有数据、他们的整个病史以及大量关于他们的保险的信息，然后规则决定了答案.

The reason for this was that Drools allowed us to implement "fall through" logic. In this case, my 1.4 million rules were determining if a hospital patient would need authorization from their insurance to have a procedure done at a hospital. The rules ranged from very general to very specific; if two rules matched the input data, we favored the more specific rule. Special use cases applied if a specific hospital or hospital+insurance combination had a custom rule. We passed all the data we knew about the patient in, their entire medical history, and a ton of information about their insurance, and then the rules decided on the answer.

想象一下这个有意简化的场景:

Imagine this intentionally simplified scenario:

rule "Car"
when
  Car() // very simple, I have a car
then
  setPrice(100)
end

rule "Red Car"
when
  Car( color == "red" ) // I have a red car
then
  setPrice(75)
end

rule "4-door Car"
when
  Car( doors == 4 ) // I have a 4-door car
then
  setPrice(200)
end

rule "Red Sedan"
when
  Car( color == "red", model == "sedan") // I have a red sedan
then
  setPrice(500)
end

rule "Blue 4-Door Discount"
when
  Car( doors == 4, color == "blue") // I have a blue 4-door car
then
  setPrice(150)
end

现在我们开始玩不同配置的 Car.黄色车，2门跑车只匹配第一条规则，价格为100.红色四门车匹配两条​​规则；价格是75还是200?取决于您如何编写规则以及设定价格"的作用；可能在我在这里写的规则中价格是 200.一辆蓝色轿车?100. 等等.

Now we start playing in different configurations of Car. A yellow car, 2-door sports car only matches the first rule and the price is 100. A red 4-door car matches two rules; is the price 75 or 200? Depends on how you've written your rules and what "set price" does; likely in the rules I've written here the price is 200. A blue sedan? 100. And so on.

如果我们将其转换为数据库表(为简单起见，单个表 Car 包含color"、model"和doors"列)，该查询会是什么样的?(我实际上不知道我没有设法编写一个足够的查询；我也不是 DBA.)

If we converted this into a database table (for simplicity, a single table Car with columns 'color', 'model', and 'doors'), what would that query look like? (I don't actually know I didn't manage to write a query that would suffice; I'm also not a DBA.)

我可以想出一整套示例，其中基于数据库的解决方案性能较差，或者根本不推荐.例如，我曾经使用规则实现了一个 psuedo-BFS 算法，以找出从任意硬件配置到最新支持配置的最佳升级路径.(每个版本只能升级到不同的其他版本，所以我们需要找出从给定版本到目标版本的最快路径，如果可能的话.)这可以在数据库中完成吗?可能，但这不是关系数据库所擅长的.代码呢?当然可以，但现在您必须管理代码中可以升级到什么的列表.

I could come up with a whole set of examples where a database-based solution would be less performant, or not recommended at all. For example, I once implemented a psuedo-BFS algorithm using rules to figure out an optimal upgrade path from an arbitary hardware configuration to the latest supported configuration. (Each version could only be upgraded to distinct other versions, so we needed to figure out the fastest path from a given version to a target version, if possible.) Could this have been done in a database? Possibly, but it's not the sort of thing a relational db would be good for. What about code? Sure, but now you'd have to manage your list of what-can-upgrade-to-what in code.

对于极其简单的规则集，其中每个规则都是完全排他的并涵盖所有用例?当然，数据库的性能可能更高.然而，现实世界的情况要么需要过于复杂的查询，要么可能根本不合适.

For extremely simple rule sets where each rule is completely exclusive and covers all use cases? Sure a database might be more performant. Real world situations, however, would either require overly complex queries, or might not be appropriate at all.

还有决策表?不惜一切代价避免它们.它们加载缓慢，执行缓慢，占用的内存比它们需要的多得多，如果尝试大规模使用它们，您会遇到未记录的限制，并且调试它们很痛苦.

And decision tables? Avoid them at all costs. They are slow to load, slow to execute, hog way more memory than they need, have undocumented limitations that you'll run into if trying to use them at scale, and debugging them is a pain.

这篇关于Drools 引擎和数据库的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！