View Management Techniques and Their Application to Data Stream Management - Evolving Application Domains of Data Warehousing and Mining - page 103

1997; Luo and Yu, 2008) where updates should
be propagated immediately (or only with a short
delay) to the materialized views.

DSMS usually make use of such joint query
plans. In Aurora, (Carney et al., 2002) the user
explicitly defines the joint query plan manually
using a graphical language, in which each operator
is represented as a box. The user adds so-called
connection points to a query plan. Aurora collects
runtime statistics and loops through the subnet-
works between connection points and then locally
optimizes each such subnetwork if necessary by
applying a set of heuristics.
The STREAM system creates joint query plans
from declaratively defined queries. However, it
merges only exactly matching subexpressions
(Motwani et al., 2003). Thus, if a new query
is added, an individual query plan is produced
for that new query. If possible, operators from
the new query plan are merged with matching
operators from the existing joint query plan.
Although this approach produces some resource
sharing, it suffers from eventual deterioration of
the joint query plan while queries are registered
and deregistered.
Although some systems address the issue of
creating joint query plans, there is still much op-
portunity for research on joint query planning.
In particular, the area of continuous query plan
adaptation is yet not comprehensively explored.
Query optimization for continuous queries must
consider statistics about relations, streams and
subqueries such as selectivity and arrival rates.
However, in the case of DSMS these estimators
may fluctuate. Therefore, joint query plans must be
adapted to these changing parameters.Algorithms
are required that are able to efficiently update joint
query plans such that optimal plans (for different
quality requirements, e.g., memory or CPU time)
can be approximated.

continuous query evaluation
and view Selection

Due to the high arrival rates of data in a DSMS,
it aims at processing queries in-memory only.
Multiple queries are evaluated against the same
set of data streams simultaneously. Therefore, it is
vital that queries are not processed in an isolated
fashion with an individual plan for each query.
Instead, joint query plans should be used which
facilitate sharing of resources such as memory
and CPU time. A shared operator in a joint query
plan can be regarded as a materialized view that
is used for answering the queries represented by
its parent operators.
Continuous query optimization therefore
concentrates on finding efficient query plans for
executing multiple queries in parallel. This is
similar to batch processing of simple relational
queries where identification of common subex-
pressions is utilized for optimization of execution
plans. Thus, instead of creating an individual
execution plan for each query, a DSMS must
create a single execution plan for a workload of
registered queries and must adapt it to changing
circumstances, such as varying data arrival rates.
This problem is very similar to the view selection
problem. In particular, speaking in terms of our
view selection classification hierarchy, continuous
query planning can be seen as a case of dynamic
view selection whereas no reuse policy is required
in this case. Candidate views are common subex-
pressions of continuous queries.
Furthermore, regarding the resource con-
straints, a DSMS has to cope at the same time
with limited storage due to the aim of in-memory
query processing and time constraints, because
queries must be evaluated in real-time. However,
the optimization goals of query response time and
maintenance costs are identical in this case.

optimization of Stream Joins

The particular characteristics of window opera-
tors cause new problems for stateful operators in
a DSMS which must be considered for resource
sharing and query plan optimization as well. One