The Design of an Acquisitional Query Processor For Sensor Networks Samuel Madden, Michael J. Franklin, Joseph M. Hellerstein, and Wei Hong Presentation by John Lynn

Overview Goals Goals Acquisitional Query Language Acquisitional Query Language Optimizations Optimizations Future Work Future Work Conclusions Conclusions Discussion Discussion

Goals Provide a query processor-like interface to sensor networks Provide a query processor-like interface to sensor networks Use acquisitional techniques to reduce power consumption compared to traditional passive systems Use acquisitional techniques to reduce power consumption compared to traditional passive systems

How? What is meant by acquisitional techniques? What is meant by acquisitional techniques? Where, when, and how often. Where, when, and how often. Four related questions Four related questions When should samples be taken? When should samples be taken? What sensors have relevant data? What sensors have relevant data? In what order should samples be taken? In what order should samples be taken? Is it worth it? Is it worth it?

What’s the big deal? Radio consumes as much power as the CPU Radio consumes as much power as the CPU Transmitting one bit of data consumes as much energy as 1000 CPU instructions! Transmitting one bit of data consumes as much energy as 1000 CPU instructions! Message sizes in TinyDB are by default 48 bytes Message sizes in TinyDB are by default 48 bytes Sensing takes significant energy Sensing takes significant energy

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

An Acquisitional Query Language Example: SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s Example: SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s Sensors viewed as a single table Sensors viewed as a single table Columns are sensor data Columns are sensor data Rows are individual sensors Rows are individual sensors

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

Windows Windows in TinyDB are fixed-size materialization points Windows in TinyDB are fixed-size materialization points Materialization points can be used in queries Materialization points can be used in 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 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

Temporal Aggregation Example SELECT WINAVG(volume, 30s, 5s) FROM sensors SAMPLE INTERVAL 1s Example SELECT WINAVG(volume, 30s, 5s) FROM sensors SAMPLE INTERVAL 1s Receive only 6 results from each sensor instead of 30 Receive only 6 results from each sensor instead of 30

Event-Based Queries An alternative to continuous polling for data 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 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

Lifetime-Based Queries Example SELECT nodeid, accel FROM sensors LIFETIME 30 days Example SELECT nodeid, accel FROM sensors LIFETIME 30 days Nodes perform cost-based analysis in order to determine data rate 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 Nodes must transmit at the root’s rate or at an integral divisor of it

Lifetime-Based Queries Tested a mote with a 24 week query Tested a mote with a 24 week query Sample rate was 15.2 seconds per sample Sample rate was 15.2 seconds per sample Took 9 voltage readings over 12 days Took 9 voltage readings over 12 days

Optimization Three phases to queries Three phases to queries Creation of query Creation of query Dissemination of query Dissemination of query Execution of query Execution of query TinyDB makes optimizations at each step TinyDB makes optimizations at each step

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

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

Using Metadata Consider the query SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s Consider the query SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s Order of magnitude difference between sample costs Order of magnitude difference between sample costs Three options Three options Measure accel and mag, then process select Measure accel and mag, then process select Measure mag, filter, then measure accel Measure mag, filter, then measure accel Measure accel, filter, then measure mag Measure accel, filter, then measure mag First option always more expensive. Second option an order of magnitude more expensive than third First option always more expensive. Second option an order of magnitude more expensive than third Second option can be cheaper if the predicate is highly selective Second option can be cheaper if the predicate is highly selective

Using Metadata Another example SELECT WINMAX(light, 8s, 8s) FROM sensors WHERE mag > x SAMPLE INTERVAL 1s Another example SELECT WINMAX(light, 8s, 8s) FROM sensors WHERE mag > x SAMPLE INTERVAL 1s Unless mag > x is very selective, it is cheaper to check if current light is greater than max Unless mag > x is very selective, it is cheaper to check if current light is greater than max Reordering is called exemplary aggregate pushdown Reordering is called exemplary aggregate pushdown

Dissemination Optimization Build semantic routing tree (SRT) Build semantic routing tree (SRT) SRT nodes choose parents based on semantic properties as well as link quality SRT nodes choose parents based on semantic properties as well as link quality Parent nodes keep track of the ranges of values for children Parent nodes keep track of the ranges of values for children

Evaluation of SRT SRT are limited to constant attributes SRT are limited to constant attributes Even so, maintenance is required Even so, maintenance is required Possible to use for non-constant attributes but cost can be prohibitive Possible to use for non-constant attributes but cost can be prohibitive

Evaulation of SRT Compared three different strategies for building tree, random, closest, and cluster Compared three different strategies for building tree, random, closest, and cluster Report results for two different sensor value distributions, random and geographic Report results for two different sensor value distributions, random and geographic

SRT Results

Query Execution Queries have been optimized and distributed, what more can we do? Queries have been optimized and distributed, what more can we do? Aggregate data that is sent back to the root Aggregate data that is sent back to the root Prioritize data that needs to be sent Prioritize data that needs to be sent Naïve - FIFO Naïve - FIFO Winavg – Average top queue entries Winavg – Average top queue entries Delta – Send result with most change Delta – Send result with most change Adapt data rates and power consumption Adapt data rates and power consumption

Prioritization Comparison Sample rate was K times faster than delivery rate. Sample rate was K times faster than delivery rate. Readings generated by shaking the sensor Readings generated by shaking the sensor In this example, K = 4 In this example, K = 4

Adaptation Not safe to assume that network channel is uncontested Not safe to assume that network channel is uncontested TinyDB reduces packets sent as channel contention rises TinyDB reduces packets sent as channel contention rises

Future Work Selectivity of operators based upon range of sensor Selectivity of operators based upon range of sensor Exemplary aggregate pushdown Exemplary aggregate pushdown More sophisticated prioritization schemes More sophisticated prioritization schemes Better re-optimization of sample rate based upon acquired data Better re-optimization of sample rate based upon acquired data

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

Discussion Is this the best way (right way?) to look at a sensor network? Is this the best way (right way?) to look at a sensor network? Is their approximation of battery lifetime sufficient? Is their approximation of battery lifetime sufficient? Was their evaluation of SRT good enough? Was their evaluation of SRT good enough?