Abstract
We investigate the in-network processing of an iceberg join query in wireless sensor networks (WSNs). An iceberg join is a special type of join where only those joined tuples whose cardinality exceeds a certain threshold (called iceberg threshold) are qualified for the result. Processing such a join involves the value matching for the join predicate as well as the checking of the cardinality constraint for the iceberg threshold. In the previous scheme, the value matching is carried out as the main task for filtering non-joinable tuples while the iceberg threshold is treated as an additional constraint. We take an alternative approach, meeting the cardinality constraint first and matching values next. In this approach, with a logical fragmentation of the join operand relations on the aggregate counts of the joining attribute values, the optimal sequence of 2-way fragment semijoins is generated, where each fragment semijoin employs a Bloom filter as a synopsis of the joining attribute values. This sequence filters non-joinable tuples in an energy-efficient way in WSNs. Through implementation and a set of detailed experiments, we show that our alternative approach considerably outperforms the previous one.
1. Introduction
In wireless sensor networks (WSNs), the values sampled by a senor node can be modeled as a relational tuple that consists of the sensor readings as its main attributes and often of the node ID, the timestamp of the sampling, the location of the node, etc. as its auxiliary attributes [1]. Thus, for a region of WSNs, the sensor readings of the nodes deployed in the region can be modeled as a virtual relation physically distributed across the senor nodes in the region. In WSN applications, which include vehicle surveillance, environment monitoring, animal habitat monitoring, and climate research to name just a few, a relational join query can be issued against two virtual relations. For example, based on the scenario in vehicle surveillance presented in [2], let us consider the identification of the moving objects that have passed two particular regions in WSNs. In each region, the ID of a passing object is sampled and stored with the time of passage. Then, the sets of sensor readings stored in the two regions are modeled as virtual relations denoted as and . The following join query is to retrieve the ID and time of the objects that have passed both of the two regions:
Since a join is an important type of query in WSNs to monitor the correlations among the senor readings, processing of joins in WSNs has received much attention. A survey of the state-of-the-art techniques is presented in [3]. A naïve method to answer a join query, , in WSNs is the external join, whereby all the tuples of and are sent to the base station where the result of the join is produced. In WSNs, the power in a node is consumed the most when the node transmits data [4]. Thus, the external join is not energy-efficient, and the state-of-the-art techniques conduct in-network processing of joins.
In this paper, we investigate the in-network processing of a special type of equijoin query called iceberg join in WSNs. It is to retrieve the frequent patterns of correlation among the sensor readings. For a joining attribute value v, it contributes to the join result only if the number of joined tuples for v exceeds some given threshold. This join frequency threshold is called iceberg threshold and denoted as α throughout this paper. Figure 1a shows an example of iceberg join of two relations and with α = 2, denoted as . A query retrieving attribute A from this iceberg join can be expressed in SQL as in Figure 1b.
Figure 1.
An Example of an Iceberg Join Query. (a) Join operand relations and , and the result of their iceberg join with α = 2; (b) SQL expression retrieving attribute A from the iceberg join in (a).
In bird habitat monitoring, sensor nodes can be deployed to sample bird songs when birds are singing. From these audio samples, their fingerprints are generated, stored, and later used to recognize the bird species and to estimate their population size in certain regions [5]. For two regions of interest in WSNs, an iceberg join query can be issued to retrieve the fingerprints that are frequently sampled in both regions in studying regional correlations in bird population. Let and denote the virtual relations storing the fingerprints in the two regions. Then, this query can be expressed as:
The iceberg join is an important type of query in WSNs because the frequent or prominent phenomena of interest in terms of correlations among sensor readings could be detected in a more energy-efficient way than with the conventional joins. Considering the resource constraints in WSNs and the cross-references required in join processing, the processing of the conventional types of join queries in WSNs could be too expensive [3]. The efficient processing of iceberg joins in WSNs deserves attention but so far little work has been reported. The most relevant ones include the schemes proposed in [6,7,8].
An iceberg join operation involves the checking of the join predicate and of the cardinality constraint between the tuples of the join operand relations. There could be two approaches depending on which condition of the two is the primary one to check. The primary condition is checked first, and for the tuples that satisfy it, the remaining condition is checked next. It would be reasonable to regard the join predicate as an intrinsic requirement of a join operation while treating the cardinality constraint as an additional one. In [6], such a view was taken, and a scheme called SRJA (Synopsis Refinement iceberg-Join Algorithm) was proposed, where a histogram-based synopsis of the joining attribute value ranges is transmitted for filtering non-joinable tuples. In [6], it was shown that SRJA significantly outperformed the baseline schemes. In this paper, we investigate an alternative approach where the cardinality constraint is checked first as the primary condition and then for those tuples that satisfy it, the join predicate is checked. We show that this approach is substantially superior to the other one. The contributions of this paper are as follows:
- We consider a logical fragmentation of join operand relations based on the aggregate counts of the joining attribute values, proposing a 2-way fragment semijoin operation using a Bloom filter as a synopsis of the joining attribute values. In the backward reduction of the 2-way fragment semijoin, the false positives inherent with the Bloom filter are efficiently handled.
- We take advantage of the Highest Count First strategy with which efficient reduction of the join operand relation (called Low Count Cut) occurs, developing a dynamic programming algorithm that generates the optimal sequence of 2-way fragment semijoins. The Highest Count First strategy is shown to be more effective in filtering non-joinable tuples than the transmissions of the value ranges widely used in WSNs.
- Through implementation and a set of detailed experiments, we show that our approach considerably outperforms the previous one.
The rest of this paper is organized as follows: in Section 2, the problem statement is given. In Section 3, the background for our scheme is presented. In Section 4, an overview of our approach is given. In Section 5, the optimization with a dynamic programming algorithm is described. In Section 6, the performance of our scheme is compared with that of SRJA. In Section 7, related work is presented. Finally, in Section 8, the conclusions are drawn and the future work is given. Notations used in this paper are summarized in Table 1 of Section 4.
2. Problem Statement
An iceberg join query Q for two virtual relations and on attribute A in WSNs is assumed to be submitted to the base station as a continuous query modeled as a sliding window join [9]. Each evaluation of the query is conducted against a window of and that of , and the query result is returned to the base station. Initially, the base station forwards Q to three sensor nodes , , and . is the coordinator node of the region for , i = 0, 1. is the node located at the midpoint between and , which is to take part in in-network query optimization and processing. In each region, a routing tree whose root is is constructed with the standard routing tree construction algorithm of [1]. disseminates Q to all the sensor nodes in the region. In each region, preprocessing is carried out to collect the aggregate count of each joining attribute value that is sampled in the window. Each sensor node in a region generates a node histogram, which is a set of (value, count) pairs in the node. Then, it sends the node histogram to its parent node in the routing tree. Eventually, obtains the region histogram. It is a binary relation with the joining attribute A and the count attribute. In [6], this relation is called the base histogram. Let us denote the base histogram of region and as and , respectively. Now the problem is to fully reduce and such that only those tuples of them that are qualified for the iceberg join remain. Let and respectively denote the full reduction of and . Then, the final result of Q can be obtained by two semijoins followed by a final join: ( ) ( ). Once and are obtained, the operations to produce the final result of Q are straightforward. Thus, in this paper, we deal only with the problem of optimally obtaining and .
3. Background
Our scheme employs the Bloom filter [10] and a variation of the 2-way semijoin [11,12]. In Section 3.1, semijoin and 2-way semijoin operations are briefly described. In Section 3.2, an overview of Bloom filter and its theory are given. In Section 3.3, the technique of SRJA [6] is described.
3.1. Semijoin and 2-Way Semijoin
The semijoin was proposed in [13] as a means to reduce join operand relations in distributed databases. Given a join , semijoin reduces such that only those tuples of joinable with remain. Assuming that and reside at different sites in distributed databases, the semijoin is executed by sending [A] to and joining the two. That is, = . is said to be fully reduced by the semijoin. Let us call the reducer relation, and the reduced relation. The size of the result of semijoin is , where s is called the semijoin selectivity and it is estimated as |R[A]|/|DA|, where is the domain of A [14].
The 2-way semijoin was investigated in [11,12,15] as an extension of the semijoin. It includes the backward reduction phase in addition to the forward reduction phase of the original semijoin such that both of the two join operand relations are fully reduced. Suppose semijoin reduces to . In the backward reduction phase of 2-way semijoin , [A] or its complement (i.e., [A][A]) or a bit vector indicating which value of [A] is joinable and which is not is sent back. In distributed query processing, this backward reduction is often effective and can be applied to a pipelined n-way join [12]. In our scheme proposed in this paper, the backward reduction is efficiently merged with the handling of the false positives inherent with the Bloom filter employed in implementing a semijoin.
3.2. Bloom Filter
A k-transform Bloom filter is a bit vector of length m that probabilistically represents a set S with k hash functions h1(), , hk() for k 1 [10]. Initially, all the m bits are set to 0. For each value x in S, h1(x)-th, ⋯ , hk(x)-th bits of the Bloom filter are set. For a given value y, y is not in S if any of the h1(y)-th, ⋯, hk(y)-th bits of the Bloom filter is not 1, whereas y is probably in S if all those k bits are 1. In the latter case, a false positive is possible due to the possibility of the collisions in hashing. However, it is guaranteed that false negatives are not possible.
For two relations and that reside at different locations, a Bloom filter can be employed in implementing semijoin with possible errors. First, is scanned to construct a Bloom filter {A} that represents [A] {A} is sent to . Then, for each value v of .A, the membership test of v {A} is done to filter non-joinable tuples of . None of the joinable tuples of is filtered out but some of the non-joinable ones could survive because of the false positives (i.e., , where denotes the semijoin implemented using a Bloom filter). Since {A} is a bit vector, it is usually much smaller than [A]. In WSNs, it would be more energy-efficient to send {A} than to send [A], provided that the false positives could be properly handled.
When the length of a k-transform Bloom filter is m, and the number of values in S is n, the probability of a false positive is approximately:
and it is minimized to when [16,17]. In this case, the number of bits used to represent a value in S is .
3.3. SRJA
Given an iceberg join of and on attribute A in WSNs, SRJA works as follows [6]: The preprocessing as described in Section 2 is carried out to obtain and At and , the values in and is respectively divided into a sequence of value ranges with the information on the count attribute associated with each range. A range is defined as a 4-tuple (minval, maxval, mincount, maxcount). minval and maxval are respectively the minimum and maximum value of A in the range, and the mincount and maxcount are respectively the minimum and maximum value of count among all the counts associated with the values of A in the range. The sequence of these ranges constitutes the synopsis of the values of A and count in (i = 0, 1). A value range represented as an interval would be much smaller than the list of all the values in the range. In WSNs, it is a common practice to send a value range (i.e., an interval [minval, maxval]) instead of the full list of values in the range to reduce data transmission cost though accuracy is compromised [18].
Figure 2.
Protocol Executed by for SRJA.
and send the synopses of and to the sensor node located at the midpoint between and . At , the value range matching is conducted first with the minval and maxval of the ranges in the synopses. In this matching process, the original synopses are modified. Some ranges of a synopsis are deleted because there is no matched counterpart in the other synopsis or further divided into subranges so that the two synopses have exactly the same set of ranges. Then, for each pair of matched ranges of and , the mincount’s and maxcount’s are checked, and the ranges are tagged as PRUNE, JOIN, or DIVIDE. The pair for which maxcount()maxcount() is tagged as PRUNE. The pair for which mincount()mincount() is tagged as JOIN. The remaining pairs are tagged as DIVIDE. The tagged synopses are sent back to and . The tuples in a PRUNE range are deleted from (i = 0, 1). The tuples in a JOIN range not qualified for the query are filtered out by 2-way semijoins, and the qualified ones are finally joined for the result. A DIVIDE range is further divided into subranges. The synopsis of is reconstructed with them. This process is repeated until the final query result is obtained. The optimization techniques for SRJA are as follows [6]:
- Optimization 1: Before the above process begins, the tuples whose value of count exceeds α is sent separately for checking their joinability because they are likely to be qualified for the query.
- Optimization 2: The tuples whose value of A belongs to a sparse range are also separately sent. Eliminating a sparse range would make the synopsis more selective.
- Optimization 3: For a range to be tagged as DIVIDE, the maxcount of the opposite range (opp_maxcount) is also sent when the tagged synopses are sent back. When the range is divided into subranges, the tuples which turn out not to be qualified for the query (countmaxcount) are deleted.
The skeleton of the protocol executed by for SRJA is described in Figure 2. The one for is symmetrical. In [6], it was shown that SRJA significantly outperformed the following baseline schemes:
- NAÏVE: The external join where all the tuples of and are sent to the base station.
- SIJ: The synopsis join of [2] extended for iceberg joins where and are sent to and fully reduced there.
4. Overview of Our Approach
Given an iceberg join of and on attribute A in WSNs, suppose the preprocessing described in Section 2 has been carried out to obtain and In this section, the main components of our scheme in fully reducing and are described. They include 2-way fragment semijoin, Low Count Cut, Highest Count First strategy, and the sequence of 2-way fragment semijoins. The issue of optimization is dealt with in Section 5. The notations used in this section and Section 5 are summarized in Table 1.
Table 1.
Notations.
| Notation | Description |
|---|---|
| , | and when i = 0; and when i = 1 |
| α | Iceberg threshold |
| The coordinator sensor node in the region for (i = 0, 1) | |
| The sensor node located at the midpoint between and . | |
| A | The joining attribute |
| The domain of A | |
| ||A|| | The size of a value of A |
| , | 2-way fragment semijoin operator |
| A logical fragment of defined as (i = 0, 1) | |
| The initial maximum value of the attribute count in (i = 0, 1) | |
| The current highest value of the attribute count in (i = 0, 1) | |
| The current lowest value of the attribute count in (i = 0, 1) | |
| The current state of after reduced by a sequence of fragment semijoins (i = 0, 1) | |
| A logical fragment of defined as (i = 0, 1) | |
| A fragment semijoin for which is the reducer relation | |
| Given and , the optimal sequence of fragment semijoins that fully reduces and provided that the first semijoin is (i = 0, 1) | |
| The cost of | |
| The cost of | |
| The value of attribute count in with which (Equation (2)) is minimized (i = 0, 1). Let n = . Then, the following sequence of fragment semijoins is the prefix of : . | |
| The Bloom filter sent for | |
| The size of | |
| The optimal number of hash functions used for | |
| The cost of handling false positives with in executing |
4.1. 2-Way Fragment Semijoin
As described in Section 2, and are the base histograms of and with attribute count. For relation (i = 0, 1), let denote the result of . is a horizontal fragment of on count, and thus, a horizontal subset of the base histogram of . For example, given an iceberg join between and in Figure 1 on attribute A, , and . Thus, , , , .
Let us consider a logical fragmentation of and on count. Suppose the lowest and highest value of count in is 1 and 7, respectively. Then, is logically partitioned into 7 fragments: , , …, . Similarly, suppose is logically fragmented into , …, . Now let us consider an iceberg join with 30. Since and are fragmented, the semijoin where a fragment is the reducer relation can be used. For example, semijoin is executed in the following way: is sent to . Since , only those tuples of that belong to the fragments where 8 could be joinable with the tuples in . Thus, only could be considered as the reduced relation. The tuples in those fragments not joinable with are deleted.
Now let us define a new type of operation called fragment semijoin by modifying the semijoin. In the semijoin, the joinable tuples of the reduced relation remain whereas the non-joinable ones are deleted. In our fragment semijoin, the tuple filtering is done in the other way around with a side-effect. The joinable ones are deleted whereas the non-joinable ones remain. In other words, the result of a fragment semijoin is the complement of the conventional semijoin (in some commercial DBMSs, this variation of the semijoin is called an anti join; in fact, the term fragment anti join might be more exact one than fragment semijoin, however, we keep the term semijoin with a modifier “fragment” because it is widely known). Let us denote a fragment semijoin operator as . With 30, a fragment semijoin is executed in the following way: is sent to . The tuples in not joinable with are intact (i.e., not deleted). Instead, the joinable ones are deleted and inserted to a separate relation The reason why the unmatched tuples remain is that they might be joined with the tuples in other fragments of . The insertion of matched tuples to is a necessary side-effect of a fragment semijoin. Initially, is empty. Every time a fragment semijoin to reduce is executed, the matched tuples, if any, are inserted to . When all the tuples of that are joinable with have been inserted to , is said to be fully reduced to . Until then, is said to be reduced to , which keeps the tuples of yet to be checked for joinability with other fragments of . Note that . The difference, , is the set of tuples of that have been finally confirmed not joinable with . How this difference is computed will be explained in the next two subsections. In a 2-way fragment semijoin, the backward reduction phase is added where the matched joining attribute values are sent back.
So far, we have assumed that the joining attribute values are sent in the forward reduction phase. In our scheme, we employ the Bloom filter as a synopsis of the joining attribute values in executing a fragment semijoin to reduce the amount of data transmission in WSNs. The fragment semijoin with a Bloom filter is the same as above except (1) the Bloom filter constructed from the joining attribute values are sent; and (2) the false positives need to be handled. With 30, the fragment semijoin using a Bloom filter is executed in the following way: The values in are represented in a Bloom filter, {A}, which is sent to . For each value of A in , the membership test is done with {A}. The matched tuples (including those due to false positives) are moved to . Their values of A are sent back to . The ones that turn out to have been sent due to false positives are sent back to , and their corresponding tuples are moved from back to their original fragments. Note that the backward reduction phase is mandatory with the fragment semijoin using a Bloom filter to sort out false positives. In the rest of this paper, what we mean by a fragment semijoin denoted with is a 2-way fragment semijoin using a Bloom filter unless stated otherwise.
4.2. Low Count Cut (LCC)
In our approach, the cardinality constraint is the primary condition to check. One of the advantages we gain by checking the cardinality constraint first is that we can delete those tuples of and with low counts without checking the join predicate. Let and respectively denote the maximum count in and . Then, the tuples in the fragments () and () cannot meet the cardinality constraint, and they need not be considered at all. For example, suppose is fragmented into ,…, whereas is fragmented into ,…,, and = 20. is ignored for the join because = 10 (110). Similarly, so is because 7 (71 and 72. In general, the maximum count of one relation determines the minimum count of the candidate tuples for the join in the other relation. The tuples with the count less than this minimum can be deleted without checking the join predicate. Let us call this reduction effect as Low Count Cut (LCC). The LCCs in the above example are called initial LCCs. The initial LCCs for would be possible after is notified of as a part of the optimization process, which will be described in Section 5.5. Other than initial ones, LCC could occur after a fragment semijoin is executed. It will be explained in the next subsection
4.3. Highest Count First (HCF)
It would be efficient to take advantage of LCCs in reducing and with a sequence of fragment semijoins. When a fragment of one relation is to be selected as the reducer relation for a fragment semijoin, it is desirable to select the fragment with the highest count in that relation, for it would result in LCC in the reduced relation. For example, suppose is fragmented into , , whereas is fragmented into , ,, and = 25. Suppose the fragment semijoin is executed, and is reduced to . In , , , remain. In , , , remain. Note that does not contain . It is deleted due to LCC. Note that the LCC due to a fragment semijoin occurs only when the fragment with the highest count is the reducer relation. If is executed to reduce to with remaining, is still contained in because some of the tuples in might be joinable with those in .
Let us call the strategy of selecting the fragment with the highest count as the reducer relation for a fragment semijoin as Highest Count First (HCF). Figure 3 shows how and are reduced after a fragment semijoin is executed with the HCF strategy. In Figure 3a, each box with a count value in and denotes a fragment. For example, the box at the top of with count = p denotes the fragment . Figure 3a shows how and are logically fragmented. As shown, (pq) and (rs). Figure 3b shows the fragment semijoin . Figure 3c shows which fragments of and remain. In , is now the fragment with the highest count. In , the LCC has occurred, and is now the lowest count in the remaining fragments.
Figure 3.
Low Count Cut with Highest Count First Strategy. (a) Logical fragmentation of and , where (pq) and (rs); (b) fragment semijoin ; (c) Remaining fragments of and after the fragment semijoin in (b).
Figure 4.
A Sequence of Fragment Semijoins. (a) Given and , the initial LCCs remove the fragments , , and ; (b–f) A sequence of fragment semijoins are executed where the fragments of (or ) being the reducer relations, and those of (or ) being the reduced relations. After each fragment semijoin, LCCs occur.
4.4. Fragment Semijoin Sequence
and could be fully reduced with a sequence of fragment semijoins which interleaves two types of fragment semijoins: one with a fragment of being the reducer relation, and the other with a fragment of being the reducer relation. Figure 4 shows an example where and are reduced by a sequence of fragment semijoins with 18. After the initial LCCs (Figure 4a), a sequence of fragment semijoins are executed after which LCCs occur (Figure 4b–f). Throughout the sequence, either the fragment with the highest count in or that in is the reducer relation. In Figure 4b,d,e, more than one fragment is depicted as being the reducer relation for fragment semijoins. Since every fragment semijoin selects one fragment at a time as the reducer relation with the HCF strategy, the number of fragment semijoins executed in Figure 4b,d,e, is respectively equal to the number of fragments marked as selected. For example, in Figure 4b, two fragment semijoins are sequentially executed; first, and then where is the result of .
5. Optimal Sequence of Fragment Semijoins
In our approach, a sequence of fragment semijoins are executed to fully reduce and , and the Bloom filter is employed as a synopsis of the joining attribute values. Data transmission for a fragment semijoin occurs to send the Bloom filter and to handle the false positives. According to the Bloom filter theory presented in Section 3.2, the length of a Bloom filter and the number of transformations used could be optimally set to minimize the probability of false positives. In this section, we present an algorithm that generates the optimal sequence of 2-way fragment semijoins with the HCF strategy whereby the total amount of data transmission in fully reducing and is minimized.
5.1. Formulation of Optimization Problem
We develop a dynamic programming algorithm to generate the optimal sequence of fragment semijoins that fully reduces and . In describing the algorithm, it is convenient to denote and as and (i = 0, 1). For example, if we need to mention both and to state something that is applied to both (Note that because the semijoin operation is not commutative.), (i = 0, 1) will do. In the rest of this paper, the subscripts i and (e.g., , ) are used with (i = 0, 1) omitted if they are related to or and the context is clear. Other notations used in this section are summarized in Table 1.
The current state of after a certain sequence of fragment semijoins has been executed can be represented with the two current highest counts in the remaining fragments of and . Let denote the current highest count of as depicted in Figure 5. The following two statements hold:
Let denote reduced thus far, and denote the fragment of defined by . Given and , let denote the fragment semijoin , and denote the optimal sequence of fragment semijoins provided that the first one is Let denote the cost of , where the cost is defined to be the total amount of data transmission in bits. is given in the following recurrence relation:
denotes the cost of . Thus, the term is the total cost of executing the following sequence of fragment semijoins: . With this sequence, the fragments where , are to be selected as the reducer relations in the descending order of j according to the HCF strategy.
Figure 5.
State of and after a certain sequence of fragment semijoins has been executed. (a) The current lowest count of is ⌈⌉, where denotes the current highest count of ; (b) Let the initial maximum count of be . Then, each fragment in has been selected as the reducer relation for the fragment semijoins executed thus far before or after reduced by some fragments of .
The termination condition of this recurrence relation is ⌈, which means either one of the two relations gets empty. In such a case, no further fragment semijoin is needed. Thus:
Let denote the value n for which in (Equation (2)) is minimized. That is,
Let be the maximum count in . Then, the optimal sequence of fragment semijoins for and is either or . Its cost is or . Let . The value of j, which is 0 or 1, indicates that the first fragment semijoin in the optimal sequence is where is the reducer relation. Thus, the optimal sequence can be represented as i (followed by a sequence of counts in and as follows:
where
i;
For example, if the sequence of fragment semijoins in Figure 4 is the optimal one, then it is represented as 1, 9, 7, 6, 5, 5.
5.2. Cost of 2-Way Fragment Semijoin
The cost of a fragment semijoin where i = 0, 1 is defined as the total amount of data transmission in bits, and given as follows:
The first term denotes the size of the Bloom filter, and the second is for the cost of handling false positives. Since the total cost of sending all the joinable attribute values (excluding those from false positives) in the backward reduction phases is the same for all the possible sequences of fragment semijoins, it is omitted. The multiplication of the number of hops between the two regions of and is also omitted because it is the same for all the sequences.
5.2.1. Size of Bloom Filter
|||| denotes the size of the Bloom filter , which represents the set of joining attribute values in to be sent in executing . When this fragment semijoin is to be executed, the reduced state of and are respectively and . That is, = x, = y, and is to represent the set of joining attribute values in . The joining attribute values in are unique among all the tuples. Thus, the number of distinct values in the joining attribute A of is . This number can be estimated as follows using the semijoin selectivity estimation described in Section 3.1:
and have been reduced by each other with a fragment semijoin sequence until () becomes (x, y). However, the above estimation is valid since the joining attribute values are unique in , that is, = (pq), and thus, the following holds: ) where pq.
Now . can be estimated as follows according to the Bloom filter theory described in Section 3.2:
where denotes the optimal number of hash functions for , which will be explained shortly. In some cases, the number of tuples of is so small that the size of the list of joining attribute values might be smaller than . In such a case, the list is sent instead of To cover such exceptions, we modify the above equation as follows:
where denotes the number of bits to represent a value in the joining attribute A, and the one added is for a flag bit (for distinguishing a Bloom filter from a value list).
5.2.2. Cost of Handling False Positives
The cost of handling the false positives is estimated as follows: Let D, E, and F respectively denote the number of joining attribute values in for which the membership tests with are to be done, the number of non-joinable tuples among those D values, and the number of false positives out of those E values. Then:
The estimation of E is according to the semijoin selectivity estimation as described in Section 3.1. In the equation of F, is the probability of a false positive as summarized in Section 3.2. The values of the false positives are sent back to in the backward reduction phase, and then sent back to after the false positives are confirmed. Thus, the cost of handling the false positives for a fragment semijoin is 2F. That is:
In case that the list of joining attribute values is sent instead of , 0.
5.2.3. Optimal Number of Hash Functions.
, the optimal number of hash functions for , is determined as follows: as summarized in Section 3.2, the probability of false positives is affected by the number of hash functions. As the number of hash functions increases, the length of the Bloom filter increases with the probability of false positives decreased. In (Equation (5)), the cost of a fragment semijoin, , is given as a sum of two terms, and . There exists a tradeoff between the two terms, and thus, should be determined to be a positive integer such that is minimized. From Equations (8) and (10), the cost of a fragment semijoin with k hash functions is given as follows:
This equation can be given as a function of : , where a, b, and c are constants. The differentiation of with respect to reveals that , where a, b. If this value is less than 1, is set to 1.
5.3. Dynamic Programming Algorithm
() and () can be obtained with a dynamic programming algorithm. From (Equation (2)) through (Equation (4)), () and () are initialized as follows: If there is no fragment remaining in either one of and , that is, if or , then () is set to 0, and () is undefined. If none of and is empty but there remains only one fragment in (i.e., ), the only possible fragment semijoin is the one where that fragment is the reducer relation. Thus, () and (). Starting from these initializations, the optimal solution for the cases where the number of remaining fragments of and is greater than 1 can be obtained. For example, suppose there are two fragments remaining in and one in (Figure 6a). can be obtained as follows: Because of the HCF strategy, the fragment with the highest count is the reducer relation in the first semijoin (Figure 6b). The remaining fragment of might be the reducer relation of the next semijoin (Figure 6c). That is, Figure 6b,c show all the possible cases. Figure 6d,e respectively show the subsequent fragment semijoin where the fragment of is the reducer relation after the semijoins in Figure 6b,c assuming that no LCC has occurred. The optimal solutions (i.e., in Figure 6d,e are already known, because the number of remaining fragment in is 1 (Figure 6d) or 0 (Figure 6e), and that in is 1. The optimal solutions here are already given from the initialization. In this way, can be obtained when there are 3, 4,…, fragments remaining in (i = 0, 1). Figure 7 describes the algorithm that carries out this process.
In the algorithm, procedure opt(i, , , , ) is invoked. As shown in Figure 8a, the arguments and are respectively the current lowest and highest count in . and are those in . Procedure opt(i, ;, , , ) vacuously returns unless and . If the arguments are valid ones, it finds . When i = 0, opt(0, , , , ) finds out a value n in the range [, ] that minimizes . (Figure 8a corresponds to the first term, and Figure 8b to the second one.) In doing so, (, ) and (, ) are obtained. Similarly, when i = 1, opt(1, , , , ) finds out a value n in the range [, ] that minimizes . (, ) and (, ) are obtained.
Figure 6.
Optimal Solution from Initialization. (a) Two fragments remaining in and one in . There are only two possible cases for , (b) One case, (c) The other case, (d) The optimal solution (i.e., ) for the case of (b) is given from the initialization, (e) The same for the case of (c).
Figure 7.
Algorithm for Generating Optimal Sequence of Fragment Semijoins.
Figure 8.
Optimal Solution Obtained with Procedure opt(i, , , , ), where and are respectively the current lowest and highest count in . (a) The optimal value of n for is obtained; (b) using the optimal solution, , for each value of n.
The variable num_frag denotes the number of remaining fragments in , and opp_num_frag denotes that in . In the two outermost loops, the values of these variables increase. In the two innermost loops, pairings of and are provided such that the difference between and is set by num_frag and opp_num_frag, i = 0, 1. The invocations of opt() in Line 8 and 9 find the optimal solution for the case where the number of fragments in the reducer relation is greater than that in the reduced relation. Those in Line 11 and 12 find the optimal solution for the inverse case.
For example, suppose four and three fragments remain in and , respectively (Figure 9a). Let us consider for them. Figure 9b–e show that there could be four cases possible with the HCF strategy. After one, , four fragments of are used as the reducer relations in succession, the remaining fragments are shown at the bottom of Figure 9b–e, respectively. To find out which case of the four would lead to , for the fragments in each of the bottom of Figure 9b–e should be already known (see (Equation (2))). In other words, before for the fragments in Figure 9a is obtained, for the fragments in each of the bottom of Figure 9b–e should have been obtained. The algorithm in Figure 7 guarantees this by calling procedure opt() in proper order through the nested loops.
Figure 9.
An Example of Optimization with Procedure opt(). (a) 4 and 3 fragments remaining in and , respectively, (b–e) For the remaining fragments in (a), 4 cases that could result in the optimal solution, , are shown at the top. Determining which case leads to the optimal solution is possible, because the optimal solution, , for the remaining fragments in each of the bottom of (b–e) is already known.
The complexity of the algorithm inFigure 7 is where , which is the number of fragments in remaining after initial LCCs (i = 0, 1), and f = max(, ). The innermost two for loops (line 6 and 7 in Figure 7) combined are repeated times. The second outermost for loop (line 5) is repeated i times when num_frag = i at the outermost for loop. Since num_frag at the outermost for loop varies from 2 to f, the computation in the nested for loops (lines 8–13) would be repeated times. The complexity would be when . Due to the characteristics of iceberg queries which are supposed to produce very selective result, ’s and would grow or shrink together. Otherwise, the query would not be so selective. It means that the number of fragments remaining after initial LCCs would not be high. When , and , for example, = 6. When , and , = 2.
5.4. Post Optimization
So far, we have assumed that the backward reduction phase is carried out for each fragment semijoin in the optimal sequence. As described in Section 4.1, the values for which false positives are confirmed need to be sent back again and their corresponding tuples need to be inserted back to the reduced relation. In the backward reduction, if the matched joining attribute values are sent back with their counts, re-insertion would not be necessary at all. In doing so, the concern is the overhead of sending the count for each individual matched value. An efficient way of handling this problem is to delay the backward reduction of each fragment semijoin until the execution of all the fragment semijoins in the optimal sequence is completed, and to conduct the backward reductions all at once. For this, sends a message of the form: , , …, , , , …, where , is the set of matched joining attribute values (possibly including those from false positives) whose count is equal to j, and , ).
5.5. Query Optimization and Processing
In-network optimization of an iceberg join query Q is carried out in the sensor node located at the midpoint between and . Thus, it is required for and to send the information necessary for the optimization to . First, sends the count information of (i.e., , , ) to . and are assumed to have already been sent to when Q was initially forwarded to , , and . All the equations inSection 5 and Section 3.2 can be evaluated if the aforementioned information is available. The node generates the optimal sequence of fragment semijoins and sends it to with the count information of (i.e., , , ). The count information of as well as the optimal sequence as described in Section 5.1 are represented as a short sequence of integers. Thus, the communication overhead for optimization could be very small. Now and are ready to execute the optimal sequence to fully reduce and .The skeleton of the protocol executed by for our scheme is described in Figure 10. The one for is symmetrical.
Figure 10.
Protocol Executed by for Our Scheme.
6. Performance Evaluation of Our Scheme and SRJA
In this section, we compare the performance of our scheme and that of SRJA. We have implemented both of our scheme and SRJA, measuring the total number of packets transmitted among the sensor nodes and the total number of transmissions among the sensor nodes while the two schemes are executed. These two performance metrics are employed to compare the energy-efficiency of the two schemes. The number of packets transmitted is measured assuming that the network is IEEE 802.15.4-compliant. We also measured the ratio of joinable values transmitted over all the values transmitted. This metric is to compare the effectiveness of data filtering as well as the energy-efficiency of the two schemes. Finally, we present an analytical comparison of the total number of transmissions in the two schemes. All the procedures for the experiments were implemented in C and the experiments were conducted in a system of Windows 7 with an AMD Phenom II X4 945 Processor (3.0 GHz) and 4 GB memory.
6.1. Parameters
The network and query parameters in the experiments are summarized inTable 2. We have considered WSNs where sensor nodes are uniformly deployed. Each of the two regions for an inter-region iceberg join where a join operand relation resides is assumed to be a square consisting of n × n nodes. The distance between the coordinator nodes and of the two regions is set to 30 hops.
Table 2.
Parameter Settings in the Experiments.
| Parameter | Value |
|---|---|
| Size of a region (nn nodes) | n = 5, 10, 15 |
| The distance between and | 30 hops |
| The range of joining attribute values | 1..10,000 |
| The range of count | 1..15 |
| Epoch (i.e., sampling interval) | 10, 20, 30, 40, 50, 60 s(default: 30 s) |
| Query window size | 3 h |
| Iceberg threshold () | 50, 100, 150, 200 |
The default epoch (i.e., sampling interval) of every sensor node is set to 30 s, and the size of the sliding window of the join query is set to 3 h as in the experiments with SRJA in [5]. After setting the join selectivity between and , the values of the joining attribute in the iceberg join operand relations are randomly generated as an integer in the range [1,10,000] with a random distribution of their counts under the constraint that the highest count for a value could be 15. The iceberg thresholds considered are 50, 100, 150 and 200.
6.2. Experimental Results
Each of the reported measurements in this subsection is the average out of 50 runs against different data values. The experimental results reveal that our scheme considerably outperforms SRJA. Figure 11a,b respectively compare the total number of packets transmitted and the total number of transmissions of the two schemes as the size of each region varies from 5 × 5 nodes to 15 × 15 nodes while is set to 150. Figure 11c,d compare the same while is set to 200. As the size of each region gets bigger, more data is collected at the sensor nodes and more tuples need to be processed in both schemes. Thus, more packets are transmitted. As for the number of transmissions, it also increases in SRJA. In our scheme, it is not so sensitive to the data volume because for a given , the optimal sequence of fragment semijoins generated could include the similar number of semijoins. For the total number of packets transmitted, the average performance improvement with our scheme over SRJA is 63.58% ( 150) and 71.97% ( 200). For the total number of transmissions, the average performance improvement with our scheme over SRJA is 59.66% ( 150) and 57.27% ( 200).
Figure 12a,b respectively compare the total number of packets transmitted and the total number of transmissions of the two schemes as varies from 50 to 200 while the size of each region is set to 10 × 10 nodes. Figure 12c,d compare the same while the size of each region is set to 15 × 15 nodes. As increases, the iceberg join query gets more selective. Thus, in both schemes, more tuples are filtered and the number of packets transmitted decreases. The number of transmissions turns out not so sensitive to the increase of except for the case of . In SRJA, the effect of subrange pruning results in the decrease of transmissions for larger ’s. In our scheme, on the other hand, the number of transmissions slightly increases from to 150, then decreases for . These changes depend on the optimal sequence of fragment semijoins generated. The more semijoins are to be executed in the optimal sequence, the more transmissions would occur. For the total number of packets transmitted, the average performance improvement with our scheme over SRJA is 59.71% (regions of 10 × 10 nodes) and 64.07% (regions of 15 × 15 nodes). For the total number of transmissions, the average performance improvement with our scheme over SRJA is 63.98% (regions of 10 × 10 nodes) and 66.13% (regions of 15 × 15 nodes).
Figure 11.
Performance Comparison with respect to Varying Sizes of a Region. (a) Total number of packets transmitted (); (b) Total number of transmissions (); (c) Total number of packets transmitted (); (d) Total number of transmissions ().
Figure 12.
Performance Comparison with respect to Varying Iceberg Thresholds. (a) Total number of packets transmitted (10 × 10 nodes); (b) Total number of transmissions (10 × 10 nodes); (c) Total number of packets transmitted (15 × 15 nodes); (d) Total number of transmissions (15 × 15 nodes).
Figure 13a,b respectively compare the total number of packets transmitted and the total number of transmissions of the two schemes as the epoch (i.e., sampling interval) at each node varies from 10 s to 60 s while the size of each region is set to 10 × 10 nodes and is set to 150. As the sampling rate gets higher, more data is collected at the sensor nodes and both schemes are supposed to transmit more packets. The number of transmissions also increases. However, SRJA turns out to suffer much more with higher sampling rates. For the total number of packets transmitted, the average performance improvement with our scheme over SRJA is 62.97%. For the total number of transmissions, the average performance improvement with our scheme over SRJA is 58.66%.
Figure 14a compares the ratio of joinable values transmitted in the two schemes as the size of each region varies from 5 × 5 nodes to 15 × 15 nodes while is set to 150. This ratio is defined as:
Figure 14b compares the same as varies from 50 to 200 while the size of each region is set to 10 × 10 nodes. This ratio gets lower as the query gets more selective or as more non-joinable values are transmitted. As the size of each region gets bigger, the number of tuples collected at the sensor nodes increases and the size of the iceberg join result also increases with a given . Thus, this ratio increases in both schemes (Figure 14a). As increases, on the other hand, this ratio decreases in both schemes because the iceberg join query gets more selective (Figure 14b). In Figure 14, this ratio in our scheme turns out to be significantly higher than that in SRJA. This means that the effectiveness of filtering out non-joinable values and the energy-efficiency in our scheme is much higher than that in SRJA.
The major reasons for the improvements are two-fold:
- In SRJA, the histogram-based value ranges are sent as a synopsis of the joining attribute values. In our scheme, a Bloom filter constructed from a count-based fragment is sent as a synopsis of the joining attribute values. The Bloom filter is more compact than the value ranges. Besides, the false positives are efficiently handled in the backward reduction phase of the 2-way fragment semijoins in our scheme.
SRJA is centered around checking the join predicate with the cardinality constraint as an additional condition. For each pair of matched ranges, if there exists at least one pair of tuples t0 and t1 such that t0.count t1.count , the non-joinable tuples in either range cannot be filtered out, and recursive divisions of each of the two ranges into subranges are required. In contrast, our scheme is centered around the cardinality constraint with the join predicate as the secondary condition. Only the fragment semijoins between the fragments satisfying the cardinality constraint are carried out to filter non-joinable tuples. Besides, the reductions from the LCCs that result with the HCF strategy are effective.
Figure 13.
Performance Comparison with respect to Varying Epochs. (10 × 10 nodes, ). (a) Total number of packets transmitted; (b) Total number of transmissions.
Figure 14.
Comparison of the Ratio of Joinable Values Transmitted with respect to (a) varying sizes of a region (); (b) varying iceberg thresholds (10 × 10 nodes).
6.3. Analytical Comparison of the Total Number of Transmissions
In this subsection, we present an analytical comparison of the total number of transmissions among the sensor nodes throughout the execution of SRJA and our scheme. In Figure 2 and Figure 10, the protocols executed by the coordinator node of a region for SRJA and our scheme are described. In each of the two schemes, let be the number of messages that sends to plus the number of messages that receives from . Let be the number of messages that sends to plus the number of messages that receives from . Let and . Then, the total number of transmissions in each scheme is where d is the distance between and in hops.
6.3.1. SRJA
Considering the protocol in Figure 2, we have:
denotes the number of messages sends to plus the number of messages receives from in processing the values with a high count (line 2 in Figure 2), denotes that in processing sparse subranges in the synopsis (line 4 or line 16), and denotes that in processing JOIN-tagged subranges (line 13). is 1 if the tagged synopsis received from includes at least one JOIN-tagged subrange. It is 0 otherwise. is 1 if the tagged synopsis includes at least one DIVIDE-tagged subrange. It is 0 otherwise. The sparse subranges could be generated after the synopsis is initialized (line 3) or after the DIVIDE-tagged subranges are divided (line 15). Finally, denotes the number of rounds needed until SRJA is terminated. It means how many times the loop (line 5 through line 18) is repeated either fully or partially (up to line 9 for breaking the loop). Thus, . Now is:
Normally, because a 2-way semijoin is executed. first sends the values with a high count with their count information to , and then receives from the list of joinable values as a result (line 2). does the same symmetrically. If these two symmetrical processes are conducted as an asymmetrical one, one message can be saved, and thus, the number of transmissions could be significantly reduced when the distance between and is long. We can let start the process by sending its data to . When returns the result, it can send its data as well. Then, finally returns the result. In this way, . Similarly, . Meanwhile, because one 2-way semijoin in either direction but not the symmetrical two is enough in processing the JOIN-tagged subranges. Thus:
Meanwhile, because is to send the synopsis to (line 7) and receive the tagged synopsis from (line 8) in each round. Thus, . Let be the total number of transmissions in SRJA. Then:
6.3.2. Our Scheme
Considering the protocol in Figure 10, we have , where denotes the number of messages sends to in the forward reduction phase (line 9 through line 15 in Figure 10), while denotes the number of messages sends to plus the number of messages receives from in the backward reduction phase (line 17 through line 20). Now is .
In executing the optimal sequence of fragment semijoins, and are supposed to take turns to play the role of reducer relation. Thus, the number of messages including the Bloom filters for a subsequence of fragment semijoins in the forward reduction phase is equal to the number of this turn overs denoted as . For example, in the sequence of fragment semijoins in Figure 4, there are 5 turn overs with being the reducer relation at first in Figure 4b. Thus, . With the same argument for why in SRJA, . Thus, .
Meanwhile, 2 because sends the count information of to once (line 2) and receive from the optimal sequence and the count information of once (line 3). Let be the total number of transmissions in our scheme. Then:
From (Equations (16) and (17)), if . For the comparison, let us not consider the restricted case of . This case happens in SRJA only when at least one of and has very small number of tuples and their join attribute values are sparsely distributed. Such a case is not of much interest. Now since 2, we have . The reason for this is as follows: in Figure 10, we note that for the final round. In each of the interim rounds, we note that because without any DIVIDE-tagged subrange the next round except the final one would not be necessary. In each of the interim rounds, it is not necessarily that . Assuming that normally it holds, iff 7. The values of and depend on several parameters such as the number of tuples, distribution of joining attribute values, their count distribution, iceberg threshold, effectiveness of non-joinable value filtering, and so on. In the experiments in the previous subsection, it turns out that 3 while 2 on average. For such values, as shown by the measurements in the experiments.
7. Related Work
In-network processing of joins in WSNs has received much attention [3]. The state-of-the-art techniques deal with various types of join queries with different types of spatio-temporal characteristics. Spatially, the type of join that has received so far the most attention is the inter-region join where each of the join operand relation is stored at a region of WSNs [2,6,19,20,21,22,23,24]. The pair-wise joins where pairing of sensor nodes for join could be determined by predicates are investigated in [25,26]. Temporally, one-shot join against a static join operand relations are dealt with in [2,23,27], while the join submitted as a continuous query against the streaming join operand relations are dealt with in [19,20,21,24,25,26,28,29]. As for the type of join predicates, equijoin queries are considered in [2,19,20], while theta-joins are considered in [20,21,22,23,24,25,26,27,28,29,30].
These techniques mostly adapt the conventional join implementations to WSNs (nested-loop join [20,21,22,23], hash join [2,19,21], and the sort-merge join [19]). The semijoins and 2-way semijoins are also employed and adapted to WSNs for filtering of non-joinable tuples [2,23,24,27,29]. In [28,30], on the other hand, a filtering approach is proposed rather than adapting the conventional join algorithms to WSNs. The cost-based optimizations are investigated in [21,22,23,24,25,26,28].
In [21], a technique called Distribute-Broadcast Join adapted from the nested-loop join is proposed. The main contribution of this work is the cost-based selection of optimal join region in WSNs. In [22,23], Mediated Join also adapted from the nested-loop join is proposed, where cost-based selection of inner and outer relation for nested-loop join is investigated. In [20], distributed algorithms for indexed nested-loop join and hash join are proposed. In the former, a technique of dynamically creating and using a distributed B+ tree in WSNs is developed. In the latter, a technique of partitioning and joining tuples with geographic hashing is investigated. In [25,26], a pair-wise join between any two sensor nodes is investigated. Multiple routing trees are employed and cost-based join initiation for long-running join query is proposed. Also, the issue of adaptive and cost-based re-optimization against the changes of sampled data is dealt with. In [2], Synopsis Join adapted from hash join as well as semijoin is proposed. It employs geographic hashing for partitioning and filtering of the joining attribute values and optimally determines the nodes of the final joins for each matched value. In [29], Two-Phase Self Join where one join operand relation is fully reduced with a semijoin is proposed. To process a join query, it employs a query decomposition technique assuming that the selection predicate on one relation is highly selective. In [27], SENS-Join based on a 2-way semijoin is proposed. It handles a general type of join predicates on multiple attributes, using a quad-tree as a multi-dimensional join filter based on Z-ordering. In [19], PEJA adapted from hash join as well as sort-merge join is proposed. In WSNs, physical sorting of the tuples distributed over the sensor nodes is infeasible. Thus, it conducts logical sort of tuples through division of joining attribute value range, partitioning and filtering tuples with geographic hashing. In [28,30], algorithms using the join filters are proposed for continuous queries on multiple attributes. At each sensor node involved in the join query processing, a join filter is installed for each joining attribute and only those tuples whose join attribute values pass the relevant filters are sent to the base station.
Other issues addressed by the state-of-the-art includes routing protocols, query dissemination, join initiation, involvement of the base station in in-network processing, collection of metadata for continuous joins [3].
In [18,24,31], in-network join processing where the Bloom filter is employed in WSNs are addressed. In [18], for a join between an external relation and the virtual relation in WSNs, a technique where a Bloom filter constructed with the joining attribute values of the external relation is injected into the network is investigated. In [24], a technique where the Bloom filter is transmitted instead of the joining attribute values in in-network computation of the two semijoins and to answer a join , is proposed. In this technique, when the Bloom filter constructed for is disseminated through the routing tree of , it is selectively forwarded to the subtrees of the routing tree such that the cost of sending it is always compensated in reduction. The optimal solution in such a selective forwarding is proposed. In [31], an extension of the Bloom filter called Window Bloom filter (WBF) is devised to support a general join query with a time window. The proposed technique represents join attribute values in a compact way with the WBF, and saves the energy consumption by not sending the redundant join attribute values.
As described in Section 3.3, in SRJA [6], the value range instead of the joining attribute values is sent as a histogram-based synopsis. Transmitting the value ranges instead of the joining attribute values is considered for in-network join processing [18]. In [2], a technique using a histogram-based synopsis of the join operand relations coupled with geographic hashing is proposed. However, the considered join in these techniques is not an iceberg join.
The iceberg query was first introduced in [32]. It is defined as a query that retrieves aggregate values above some specified threshold in the applications such as data warehousing, data mining, information retrieval, and so on. Iceberg query processing over distributed data was also investigated [33,34,35]. However, the join query was not dealt with in these work. In [7], an iceberg distant join in spatial databases was investigated. In this work, the type of the join query is different from the one we consider in this paper in that the cardinality constraint is only on one join operand relation. That is, when the iceberg threshold is , the tuple of one relation that is joined with more than tuples of the other relation is qualified for the query.
8. Conclusions
In this paper, we investigated an alternative approach to processing an iceberg join in WSNs, and described an optimized scheme. In the previous approach, the join predicate is checked first, and the cardinality constraint is checked next. In our approach, the order is reversed. Our scheme refers to the aggregate count of each of the joining attribute values, logically fragmenting the relations on the counts. Based on the fragmentation, it generates the optimal sequence of 2-way fragment semijoins using a Bloom filter as a synopsis of joining attribute values in filtering non-joinable tuples. A detailed set of experiments showed that our approach is substantially superior to the previous one.
As a future work, we plan to extend our scheme for more complicated cases. First, the two regions producing the virtual relations to be joined could partially or fully overlap with each other. Secondly, more than two regions are involved in multiple joins. Thirdly, the correlations among the sensor readings along the neighboring n regions are to be monitored with an n-way join.
Conflicts of Interest
The author declares no conflict of interest.
References
- Madden, S.; Franklin, M.; Hellerstein, J.; Hong, W. TinyDB: An Acquisitional Query Processing System for Sensor Networks. ACM Trans. Database Syst. 2005, 1, 122–173. [Google Scholar] [CrossRef]
- Yu, H.; Lim, E.; Zhang, J. On In-Network Synopsis Join Processing for Sensor Networks. In Proceedings of the 7th International Conference on Mobile Data Management, Nara, Japan, 9–13 May 2006; pp. 32–39.
- Kang, H. In-network processing of joins in wireless sensor networks. Sensors 2013, 13, 3358–3393. [Google Scholar] [CrossRef] [PubMed]
- Zhao, F.; Guibas, L. Wireless Sensor Networks: An Information Processing Approach; Morgan Kaufmann: San Francisco, CA, USA, 2004. [Google Scholar]
- Stattner, E.; Vidot, N.; Hunel, P.; Collard, M. Wireless Sensor Network for Habitat Monitoring: A Counting Heuristic. In Proceedings of the 37th Annual IEEE Conference on Local Computer Networks Workshops, Clearwater, FL, USA, 22–25 October 2012; pp. 753–760.
- Lai, Y.; Lin, Z.; Gao, X. SRJA: Iceberg Join Processing in Wireless Sensor Networks. In Proceedings of the International Workshop on Database Technology and Applications, Wuhan, China, 27–28 November 2010; pp. 1–4.
- Shou, Y.; Mamoulis, N.; Cao, H.; Papadias, D.; Cheung, D. Evaluation of Iceberg Distance Joins. In Proceedings of the 8th International Symposium on Advances in Spatial and Temporal Databases, Santorini Island, Greece, 24–27 July 2003; pp. 270–288.
- Cohen, S.; Matias, Y. Spectral Bloom Filters. In Proceedings of the ACM SIGMOD International Conference on Management of Data, San Diego, CA, USA, 9–12 June 2003; pp. 241–252.
- Arasu, A.; Babu, S.; Widom, J. The CQL continuous query language: Semantic foundations and query execution. VLDB J. 2006, 2, 121–142. [Google Scholar] [CrossRef]
- Bloom, B. Space/time trade-offs in hash coding with allowable errors. Comm. ACM 1970, 7, 422–426. [Google Scholar] [CrossRef]
- Kang, H.; Roussopoulos, N. Using 2-way Semijoins in Distributed Query Processing. In Proceedings of the 3rd IEEE International Conference on Data Engineering, Los Angeles, CA, USA, 3–5 February 1987; pp. 644–651.
- Roussopoulos, N.; Kang, H. A pipeline n-way join algorithm based on the 2-way semijoin program. IEEE Trans. Knowl. Data Eng. 1991, 4, 486–495. [Google Scholar] [CrossRef]
- Bernstein, P.A.; Chiu, D.W. Using semi-joins to solve relational queries. J. ACM 1981, 1, 25–40. [Google Scholar] [CrossRef]
- Özsu, M.T.; Valduriez, P. Principles of Distributed Database Systems, 3rd ed.; Springer: New York, NY, USA, 2011. [Google Scholar]
- Li, Z.; Ross, K.A. RERF Join: An Alternative to Two-way Semijoin and Bloomjoin. In Proceedings of the 4th International Conference on Information and Knowledge Management, Baltimore, MD, USA, 28 November–2 December 1995; pp. 137–144.
- Andrei, B.; Mitzenmacher, M. Network applications of Bloom filters: A survey. Internet Math. 2004, 4, 485–509. [Google Scholar]
- Mullin, J.K. Optimal semijoins for distributed database systems. IEEE Trans. Softw. Eng. 1990, 5, 558–560. [Google Scholar] [CrossRef]
- Abadi, D.; Madden, S.; Lindner, W. REED: Robust, Efficient Filtering and Event Detection in sensor networks. In Proceedings of the 31st International Conference on very Large Data Bases, Trondheim, Norway, 30 August–2 September 2005; pp. 769–780.
- Lai, Y.; Chen, Y.; Chen, H. PEJA: Progressive energy-efficient join processing for sensor networks. J. Comput. Sci. Technol. 2008, 6, 957–972. [Google Scholar] [CrossRef]
- Pandit, A.; Gupta, H. Communication-Efficient Implementation of Range-Join in Sensor Networks. In Proceedings of 11th International Conference on Database Systems for Advanced Applications, Singapore, 12–15 April 2006; pp. 859–869.
- Chowdhary, V.; Gupta, H. Communication-efficient Implementation of Join in Sensor Networks. In Proceedings of the 10th International Conference on Database Systems for Advanced Applications, Beijing, China, 17–20 April 2005; pp. 447–460.
- Coman, A.; Nascimento, M. Distributed Algorithm for Joins in Sensor Networks. In Proceedings of the 19th International Conference on Scientific and Statistical Database Management, Banff, Canada, 9–11 July 2007.
- Coman, A.; Nascimento, M.; Sander, J. On Join Location in Sensor Networks. In Proceedings of the 8th International Conference on Mobile Data Management, Mannheim, Germany, 7–11 May 2007; pp. 190–197.
- Min, J.; Yang, H.; Chung, C. Cost based in-network join strategy in tree routing sensor networks. Inf. Sci. 2011, 16, 3443–3458. [Google Scholar] [CrossRef]
- Mihaylov, S.; Jacob, M.; Ives, Z.; Guha, S. Dynamic Join Optimization in Multi-Hop Wireless Sensor Networks. In Proceedings of the 36th International Conference on very Large Data Bases, Singapore, 13–17 September 2010; pp. 1279–1290.
- Mihaylov, S.; Jacob, M.; Ives, Z.; Guha, S. A Substrate for In-Network Sensor Data Integration. In Proceedings of the 5th Workshop on Data Management for Sensor Networks, Auckland, New Zealand, 24 August 2008; pp. 35–41.
- Stern, M.; Buchmann, E.; Böhm, K. Towards Efficient Processing of General-Purpose Joins in Sensor Networks. In Proceedings of the 25th IEEE International Conference on Data Engineering, Shanghai, China, 29 March–2 April 2009; pp. 126–137.
- Stern, M.; Böhm, K.; Buchmann, E. Processing Continuous Join Queries in Sensor Networks: A Filtering Approach. In Proceedings of the ACM SIGMOD International Conference on Management of Data, Indianapolis, IN, USA, 6–11 June 2010; pp. 267–278.
- Yang, X.; Lim, H.; Özsu, M.; Tan, K. In-Network Execution of Monitoring Queries in Sensor Networks. In Proceedings of the ACM SIGMOD International Conference on Management of Data, Beijing, China, 12–14 June 2007; pp. 521–532.
- Mo, S.; Fan, Y.; Li, Y.; Wang, X. Multi-Attribute Join Query Processing in Sensor Networks. J. Netw. 2014, 10, 2702–2712. [Google Scholar]
- Min, J.; Kim, J.; Shim, K. TWINS: Efficient time-windowed in-network joins for sensor networks. Inf. Sci. 2014, 1, 87–109. [Google Scholar] [CrossRef]
- Fang, M.; Shivakumar, N.; Garcia-Molina, H.; Motwani, R.; Ullman, J.D. Computing Iceberg Queries Efficiently. In Proceedings of the 24th International Conference on Very Large Data Bases, New York, NY, USA, 24–27 August 1998; pp. 299–310.
- Zhao, H.; Lall, A.; Ogihara, M.; Xu, J. Global Iceberg Detection over Distributed Data Streams. In Proceedings of the 26th International Conference on Data Engineering, Long Beach, CA, USA, 1–6 March 2010; pp. 557–568.
- Manjhi, A.; Shkapenyuk, V.; Dhamdhere, K.; Olston, C. Finding (Recently) Frequent Items in Distributed Data Streams. In Proceedings of the 21st International Conference on Data Engineering, Tokyo, Japan, 5–8 April 2005; pp. 767–778.
- Zhao, Q.; Ogihara, M.; Wang, H.; Xu, J. Finding Global Icebergs over Distributed Data Sets. In Proceedings of the 25th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, Chicago, IL, USA, 26–28 June 2006; pp. 298–307.
© 2015 by the authors; licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/4.0/).