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

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

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

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

Basic Architecture 05/02/2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

THANK YOU 05/02/2006