The Design of an Acquisitional Query Processor For Sensor Networks

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

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

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?

5. Basic Architecture

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

21. THANK YOU