


















Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Haar wavelets, their use in signal processing for studying frequency components and data reduction, and their application in sensor networks for multi-resolution query processing. The document also covers the challenges of ordering data elements, zero-padding, and communication tree design. Additionally, it mentions tinydb and its acquisitional query processing approach.
Typology: Study notes
1 / 26
This page cannot be seen from the preview
Don't miss anything!



















University of Maryland, College Park
Need to normalize first (not discussed in paper in detail) Minimizes the sum-squared error
Need to normalize first (not discussed in paper in detail) Minimizes the sum-squared error
In signal processing, the numbers form a sequence, so they are ordered In some cases, you might be able to reorder Most likely NP-Hard to find the best ordering
Depends on the application
Take the two PSRs from children, and merge them Send top “k” coefficients up Two problems: May have more than 2 children The children may be of different sizes Must “zero-pad” Can have too many zeros This introduces larger errors Consider a Haar wavelet on the sequences: {100, 100, 0, 0, 0, 0, 0, 0} vs {100, 100}
For Haar wavelets, it is a binomial tree
$
% & !'
( '( '$ $ ') ( # %
" ' % '# #%
$ % & ( % " ' *#+ *%+ (^) *(+ *"+ *'),!"+ '$,#,!",#+$,#+ [t] igure 3: An in-network computation of the Haar wavelet of Figure 1. The left side annotates the (logical) support ee with dark arrows representing physical message-passing between the sensor nodes. The right side of the figure hows just the (physical) communication tree, i.e., the leaf level of the left side. Each edge on the right is labeled with
Open problem
Use overlay networks Nodes forward messages without applying merging functions Essentially assume a complete communication graph Hard to optimize (need to use weighted graphs)
Basic ideas also extend to peer-to-peer networks
We can control when/where to observe data (within certain limits) In traditional databases, the data is given How does this change query processing?
locally. The mote then switches to a “Processing and Receiving” mode, where results are collected from neighbors over the radio. Finally, in the “Transmitting” mode, results for the query are delivered by the lo- cal mote – the noisy signal during this period reflects switching as the receiver goes off and the transmitter comes on and then cycles back to a receiver-on, transmitter-off state.
2
4
6
8
10
12
14
16
18
20
22
0 0.5 1 1.5 2 2.5 3
Current (mA)
Time (seconds)
Time v. Current Draw In Different Phases of Query Processing
Transmitting
Processing and Listening
Processing
Snoozing
Figure 2: Phases of Power Consumption In TinyDB
adios such as m a few feet environmen- deployments ediate nodes mmunication filter so that eighbors are tional energy age from the ents indicat- bor node. No ce and easy utomatically defined sample intervals that are a parameter of the query. The per time between each sample interval is known as an epoch. As we d in Section 6, epochs provide a convenient mechanism for struc computation to minimize power consumption. Consider the quer SELECT nodeid, light, temp FROM sensors SAMPLE INTERVAL 1s FOR 10s This query specifies that each sensor should report its own id, ligh temperature readings (contained in the virtual table sensors) on second for 10 seconds. Results of this query stream to the root network in an online fashion, via the multi-hop topology, wher may be logged or output to the user. The output consists of an growing sequence of tuples, clustered into 1s time intervals. Each includes a time stamp corresponding to the time it was produced. Note that the sensors table is (conceptually) an unbounded, c uous data stream of values; as is the case in other streaming an line systems, certain blocking operations (such as sort and sym
easy ically me of hbors orma- work. a link esults use a o dis- rmed node r this til the count, Note that the sensors table is (conceptually) an unbounded, contin uous data stream of values; as is the case in other streaming and on line systems, certain blocking operations (such as sort and symmetri join) are not allowed over such streams unless a bounded subset of th stream, or window , is specified. Windows in TinyDB are defined a fixed-size materialization points over the sensor streams. Such mater alization points accumulate a small buffer of data that may be used i other queries. Consider, as an example: CREATE STORAGE POINT recentlight SIZE 8 AS (SELECT nodeid, light FROM sensors SAMPLE INTERVAL 10s) This statement provides a shared, local (i.e. single-node) location t store a streaming view of recent data similar to materialization point in other streaming systems like Aurora or STREAM [7, 34], or mater alized views in conventional databases. Joins are allowed between tw storage points on the same node, or between a storage point and th sensors relation, in which case sensors is used as the outer rela
3.2 Event-Based Queries As a variation on the continuous, polling based mechanisms for data acquisition, TinyDB supports events as a mechanism for initiating data collection. Events in TinyDB are generated explicitly, either by another query or the operating system (in which case the code that generates the event must have been compiled into the sensor node.) For example, the query: ON SELECT EVENT AVG(light),bird-detect(loc): AVG(temp), event.loc FROM WHERE sensors dist(s.loc, AS s event.loc) < 10m SAMPLE INTERVAL 2 s FOR 30 s could be used to report the average light and temperature level at sen- sors near a bird nest where a bird has just been detected. Every time a bird-detect event occurs, the query is issued from the detecting node and the average light and temperature are collected from nearby nodes once every 2 seconds for 30 seconds. Such 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. Since most mi- croprocessors include external interrupt lines than can wake a sleeping device to begin processing, events can provide significant reductions in power consumption, shown in Figure 3.
3.3 L In lieu specific < x > much m Especia not par nor do sumptio of the n
This qu samplin sible an To satis goal of rate giv ering ho these ra to comp
Can specify a lifetime for the query Decide the sampling rate based on that Tricky to estimate lifetimes accurately Also, the sampling rate is usually dependent on the application
Also aggregates (whether they are monotonic, distributive etc..)
Should interleave taking samples and evaluating predicates