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).

在流口水中，我们将业务规则(在.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天之内)，该UI与公开的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.

有人可以在这里帮忙吗?

Can someone help here?

推荐答案

与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.红色的4门跑车则匹配两个规则；价格是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屋！