[rules-users] Independent rule evaluations
Edson Tirelli
tirelli at post.com
Thu Nov 6 12:54:32 EST 2008
I guess you need to talk to Kris, the ruleflow master. :)
2008/11/6 techy <techluver007 at gmail.com>
>
> Thanks Edson for the clarification.
> 1. actually I want to manage rule flow from the database.
> Do I have to store whole rfm file content in the database as text column?
> If so, I was looking at the sample rfm file and its content does not look
> simpler. If I want to edit to rfm file in the database(add/remove nodes or
> rule group etc),it seems too much complicated or very error prone.Editing
> of
> rfm does not look feasible without using eclipse graphical editor. If
> that's
> the case, How can I have rule flow as database driven? Or may be whenever I
> want to edit rule flow, then I can do it in the eclipse GUI and update the
> content in the databse. then I wont call this as database driven. Please
> clarify.
>
>
> Edson Tirelli-3 wrote:
> >
> > Trying to answer:
> >
> > 1. not sure what you mean. You design a rule flow as a sequence of steps
> > (groups) in the same way you would do when designing a workflow. When you
> > write your rules, you associate those rules to groups in that flow. The
> > ruleflow design itself is an XML file. So, the general answer is: you can
> > store a ruleflow in a database. Rebuilding the rulebase is fine, and
> > AFAIK,
> > ruleflows are dynamic, so you can add them to existing rulebases. Kris
> can
> > confirm this to you.
> >
> > 2. yes, there are several optimizations you can do to the engine and to
> > your
> > rules, in a similar way you would do for a database. Which optimizations
> > and
> > how to do it can only be answered by seeing your use case, and fine
> > tunning
> > it. Regarding volumes, we have users using thousands of rules and
> millions
> > of facts without problems, but as you know, the bigger the size, more
> > careful you need to be on the engine configuration and the quality of
> your
> > rules.
> > I'm trying to get a user to write a blog on the sizing of the application
> > they have right now. I don't want to disclose the information before they
> > allow me to do it, but their specific solution does not have as many
> rules
> > as yours, but process a similar volume of facts as yours in 2-hours
> > windows.
> > They run in a server with just a few cores, but use a considerable amount
> > of
> > memory.
> >
> > Regarding your question about if a production rules engine fits your
> > use
> > case, Rete algorithm as a general rule, will provide increasing benefits
> > as
> > the rule base grows, because more rules you have, more you will benefit
> of
> > optimizations like node sharing and other techniques.
> >
> > If you go ahead, I suggest you contact Red Hat. They can help with
> your
> > solution design, training (if necessary) as well as provide support for
> > development and production.
> >
> > []s
> > Edson
> >
> > 2008/11/4 techy <techluver007 at gmail.com>
> >
> >>
> >> Thanks Edson.
> >> Few more questions based on my requirements.
> >>
> >> I want to load all rules from the database once for everyday(during
> daily
> >> job startup) and apply them against huge amount of data.here rules are
> >> once
> >> loaded, no further need for dynamic addition/removal during that
> >> execution.
> >> But If I add any new rules to the database, rule engine should be able
> to
> >> pick those during next execution(Intention here is to provide a custom
> >> editor later on for the user to manage the rules.since droosl's BRMS
> does
> >> not seem handle all of our use case conditions, I've concluded to have
> >> custom BRMS).
> >>
> >> 1.Can I have rule flow as database driven?
> >> i.e Can I store rule flow content for each rule as text column in the
> >> database and create rule flow file during the execution of each day?
> >>
> >> 2. my requirement is to run 1200 use cases(rules) against 40- 50 million
> >> records each day, I'm really concerned about execution time also. Can I
> >> do
> >> any optimization in the rule engine for faster execution?
> >> Is rule engine still a good option in this case?
> >>
> >> appreciate your help.
> >>
> >>
> >>
> >> Edson Tirelli-3 wrote:
> >> >
> >> > Yuri,
> >> >
> >> > Right now, the only way is to work with different rule bases and
> >> > working
> >> > memories. Even using agenda-groups or rule-flow, rules are still being
> >> > eagerly evaluated, as this is how standard Rete works.
> >> > The problem of creating and canceling too many activations is a
> >> known
> >> > problem and the only way around it right now is sequential mode, but
> >> > sequential mode has some restrictions on what you can do. For
> instance,
> >> > you
> >> > must work with a stateless working memory and can not modify/retract
> >> facts
> >> > in your rules to work with sequential mode, but it will give you big
> >> > performance boosts.
> >> >
> >> > We are evaluating the possibility of creating physical network
> >> > partitions for next version, but that will require some R&D yet.
> >> >
> >> > []s
> >> > Edson
> >> >
> >> > 2007/8/14, Yuri <ydewit at gmail.com>:
> >> >>
> >> >> Dr. Gernot Starke <gs <at> gernotstarke.de> writes:
> >> >> > can you detail your problem a little?
> >> >>
> >> >> I basically need to find perfect matches between two different sets
> of
> >> >> objects.
> >> >> If perfect matches are not found, I then create bulks of objects that
> >> are
> >> >> then
> >> >> used in combination with the individual ones to find bulk matches. If
> >> no
> >> >> matches
> >> >> are found I need then to categorize the breaks (around 10 different
> >> >> categorizations) and report them.
> >> >>
> >> >> The matching criteria between two object is specific enough to be
> >> fast.
> >> >> Once I
> >> >> get into break, which basically is removing some criteria components,
> >> the
> >> >> possible combinations increase exponentially. Bulking just compounds
> >> the
> >> >> problem
> >> >> by adding more matchable/breakable facts into memory.
> >> >>
> >> >> My bulking logic (I didnt have collect when I started with 3.0)
> starts
> >> a
> >> >> bulk
> >> >> looking for two diff objects with the same bulkling criteria (this is
> >> my
> >> >> first
> >> >> potential cross product since drools would produce C!/N!(C-N)!
> >> >> combinations).
> >> >> Then once the bulk for a given criteria is create I have a second
> rule
> >> >> that
> >> >> expands or contracts the bulks as new facts are asserted causing many
> >> >> different
> >> >> side effects.
> >> >>
> >> >> What I am basically seeing is that asserting a fact that would for
> >> >> instance be a
> >> >> perfect match, causes many of the bulking and breaking rule
> >> activations
> >> >> to
> >> >> be
> >> >> created and then cancelled. Considering that I am talking about tens
> >> or
> >> >> hundreds
> >> >> of thousands of facts I thought that if I could stage the activation
> >> >> creations I
> >> >> would increase processing speed.
> >> >>
> >> >> With 15K objects on each side I have been seeing something like 1
> >> >> assertion per
> >> >> second.
> >> >>
> >> >> I am aware that this could be cross product somewhere but I have
> >> already
> >> >> revised
> >> >> the rules many many times so now I am looking for other alternatives.
> >> >>
> >> >> I am now trying to understand looking I basically need to find
> perfect
> >> >> matches
> >> >> between two different sets of objects. If perfect matches are not
> >> found,
> >> >> I
> >> >> then
> >> >> create bulks of objects that are then used in combination with the
> >> >> individual
> >> >> one to find bulk matches. If no matches are found I need then to
> >> >> categorize the
> >> >> breaks (around 10 different categorizations) and report them.
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> rules-users mailing list
> >> >> rules-users at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Edson Tirelli
> >> > Software Engineer - JBoss Rules Core Developer
> >> > Office: +55 11 3529-6000
> >> > Mobile: +55 11 9287-5646
> >> > JBoss, a division of Red Hat @ www.jboss.com
> >> >
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Independent-rule-evaluations-tp12129972p20335308.html
> >> Sent from the drools - user mailing list archive at Nabble.com.
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> >
> >
> > --
> > Edson Tirelli
> > JBoss Drools Core Development
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Independent-rule-evaluations-tp12129972p20364536.html
> Sent from the drools - user mailing list archive at Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20081106/9881f756/attachment.html
More information about the rules-users
mailing list