Use indexes to improve rule performance. Indexes enable the rule engine to find event or data instances more rapidly. When only a limited selection of instances is required, an index avoids iteration over all instances. You can also use an index to determine the order of iteration over a set of event or data instances.
A sorted index implements an order on the instances. If the goal is to determine the search order, use a sorted index. When the goal is mainly performance improvement, a hashed index (an index based on a hash table) will produce the best results.
You must define key slots when there is a need to enforce uniqueness on a combination of slots. Hashed indexes do not enforce uniqueness. Several instances can have the same value for all of their indexed slots, but with key slots, only one instance can have a certain combination of slot values. When there is no need to enforce a uniqueness, use hashed indexes rather than key slots for optimization.
Indexes are defined with in the MRL with a rule-like syntax. An index rule will not do any processing on an incoming event. Following is the syntax for an index definition within a rule:
You can define an index for an event class and for a data class.
You can define an index for a single slot or for a list of slots. On a list of slots, a sorted index will start sorting on the first slot. Instances with the same value in the first slot will be sorted on the second slot and so on. The slots in the slot list must be slots of the indicated class or of one of its superclasses.
You can define more than one index for the same class. A subclass inherits an index definition from its superclass if one is defined. An index definition for a subclass does not override an inherited index. All index definitions for a class remain effective whether they are defined directly for the class or inherited from a superclass.
The following example shows two index definitions. The first is a sorted index for two slots; the second is a hashed index for a single slot.
You use an index in a
usingclause. Instead of specifying a class name, you can specify an index name defined for that class.
The following example shows three general forms of an index
The difference among these three forms is in the specification of the actual indexed slot values.
A sorted index does not require you to provide an actual value for each of the indexed slots. However, all slots for which an actual value is specified must be at the beginning of the slot list in the definition. For example, if an index is defined for the slot list
slot4], it is valid to have an actual value for
slot2 and no values for
slot4. It is not valid to provide an actual value for
slot3 only, because the first slot,
slot1, is left unspecified. It also valid to specify none of the indexed slots for a sorted index.
To use a hashed index, you must specify all indexed slots with an actual value.
The rule compiler will report invalid use of an index in error messages.
For these indexes:
the following example illustrates their use in New rules:
The rules use
$E to refer to the
EVENT_CLASS instances and
$D to refer to the
BMC_BaseElement instances that are retrieved through the indexes.
The first rule,
Rule1 uses the sorted index
Idx1 without specifying any of the indexed slots. As a result, it iterates over all
EVENT instances in the order of the index (which can impact performance if there is a large number of instances). The additional
where condition selects the desired data instances.
The second rule,
Rule2 uses a hashed index. It provides the mandatory actual value for the indexed slot
Name, assuming that the
MY_EVENT instance has a slot
ci_name that contains the
Name of the relevant