Tiny Db

Fakultät Informatik – Institut für Systemarchitektur – Professur Rechnernetze

TinyDB

Dong QianWu BinbinZhang XianwenSupervisor: Dr. Waltenegus Dargie

Table of contents

1. Introduction and Motivation

2. TinyDB Components

3. Acquisitional Query Language

4. Power-aware Optimization

5. Power-sensitive Dissemination and Routing

6. Processing Queries

7. Summary

8. References

Introduction and Motivation

Introduction

• Query processing system for extracting information from a network of TinyOS sensors

• Incorporate acquisitional techniques designed to minimize power consumption

• simple, SQL-like interface to specify the data you want to extract, along with additional parameters

• collects data from motes, filters it, aggregates it together, and routes it out to a PC

Introduction

• To use TinyDB, install its TinyOS components onto each mote in the sensor network

• simple Java API for writing PC applications that query and extract data from the network

• simple graphical query-builder and result display that uses the API.

Introduction

• Queries submitted in PC

• Parsed, optimized in PC

• Disseminated and processed

in network

• Results flow back through the

routing tree

A query and results propagating thru the network

Motivation

• The primary goal of TinyDB is to allow data-driven applications to be developed and deployed much more quickly.

• TinyDB frees you from the burden of writing low-level code for sensor devices, including the very tricky sensor network interfaces.

• Acquire and deliver desired data while conserving as much power as possible

TinyDB Components

The system can be classified into two subsystems:

1. Sensor Network Software:Sensor Catalog and Schema Manager

Query Processor

Memory Manager

Network Topology Manager

TinyDB Components

2. Java-based Client Interface:A network interface class that allows applications to inject queries

and listen for results.

Classes to build and transmit queries.

A class to receive and parse query results.

A class to extract information about the attributes and capabilities of devices.

A GUI to construct queries.

TinyDB Components

A graph and table GUI to display individual sensor results.

A GUI to visualize dynamic network topologies.

An application that uses queries as an interface on top of a network of sensors.

TinyDB Components

Acquisitional Query Language

Basic Language Features Queries in TinyDB consist of a SELECT-FROM-WHREE clause supporting

selection, join, projection, aggregation, sampling, windowing, and sub-queries via materialization points.

Sensor data is viewed as a single table with one column per sensor type. Tuples are appended to this table periodically, at well-defined sample intervals.

Query example:

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

Results of query stream to the root of the network in an online fashion, via the multi-hop topology, where they may be logged or output to the user. The output consists of a sequence of tuples and each tuple includes a timestamp.

Acquisitionnal Query Language

Sensors table is conceptually an unbounded, continuous data stream of values, certain blocking operations are not allowed over such streams unless a bounded subset of the stream, or window, is specified.

Joins are allowed between two storage points on the same node, or between a storage point and the sensors relation, in which case sensors is used as the outer relation in a nested-loops join.

Exampe:

SELECT COUNT(*)

FROM sensors AS s, recentlight AS rl

WHERE rl.nodeid = s.nodeid

AND s.light < rl.light

SAMPLE INTERVAL 10s


In the event that a storage point and an outer query deliver data at different rates, a simple rate matching construct is provided that allows interpolation between successive samples, or specification of aggregation function to combine multiple rows.

TinyDB includes support for grouped aggregation queries. It reduces the quantity of data that must be transmitted through the network.

When a query is issued in TinyDB, it is assigned an identifier that is returned to the issuer. This identifier can be used to stop a query , limite a query to run for a specific time period or include a stopping condition as an event.


Event-Based Queries TinyDB supports events as a mechanism for initiating data collection.

Events in TingDB are generated either by another query or the operation system.

Query example:

ON EVENT bird-detect (loc):

SELECT AVG ( light ), AVG ( temp ), event.loc

FROM sensors AS s

WHERE dist (s.loc, event.loc) < 10m

SAMPLE INTERVAL 2s FOR 30s

Events are central in ACQP, as they allow the system to be dormant until some external conditions occurs, instead of continually polling or blocking on an iterator waiting for some data to arrive.


Lifetime-Based Queries Specifying lifetime is a much more intuitive way for users to reason about

power consumption. Because users are not concerned with small adjustments to the sample rate and how such adjustments influence power consumption, but every concerned with the lifetime of the network executing the queries.

To satisfy a lifetime clause, TinyDB preforms lifetime estimation. The goal of lifetime estimation is to compute a sampling and transmission rate given a number of Joules of energy remaining.

The rates a single node at the root of the sensor network are computed via a simple cost-based formula, considering the costs of accessing sensors, selectivities of operators, expected communication rates and current battery voltage.


Folie 18

Example of a lifetime computation for simple queries of the form:

SELECT a1, ... , a numSensors

FROM sensors

WHERE p

LIFETIME l hours

1st: determine the available power Ph per hour:

2nd: compute the energy to collect and transmit one sample,

including the costs to forward data for our children:

3rd: compute the maximum transmission rate:


Coordinate the transmission rate across all nodes in the routing tree:

reason: sensors need to sleep between relaying of samples, it is

important that senders and receivers synchronize their

wake cycles.

method: we allow nodes to transmit only when their parents in the

routing tree are awake and listening which is usuall the

same time they are transmitting.


Problem arises: no control over the sample rate by user.

reason: some applications require the ability to monitor physical

phenomena at a particular granularity.

method: allow an optional MIN SAMPLE RATE r clause to be

supplied. If the computed sample rate for the specified

lifetime is greater than this rate, sampling proceeds at the

computed rate. Otherwise, sampling is fixed at a rate of r and

the prior computation for transmission rate is done assuming

a different rate for sampling and transmission.

Note: Need to periodically re-estimate power consumption.


Power-aware Optimization


• Cost-based optimizer lowest overall power consumption

• The cost is dominated by sampling the physical sensors and transmitting query results rather than applying individual operators.

• Focus on ordering joins, selections, and sampling operations.


Metadata Management:• Each node in TinyDB maintains a catalog of metadata that describes

its local attributes, events, and user-defined functions.

• Periodically copied to the root of the network for use by the optimizer.

Metadata fields kept with each attribute


Ordering of Sampling and Predicates:• Sampling is often an expensive operation in terms of power.

• The metadata information is used in query optimization to order the sampling and predicates.

Energy costs of accessing various common sensors


Ordering of Sampling and Predicates:Consider the query below:

SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s

Compare the following options of ordering:1. sample accelerometer and magnetometer, then apply the selection2. sample magnetometer, apply selection over its reading first; then

sample accelerometer3. sample accelerometer, apply selection over its reading first; then

sample magnetometer


Event Query Batching to Conserve Power:• It is possible for multiple instances of the internal query to

be running at the same time power waste• Multi-query optimization technique based on rewriting to

alleviate the burden of running multiple copies of the same identical query

• The advantage of this approach is that only one query runs at a time no matter how frequently the events of type e are triggered.

• For frequent event-based queries, rewriting them as a join between an event stream and the sensors stream can significantly reduce the rate at which a sensor must acquire samples.


Event Query Batching to Conserve Power:

ON EVENT e (nodeid)SELECT a1FROM sensors AS sWHERE s.nodeid = e.nodeidSAMPLE INTERVAL d FOR k

SELECT s.a1FROM sensors AS s, events AS eWHERE s.nodeid = e.nodeidAND e.type = eAND s.time – e.time <= k AND s.time > e.timeSAMPLE INTERVAL d

Power-sensitive Dissemination and Routing


Motivation:• When each sensor hears a query, it must decide if the query

applies locally or needs to be broadcast to its children in the routing tree.

• If a node knows none of its children will ever satisfy the value of some selection predicate, it need not forward the query down the routing tree, which can save the costs of disseminating, executing, and forwarding results for the query.


Semantic Routing Tree (SRT):

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

• An SRT is an index over constant attribute that can be used to locate nodes that have data relevant to the query.


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, prepare to receive results and forward the query• If no, do not forward q

• Is query q applied locally:• If yes, execute the query• If no, simply ignore it


Gray nodes must produce or forward results in the query


SRT Summary:• Provide an efficient mechanism for disseminating queries

and collecting query results for queries over constant attributes.

• Reduce the number of nodes that must disseminate queries and forward the continuous stream of results from children by nearly an order of magnitude.

Processing Queries

Processing Queries

• Parent nodes have access to their children’s readings before aggregating.

• Subdivide the epoch into fixed-length time intervals, assign nodes to intervals based on their position in the routing tree

Communication Scheduling

Processing Queries

• During each interval– Computing the partial state record

• Child values• Local readings

– Output the partial state record to the network

• Information reach the root during interval 1

Aggregate Queries

Processing Queries

Partial state records flowing up the tree during an epoch using interval-based communication.

Aggregate Queries

Processing Queries

Three prioritization Schemes:• Naive scheme

– no tuple is considered more valuable than any other– FIFO – latest tuples are dropped if the queue is full

• Winavg: – basic FIFO scheme– when the queue is full, two results at the head of the

queue are averaged to make room for new tuple

Policies for Selection Queries

Processing Queries

Three prioritization Schemes:• Delta scheme

– Relies on the intuition that the largest changes are probably interesting

– Tuple with highest score is always delivered– Allowing out of order delivery

– When queue is full, the tuple with the lowest change is discarded

– Score is used to represent the change

Policies for Selection Queries

Processing Queries

• Setting :– Sample rate is faster than the maximum delivery rate

• Environment : – Single mote running TinyDB

• Winavg versus Delta scheme– Delta is closer to the original signal as it tends to

emphasize the extremes– Winavg tends to dampen them

Performance comparison

Processing Queries

An acceleration signal (top) approximated by a delta (middle) and an average (bottom), K=4.

Performance comparison

Processing Queries

RMS Error for Different Prioritization Schemes and Signals(1000 Samples, Sample Interval = 64ms)

RMS Error comparison

Processing Queries

• Snooping– Allows nodes to locally suppress local aggregate values

by listening to the neighboring nodes.

• Example: Max aggregation– Node n hears the value a of a MAX query and compare

it with local partial MAX.• If the neighboring a greater than partial a, it assigns partial

MAX a low score or suppresses it together.• If the neighboring a less than partial a , it assigns partial MAX

a high score.

Policies for Aggregate Queries

Processing Queries

Snooping reduces the data nodes must send in aggregate queries. Here node 2’s value can be suppressed if it is less than the maximum value snooped from nodes 3,4, and 5.

Example of snooping

Processing Queries

• When optimizing a query, transmission and sample rate are set.– considering network conditions, sample rates and

lifetime– static decision

• The Need for Adaptivity– Conditions of Network contention and power

consumption are varying– Adaptive backoff : transmission and sample rate

changes

Adapting Rates

Processing Queries

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

Adapting Rates

Processing Queries

• Compute a predicted battery voltage into processing a query

• Compare the current voltage with the predicted voltage • Re-estimate the power consumption characteristics and re-

run the life-time calculation

Power Consumption

Processing Queries

Measuring power consumptions

SUMMARY

Summary

• Query Language– SQL Extension, Event-based query, Lifetime-based

query

• Query Optimization– Ordering of sampling and predicates, Event query

batching (Query rewriting)

• Query Dissemination and Routing– Semantic Routing Tree (SRT)

• Query Execution– Prioritizing data delivery, Adapting rates

References

1. The TinyDB homepage http://telegraph.cs.berkeley.edu/tinydb/

2. Sam Madden, et al. The design of an acquisitional query processor for sensor networks, SIGMOD '03: Proceedings of the 2003 ACM SIGMOD international conference on Management of data, pages 491--502 , 2003

3. Sam Madden, et al. TinyDB: An acquisitional query processing system for sensor networks, ACM Trans. Database Systems. Vol. 30, pages 122-173, 2005

4. TinyDB: In-network query processing in TinyOS, the TinyDB documentation

http://telegraph.cs.berkeley.edu/tinydb/

Technology

Tiny Db