The Design of an Acquisitional Query Processor For Sensor Networks Samuel Madden, Michael J....
-
date post
21-Dec-2015 -
Category
Documents
-
view
223 -
download
2
Transcript of The Design of an Acquisitional Query Processor For Sensor Networks Samuel Madden, Michael J....
The Design of an Acquisitional Query Processor For Sensor Networks
Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong
Presentation by Xin Liu
Outline
Introduction Acquisitional Query Language Query Optimization Query Dissemination and Routing Query Execution Summary Discuss
Introduction
A sensor node is a battery-powered, wireless computer, which power is extremely low. So reducing power consumption is important.
ACQP (ACquisitional Query Processor):
use acquisitional techniques to reduce power consumption compared to traditional passive systems.
Introduction (cont.)
What is meant by acquisitional techniques? Where, when, and how often to acquire data.
Four related questions: When should samples be taken? What sensors have relevant data? In what order should samples be taken? Is it worth to process and relay a sample?
Introduction (cont.)
TinyDB (ACQP engine) is a distributed query processor which runs on each of the nodes in a sensor network.
TinyDB runs on the Berkeley Mica mote platform, on top of the TinyOS operating systems.
Acquisitional Query Language Data Model
Entire sensor network viewed as one single, infinitely-long logical table: sensors
Columns consist of all the attributes defined in the network. Rows are individual sensor data.
Queries as a Stream Sensors table is an unbounded, continuous data stream. Operations such as sort and symmetric join are not allowed.
SQL-like queries in the form of SELECT-FROM-WHERESELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s
Acquisitional Query Language Event-Based Queries Instead of continuous polling for data, query runs only when
interesting events happens. Example:
ON EVENT bird-detector(loc) SELECT AVG(light), AVG(temp), event.loc FROM sensors AS s WHERE dist(s.loc, event.loc) < 10m SAMPLE INTERVAL 2s FOR 30s
Acquisitional Query Language Lifetime-Based Queries
Example:
Nodes perform cost-based lifetime estimate to determine data rate.
Nodes must transmit at the root’s rate or at an integral divisor of it.
SELECT nodeid, accel FROM sensors LIFETIME 30 days
Query Optimization
Query optimization is power-based, the goal is to yield lowest overall power consumption.
Queries are optimized by base station before dissemination.
Power consumption dominated by: sampling transmitting
Query Optimization Metadata Management
Each node contains metadata about its attributes.
Nodes periodically send metadata to root.
Information about cost, time to fetch, and range is used in query optimization.
Query Optimization Ordering of Sampling and Pridicates
Consider the query:
1s
Three options: sample accel and mag, then process select sample mag, filter, then sample accel sample accel, filter, then sample mag
First option is always more expensive. If Smag is more selective than Saccel , then second is cheaper. If Saccel is highly selective, the third can be cheaper.
SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s
Query Optimization Event Query Batching
Consider the following query:
Maybe multiple instances of query run at the same time. Thus, the independent sampling and delivering results will consume significant energy.
What can we do with this?
ON EVENT e(nodeid) SELECT a1
FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k
Query Optimization Event Query Batching
Solution: convert external events into a stream of events, and rewrite the query as a sliding window join between events and sensors.
When an event arrives, add it to the buffer of events. When a sensor tuple s arrives, events older than k seconds
are dropped from the buffer and s is joined with the remaining events.
SELECT s.a1 FROM sensors AS s, events AS e WHERE s.nodeid = e.nodeid AND e.type = e AND s.time – e.time <= k AND s.time > e.time SAMPLE INTERVAL d FOR k
ON EVENT e(nodeid) SELECT a1
FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k
Dissemination and Routing
Intuition: if a node knows that none of its children will satisfy
the selection predicate, say because they have constant attribute values outside the predicate’s range, it need not forward the query down.
What can we do?
SELECT light FROM sensors WHERE loc.x > 3 AND loc.x < 7
Dissemination and Routing Semantic Routing Tree
Semantic Routing Tree
Each node stores a interval representing the range of A values beneath each of its children. (A is a constant attribute)
When a query q with a predicate over A arrives at node n, n checks if any child’s value of A overlaps with the range of A in q. If so, forwards the query and prepares to receive results. Otherwise, the query is not forward.
Dissemination and Routing Semantic Routing Tree
The gray nodes participate in the query, while white nodes doesn’t.
Dissemination and Routing Semantic Routing Tree
Building Semantic Routing Tree Flooding SRT building request. This request includes the name
of the attribute A over which the tree should be built.
Each node forwards the request to the children. The leaf node selects a parent, and reports the value of A to its parent.
When a node heard from all of its children, it choose a parent and sends a selection message indicating the range of values of A which it and its descendents cover.
The parent records this interval with child node id and proceeds to choose its own parent in the same manner, until root.
SRT are limited to constant attributes, but maintenance is required.
Query Execution Prioritizing Data Delivery
The radio queue of sensor node could be overflow, how to deal with this?
Approach: prioritize data that need to be sent. Three simple prioritization schemes:
Naive – no tuple is considered more valuable, just FIFO
Winavg – average two results at head of queue when queue fills.
Delta – each tuple is assigned a score relative to its difference form the most recent value successfully transmitted, delivery the tuple with the highest score first, discard the lowest when queue fills.
Query Execution Prioritization Comparison
Sample rate was K times faster than delivery rate. In this example, K = 4
Query Execution Adapting Rates
Adaption based on Network contention TinyDB monitors channel contention and adaptively
reduces the number of packets transmitted as contention rises.
Adaption based on Power consumption Goal: adapting tuple delivery rate to meet specific
lifetime requirements. Approach:
Compare current voltage to predicted voltage Re-estimate power consumption characteristics of device Re-run lifetime calculation to determine rates
Summary
Discuss important aspects of an acquisitional query language, introducing event and lifetime clauses.
Query optimization Ordering the sampling operators Event query batching
Use semantic routing tree to disseminate query.
Query execution Prioritizing data according to quality Techniques to adapt the transmission and sampling rate
Discuss
Main Contribution: TinyDB and other early work are an important first step
to investigate some Database research issues in Sensor Network.
Provide simple extensions to SQL for controlling data acquisition.
Proposed a series of acquisitional techniques which provide significant reductions in power consumption.
Related Work: TAG (Tiny AGgregation Service) – UC Berkeley Cougar Sensor Database Project – Cornell Directed Diffusion – UCLA and ISI
Discuss (cont.)
Future Work: Ordering exemplary aggregate in query optimization
Better re-optimization of sample rate based upon acquired data
More sophisticated prioritization schemes
Mechanisms allowing users to express their prioritization preferences
References TinyDB http://telegraph.cs.berkeley.edu/tinydb/
Query processing challenges in sensor networks http://telegraph.cs.berkeley.edu/tinydb/tinydb_tutorial.ppt
Query Processing For Streaming Sensor Data, Samuel R. Madden, Ph.D Quilifying Exam Proposal, May 2002
Fjording the Stream: An Architecture for Queries over Streaming Sensor Data, Samuel R. Madden, Michael J. Franklin, ICDE 2002
TAG: a Tiny Aggregation Service for Ad-Hoc Senser Network, Samuel R. Madden, Michael J. Franklin, etc., OSDI, Dec. 2002
Telegraph Research Project http://telegraph.cs.berkeley.edu/
Cougar http://www.cs.cornell.edu/database/cougar/
Appendix
A stable release of TinyDB is included with the TinyOS 1.1 release.
TinyDB provides a PC interface written in Java.
Appendix in the UC Berkeley Botanical Garden, 50 "micromote" sensors
are dangled like earrings from the branches of 3 redwood trees to monitor their growth.