The design of an acquisitional query processor for sensor networks
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

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


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

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

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

CS851 Presentation 2005

Presented by: Gang Zhou

University of Virginia


Outline

Outline

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


Application structure

Application Structure

  • Queries submitted in PC

  • Parsed, optimized in PC

  • Disseminated and processed in network

  • Results flow back through the routing tree


Design goals

Design Goals

  • Provide a query processor-like interface to sensor networks

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


The design of an acquisitional query processor for sensor networks

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?


What s the big deal

What’s the big deal?

  • Radio is expensive

  • Sensing takes significant energy

  • Four Energy Levels:

    • Snoozing

    • Processing

    • Processing and receiving

    • Transmitting


Roadmap

Roadmap

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


An acquisitional query language

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


Why windows

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)


Windows

Windows

  • Windows in TinyDB are fixed-size materialization points over sensor streams.

  • Materialization points can be used in queries

  • ExampleCREATESTORAGE POINT recentlight SIZE 8AS (SELECT nodeid, light FROM sensorsSAMPLE INTERVAL 10s)SELECT COUNT(*)FROM sensors AS s, recentlight AS r1WHERE r.nodeid = s.nodeidAND s.light < r1.lightSAMPLE INTERVAL 10s


Temporal aggregation

Temporal Aggregation

  • Why Aggregation?

    • Reduce the quantity of data that must be transmitted through the network

  • Example

    SELECT WINAVG (volume, 30s, 5s)FROM sensorsSAMPLE 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…


Event based queries

Event-Based Queries

  • An alternative to continuous polling for data

  • ExampleON EVENT bird-detector(loc):SELECT AVG(light), AVG(temp), event.locFROM sensors AS sWHERE dist(s.loc, event.loc) < 10mSAMPLE 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?


Lifetime based queries

Lifetime-Based Queries

  • ExampleSELECT nodeid, accelFROM sensorsLIFETIME 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


Lifetime based queries1

Lifetime-Based Queries

  • Nodes perform cost-based analysis in order to determine data rate for each node

???


Lifetime based queries2

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?


Roadmap1

Roadmap

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


Power aware optimization

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


Reordering sampling and predicates

Reordering Sampling and Predicates

  • Consider the querySELECT accel, magFROM sensorsWHERE accel > c1AND mag > c2SAMPLE 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.


Example 2

Example 2

  • Another exampleSELECT MAX (light)FROM sensorsWHERE mag > xSAMPLE 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


Event query batching

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


The design of an acquisitional query processor for sensor networks

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


Roadmap2

Roadmap

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


Semantic routing trees

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.


The design of an acquisitional query processor for sensor networks

  • 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


The design of an acquisitional query processor for sensor networks

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


Evaluation of srt

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


Evaluation of srt1

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


Srt results

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?


Roadmap3

Roadmap

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


Processing queries

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


Prioritization comparison

Prioritization Comparison

  • Sample rate was 4 times faster than delivery rate.

  • Readings generated by shaking the sensor

  • Delta seems to be better


Adaptation

Adaptation

  • Not safe to assume that network channel is uncontested

  • TinyDB reduces packets sent as channel contention rises

    • How much? No detail!


Adaptation1

Adaptation


Roadmap4

Roadmap

  • Application Structure & Design Goals

  • Acquisitional Query Language

  • Power-Aware Optimization

  • Power Sensitive Dissemination and Routing

  • Processing Queries

  • Conclusions and Future Work

  • Discussion


Conclusions future work

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


Discussion

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?


  • Login