The design of an acquisitional query processor for sensor networks
1 / 28

The Design of an Acquisitional Query Processor For Sensor Networks - PowerPoint PPT Presentation

  • Uploaded on

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 Acquisitional Query Language Optimizations Future Work Conclusions Discussion. Goals.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'The Design of an Acquisitional Query Processor For Sensor Networks' - wesley

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The design of an acquisitional query processor for sensor networks

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 Networks

  • Goals

  • Acquisitional Query Language

  • Optimizations

  • Future Work

  • Conclusions

  • Discussion

Goals Networks

  • Provide a query processor-like interface to sensor networks

  • Use acquisitional techniques to reduce power consumption compared to traditional passive systems

How? Networks

  • What is meant by acquisitional techniques?

    • Where, when, and how often.

  • Four related questions

    • When should samples be taken?

    • What sensors have relevant data?

    • In what order should samples be taken?

    • Is it worth it?

What s the big deal
What’s the big deal? Networks

  • Radio consumes as much power as the CPU

  • Transmitting one bit of data consumes as much energy as 1000 CPU instructions!

  • Message sizes in TinyDB are by default 48 bytes

  • Sensing takes significant energy

An acquisitional query language
An Acquisitional Query Language Networks

  • 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

An acquisitional query language1
An Acquisitional Query Language Networks

  • Example:SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s

  • Sensors viewed as a single table

  • Columns are sensor data

  • Rows are individual sensors

Queries as a stream
Queries as a Stream Networks

  • 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)

Windows Networks

  • Windows in TinyDB are fixed-size materialization points

  • 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

Temporal aggregation
Temporal Aggregation Networks

  • ExampleSELECT WINAVG(volume, 30s, 5s) FROM sensors SAMPLE INTERVAL 1s

  • Receive only 6 results from each sensor instead of 30

Event based queries
Event-Based Queries Networks

  • 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

Lifetime based queries
Lifetime-Based Queries Networks

  • ExampleSELECT 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

Lifetime based queries1
Lifetime-Based Queries Networks

  • Tested a mote with a 24 week query

  • Sample rate was 15.2 seconds per sample

  • Took 9 voltage readings over 12 days

Optimization Networks

  • Three phases to queries

    • Creation of query

    • Dissemination of query

    • Execution of query

  • TinyDB makes optimizations at each step

Power based optimization
Power-Based Optimization Networks

  • 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

Metadata Networks

  • 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

Using metadata
Using Metadata Networks

  • Consider the querySELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s

  • Order of magnitude difference between sample costs

  • 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 an order of magnitude more expensive than third

  • Second option can be cheaper if the predicate is highly selective

Using metadata1
Using Metadata Networks

  • Another exampleSELECT 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

  • Reordering is called exemplary aggregate pushdown

Dissemination optimization
Dissemination Optimization Networks

  • 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

Evaluation of srt
Evaluation of SRT Networks

  • SRT are limited to constant attributes

  • Even so, maintenance is required

  • Possible to use for non-constant attributes but cost can be prohibitive

Evaulation of srt
Evaulation of SRT Networks

  • Compared three different strategies for building tree, random, closest, and cluster

  • Report results for two different sensor value distributions, random and geographic

Srt results
SRT Results Networks

Query execution
Query Execution Networks

  • 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

    • Naïve - FIFO

    • Winavg – Average top queue entries

    • Delta – Send result with most change

  • Adapt data rates and power consumption

Prioritization comparison
Prioritization Comparison Networks

  • Sample rate was K times faster than delivery rate.

  • Readings generated by shaking the sensor

  • In this example, K = 4

Adaptation Networks

  • Not safe to assume that network channel is uncontested

  • TinyDB reduces packets sent as channel contention rises

Future work
Future Work Networks

  • 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

Evaluation Networks

  • TinyDB provides a simple yet powerful interface to sensor networks

  • TinyDB takes measures to conserve power at all phases of query processing

Discussion Networks

  • 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?