1 / 36

The Design of an Acquisitional Query Processor for Sensor Networks

The Design of an Acquisitional Query Processor for Sensor Networks. CS851 Presentation 2005 Presented by: Gang Zhou University of Virginia. Outline. Application Structure & Design Goals Acquisitional Query Language Power-Aware Optimization Power Sensitive Dissemination and Routing

knut
Download Presentation

The Design of an Acquisitional Query Processor for Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Design of an Acquisitional Query Processor for Sensor Networks CS851 Presentation 2005 Presented by: Gang Zhou University of Virginia

  2. Outline • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  3. Application Structure • Queries submitted in PC • Parsed, optimized in PC • Disseminated and processed in network • Results flow back through the routing tree

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

  5. How? • What is meant by acquisitional techniques? • Where, when, and how often data is acquired and delivered to query processing operators • 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 samples?

  6. What’s the big deal? • Radio is expensive • Sensing takes significant energy • Four Energy Levels: • Snoozing • Processing • Processing and receiving • Transmitting

  7. Roadmap • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  8. An Acquisitional Query Language • SQL-like queries in the form of SELECT-FROM-WHERE SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s • Sensors viewed as a single table • Unbounded, continuous data stream of values • Columns are sensor data • Rows are individual sensors

  9. Why Windows? • Sensors table is 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)

  10. Windows • Windows in TinyDB are fixed-size materialization points over sensor streams. • Materialization points can be used in queries • ExampleCREATE 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

  11. Temporal Aggregation • Why Aggregation? • Reduce the quantity of data that must be transmitted through the network • Example SELECT WINAVG (volume, 30s, 5s) FROM sensors SAMPLE INTERVAL 1s • Report the average volume over the last 30 seconds once every 5 seconds, sampling once per second • How about spacial aggregation or spacial-temporal aggregation? • It’s hard; needs communication; depending on routing tree…

  12. Event-Based Queries • An alternative to continuous polling for data • ExampleON 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 • Currently, events are only signaled on the local node. • How about a fully distributed event propagation system? • What is the gain? • What is the pay?

  13. Lifetime-Based Queries • ExampleSELECT nodeid, accel FROM sensors LIFETIME 30 days • The query specifies that the network should • Run for as least 30 days • Sampling light and acceleration sensors as quick as possible and still maintains the life time goal

  14. Lifetime-Based Queries • Nodes perform cost-based analysis in order to determine data rate for each node ???

  15. Lifetime-Based Queries • Tested a mote with a 24 week query • Sample rate was 15.2 seconds per sample • Took 9 voltage readings over 12 days • Reasonable to drop the first two data? • Reasonable to use data from the first 12 days to fit a line which covers 168 days?

  16. Roadmap • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  17. Power-Aware Optimization • Where? • Queries optimized by base station before dissemination • why? • Cost-based optimization to yield lowest overall power consumption • Cost dominated by sampling and transmitting • How? • Optimizer focuses on ordering joins, selections, and sampling on individual nodes

  18. Reordering Sampling and Predicates • Consider the querySELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s • Three options • Measure accel and mag; then process select • Measure mag; filter; then measure accel • Measure accel; filter; then measure mag • First option always more expensive. • Second option is more expensive than third, when Saccel is more selective than Smag. • Second option can be cheaper if the Smag is highly selective.

  19. Example 2 • Another exampleSELECT MAX (light) FROM sensors WHERE mag > x SAMPLE INTERVAL 8s • Unless mag > x is very selective, it is cheaper to check if current light is greater than the previous maximum and then apply the predicate over mag, rather than first sampling mag. • Reordering is called exemplary aggregate pushdown

  20. Event Query Batching • Have a query ON EVENT e (nodeid) SELECT a1 FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k • Every time e occurs, an instance of the internal query is started. • Multiple independent instances at the same time, independent sampling and data delivering

  21. 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 ON EVENT e (nodeid) SELECT a1 FROM sensors AS s WHERE s.nodeid = e.nodeid SAMPLE INTERVAL d FOR k • Solution: • Convert event e into an event stream • Rewrite the internal query as a sliding window join between the event stream and sensors

  22. Roadmap • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  23. Semantic Routing Trees • Why SRT? • It is a routing tree designed to allow each node to efficiently determine if any of the nodes below it will need to participate in a given query over some constant attributes. • Used to prune the routing tree. • What is SRT? • An SRT is an index over constant attribute A that can be used to locate nodes that have data relevant to the query. • It is an overlay on the network.

  24. How to use SRT? • When a query q with a predicate over A arrives at node n, n checks whether any child’s value of A overlaps the query range of A in q: • If yes, forward the query and prepare to receive results • If no, do not forward q • Is query q applied locally: • If yes, execute the query • If not, ignored

  25. How to build SRT? • Flood the SRT build request down the network • Re-transmitted by every mote until every mote hears it • If a node has no children • Choose a parent p; report the value of A to p • should it be range? • If a node has children • Forward the request, and wait for reply • Upon reply from children, choose a parent p; report to p the range of values of A which it and its descendents cover • Since each constant attribute A may have a separate SRT, is the scheme scalable?

  26. 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

  27. Evaluation of SRT • Compared three different strategies for building tree, random, closest, and cluster • Random: pick a random parent from the nodes with reliable communication • Closest: pick the parent whose attribute value (index attribute) is closest • Cluster: by snooping siblings’ parent selection, each node try to pick the right parent, to minimize the spread of attribute values underneath all of its available parents • Report results for two different sensor value distributions, random and geographic • Random: each attribute value is randomly selected from the interval [0,1000] • Geographic: values among neighbor are highly correlated

  28. SRT Results • The Cluster scheme is superior to the random scheme and the closest scheme. • With the geographic distribution, the performance of the cluster scheme is close to the optimal. • Where is the data of SRT’s overhead?

  29. Roadmap • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  30. Processing Queries • Queries have been optimized and distributed, what more can we do? • Aggregate data that is sent back to the root • Prioritize data that needs to be sent (why??) • Naïve - FIFO • Winavg – average the two results at the queue’s head to make room for the new data • Delta – Send result with most changes • Adapt data rates and power consumption

  31. Prioritization Comparison • Sample rate was 4 times faster than delivery rate. • Readings generated by shaking the sensor • Delta seems to be better

  32. Adaptation • Not safe to assume that network channel is uncontested • TinyDB reduces packets sent as channel contention rises • How much? No detail!

  33. Adaptation

  34. Roadmap • Application Structure & Design Goals • Acquisitional Query Language • Power-Aware Optimization • Power Sensitive Dissemination and Routing • Processing Queries • Conclusions and Future Work • Discussion

  35. Conclusions & Future Work • Conclusions: • Design of an acquisitional query processor for data collection in sensor networks • Evaluation in the context of TinyDB • Future Work: • Selectivity of operators based upon range of sensor • Exemplary aggregate pushdown • More sophisticated prioritization schemes • Better re-optimization of sample rate based upon acquired data

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

More Related