Kapokfly,
For issue 1:
I have a very similar issue. What I am currently doing, is to pre-load my
reference data from DB into my JVM, but I do not load those entities into
working memory. Instead, I have the rules written to use the FROM clause in
the left hand side of the rule.
Example:
When
Customer ( $indCode : clientIndustry, activeSw == true )
$industry : Industry () from lookupIndustry( $indCode )
What this does, is obtain the client Industry code from my customer object, and
capture the value to the "$indCode" variable. I then capture all Industry
objects into the "$industry" variable that are returned from the call to the
function "lookupIndustry()". The lookupIndustry function is purpose built to
locate the specific industry objects that meet the query criteria provided as
the function argument. In this case, I am looking up the industry from a map
of Industries, with the key of the map set to the unique Industry code.
In my real-world scenario, I would prefer to rely on a no:sql DB to perform the
lookups for me. This would buy me the performance benefits of my key:value
maps being driven by faster C/C++ code, while removing the need to me to code
such lookup and caching services in my own code.
In addition, my caching process, does actually cache my DB objects in the JVM
memory, but instead it preloads my no:sql DB with all my facts, and using a
Real Time Messaging system, I intercept all DB updates to sync up my no:sql
data.
The no:sql is not always the best fit, but because of the types of lookups I
need to perform, no:sql can retrieve my facts from DB and return them to my
code as instantiated objects much faster can JPA, or native SQL queries against
my RDBMS, and with much less memory impact than locally coded JAVA data maps.
Two million records is a lot, regardless of the actual data content, so it
seems to me you might want to either query SQL using an function, or querying a
no:sql system (like mongodb) and then using this logic to process on the data
in almost the same way you would had you loaded the data in working memory of
the knowledge session.
Hope this helps.
Regards,
Armand Welsh
-----Original Message-----
From: rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] On Behalf Of kapokfly
Sent: Friday, November 11, 2011 2:54 AM
To: rules-users@lists.jboss.org
Subject: [rules-users] Showstopper issues for Drools Adoption in our
organization
Not sure if these are also your questions you might have with the rule engine
adoption, but we have seen 2 showstopper issues for drools adoption in our
organization, or it is just because we are lack of some necessary knowledge.
Issue 1) : pattern match for large data
There are cases in a rule we need find matched records against a large
population of data and perform some actions.
Example:
From 2 millions employee directory, find those belongs to Depart1 and with
salary increased by 10% last year.
Inserting all these employee's data into WorkingMemory is HUGE and mission
impossible, we can't simply load the entire db into the working memory, do we
have any other approach to accomplish or this is just not a use case can be
resolved by a rule engine?
Issue 2): Map business object to real engineering implementation
What we are trying to do is to build a rule UI which a business user without
engineering background of our codebase can work with; the business object we
show on the UI might be different with the real engineering objects already in
system, for example, on the UI a user might be able to able to see something
like person.address.addressLine1 but the actually implementation might not be
an object traverse implementation.
Example, the model could be Long Person.addressId ; then referring to his
address we need another lookup and we want to hide such complexity to the end
user.
The approach we took is to design a translation layer to translate the user
input to drools rule string, is this the right approach?
If not, any suggestions? I know Drools is mainly designed for developers but
just trying to see if there is any way we can work it around.
Thanks and looking forward to your recommendations.
Ivan
-----
Ivan, your Panda, forever
--
View this message in context:
http://drools.46999.n3.nabble.com/Showstopper-issues-for-Drools-Adoption-in-our-organization-tp3499367p3499367.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
