Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Gator : an optimized discrimination network for active database rule condition testing
Full Citation
Permanent Link:
 Material Information
Title: Gator : an optimized discrimination network for active database rule condition testing
Series Title: Department of Computer and Information Science and Engineering Technical Report ; TR93-036
Physical Description: Book
Language: English
Creator: Hanson, Eric N.
Hasan, Mohammed S.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: December, 1993
Copyright Date: 1993
 Record Information
Bibliographic ID: UF00095202
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

1993118 ( PDF )

Full Text

Gator: An Optimized Discrimination Network for

Active Database Rule Condition Testing

Eric N. Hanson
301 CSE
CIS Department
University of Florida
Gainesville, FL 32611
(904) 392-2691
FAX: (904) 392-1220

Mohammed S. Hasan
301 CSE
CIS Department
University of Florida
Gainesville, FL 32611

December 1993

This paper introduces a new discrimination network structure called Gator that is a generalization of
the widely known Rete and TREAT algorithms. Gator can be used as a replacement for Rete or TREAT
in active database rule systems and production system interpreters. In Gator, f/-memory nodes that hold
intermediate join results can have two or more inputs, not exactly two inputs as they do in Rete. Gator
is designed as the target structure for a discrimination network optimizer. Algorithms for performing
pattern matching using a Gator network to see if a rule condition has been satisfied are given. Cost
estimation functions for Gator networks based on cardinality, predicate selectivity, and update frequency
information are introduced, and a technique for constructing optimized Gator networks is described. A
Gator network optimizer has been developed, and the optimizer has been tested with simulated inputs.
The results show that in terms of time, Gator can substantially outperform unoptimized Rete networks,
TREAT networks, and optimized Rete networks, often by an order of magnitude. Gator also uses space
effectively, requiring only slightly more space than TREAT and much less then Rete.

1 Introduction

Both production systems and active database systems must perform rule condition matching during execution

to determine which rules to fire. The most successful rule condition testing mechanisms developed for main-

memory production systems system are discrimination networks known as Rete [5] and TREAT [12]. Like

production systems, active database systems must also test rule conditions, and we believe some kind of

discrimination network will be the best tool for doing so. However, choosing a good discrimination network

structure is far more important in the active database environment than in main-memory production systems

because of the volume of data involved, and the fact that some or all of the data may be on secondary storage.

R1.d=R2.d R2.e=R4.e R4.f=R5.f
R)-- R2 R4 R5
R1.a>17 R5.b="Friday"



Figure 1: Example rule condition graph.

Previous work has shown that the TREAT algorithm usually out-performs the Rete algorithm [12]. A

recent performance study comparing Rete and TREAT in a database environment showed that neither Rete

nor TREAT always is best, TREAT normally is better than Rete, but sometimes Rete can vastly outperform

TREAT [18]. This lead us to search for a more general structure than Rete or TREAT.

This paper presents a generalized discrimination network structure called the Gator (Generalized TREAT/Rete)

network. Gator networks are general tree structures. Rete and TREAT networks are special cases of Gator.

Gator networks are suitable for optimization because there are a very wide variety of Gator structures that

can perform pattern matching for a single rule. In contrast, there is only a single TREAT network for a

given rule, and Rete networks are limited to binary-tree structures.

In many situations the optimal discrimination network will have the form of a Gator network, not a

Rete or TREAT network. Gator networks are also appropriate when there are storage constraints since the

number of internal memory nodes is not fixed as in Rete.

2 Gator network structure

The condition of a rule in a production system or active database system has a structure similar to that of

a relational database query. This structure can be represented as a rule condition graph with one node for

each rule condition element (RCE), and one edge for each join condition. The nodes are decorated with the

selection conditions associated with the corresponding condition elements. An example rule condition graph

is shown in figure 1. This graph is based on some example relations R1 through R5.

Rete, TREAT and Gator networks are all made up of nodes of the following types:

Rete TREAT Gator

al a2 a3 a4 a5 al--- aa c4-- a5 al-- a2-- a3 a4 a5

\\ // /
P2 P31

P3 /P-node


Figure 2: Examples of Rete, TREAT and Gator discrimination network structure.

a-memory One a-memory holds all tuples from a single relation that match the selection condition of one


3-memory One 3-memory holds combinations of tuples that match a subset of the selection and join

conditions of the rule condition. The tree of nodes rooted at the 3-memory defines this subset of the


P-node A P-node is a special node that takes the place of a 3-memory at the bottom of the network. There

is one P-node for each rule. The tree rooted at the P-node corresponds to all the selection and join

conditions in the rule condition.

TREAT networks have only a-memory nodes. Rete networks have a left-deep binary tree format and

maintain internal (3-memory) nodes, which always have two inputs. Unlike a Rete network, a Gator network

may have internal memory nodes with two or more inputs, not just two. These multiple-input nodes are

called 3-memories to be consistent with Rete terminology. Children of a multiple-input node may be a

combination of leaves (a-memories) and other multiple-input nodes.

Sample Rete, TREAT, and Gator networks for the rule whose condition graph is shown in figure 1 are

shown in figure 2. The Gator network subtree with three children has the structure of a TREAT network.

3 Virtual-a memories

Another property of the Gator network is that a memory nodes may be either materialized, and thus contain

all the tokens that match their selection condition, or they may be virtual, in which case they contain only

their selection predicate but not the tokens matching the predicate. The concept of virtual a-memories

has been used in a variation of the TREAT algorithm called A-TREAT [6]. Use of virtual a-memories for

rule condition matching in Gator is identical to that in A-TREAT. Virtual a-memories save space since

the matching tokens need not be stored in the memory node. This is particularly important in a database

environment since the underlying data sets can be huge.

4 Rule condition matching in a Gator network

When a base relation tuple is inserted, deleted or modified, rule condition matching must be performed to

see if any rules are triggered or made no longer eligible to fire. The rule condition matching strategy of

Gator is similar to the algorithms for rule condition matching in Rete and TREAT [5, 12]. Gator performs

rule condition matching by propagating lokens through the network. When a tuple is inserted into a base

relation table, an insert token, or "+" token, is created by tagging a copy of the tuple with a + tag. This +

token is then propagated through the network. When a tuple is deleted from a base relation, a delete token,

or "-" token, is created similarly and propagated through the network. Modifications are treated as deletes

followed by inserts. The rest of this section covers handling of + tokens and tokens. The algorithms for

processing tokens are described here in a set-oriented style that is suitable for use in active database systems.

A tuple-at-a-time, recursive style of the algorithm suitable for main-memory production systems is presented

elsewhere [7].

In the following discussion, memory nodes of type a and 3 will be referred to together as memory nodes.

Nodes that can have multiple inputs, including 3-memories and P-nodes, will be called multiple input nodes.

The term node may be used to describe an a-memory, 3-memory, or P-node.

4.1 Handling + tokens

The set-oriented version of the Gator algorithm keeps around at each step a set of tokens called a temporary

join result (TR). For processing a + token, this algorithm is implemented in terms of a recursive function,

InsertPlusTempResult. As part of each memory node N in the network, there is a list of pairs, one pair for

each multiple-input node of which N is a child (N may have more than one parent if it is part of a shared

subexpression). Each pair contains the following:

a multiple input node Parent which has N as one of its inputs, and

a plan P for how to join a temporary result inserted into N to the other input nodes of Parent. This

plan is a list of the identifiers of these other nodes, in the order in which they should be joined to the

temporary result.

The list of pairs of the above form is called the parent/plan pair list, or PPPlist. The function Parent(PPpair)

extracts the parent node from the parent/plan pair PPpair. The function plan(PPpair) extracts from PPpair

the list of nodes specifying the join order. Based on this terminology, InsertPlusTempResult is shown in

Figure 3. To initiate match processing when a new token t is inserted into a leaf node LEAF of the Gator

network (LEAF is either a P-node or an a-memory), an initial temporary result TR1 is constructed. TR1 is

a set containing only one token, t. Then InsertPlusTempResult is called with TR1 and LEAF as arguments.

The algorithm InsertPlusTempResult terminates when the temporary result is empty or the final temporary

result is added to the P-node.

As an example, referring to figure 1 and the Gator network in figure 2, suppose that a tuple was added

to R3 with a value of "on" for attribute c. TR1 would contain an entry for just this tuple. TR1 would arrive

at a3. TR1 would then be joined to a2 via the join condition on the dashed edge from a3 to a2, yielding

TR2. TR2 would similarly be joined to al, yielding TR3. The contents of TR3 would be added to i1, and

then joined to 32, yielding TR4. TR4 would then be added to the P-node. If any of the temporary results

TR2, TR3 or TR4 were empty upon creation, processing would stop at that point.

Selection of a good join order plan for each input of a multiple-input node is considered later. The nested

loop join method will normally be used to join a TR to a memory node, and will make use of any existing

/* TR is a temporary result.
Node is a memory node or P-node in a Gator network. */
If TR is empty, return.
Insert the tokens in TR into the collection of tokens
belonging to Node.
If Node is a P-node,
adjust the rule agenda if necessary, and return.

For each parent/plan pair x in PPPlist(Node) {
For each node y in plan(x),
in order from first to last,
/* Join the current temporary result to the next
memory node specified by the join order plan,
forming the next temporary result. */
TR = join(TR,y)
/* Insert the final temporary result into the
multiple input node for which
new matching tokens are being found. */

Figure 3 Procedure inserting a temporary resultinto a node

Figure 3: Procedure for inserting a temporary result into a node

index on the join attribute of the memory node. A sort-merge or other join strategy could be used sometimes

if appropriate.

4.2 Handling tokens

Handling (delete) tokens is slightly different from handling of + tokens. The standard delete optimization

familiar from implementations of Rete is used. This optimization does not do joins during deletions. Rather,

when a token t enters a node, the token is deleted from the node. Then, if that node feeds into a multiple

input node, the tokens in the multiple input node are scanned to see if they contain t as a component. If

so, they are deleted. In turn, more tokens are generated and passed to the successor of the multiple input

node. Detailed algorithms for tokens are not presented.

A discussion of how Gator supports negated condition elements like those that can be specified in OPS5

[2] is given elsewhere [7]. To perform well, the Gator rule condition matching strategy needs a Gator network

with a good structure. How to find an efficient network is the subject of the next section.

5 Optimization of Gator networks

The key parts of an optimization strategy for building a good Gator network are computation of costs of

partial solutions, and search strategies and heuristics for building new partial solutions from smaller partial

solutions. These issues are addressed below.

5.1 A strategy for optimizing Gator networks

The optimization algorithm is a dynamic programming algorithm which progressively builds a set of larger

networks by combining smaller networks that have already been created. It starts by creating a set of

networks of size one. It then builds networks of size i, iterating i from 2 up to n, where n is the number of

nodes in the rule condition graph.

During the iteration when the algorithm is creating the networks of size i, all the networks of size less

than i have already been created. The algorithm takes all possible pairs of already created networks such

that the sum of the sizes of the elements of the pair is equal to i, then checks whether the networks can be

combined, and after combination whether the combined network is the optimal one. Networks cannot be

combined unless they satisfy the disjointness constraint, which states that their respective sets of RCE's

must not overlap. The combined network is considered optimal if it is the cheapest one found so far for the

subset of the nodes in the rule condition graph corresponding to the leaf nodes of the combined network. If

the combined network of size i is optimal, it is added to the set Nets[i], otherwise it is discarded.

The algorithm uses the following rules to combine networks:

Join: Combine two memory nodes m and m' by creating a single two-input node 3 with the other two nodes

as inputs.

Absorb: Combine a node m and a multiple-input node 3 by adding m as another input node of 3. If both

m and 3 are multiple-input nodes, then each of them can absorb the other, so there are two ways to

apply this rule.

Merge: Combine two networks rooted at 3 nodes m and m' by merging m and m' into a single 3 node.

This new P node will have as its children all the children of m and m' combined.

A graphical representation of the rules is shown in figure 4.

In order to limit the number of sub-networks generated, the following heuristics are used:

Connectivity Heuristic: Do not combine two Gator networks unless there is an explicit join between them

in the rule condition graph.

In other words, do not combine a Gator network nl with a Gator network n2 if there is no edge between

the subgraph of the rule condition graph corresponding to nl, and the subgraph corresponding to n2. In the

case where the rule condition graph is not connected, dummy join edges with i .. --" predicates are added

until the graph becomes connected. These dummy edges are placed so that no cycles are added to the graph.

A caveat to the connectivity heuristic is that the optimization algorithm proposed here assumes that

the rule condition graph is acyclic. If there are cycles in the graph, edges will be removed until no cycles

remain before optimization starts. Conditions corresponding to the removed edges will be added to the

Join 0 + 0 =

Absorb Q +

Merge \ O \ \

Figure 4: Graphical representation of rules for combining Gator networks.

Gator network chosen by the optimizer so that rule condition matching will function correctly. Better ways

to handle cyclic and unconnected rule condition graphs await further study.

Lowest Cost Heuristic: In the case where there already is a network corresponding to the same set of

condition elements as the network just created, and the existing network costs no more than the new

network, discard the new network.

The optimization algorithm is described in detail in figure 5. Line 2 of the algorithm initializes the set of

networks of size 1. Line 3 starts the iteration; at iteration I, the set of networks of size I, Nets[I], is filled. To

create a network of size I, a network of size J and another of size (I-J) are combined. To avoid overlapping,

J is varied from 1 to [-] (line 4). Lines 7 and 8 scan every member of sets Nets[J] and Nets[I-J]. Line 9

checks the connectivity and disjointness constraints. If the two networks satisfy these constraints, they are

combined in line 10, after searching through all four possible combined networks. Line 11 checks if there is

already a network of size I covering the same subgraph. If there is one, the cheaper of the two networks is

kept and the more costly one is deleted (line 14-16). Since there is only one subgraph of size equal to the

size of the rule-graph, namely, the rule-graph itself, there will be only one member of Nets[n]. That is the

optimum network (line 17-18).

Gator optimize(RuleCond rule)
{ Gator INet,JNet;
Nets netsJ,netsIMinusJ,*NetsArray;
Gator T,T1;
(0) n = sizeOf(rule);
(1) initialize NetsArray to size n
(2) Initialize NetsArray[1];
(3) for I= 2 to n do
(4) for J = 1 to ['] do
(5) netsIMinusJ =NetsArray[I-J];
(6) netsJ = NetsArray[J];
(7) for each JNet E netsJ do
(8) for each INet E netsIMinusJ do
(9) if( isConnected(INet,JNet) && isDisjoint(INet,JNet))
(10) T = combine(INet,JNet,rule);
(11) if(there is already another network for the same rule subgraph
as the rule subgraph corresponding to T)
(12) T1 = that other network;
(13) if(T is cheaper than T1)
(14) add T to NetsArray[I]; remove T1 from NetsArray[I];
(15) else
(16) delete T;
(17) T =the only network from NetsArray[n]
(18) return T;

Figure 5: Gator network optimization algorithm

In the earlier discussion of how the match is performed using a Gator network, it was mentioned that

there is a join order plan associated with each memory node N for each multiple input node to which N

is an input. During optimization, this plan will be constructed as follows. Let N be an input node of a

multiple input node p. When a temporary result TR1 enters N, TR1 is joined to a sibling of N to form

TR2, then TR2 is joined to another sibling of N to form TR3, and so on until no siblings remain. The join

order plan is built so that TRi+l is always formed by joining TRi to the remaining sibling S of N such that

(1) TRi has a join edge to S in the rule condition graph, and (2) the TRi+l value with the smallest expected

cardinality is generated. TRi is said to have a join edge to sibling S if the subgraph of the rule condition

graph corresponding to TRi, and the subgraph of the rule condition graph corresponding to S are linked

directly by an edge.

The procedure described above uses a heuristic to construct a reasonably good join plan quickly. An

alternative would be to use a query optimizer to decide the join plan, but that would be prohibitively

expensive since construction of the plan is part of the larger optimization process to build an optimized

Gator network. Running a query optimizer hundreds or thousands of times as part of optimizing the Gator

network for a single rule would simply take too long to be feasible. Also, since the initial temporary result

coming into N is likely to be small, it will usually be best to join that temporary result to a sibling of N as

the first step because that will tend to make the next temporary result small as well.

This concludes the discussion of the search strategy for constructing Gator networks, pruning bad subnet-

works, and eventually returning the best network. Even though a very large number of Gator networks and

subnetworks are built during the optimization process, the process still normally terminates in a reasonable

amount of time (less then a few seconds for one rule) because typical rule condition graphs have only a few

nodes. It will be very rare for a rule condition graph to have more than ten nodes. Most will have one to

five nodes.

The optimization technique discussed above has been implemented as part of a simulator to compare

Gator with Rete and TREAT. Randomized optimization strategies such as simulated annealing, iterative

improvement, and two-phase optimization [9, 10] can also be applied to Gator networks, and are also being

investigated [13]. The search space for Gator network optimization grows with the size of the rule condition

graph even more rapidly than the size of the search space for query optimization grows with the size of the

query graph, since Gator network inner node fan-out can be greater than two while query graph inner node

fan-out is always two. Because of this, randomized optimization techniques may be more important for Gator

network optimization than they are for query optimization. We have observed that dynamic programming

takes an impractical amount of time (greater than one minute) when the rule condition has 12 or more

condition elements.

This section assumes all a-memories in a Gator network are stored, not virtual. Developing a process

for building optimized Gator networks that may contain virtual a-memories is a subject for future work. At

this point, it is suggested that if virtual a-memories are to be used, a post-processor can be applied to the

Gator network produced by the optimizer to decide which nodes should be virtual. Below, the functions for

estimating the cost of a piece of Gator network are discussed in detail.

5.2 Cost functions

The question that must be answered is, what does a Gator network cost? First, the units of cost will be

update frequency times elapsed time. To see why this is important and how it can lead to good Gator network

structures, observe the following. If no tokens ever enter the memory nodes at the leaves of a Gator network,

then its cost is zero, so its structure is not important. If the tokens frequently enter one leaf node al but not

the others, then it will probably be appropriate to construct any Gator network for the infrequently updated

nodes, as long as it has a 3-memory at the bottom, and then join a1 to that 3-memory. This will require

only a one-way join when tokens enter a1, rather than a multi-way join.

Since the optimizer will operate in a database management system environment, the catalog statistics

about relation size, attribute cardinality, and attribute value distribution will be available. These statistics

can be used by the optimizer to compute estimates of selection predicate and join predicate selectivity, just

as they are used by query optimizers [15]. The most important variable in the problem of discrimination

network optimization that is different from those used for query optimization is update frequency. Relative

frequency of updates to different memory nodes in a discrimination network can have a major impact on

the choice of the optimal structure. It is assumed that the database system keeps the insert and delete

frequencies of each relation in the system catalogs. Modifications of existing records are treated as deletes

followed by inserts. The frequency might be in units like "total number of operations performed in the last

24 hours." The discussion below gives the parameters involved in computing the cost of a Gator network,

and then develops formulas for estimating the total cost of a network.

5.3 Parameters used

The following are the parameters that are needed to estimate the cost of a Gator network. Unless stated

otherwise, N represents any kind of Gator network node (a, 3 or P-node).

Fi(N) is the frequency with which new + tokens enter a node and update it.

Fd(N) is the frequency with which new tokens enter a node and update it.

S(N) is the cardinality of a given node.

Pages(N) is the number of pages occupied by N.

Sel(a) is the selectivity of the predicate associated with the a-memory node a. This value can be estimated
from catalog data using standard techniques [15].

JSF(Ni, N2) is the estimated join selectivity factor between a pair of nodes N1 and N2. It is an estimate
of the following value:
S(Ni N2)
S(Ni) S(N2)

I/Oweight is the time to do a disk read or write.

CPUweight is the CPU time spent to insert or delete a tuple in a memory node or perform a predicate test
on a tuple or between a pair of tuples.

Reln(a) is the relation from which a-memory node a is derived. The frequencies Fi(Reln(a)) and Fd(Reln(a))
of updates to this relation can be obtained from statistics maintained in the catalog.

Cost(N) is the total cost associated with the subnetwork rooted at N.

LocalCost(N) is the cost associated with only local processing at N (i.e. not including the cost of its

In the cost formulas to follow, it will sometimes be necessary to estimate the number of pages touched

in a memory node of size m blocks when k records in it are accessed at random. For this the following

approximation to the Yao function [19] is used:

f m(1 -(1- /m)k) if c> 1
Yao(m,) k if k <

In the cost functions that follow, unless stated otherwise, it is assumed that any disk pages read are not

already in the buffer pool.

5.3.1 Total cost of a Gator network

The total cost of a Gator network with P-node P is Cost(P). The Cost function is recursively defined. Its

implementation for each of the different node types follows.

5.3.2 Cost computation of a nodes

The a nodes will either be stored on a single page, or organized using a clustered index on the primary key.

If an index is used, it is assumed that no index I/O will be needed because the index will be in the buffer

pool. Hence, one disk read and one disk write are required to do either an insert or delete. Since only one

tuple is touched, only one CPUweight cost is incurred. This leads to the following formula:

Cost(a) = LocalCost(a) = (2 I/Oweight + CPUweight) (Fi(a) + Fd(a))

The insert and delete frequencies of the a node, Fi(a) and Fd(a), are given by these formulas:

Fi(a) = Fi(Reln(a)) ( Sel(a)

Fd(a) = Fd(Reln(a)) Sel(a)

5.3.3 Cost computation of 3 nodes

The cost of a 3 node is a function of the cost of processing tokens propagated from each of its children.

This involves join costs for doing the matching, plus costs to update the stored copy of the 3 node itself.

Associated with each child c of a 3 node is a join plan that gives the sequence in which join operations

should be performed when a temporary result TR arrives at a child c of a 3 node. The join plan is the

sequence (mi, m2, ..., nmk), where mi through mk are the children of 3 except for c. When TR enters c, then

the following sequence of operations is performed:

TR = TR N mi
TR = TR N m2

TR = TR N mk

At this point, the contents of TR are inserted into or deleted from 3, as appropriate.

Each child of a 3 node either fits on one page or has a secondary index (or indexes) for faster access on

the join fields. The indexes on the child nodes are used when the TR is joined with them. The cost of a P

node includes the cost of its children, the cost of updating the node itself, and the cost of performing joins

when temporary results are propagated from its children.

Cost(3) = LocalCost(3) + Cost(N)

LocalCost(3) = F(N) PerChildInsCost(N, 3) + Fd(N) PerChildDelCost(N, 3)

The function PerChildInsCost(N, f) accounts for the cost to process a temporary result containing one +

token arriving at f from child N. This represents a simplifying assumption that if a temporary result TR

arrives at 3 from N, each token in TR will be processed individually. Not making this assumption would make

the cost estimation functions significantly more complex. The function PerChildDelCost(N, f) accounts for

the cost to process a temporary result containing a single token arriving at f from child N. The function

PerChildInsCost(N, f) is most easily represented as the following procedure:

PerChildInsCost(N, f) {
(size, cost) = JoinSizeAndCost(N, f)
return( cost + updateCost(f, size)

The body of this procedure calls a function JoinSizeAndCost(N, f) that returns a pair of numbers which

are the expected size of the last temporary result generated after a token comes into N, and the cost of

generating that temporary result. The function JoinSizeAndCost(N, f) is shown in figure 6. Another

procedure called in PerChildInsCost is UpdateCost(P,TRsize), and this procedure gives the time required

to update a multiple-input node 3 to reflect the contents of a temporary result of size TRsize that is to be

propagated through P. The UpdateCost function is shown in figure 7.

JoinSizeAndCost(N, 3) {
TRsize = 1 /* initial temporary result size */
cost = 0
L = plan(N, 3) /* initialize join order list */
previousNode = N
m = first(L) /* let m be first element of list L */
while ( m f Null ) {
if m fits on one page then
cost = cost +I/Oweight + CPUweight S(m). TRsize
else /* m is bigger than one page, so assume */
/* only tuples on one page of m are examined */
/* for each tuple in TR. */
cost = cost +I/Oweight min(pages(m),TRsize) +
CPU eight tuplesPerPage(m). TRsize
TRsize = JSF(previousNode, m)-TRsize.S(m)
L =rest(L) /* set list L to remaining list elements
after the first element */
previousNode = m
m = first(L)

Figure 6: When a temporary result TR is propagated out of a node N that is an input node to a node 3,
TR must be joined to the other input nodes of 3. This procedure computes both the cost of doing these
joins, and the size of the final temporary result generated after doing the joins.

UpdateCost(P,TRsize) {
/* A TRsize value less than one is significant
since small join selectivities can produce temporary
results that are small on average. The Yao function
takes this into consideration. */
cost = Yao(pages(3),TRsize) 2 I/Oweight + TRsize -CPUweight
/* If TR is larger than one page, add the cost to
allocate or delete pages in 3. */
if TRsize >1
TRsize 2 IlOweight
cost = cost + tupleP e 2 I/Ow t

Figure 7 Function to compute cost to update a memory node

Figure 7: Function to compute cost to update a 3 memory node.

The procedure PerChildDelCost(N, 3) has a slightly different structure than the procedure

PerChildInsCost(N, 3). It is assumed that the standard delete optimization discussed earlier that is often

used in Rete and TREAT implementations is employed.

The function PerChildDelCost(N, 3) must account for the cost to read all pages of the 3 node (no index

is available to support this operation), plus the cost to write pages of / that contain tokens with components

from child N. Each token in 3 must be examined, so one CPUweight factor must be paid for each token in

3 as well. This function is most easily represented as the following procedure:

PerChildDelCost(N, /) {
(size, cost) = JoinSizeAndCost(N, 3)
return( (Yao(Pages(3), size) + Pages(3)) I/Oweight
+S(3) CPUweight)

5.3.4 P-node cost

The P-node is not stored permanently on durable storage, and it is emptied when the rule associated with it

is fired. The formula for the cost of a P-node is similar to the one for a 3-memory except the cost to update

the contents of the P-node is a CPU-only cost [7]. For brevity, the detailed cost functions for P-nodes are


5.3.5 Estimating update frequency of 3 nodes

Formulas given previously have used the frequency functions Fi and Fd on 3 nodes. To finish the story it is

necessary to show how Fi and Fd for 3 nodes can be estimated. The value of Fi(P) is the relative frequency

of propagation of compound + tokens out of 3 compared with other nodes. Similarly, the value of Fd(3) is

the relative frequency of propagation of compound tokens out of P. An estimate for Fi is:

Fi(3)= F(N) JoinSize(N, 3)

where JoinSize(N, P) simply returns the size value from the pair of values returned by JoinSizeAndCost(N, 3).

Similarly, an estimate for Fd is:

Fd(3) = Fd(N) JoinSize(N, 3)

This section has presented a search strategy for building an optimized Gator network, and functions for

estimating the cost of a Gator network to help guide the search. Though the cost estimates are approxi-

mate, they are useful for purposes of comparing relative network cost. Query optimizers based on similar

approximate cost estimates have proven highly effective [15].

6 Optimizer implementation and evaluation

A Gator optimizer has been implemented in a simulated database ,- ii..i ......I ['] Inputs to the optimizer

are a collection of relation descriptors, and a collection of rule descriptors. A relation descriptor describes

a relation though the actual tuples of the relation are not stored. A relation description includes, among

other things, the number of attributes, cardinality, update frequencies, etc. for a relation. A rule descriptor

describes a rule in the form of a rule graph. Each node in the rule graph represents a tuple variable, and

each edge represents a join. Among the parameters of a node is the predicate selectivity, defined as Sel(a)

in the cost model. Parameters of an edge include the JSF of the join represented by that edge. A number

of parameters are given as input to the database simulator, which creates relation and rule descriptors in

a random fashion using those parameters. The behavior of the optimizer is estimated for varying database

conditions by changing the input parameters to the simulator.

Five different types of networks have been created and compared for a number of rules. These are

Gator, Best Rete, Best TREAT, Worst Rete, and Overall Worst. Rete networks are created by modifying

the combination methods of the optimizer, and the worst networks are created by optimizing for maximum

instead of minimum cost. The Worst Rete network is the network with the maximum cost having a binary

tree structure. Similarly, the Overall Worst network is the network having a Gator structure but with

maximum cost. The -..i-1 networks are created to show the worst possible network cost that might by

chance be observed without optimization.

The performance of a network is characterized by the time it takes to test the rule condition using that

network, and the disk or memory space the network occupies. The average time for the rule condition

matching through a network is estimated as the cost of that network, as defined in the Gator cost model.

The cost is a product of two terms, namely time (CPUweight and IOweight) and frequency (Fi and Fd). Thus

the cost is a dimensionless quantity. Although it does not have any unit, it is nonetheless a measure of time

that is spent for rule condition matching through the network. This measure is useful only to compare the

relative performance of networks.

In addition to the cost, a measure of relative merit of a network is its expected space requirement. Space

occupied by a network is estimated as the sum of the page() quantity of all of its nodes, which gives the

number of disk pages occupied by the network. The performance of the optimizer in terms of optimization

time is also assessed.

6.1 Cost of a network

The following table shows the costs of five types of networks for five randomly generated rule graphs. Each

rule graph has five rule condition elements. In general, it has been found that the cost of a Gator network

is always less than those of a Rete and a TREAT network for the same rule. The difference in cost varies;

in most cases it is large.

Cost Comparison for Sample Networks
Rule Size Gator TREAT Best Rete Worst Rete Worst
0 5 1.44E+06 1.48E+06 3.15E+09 2.75E+12 2.75E+12
1 5 2 '-,1 +-', 3.03E+05 1.55E+08 1.44E+11 1.44E+11
2 5 9.46E+04 2.87E+05 2.27E+10 5.43E+11 5.43E+11
3 5 1.63E+01 4.11E+01 9.16E+02 2.83E+04 2.83E+04
4 5 5.17E+04 1.06E+05 2 ". +d 9.55E+10 9.55E+10

It is not surprising that the Gator network chosen has minimum cost for each rule. But the difference

in cost between different types of networks is interesting. In the above table, the difference in cost between

different networks for all rules except rule 2 and 3 are similar. Rule 2 shows a large difference in costs

and rule 3 shows a small difference. As shown in the cost model, network cost is a function of a large

number of parameters, and it is difficult to isolate the affects of these parameters analytically. Therefore, an


o 2000 -


1000- TREAT


0 -
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018


Figure 8: Network Cost increases as Selectivity(value) of predicates increase.

experimental approach has been taken to study the effect of various database parameters on the performance

of the discrimination network, particularly on the cost value of the network. The following discussion

illustrates what was observed.

6.2 Predicate and join selectivity

Selectivity of the predicate associated with a tuple variable (RCE) is defined as the fraction of tuples in the

relation associated with the tuple variable that satisfy the predicate. In figure 8, the cost of networks is

plotted against the SeleciThresh a parameter to the simulator. Nodes having small selectivity are assigned

selectivity value randomly within the range (O,SeleciThresh ]. Therefore, larger value of SeleciThresh means

larger value of selectivity for predicates and hence more tuples filtered toward the a nodes of the network.

Parameter B3 is the fraction of nodes having small selectivity. The parameter A3 (= 1 B3) is the fraction

of the nodes having large selectivity, which is randomly chosen within the range (SelectThresh,1.O].

At small values of SeleciThresh, the cost of Gator, TREAT and Rete networks are low, indicating that

the discrimination networks do not see much activity. One interesting phenomenon in this region is that the

Rete network beats TREAT, and at very low selectivity values, Gator is in fact a Rete. This is expected

because the 3 nodes are very small in this region. The cost to maintain the 3 nodes is offset by the savings

in the cost of joins. As A3 [= 0.2, only a tiny fraction of nodes have poor selectivity, most of the nodes are

highly selective. TREAT does not take advantage of this and performs poorly. Whereas Rete keeps these

profitable 3 nodes and outperforms TREAT. However, the difference in cost is small and not very significant.

The superiority of Gator becomes startling at higher values of selectivity threshold. The cost of Gator

increases almost linearly with selectivity threshold, a very shallow slope, whereas Rete and TREAT show

a vastly more rapid increase. After a point TREAT outperforms Rete and keeps doing so as the value of

SeleciThresh increases. This also supports the fact that at large values of selectivity, most of the tokens

will propagate through the selection predicates. Keeping this large volume of incoming data in 3 nodes is

expensive compared to the profit they yield. Therefore, TREAT, which does not keep these 3 nodes, is

expected to perform better than Rete. Gator, however, keeps only those / nodes which provide more profit

than their cost of maintenance, thereby outperforming both Rete and TREAT by an order of magnitude in


Figure 9 shows the effect of average JSF on the network cost. The effect of JSF over network cost is

similar to that of predicate selectivity. Both the selectivities indicate the permeability of the filtering action

of the discrimination network. Thus, the larger the values of the parameters, the more the data flow, and

consequently, the higher the cost of the network.

Figure 10 demonstrates the effect of varying the average JSF of the join conditions on the total space (in

pages) occupied by the memory nodes in the network. A very similar graph is observed if selection predicate

selectivity (selectivity threshold) is varied on the x axis instead of JSF. Intuitively, a TREAT network should

have the lowest space requirement, Rete the highest, and Gator in between. The data obtained in this regard

support this intuition. There is another interesting observation: the space requirement of Gator is near to

the minimum, almost equal to that of TREAT. This is a very important result. One of the reasons for which

TREAT is favored for disk bound production systems is its low space requirement. These results show that

the space requirement of Gator is very close to that of TREAT, while its performance is much better than





0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01

Figure 9: Effect of JSF on Network Cost

TREAT, as is suggested by the difference in cost values. This fact brings out Gator as the clear winner over

Rete and TREAT, considering space and time performance together. The low space requirement of Gator

can be explained by the cost functions discussed before. A major portion of the cost of the 3 nodes, the

most expensive among all nodes, is the UpdateCost, which depends on the size of the node. Large 3 nodes

take a lot of time to maintain as tokens flow through the network. Hence, the optimizer avoids creating large

3 nodes.

6.3 Rule size and optimization time

The number of RCE's in a rule determines the performance of the optimizer. The size of the search space

of the optimizer increases exponentially with the number of the nodes in the rule graph. But the optimizer

keeps the growth of its search space in check by pruning out sub-optimal subnetworks using constraints and

heuristics. It has been found that, as shown in figure 11, the optimizer can find the Best Gator network

within one second for rules with up to five RCE's. At 11 RCE's, it takes roughly one minute to find the




S105- RETE


0 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.01

Figure 10: Network space vs. average JSF

best Gator network. Rules in any database will rarely contain more than 12 RCE's, thus performance of

the dynamic programming-based optimizer will be adequate for most situations. Randomized optimization

methods are being investigated to handle rules with more than 12 RCE's [13].

6.4 Generality of the Gator network structure

One of the targets of the design of the Gator network optimizer was that it will not favor any particular

discrimination network configuration; it will always choose the best, in terms of network cost, regardless

of whether it is Rete, TREAT or anything in between. Results obtained from the optimizer show that the

optimizer is indeed choosing the cheapest network without favoring any particular configuration. It has been

found that, at very low level network activity, characterized by small values of update frequency, selectivity

and JSF, Rete style networks are better than TREAT style networks. By the term Rete style, we mean

networks where most 3 nodes have 2 inputs. These networks have almost a binary tree structure. When it

is a left deep or right deep binary tree, it is a pure Rete network. As the level of database activity increases,



< 100


2 4 6 8 10 12 14

Figure 11: Time taken to produce optimized Gator and Rete networks using dynamic programming vs. the
number of rule condition elements. A TREAT network can be constructed in a fraction of a second without
optimization for rules with any reasonable number of RCE's.

TREAT style networks seem to be a better choice. These networks have fewer 3 nodes, thus most of the

3 nodes have multiple inputs. This transition of choice is smooth and consistent. As one or more of the

parameters are varied from low to high values, the transition from one type of network to the other can

be seen. Figure 12(b) shows the network for the rule graph in figure 12(a) when selectivity threshold is

very small, .0008. All the 3 nodes have two inputs, except one that has three inputs. In figure 12(c), the

selectivity values are larger, which has eliminated one 3 node, in addition to rearranging other a and 3

nodes. Figure 12(d) has only three 3 nodes, each taking inputs from three a nodes.

7 Related work

The Gator network is a descendant of Rete and TREAT [5, 12]. The Gator network is only useful with an

optimizer or at least a good set of heuristics for constructing a network for a particular rule or set of rules. The

feasibility of generating an optimizer for Rete networks was demonstrated by Ishida [11]. Use of heuristics to

construct a good discrimination network for testing active database rule conditions was discussed by Fabret

1 a(0) o(4) (1l) a(3) 0(5) a(6) o(7) a(2)

2 5

Rule Graph (a)
/ Network when SelectThresh= 0.005
u(4) a(0) u(6) U(5) a(1) a(7) a(2) u(3) A = 0.4 B = 0.6
P (c)

S\a(0) a(4) (1) a(2j (7) o(( ) ) (3) a(6)

/P Network when SelectThresh = 0.0008
A3= 0.4, B3= 0.6
() Network when SelectThresh = 0.02
p A3 = 0.4, B3 = 0.6


Figure 12: Variation of network structure depending on rule condition selectivity.

et al. [3], but that work did not introduce a general discrimination network structure, a detailed cost model,

or a search-based optimization strategy like the ones given in this paper. The results presented in this paper

build on fundamental query optimization and query plan cost estimation techniques [15]. Work on extended

query optimization problems such as optimizing large join queries and considering bushy join trees [9, 10] is

also relevant. There is also some similarity between the problem of optimizing the discrimination network

for a collection of rules, and optimizing an execution plan for simultaneously evaluating a set of queries

[4, 14, 16]. A major difference between work on discrimination network optimization and query optimization

is that in discrimination network optimization, update frequency is a key variable. Moreover, discrimination

network construction requires making decisions about whether or not to construct memory nodes, and that

requires considering the cost of maintaining that memory node. In query processing there is no need to

consider update frequency, and their is nothing analogous to maintaining a memory node.

8 Summary and conclusion

This paper has introduced a new, generalized discrimination network structure called Gator that can be used

to test rule conditions in active databases and production systems. Gator is extremely general, capturing

both the Rete and TREAT structures as special cases. The key difference between Gator and Rete is

that in Gator, a multiple-input (3) node can have more than two inputs. Because the Gator structure is

so general, an optimizer is essential to pick a good structure for a rule depending on the environment. A

dynamic programming optimization strategy somewhat akin to a query optimization method [15], but taking

into consideration additional factors such as update frequency and memory node size, has been designed,

implemented, and tested in a simulation. Results show that Gator can be expected to outperform Rete and

TREAT by and order of magnitude or more in terms of time in some cases. Gator also uses space effectively

since it is reluctant to materialize large 3 nodes. The dynamic programming strategy for Gator optimization

is currently workable for rules with up to roughly 11 condition elements.

Preliminary results from a study of optimization of Gator networks using randomized algorithms shows

that it is feasible to build optimized networks for rules with up to 24 rule condition elements in a few seconds

[13]. Plans for future work include optimization of Gator networks for multiple rules with subexpression

sharing, extending the Ariel system to use the Gator algorithm instead of the currently used modified

TREAT strategy, and then testing Gator in a real database environment. In addition, a variation of Gator is

being considered that would support a new match strategy called collection-oriented match [1]. A collection-

oriented Rete strategy has given up to a 1000-times speedup for some main-memory OPS5 applications.

Finally, parallel versions of Gator and collection-oriented Gator are also being considered.


[1] Anurag Acharya and Milind Tambe. Collection-oriented match: Scaling up the data in production
systems. Technical Report C'IU-CS-92-218, Carnegie-Mellon University, December 1992.

[2] L. Brownston, R. Farrell, E. Kant, and N. Martin. Programming Expert Systems in OPS5: an Intro-
duction to Rule-Based Programming. Addison Wesley, 1 -.

[3] Francoise Fabret, Mireille Regnier, and Eric Simon. An adaptive algorithm for incremental evaluation
of production rules in databases. In Proceedings of the VLDB Conference, 1993.

[4] S. Finkelstein. Common expression analysis in database applications. In Proceedings of the AC if
SIC, iOD International Conference on Management of Data, pages 235-245, 1982.

[5] C. L. Forgy. Rete: A fast algorithm for the many pattern/many object pattern match problem. Artificial
Intelligence, 19:17-37, 1982.

[6] Eric N. Hanson. Rule condition testing and action execution in Ariel. In Proceedings of the AC if
SIC, iOD International Conference on Management of Data, pages 49-58, June 1992.

[7] Eric N. Hanson. Gator: A discrimination network suitable for optimizing production rule matching.
Technical Report CIS-TR-007-93, University of Florida CIS Dept., February 1993. Available by anony-
mous ftp from See README file under /cis/techreports.

[8] Mohammed Hasan. Optimization of discrimination networks for active databases. Master's thesis,
University of Florida, CIS Department, November 1993.

[9] Yiannis loannidis and Younkyung Cha Kang. Randomized algorithms for optimizing large join queries.
In Proceedings of the AC if SIC, iOD International Conference on Management of Data, pages 312-321,
May 1990.

[10] Yiannis loannidis and Younkyung Cha Kang. Left-deep vs. bush trees: An analysis of strategy spaces and
its implications for query optimization. In Proceedings of the AC if SIC, iOD International Conference
on Management of Data, pages 168-177, May 1991.

[11] Toru Ishida. Optimizing rules in production system programs. In Proc. AAAI National Conference on
Artificial Intelligence, pages 699-704, 1988.

[12] Daniel P. Miranker. TREAT: A better match algorithm for AI production systems. In Proc. AAAI
National Conference on Artificial Intelligence, pages 42-47, August 1 .

[13] Jayashree Rangarajan. A randomized optimizer for rule condition testing in active databases. Master's
thesis, University of Florida, CIS Department, December 1993.

[14] A. Rosenthal and U.S. Chakravarthy. Anatomy of a modular multiple query optimizer. In Proc. of
VLDB Conf., pages 230-239, 1988.

[15] P. Selinger et al. Access path selection in a relational database management system. In Proceedings of
the AC if SIC, iOD International Conference on Management of Data, June 1979. (reprinted in [17]).

[16] Timos Sellis. Global query optimization. AC if TODS, 13(1):23-52, 1988.

[17] Michael Stonebraker, editor. Readings in Database Systems. Morgan Kaufmann, 1988.

[18] Yu-wang Wang and Eric N. Hanson. A performance comparison of the Rete and TREAT algorithms
for testing database rule conditions. In Proc. IEEE Data Eng. Conf., pages 88-97, February 1992.

[19] S. B. Yao. Approximating block accesses in database organizations. Communications of the AC i!
20(4), 1977.

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs