Event Query Batching to Conserve Power
As a second example of the benefit of power-aware optimization, we consider
the optimization of the query:
ON EVENT e(nodeid)
SELECT a1
FROM sensors AS s
WHERE s.nodeid = e.nodein
SAMPLE INTERVAL d FOR k
This query will cause an instance of the internal query (SELECT ...) to be
started every time the event e occurs. The internal query samples results at
every d seconds for a duration of k seconds, at which point it stops running.
Note that, by the semantics formulated above, it is possible for multiple instances
of the internal query to be running at the same time. If enough such
queries are running simultaneously, the benefit of event-based queries (e.g. not
having to poll for results) will be outweighed by the fact that each instance of
the query consumes significant energy sampling and delivering (independent)
results. To alleviate the burden of running multiple copies of the same identical
query, we employ a multi-query optimization technique based on rewriting.
To do this, we convert external events (of type e) into a stream of events, and
rewrite the entire set of independent internal queries as a sliding window join
between events and sensors, with a window size of k seconds on the event
stream, and no window on the sensor stream. For example:
SELECT a1
FROM sensors AS s
WHERE s.nodeid = e.nodein
SAMPLE INTERVAL d FOR k
The advantage of this approach is that only one query runs at a time no
matter how frequently the events of type e are triggered.
Pages:
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516