View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
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.
SELECT nodeid, light, temp
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.
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.
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.
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.
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.
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