Image Processing Reference
In-Depth Information
transmissions. As current sensor nodes are known to be unreliable and the performance of the
various in-network processing schemes can change dramatically with varying degrees of reliability,
thisremainsasatopicwhichisopentofurtherresearch.
4.4.4 Acquisitional Query Processing
In conventional database systems, when posing a query to the system, a user need not bother about
how the data should be extracted in the most efficient way. The same concept holds true in dis-
tributed database systems where the requested data might be stored in small fragments spanning
the entire network. In this case, the user does not require knowledge of where the data resides.
In other words, the techniques used to locate data or the methods followed to extract data in an effi-
cient manner, are processes that are completely transparent to the user. The user simply injects the
query into the network and waits for the result to appear. It is the responsibility of the query process-
ingsystemtohandletheabove-mentionedtasksandactasaninterfacebetweentheuserandthedata
sources.
One of the tasks of a query processor for WSNs is to generate an optimized query execution plan
that outlines an energy-efficient strategy to execute a query. While conventional database query opti-
mization techniques calculate the cost of executing a query based on a number of parameters such
as CPU instructions, I/O operations, messages transmitted, etc. the model necessary for WSNs is
slightly different due to its unique characteristics described earlier. The tight power constraints of
WSNs have driven researchers to find novel ways to minimize the two main sources of power con-
sumption on a sensor node—the operation of the radio transceiver and the sampling of the sensors
to obtain readings. he idea of managing sensor sampling as one of the tasks of the query processor
was first introduced in TinyDB [] and was termed as acquisitional query processing.
TinyDB carries out query optimization at the root node. Metadata such as the energy and time
required to sample a particular sensor, information about the costs of processing and delivering data,
etc. are periodically copied from the nodes to the root for use by the query optimizer. he optimizer
also has the task of initializing, merging, and updating the final value of partial aggregate records as
they propagate through the network toward the root.
Before a query is injected into the network through the root node, the query optimizer can optimize
the query in various ways using the collected metadata. For example, since the difference in power
consumption of sampling various sensors on a single node can differ by several orders of magnitude,
the order in which sensors are sampled when evaluating a query can have a substantial impact on
network lifetime.
Consider the scenario where a user requires readings from a light sensor when the temperature
and humidity sensors reach thresholds
t
and
h
,respectively.Ifthenodeusesahumiditysensorthat
requires times more energy to sample than the temperature sensor, in most cases, it would be a lot
more energy-efficient to sample the temperature sensor first to check if the threshold has been met
and proceed with the sampling of the humidity sensor only if the result of the temperature threshold
check is found to be true. In fact, in such a scenario, sampling the humidity sensor first could be up
to an order of magnitude more expensive.
TinyDB also performs multi-query optimization on event-based queries in order to reduce costs
due to sensor sampling and transmission. Consider a query
Q
that requests temperature readings
only when a certain event
E
occurs. he occurrence of a string of event
E
swithinashorttimeinter-
val would trigger multiple instances of the query to run simultaneously. his results in high energy
consumption as every instance of a query performs its own sensor sampling and transmission of
results. To alleviate this problem TinyDB optimize's such queries by rewriting them so that all occur-
rences of event
E
of the last
k
seconds are bufered. When a sensor reading is obtained, it is compared
against the buffered events and the temperature readings are returned. hus no matter how frequently
events of type
E
are triggered, only one query is required to run.
