For years OpenRules was among the fastest rule engines. When last year we moved from run-time interpretation to design-time code generation, we, like our colleagues at Red Hat Drools, managed to further improve the overall performance and provide support for practical decision microservices. As a result, we dramatically minimized start-up time, went from 50-100 milliseconds per transaction to 5-10 milliseconds, made memory footprint small. These are really good results needed by modern enterprise decision-making systems.

However, I knew that we have multi-year customers that use really big (!) decision tables with 10 and even 30 thousands of rules. How to improve their performance?

The standard decision engine delivers acceptable but not great performance for big tables, especially when they are being executed million times a day. You may suspect that these customers mistakenly moved their DB tables to rules. Sometimes it’s true and their big tables may be simple “lookup” tables. Still, these customers prefer to treat every row in such tables as a rule that they easily can understand, change, and add more rules. But visiting customers, I’ve also seen the huge multi-hit decision tables with rules overrides and quite complex inter-rules relationships. Even after splitting their big tables into several smaller tables, they still have tables with 15-20 thousands of rules. They don’t really complain about production performance but making changes in such big tables, and then re-loading and testing them takes time. I always wanted to change that.

This January we decided to tackle this problem and create a brand new execution mechanism for big tables. Today I am proud to report that the OpenRules development team did even better than I could expect 4 months ago. The newly implemented algorithm improves the performance of very big decision tables from 10 to 100 times! And this new mechanism is now available with the Release 8.1.2 of OpenRules Decision Manager.

How was it done? First of all, we introduced a special type of decision tables using the new keyword “BigTable” instead of “DecisionTable”. They are the same classical OpenRules decision tables created in Excel. However, they are being evaluated using a completely different execution mechanism that is based on a self-balancing binary search algorithm adjusted to specifics of our decision tables. Let’s consider an example of a big decision table included in the standard installation as the “HugeTable” decision project:

If you click on this image, you will open the actual table in Excel and will see that it contains 16,372 rows (rules) and this Excel file occupies almost 3 MB. So, it is quite a big table. You may execute this table against different combinations of input parameters using this online GUI:

http://amazon.openrules.com:8080/BigTable/

Click on this picture (or the link under it) to run this demo. I quickly created this GUI using OpenRules Dialog, and when a user clicks on the button “Execute” my dialog simply calls a remote decision service deployed as AWS Lambda. The AWS Lambda was created and deployed using OpenRules 8.1.2 sample “HugeTable”. You may download it and use a prototype for creating AWS Lambdas using your own big decision tables.

Similarly, I may call the “HugeTable” Lambda from POSTMAN, and it is constantly finding the corresponding rules in the above BigTable under 1 millisecond!

Our development team did a great job with a new algorithm. However, such fantastic performance comes with a few restrictions:

1. “BigTable” doesn’t allow a table designer to use Java or FEEL snippets inside its cells;
2. Only comparison operators (=, >, <, >=, <=) are allowed in the optional 4th row of this table. These row can contain operators +=, -, *= for Then-columns.

I believe these restrictions are reasonable because people rarely use complex formulas in big decision tables. Besides, you always may change the keyword “BigTable” to “DecisionTable” and it will continue to work (but slower).

The above BigTable is an example of a single-hit decision table, you even may use the keyword “BigTableSingleHit”. However, you also can use big multi-hit decision tables by using the keyword “BigTableMultiHit“. When I changed the above BigTable to BigTableMultiHit, if found and executed several rules that satisfied my test criteria, and the latest satisfied rule overrode previous rules.  For multi-hit bis decision tables, it can be useful to use increment/decrement operators “+=” or “-=” in the 4th row of the Then-columns. For instance, in large scorecards, you may execute only a limited number of satisfying rules to accumulate a score in the Then-column.

Conclusion. I know that at least several of our customers will be happy with new Big Tables, and I expect many other customers and prospects would appreciate this new feature and the overall high performance of OpenRules Decision Manager 8.1.2.