Tiny Db
Upcoming SlideShare
Loading in...5
×
 

Tiny Db

on

  • 1,208 views

 

Statistics

Views

Total Views
1,208
Views on SlideShare
1,208
Embed Views
0

Actions

Likes
1
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tiny Db Tiny Db Presentation Transcript

  • TinyDB
      • Dong Qian
      • Wu Binbin
      • Zhang Xianwen
      • Supervisor: Dr. Waltenegus Dargie
  • Table of contents
    • Introduction and Motivation
    • TinyDB Components
    • Acquisitional Query Language
    • Power-aware Optimization
    • Power-sensitive Dissemination and Routing
    • Processing Queries
    • Summary
    • 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
    Acquisitionnal Query Language
    • 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.
    Acquisitionnal Query Language
    • 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.
    Acquisitionnal Query Language
    • 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.
    Acquisitionnal Query Language
    • Example of a lifetime computation for simple queries of the form:
    • SELECT a1, ... , a numSensors
    • FROM sensors
    • WHERE p
    • LIFETIME l hours
      • 1 st : determine the available power Ph per hour:
      • 2 nd : compute the energy to collect and transmit one sample,
      • including the costs to forward data for our children:
      • 3 rd : compute the maximum transmission rate:
    Acquisitionnal Query Language
    • 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.
    Acquisitionnal Query Language
    • 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.
    Acquisitionnal Query Language
    • Power-aware Optimization
  • 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.
  • Power-aware Optimization
    • 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
  • Power-aware Optimization
    • 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
  • Power-aware Optimization
    • 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 selection
      • 2. sample magnetometer, apply selection over its reading first; then sample accelerometer
      • 3. sample accelerometer, apply selection over its reading first; then sample magnetometer
  • Power-aware Optimization
    • 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.
  • Power-aware Optimization
    • Event Query Batching to Conserve Power:
    • ON EVENT e (nodeid)
    • SELECT a1
    • FROM sensors AS s
    • WHERE s.nodeid = e.nodeid
    • SAMPLE INTERVAL d FOR k
    • 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
    • Power-sensitive Dissemination and Routing
  • 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.
  • Power-sensitive Dissemination and Routing
    • 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.
  • Power-sensitive Dissemination and Routing
    • 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
  • Power-sensitive Dissemination and Routing
    • Gray nodes must produce or forward results in the query
  • Power-sensitive Dissemination and Routing
    • 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
      • w hen 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
    • The TinyDB homepage http://telegraph.cs.berkeley.edu/tinydb/
    • 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