At the core of the system is a single eddy that routes tuples to operators
for processing. Each operator has an input queue of tuples waiting to be processed
by it. Operators dequeue tuples, process them, and return them to the
eddy for further routing. The eddy maintains a pool of tuples that are waiting
to be placed on the input queue of some operator. When the pool is empty,
the eddy can schedule a scan operator to cause more tuples to be fetched or
produced.
Multiple Queries
The goal of the multiple-query solution in the absence of join is to use a
single eddy to route tuples among all of the continuous queries currently in
the system. In our solution, tuples are never copied: two di?®erent queries with
two di?®erent predicates over the same relation should operate over exactly
the same tuples. This is important for two reasons: tuples occupy storage
that must be conserved, and copying takes valuable processor cycles. A key
part of the multiple query solution without join is the grouped filter that
allows us to share work between multiple selections over the attribute of a
relation.
Fig. 16. The Architecture of Continuous Query processing [11].
317
Jinbao Li, Zhipeng Cai, and Jianzhong Li
Figure 16 shows the basic architecture. Users submit queries Q1, Q2 and
Q3, consisting of selection predicates S1 through S6, over two fields, a and b
of source S. All the queries are submitted to a single eddy, with just one filter
operator (and its associated grouped filter) for field a, and one for field b.
Pages:
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510