Fakultät für Informatik TU München - Fakultät für Informatik
Lehrstuhl III: Datenbanksysteme 		Technische Universität München
Home  |  Personen  |  Forschung  |  Lehre  |  Sonstiges  | 

StreamGlobe: Adaptive Query Processing and Optimization in Streaming P2P Environments

Bernhard Stegmaier

Richard Kuntschke

Alfons Kemper


Introduction

In recent years, Peer-to-Peer (P2P) networks have gained huge attention both in the media and the computer science community. This is, on the one hand, due to the stunning success of filesharing systems like, e.g., Napster and Gnutella. But on the other hand, it is also caused by the degree of flexibility these networks provide. For example, they can be used for setting up ad-hoc sensor networks where sensors can join and leave the network at any time, e.g., while moving across the area covered by the respective network. Of course, this does not only hold for the data delivering sensors, but also for the network nodes that query the data streams within the ad-hoc network. In the past, various approaches for finding information, i.e., documents, files, etc., in P2P networks have been studied, which has led to a number of topologies for P2P networks, one example being super-peer networks [14]. Dealing with data streams, finding peers which deliver the required information is not the only task. Additionally, a continuous data flow from data sources to consumers in the network has to be established. An interesting challenge arising in this highly dynamic environment is to develop a distributed, self-organizing system for efficient routing and in-network query processing. We pursue this goal with our StreamGlobe system, which is based on its predecessor ObjectGlobe [2]. While StreamGlobe is not restricted to sensor networks, we use them as a motivating example in the following.

Consider Figure 1 as an abstract example of a possible application scenario for StreamGlobe. The depicted network contains four so-called super-peers ($SP_0$ to $SP_3$), forming a stationary super-peer backbone network, and five possibly mobile thin-peers, or peers for short, ($P_0$ to $P_4$) connected to the backbone. Peers $P_0$, $P_2$ and $P_3$ are a cell phone, a laptop, and a PDA, respectively. These peers are meant to register queries in the network and are therefore at the receiving end of data streams. In contrast to that, peers $P_1$ and $P_4$ are sensors delivering their sensor data to the network in the form of XML data streams. Two examples for applications of similar real-life networks would be satellite communication and weather observation. In the former case, orbiting satellites would be the moving sensors--or rather collections of sensors--streaming their data to various receiving stations on the ground for evaluation. In the latter case, the sensors would be attached to weather balloons or observation planes, delivering data like temperature, humidity, etc. to enable weather forecasts for different regions.

To illustrate some of the difficulties of query processing in such networks and to motivate our approach, we now introduce a rather simplified real-world example in a little more detail. Let us assume that $P_4$ in Figure 1 delivers a data stream produced by special sensor suits worn by firefighters in action. The sensors continuously deliver sensor readings containing the firefighters' identity (id) and GPS coordinates (x, y), as well as information about their vital statistics and the environmental conditions. We have exemplarily chosen to monitor body temperature (bt), pulse rate (pr), and oxygen saturation (os), as well as environmental temperature (et), carbon dioxide concentration (CO2), and sulfur dioxide concentration (SO2). For brevity, we use the following simplified DTD to describe the data stream, although StreamGlobe actually employs XML Schema. 

<!ELEMENT reading (id, x, y, bt, pr, os,
                   et, CO2, SO2)>
<!ELEMENT id (#PCDATA)> ...
The remaining elements have analogous DTD entries. Let us now further assume that $P_0$ and $P_2$ are devices used by an emergency physician and the fire department. The former should receive a notification on a cell phone whenever a firefighter's oxygen saturation reaches a critical level. Therefore, the peer represented by the physician's cell phone registers the following XQuery. 
for $m in stream("firefighters")/reading
where $m/os < 92 or $m/os > 98
return <alert> {$m/id} {$m/x} {$m/y}
               {$m/os} </alert>
The fire department is interested in monitoring the environmental conditions, e.g., to be able to issue a warning if the conditions get critical for the firefighters on site or the residents living nearby. Thus, it registers the following XQuery. 
for $m in stream("firefighters")/reading
return <gas> {$m/id} {$m/x} {$m/y}
             {$m/CO2} {$m/SO2} </gas>
StreamGlobe will handle this scenario as follows. Suppose we want to reduce network traffic. The data of $P_4$ will be sent to $SP_3$ where it will be filtered, leaving only the elements id, x, y, os, CO2 and SO2 in the stream. The elements bt, pr and et can be removed as they are not needed (i.e. not subscribed) anywhere else in the network, leading to a smaller data stream and therefore reducing network traffic. The resulting stream, containing the combined information for satisfying the queries of $P_0$ and $P_2$, is routed to $SP_2$. Note that up to now, data needed by both $P_0$ and $P_2$ has been routed as one single stream through the network. At $SP_2$, however, the stream has to be split into the--in our case--non-disjoint parts for the two receiving peers. This involves replicating the stream and again filtering the two new streams, resulting in two streams which constitute the final results for the two queries. These are eventually routed to $P_0$ and $P_2$ via $SP_0$ and $SP_1$, respectively.

Decisions such as where to execute which operators in the network and how to route the data streams are made by the StreamGlobe Query Optimizer. Additional difficulties arise by the fact that the network can change over time by adding or deleting queries and data streams which requires a strategy for continuous or periodic reoptimization. The distinguishing features of StreamGlobe compared to related systems are thereby its self-organizing network, in terms of continuous reactions to dynamic changes in registered data streams and queries, and its routing and optimization approaches for query and network traffic optimization in P2P networks.

Figure 1: Example Scenario
\includegraphics[width=0.8\linewidth]{figures/scenario}

The remainder is organized as follows. Section 2 presents some related work. In Section 3 we give an overview of the StreamGlobe system architecture. Section 4 deals with optimization and query processing in StreamGlobe. In Section 5 we present a brief report on the current implementation status of our StreamGlobe prototype. Finally, Section 6 concludes the paper.


Related Work

In the following, we present a brief overview of some work related to our StreamGlobe system. We will only deal with existing data stream systems and a few aspects of query processing.

TelegraphCQ [5] is a system that deals with continuously adaptive query processing in a data stream environment. Cougar [15] tasks sensor networks through declarative queries. Aurora [4] is a new DBMS for monitoring applications and constitutes a centralized stream processor for dealing with streaming data. In [7] two complementary large-scale distributed stream processing systems, Aurora* and Medusa, are described. Aurora* is a distributed version of Aurora with nodes belonging to a common administrative domain. Medusa supports the federated operation of several Aurora nodes across administrative boundaries. STREAM [1] incorporates its own declarative query language for continuous queries over data streams and relations. It handles streams by converting them into relations using special windowing operators and converting the query result back into a data stream if necessary. All of these systems more or less focus on special aspects of (adaptive) query processing, load balancing, or quality-of-service management. The major contribution of StreamGlobe lies in the fact that it does not only efficiently locate and query data streams, but also employs in-network query processing for adaptively optimizing data flow within the network. Thus, StreamGlobe pushes query processing from subscribing clients towards data sources in the network. The optimization is based on data stream clustering derived from clustering the queries in the system. NiagaraCQ [6] intends to achieve a high level of scalability in continuous query processing by grouping continuous queries according to similar structures. In StreamGlobe, we employ a similar multi-query optimization approach to reduce network traffic and to enable efficient query evaluation.

With respect to query processing, works in the fields of multi-query optimization, as pointed out above, and continuous queries are related to StreamGlobe. Multi-query optimization (MQO) has been addressed in [13]. It pursues the goal of processing multiple queries all at once instead of one query at a time. The main optimization potential lies in the fact that queries may share a considerable amount of common--or at least similar--input data that can be reused for more than one query. Obviously, StreamGlobe in general has to deal with a set of queries simultaneously, thus rendering multi-query optimization an applicable and suitable optimization approach. Also, queries in StreamGlobe are usually continuous queries over data streams. Efficient processing of such queries has been examined in [11]. Query processing in sensor networks has been explicitly addressed in [16].


StreamGlobe Architecture Overview

StreamGlobe constitutes a federation of servers (or peers) which carry out query processing tasks according to their capabilities. The basic architecture of a peer is depicted in Figure 2. The various layers of this architecture will be discussed in the following sections. Dashed lines mark layers whose presence depends on the capabilities of the peer.

Network Topology

At the bottom of Figure 2, the physical network layer is depicted. On top of this, StreamGlobe establishes a logical overlay network constituting a federation of heterogeneous peers. Being a research platform, we do not restrict ourselves to employing a special P2P network topology for StreamGlobe at the moment, so our notion of a P2P network is as follows: The P2P network consists of a set of peers. Each peer has a set of other peers as neighbors. A peer only interacts with its neighbors, i.e., no direct communication takes place between two peers not being neighbors. If data has to be transferred between two random peers, a route between these two peers has to be established such that two successive peers on this route are neighbors and the start/end of the route is the source peer and the destination peer, respectively. For the implementation of this overlay network, previous work on P2P network topologies can be employed, e.g., a structured approach based on Cayley graphs as used in the HyperCuP [12] topology. Since a major goal is building a network with various peers having a great variety in their computing power--ranging from small, mobile devices to stationary workstations or servers--, we have to classify peers according to their capabilities. Thin-peers are devices with low computational power, like sensor devices, PDAs, cell phones, etc., which are not able to carry out complex query processing tasks. In contrast, super-peers are stationary workstations or servers providing enough resources for extensive query processing. These super-peers establish a backbone taking over query processing tasks which cannot be performed by other peers and thus they constitute a super-peer network topology similar to that in [14].

Client Interface

User interaction in StreamGlobe is depicted at the top layer of Figure 2. StreamGlobe enables clients to specify subscription rules for information processing and retrieval using the XQuery language. A subscription rule is registered at a certain peer, i.e., normally at the devices users are working with, e.g., their PDAs, laptops, etc. In our context, subscriptions are real queries and not just queries for retrieving matching files or documents. In fact, StreamGlobe enables expressive transformations of data streams according to registered subscription rules, allowing clients to flexibly tailor data streams to their individual requirements.

Similar to clients, data sources also register the provided data streams at a certain peer within the StreamGlobe system. Data streams can be registered in two ways. A data source may register its data stream as an individual stream, which then is published using a unique identifier. Another possibility is registering a data stream as part of a virtual data stream, which again is accessible using a unique identifier and multiplexes all the data of the participating data sources into one single stream. This technique is used in the introductory example to merge the sensor data of all firefighters. The schema of the data streams is specified using XML Schema. Streams are fed into StreamGlobe using wrappers, which are running on corresponding peers and transform the data into a suitable format, e.g., by converting raw sensor data to XML.

Figure 2: Architecture Overview
\includegraphics[width=0.6\linewidth]{figures/architecture}

Peer Architecture

A more detailed view of the peer architecture is depicted in Figure 3.

Figure 3: Peer Architecture
\includegraphics[width=0.6\linewidth]{figures/node}
It basically reflects the structure sitting on top of the P2P network layer of Figure 2. Every peer has a control port over which the individual peers exchange control information, e.g., registration of new neighbors, subscriptions, etc. This interface is implemented using SOAP RPC calls for interchanging control messages. Parameters of the control messages are specified as XML documents. These control messages are parsed by the command parser and correspondingly executed. Dashed boxes mark modules that vary between different peers according to their functionality, as mentioned earlier. For example, thin-peers do not incorporate a complete optimization and query execution unit, but only provide basic functionality. E.g., a cell phone might only provide functionality for receiving and displaying data streams and a sensor device might only be able to transmit its measurement data. The metadata management component, which will be discussed further in the next section, interacts with each of the components and provides information needed for network management, optimization, and query execution. Peers exchange XML data streams representing user data over their data ports. The data streams are initially parsed by the wrappers and represented as a sequence of SAX events. Special events are interspersed within these streams, which are used for internal purposes. E.g., synchronization marks are generated whenever the system restructures the data flow to synchronize all affected peers for the change in query execution.


Metadata Management

As Figures 2 and 3 suggest, metadata is needed in all layers of the StreamGlobe architecture. The metadata management is based on the distributed metadata management of ObjectGlobe [8] and forms a backbone that peers exchange metadata with. Among other things, the metadata management stores neighborhood relationships and capabilities of peers, subscription rules, and registered data streams. Moreover, it collects and provides statistics of data streams, i.e., size and frequency of contained elements. Statistics can be supplied by the data source, computed online by the corresponding wrapper, or both. If changes in the network occur, e.g., peers joining or leaving the network, the metadata is updated correspondingly.


Optimization and Evaluation Strategy

In Section 1 we have briefly introduced our approach of optimizing the data flow in the network using in-network query processing. Obviously, a centralized optimization component is not feasible in a large, distributed environment. Thus, we employ a hierarchically organized optimization. For that purpose, the network is partitioned into segments or subnets. In each subnet, a so-called speaker-peer performs local optimization and coordination with neighboring subnets. Basically, optimization in StreamGlobe determines the peers at which (at least parts of) the subscriptions are executed and decides how to route the data streams in the network. Optimization has three major goals:

  1. Enable users to register arbitrary subscriptions at any (suitable) device regardless of its processing capabilities.
  2. Achieve a good distribution of data streams in the network without congesting it with redundant transmissions.
  3. Optimize the evaluation of a large number of subscription rules by means of multi-query optimization.
The goals (1) and (3) are accomplished by pushing query execution into the network. Subscription rules, i.e., XQueries, are evaluated using our FluX query engine [10]. The second goal is achieved by placing filtering operators on the routes of data streams. These filter operators are implemented using XSAGs [9]. More details will be presented in Section 4.

Of course, optimization is a continuous process which reoptimizes the system on-the-fly as peers come and go, data sources and subscription rules are registered and deregistered, and data streams change over time.


Optimization and Query Processing

In this section, we describe some of our approaches to optimizing network traffic and performing efficient query processing.

Optimization

First, we address the key ideas for achieving the three optimization goals stated in Section 3.5. The first goal is achieved by appropriately pushing subscription evaluation into the network. This is done by executing the subscription as a whole or in part at one or more appropriate peers on a route from the data sources to the peer where the subscription was registered. An appropriate peer is a peer that is able to process the subscription, i.e., has sufficient computing power, and is selected by the query optimizer, taking into account optimization goals like, e.g., reducing network traffic. In order to support powerful subscription rules, the concept of mobile code is employed. Besides peers providing a basic set of functionality, users are enabled to include user-defined code in subscription rules, e.g., predicates, aggregation operators, etc. This user-defined code is subsequently instantiated at the peer processing the corresponding part of the subscription.

The second goal is accomplished by using two techniques complementing each other. The first technique is filtering of data streams. Filtering is achieved by using either projection (called structural filtering) or selection (called content-based filtering) or both on the elements of a data stream--as described in the example scenario in Section 1--and is performed by filtering operators. These filtering operators are executed at peers on the route of the data stream as close to the source of the stream as possible. Thus, the amount of data that has to be transmitted through the network is reduced. Filtering is complemented by data stream clustering. During the registration of a new query, the system identifies the constituent parts of the query. This includes the data streams needed to answer the query (content aspect) as well as the operations, e.g., projection, selection, joins, etc., applied to those streams (structural aspect). The result of this step is a set of partial data streams needed to answer the respective query. The partial data streams are represented by partial schemas based upon the schemas of the original data streams referenced in the query. These are used during the actual data stream clustering stage. In this stage, it is the task of the StreamGlobe Query Optimizer to distribute the identified partial schemas in the network. To do so, it takes into account the current distribution of data streams in the network (the current data stream clustering) as well as a cost model based on parameters like network bandwith, network traffic, computing power, load factor of peers, etc., to map (partial) data streams to network connections. This possibly leads to the combination of existing streams with newly identified partial streams from the currently processed query to form new data stream clusters in the network. The final result of this step is a new data stream clustering for the network.

Data stream clustering as described above also contributes to fulfilling the third goal of effective multi-query optimization. In every subnet, the speaker-peer analyzes all registered subscriptions and identifies common subexpressions. These common subexpressions are evaluated once in this subnet by executing a subscription rule corresponding to a common subexpression at a suitable peer. Rather than evaluating this subexpression in each of the original subscriptions individually, they are rewritten to utilize the newly generated and specialized data stream stemming from the common subexpression. Besides reducing the workload of the affected peers, network traffic might be further reduced. For instance, a common task will be aggregating sensor data. Instead of transmitting the whole dataset to every peer performing the same aggregation, it will be executed near the data source and only the aggregated results, which will be a much smaller amount of data, will be delivered to the respective peers.

Figure 4 shows the query evaluation strategy using the example scenario from Section 1. The symbols at the network connections represent groups of elements. The diamond represents the elements bt, pr, and et, the circle represents os, the triangle represents CO2 and SO2, and the rectangle represents id, x, and y. Projections cause symbols to disappear as their corresponding elements are filtered out of the stream. Selections remove certain instances of elements that do not fulfill the selection predicates which is depicted as dotted symbols. An exclamation mark denotes a change in data representation, e.g., the introduction of the alert element at $SP_2$ in the result for the query at $P_0$. In our example, the introduction of the gas element in the answer for the query at $P_2$ is supposed to take place at $P_2$ itself and therefore does not show up in the network. The decision whether to perform the FluX subscription evaluation at $P_2$, $SP_1$, or $SP_2$ is made by the optimizer and is based on factors like computational power and current load factor of peers.

Continuing with our example from Section 1, let us now assume that $P_2$ requires the data from $P_4$ to be joined with data from sensor $P_1$. One possibility would be to filter $P_1$'s data stream accordingly at $SP_0$ and route the resulting stream directly to $SP_1$ where the join processing takes place and the result gets delivered to $P_2$. This would probably be the best solution if no data from peer $P_1$ is needed anywhere else in the network. However, when $P_3$ also requests data from $P_1$, it might be better to route a data stream with the data for both $P_2$ and $P_3$ from $SP_0$ to $SP_2$ first and then split the stream at $SP_2$, routing $P_3$'s part directly to $P_3$. The remaining stream for peer $P_2$ could then be routed to $SP_1$ where the join processing could take place. But if the join is known to produce a relatively small result compared to the input streams, it would probably be better in terms of network traffic to process the join already at $SP_2$ and then route the result to $P_2$ via $SP_1$. This is an example for a more difficult decision that has to be made by the StreamGlobe Query Optimizer.

Figure 4: Query Evaluation Plan for Example Scenario
\begin{figure}\begin{center} \resizebox{\linewidth}{!}{% \input{figures/filter.pstex_t}} \end{center} \vspace*{-3ex} \vspace*{1.5ex} \end{figure}

Query Processing

Let us now outline some basic concepts used for in-network query processing. Query execution in StreamGlobe focuses on processing streaming data and therefore employs push-based evaluation strategies--in contrast to traditional query engines where data is normally ``pulled'' from subordinate operators, e.g., by using the iterator model.

First, we will explain how filtering operators are executed. As outlined before, filtering operators perform a projection of a data stream on the required parts of the entire schema and a selection according to predicates of a subscription rule. Since the basic schema of the original data stream remains the same1 (besides discarding unnecessary information), projection can be done on-the-fly without the need of buffering parts of the data stream. Performing selections is somewhat more difficult, because in the worst case data cannot be propagated before the predicate is evaluated, which renders buffering inevitable. Thus, we restrict filtering operators to only employ predicates referring to a single data object of the data stream. Therewith, at most the current data object has to be buffered for being able to propagate the filtered data stream. Hence, we can implement these operators scalably and efficiently using automata-based techniques as described in [9].

In order to evaluate subscription rules on data streams, we employ novel optimization techniques, called FluX [10], for minimizing memory buffer consumption during the execution of XQueries on streaming data. These techniques enable query evaluation on data streams with very low memory consumption and thus provide for a scalable evaluation of subscription rules. However, some subscription rules might possibly need unbounded buffering, e.g., subscriptions containing joins or special aggregates. In such cases, unbounded buffering is precluded by requiring users to specify window constraints. These allow for a scalable execution on infinite data streams.


Implementation Status

We have implemented the basic infrastructure of StreamGlobe and we are able to establish an overlay P2P network between peers. We have completed prototype implementations of the filtering operators (XSAGs) and the streaming query engine for evaluating subscription rules (FluX). These approaches are currently being integrated into the StreamGlobe system. At the moment, the optimization techniques of Section 4 are developed and implemented. A first prototype system of StreamGlobe including all the basic features presented in this paper will be operational by the end of the year.


Conclusion

We have described the ongoing development of our StreamGlobe system. StreamGlobe is focused on meeting the challenges that arise in processing data streams in an ad-hoc P2P network scenario. It differs from other data stream systems in not only efficiently locating and querying data streams, but also optimizing the data flow in the network using expressive in-network query processing techniques. Specifically, this is achieved by pushing operators for query processing into the network together with structural and content-based filtering. Continuous reoptimization leads to an adaptive and self-optimizing system, which enables users to carry out powerful information processing and retrieval. StreamGlobe serves as a research platform for our future work. Future research will cover further topics in query processing on streaming data, optimization methods for distributed data stream processing, load balancing and quality-of-service aspects [3] in a distributed data stream management system.




Bibliography

1
A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, R. Motwani, I. Nishizawa, U. Srivastava, D. Thomas, R. Varma, and J. Widom.
STREAM: The Stanford Stream Data Manager.
IEEE Data Engineering Bulletin, 26(1):19-26, Mar. 2003.

2
R. Braumandl, M. Keidl, A. Kemper, D. Kossmann, A. Kreutz, S. Seltzsam, and K. Stocker.
ObjectGlobe: Ubiquitous query processing on the Internet.
The VLDB Journal, 10(1):48-71, Aug. 2001.

3
R. Braumandl, A. Kemper, and D. Kossmann.
Quality of Service in an Information Economy.
ACM Transactions on Internet Technology, 3(4):291-333, Nov. 2003.

4
D. Carney, U. Çetintemel, M. Cherniack, C. Convey, S. Lee, G. Seidman, M. Stonebraker, N. Tatbul, and S. B. Zdonik.
Monitoring Streams - A New Class of Data Management Applications.
In Proc. of the Intl. Conf. on Very Large Data Bases, pages 215-226, Hong Kong, China, Aug. 2002.

5
S. Chandrasekaran, O. Cooper, A. Deshpande, M. J. Franklin, J. M. Hellerstein, W. Hong, S. Krishnamurthy, S. Madden, V. Raman, F. Reiss, and M. A. Shah.
TelegraphCQ: Continuous Dataflow Processing for an Uncertain World.
In Proc. of the Conf. on Innovative Data Systems Research, Asilomar, CA, USA, Jan. 2003.

6
J. Chen, D. J. DeWitt, F. Tian, and Y. Wang.
NiagaraCQ: A Scalable Continuous Query System for Internet Databases.
In Proc. of the ACM SIGMOD Intl. Conf. on Management of Data, pages 379-390, Dallas, TX, USA, May 2000.

7
M. Cherniack, H. Balakrishnan, M. Balazinska, D. Carney, U. Çetintemel, Y. Xing, and S. B. Zdonik.
Scalable Distributed Stream Processing.
In Proc. of the Conf. on Innovative Data Systems Research, Asilomar, CA, USA, Jan. 2003.

8
M. Keidl, A. Kreutz, A. Kemper, and D. Kossmann.
A Publish & Subscribe Architecture for Distributed Metadata Management.
In Proc. of the IEEE Intl. Conf. on Data Engineering, pages 309-320, San José, CA, USA, Feb. 2002.

9
C. Koch and S. Scherzinger.
Attribute Grammars for Scalable Query Processing on XML Streams.
In Proc. of the Intl. Workshop on Database Programming Languages, pages 233-256, Potsdam, Germany, Sept. 2003.

10
C. Koch, S. Scherzinger, N. Schweikardt, and B. Stegmaier.
Schema-based Scheduling of Event Processors and Buffer Minimization on Structured Data Streams.
In Proc. of the Intl. Conf. on Very Large Data Bases, Toronto, Canada, Aug. 2004.
Accepted for publication.

11
S. Madden, M. A. Shah, J. M. Hellerstein, and V. Raman.
Continuously Adaptive Continuous Queries over Streams.
In Proc. of the ACM SIGMOD Intl. Conf. on Management of Data, pages 49-60, Madison, WI, USA, June 2002.

12
M. T. Schlosser, M. Sintek, S. Decker, and W. Nejdl.
HyperCuP - Hypercubes, Ontologies, and Efficient Search on Peer-to-Peer Networks.
In Proc. of the Intl. Workshop on Agents and Peer-to-Peer Computing, pages 112-124, Bologna, Italy, July 2002.

13
T. K. Sellis.
Multiple-Query Optimization.
ACM Trans. on Database Systems, 13(1):23-52, Mar. 1988.

14
B. Yang and H. Garcia-Molina.
Designing a Super-Peer Network.
In Proc. of the IEEE Intl. Conf. on Data Engineering, pages 49-60, Bangalore, India, Mar. 2003.

15
Y. Yao and J. Gehrke.
The Cougar Approach to In-Network Query Processing in Sensor Networks.
ACM SIGMOD Record, 31(3):9-18, Sept. 2002.

16
Y. Yao and J. Gehrke.
Query Processing for Sensor Networks.
In Proc. of the Conf. on Innovative Data Systems Research, Asilomar, CA, USA, Jan. 2003.


Footnotes

... same1
In particular, the order of elements is preserved.
Lehrstuhl für Datenbanksysteme
Letzte Änderung: 25.05.2005 um 14:37:48