1. The Design of an Acquisitional Query Processor For Sensor Networks
Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong
Presentated By
Muhammed Z. Miah
May 02, 2006

2. Goals Provide a query processor for data collection in sensor networks
Use acquisitional techniques to reduce power consumption compared to traditional passive systems
05/02/2006

3. Acquisitional Issues What is meant by acquisitional techniques?
Where, when, and how often data is physically acquired (sampled) and delivered to query processing operators
05/02/2006

4. Four ACQP-related questions
When should samples for a particular query be taken?
What sensors nodes have relevant data to a particular query?
In what order should samples for this query be taken, and how should sampling be interleaved with other operations?
Is it worth expending computational power or bandwidth to process and relay a particular sample?
05/02/2006

5. Basic Architecture
05/02/2006

6. Query Flow Queries are submitted at a powered PC (base station)
Parsed, optimized and then sent into the sensor network, where they are disseminated and processed,
With results following back up the routing tree was formed as the query propagated
05/02/2006

7. Data Model Sensors Table – one row/node per instant in time
Records in these table are materialized (acquired) only as needed to satisfy the query, and are stored only for a short period of time or delivered directly out of the network
Projections and/or transformations of tuples from sensors table may be stored in materialized points
Missing sensor produce NULLs
NULLs are filtered out in WHERE clause
Reading from sensors table of each node must be collected at some common node
05/02/2006

8. Acquisitional Query Language
SQL-like queries in the form of SELECT-FROM-WHERE
Support for selection, join, projection, and aggregation
Also support for sampling, windowing, and sub-queries
Not mentioned is the ability to log data and actuate physical hardware
05/02/2006

9. Acquisitional Query Language
Example:
SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s
Once per second for 10 seconds
05/02/2006

10. Queries as a Stream
Sensors table is (conceptually) an unbounded, continuous data stream
Operations such as sort and symmetric join are not allowed on streams
They are allowed on bounded subsets of the stream (windows)
05/02/2006

11. Windows
Windows in TinyDB are fixed-size materialization points over the sensor streams
Materialization points accumulate a small buffer of data that may be used in other queries
Example
CREATE STORAGE POINT recentlight SIZE 8 AS (SELECT nodeid, light FROM sensors SAMPLE INTERVAL 10s) SELECT COUNT(*) FROM sensors AS s, recentlight AS r1 WHERE r.nodeid = s.nodeid AND s.light < r1.light SAMPLE INTERVAL 10s
05/02/2006

12. Temporal Aggregation
In addition to aggregation over values, also supports temporal aggregation
Example
SELECT WINAVG(volume, 30s, 5s) FROM sensors SAMPLE INTERVAL 1s
Average volume over last 30 secs once every 5 secs (6 readings), sampling once per sec
05/02/2006

13. Event-Based Queries An alternative to continuous polling for data
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
05/02/2006

14. Lifetime-Based Queries
Example
SELECT nodeid, accel FROM sensors LIFETIME 30 days
Nodes perform cost-based analysis in order to determine data rate
Nodes must transmit at the root’s rate or at an integral divisor of it
05/02/2006

15. Power-Based Optimization
Queries optimized by base station before dissemination
Cost-based optimization to yield lowest overall power consumption
Cost dominated by sampling and transmitting
Optimizer focuses on ordering joins, selections, and sampling on individual nodes
05/02/2006

16. Metadata Each node contains metadata about its attributes
Nodes periodically send metadata to root
Metadata also contains information about aggregate functions
Information about cost, time to fetch, and range is used in query optimization
05/02/2006

17. Dissemination and Routing
Build semantic routing tree (SRT)
SRT nodes choose parents based on semantic properties as well as link quality
Parent nodes keep track of the ranges of values for children
05/02/2006

18. Evaluation of SRT SRT are limited to constant attributes
Even so, maintenance is required
Possible to use for non-constant attributes but cost can be prohibitive
Can reduce no. of nodes that must disseminate queries for highly correlated attributes in routing tree
05/02/2006

19. Query Execution
First nodes sleep, then they wake, sample sensors and apply operators to generated locally and received from neighbors, and then delivers results to their parents
Aggregate data that is sent back to the root
Prioritize data that needs to be sent
Naïve – FIFO and tuples dropped if do not fit in queue
Winavg – Two results at the head of queue are averaged
Delta – Send result with most change
05/02/2006

20. Conclusion
TinyDB provides a simple yet powerful interface to sensor networks
TinyDB takes measures to conserve power at all phases of query processing
05/02/2006

21. THANK YOU
05/02/2006