A Data Stream Publish/Subscribe Architecture with Self-adapting Queries

Transcription

1 A Data Stream Publish/Subscribe Architecture with Self-adapting Queries Alasdair J G Gray and Werner Nutt School of Mathematical and Computer Sciences, Heriot-Watt University, Edinburgh, EH14 4AS, UK. Abstract. In data stream applications, streams typically arise from a geographically distributed collection of producers and may be queried by consumers, which may be distributed as well. In such a setting, a query can be seen as a subscription asking to be informed of all tuples that satisfy a specific condition. We propose to support the publishing and querying of distributed data streams by a publish/subscribe architecture. To enable such a system to scale to a large number of producers and consumers requires the introduction of republishers which collect together data streams and make the merged stream available. If republishers consume from other republishers, a hierarchy of republishers results. We present a formalism that allows distributed data streams, published by independent stream producers, to be integrated as views on a mediated schema. We use the formalism to develop methods to adapt query plans to changes in the set of available data streams and allow consumers to dynamically change which streams they subscribe to. 1 Introduction Data streams usually record measurements that originate from sensors which are installed at multiple locations, or which may even be moving, e.g. in road traffic monitoring. Similarly, users interested in the streams are often distributed as well. We propose to understand the management of such streams as a data integration task [9]. As opposed to the one-time queries posed over a database, which are interested in receiving a set of answers against the current set of data, queries over data streams are continuous. One can distinguish three main ways in which such queries are used. The first is to direct data to a database where it is archived to be queried later on. Another is to feed monitoring data produced by sensors into databases that maintain a cache of current data and reflect the current state of the entities being monitored. Finally, continuous queries may be set up to detect classes of events. Such queries scan a stream for data values that exceed some threshold or that form specific patterns. Often, considerable leverage can already be gained if such tasks are realised for relatively weak query languages [4, 12]. In the present paper, we build upon a data integration approach to publishing and querying data streams which has been partially implemented in the R-GMA Grid information and monitoring system [3, 4] which is now being deployed in

2 major production Grids, e.g. LCG. The approach follows the proposal for a Grid Monitoring Architecture (GMA) [13] made by the Global Grid Forum. Although these ideas have been developed first in the context of Grid monitoring, they are far more general and can be applied to other scenarios where queries are posed over distributed streams. In this approach, sources of stream data are called producers while entities posing queries are called consumers. Producers and consumers interact with each other according to a publish/subscribe protocol. A registry service allows producers to advertise what kind of data they can supply, and consumers to register what kind of data they request. Both advertisements and requests take the form of queries over a set of relations which together make up a global schema. The rôle of the mediator [14] is shared by the registry service, which finds suitable producers for a query, and the consumer, which constructs a collection of queries over these producers and executes them. Since components can only maintain a limited number of connections, we introducer republishers to enable such a system to scale to a large number of producers and consumers, as necessary for a Grid. A republisher poses a query over the global schema, and makes the answer stream available for other queries. As such, these republishers can be used to create a hierarchy. At the bottom of such a hierarchy would be the producers. These would feed into the republishers with the most specific queries. In turn, these republishers would be used by more general republishers. The need for something like a republisher hierarchy has been identified in other Grid monitoring systems. For example, the widely used MDS2 system [5] has an information collection service called a GIIS which can be formed into a hierarchy. In such a hierarchy, the bottom level GIISs collect information directly from the data sources. These then feed information into GIISs at the higher levels of the structure. The formation of a hierarchy is useful as it (i) collects the trickles of information produced by sensors and merges them into data streams, (ii) reduces the number of connections that any one component needs to maintain, e.g. a consumer need not contact every producer of relevant information if there exists a republisher which already merges this data together, and (iii) can be used as a cache of either latest-state information or historical data by storing the data streams into a suitable database. Whilst the presence of republishers allows for more efficient ways to answer a consumer query, they also introduce complications. First, with republishers, redundancy arises amongst data, since a piece of data that has been published by a producer may also be made available by one or more republishers. Thus, when answering a query, a choice has to be made as to where to retrieve which data. Secondly, continuous queries are issued at some point in time and continue to return answers until explicitly ended. This means that producers or republishers may be added to, or removed from, the hierarchy during the lifetime of a query and techniques are needed to adjust consumer query plans to such changes. Related to this is the issue of maintaining the hierarchy. The formation

3 of hierarchies in the MDS2 system, for instance, is a manual process. Thus, if a GIIS should become unavailable there is no mechanism by which the system can adapt to overcome this. Building upon previous techniques for planning consumer queries in the presence of stream republishers [3, 8], the main contributions of this paper are to (i) formalise the techniques for adapting queries when the set of data sources changes, and (ii) develop suitable mechanisms to enable consumers to switch between data sources. The rest of this paper is structured as follows. In Section 2 we present the approach developed for publishing and querying distributed data streams. Section 3 then considers how to maintain these query plans. In Section 4 we identify desirable properties for a hierarchy of republishers and in Section 5 we develop methods for switching between data sources. We present related work in Section 6 and our conclusions in Section 7. 2 Publishing and Querying Relational Data Streams A stream publish/subscribe network consists of three kinds of components: producers, consumers, and republishers. A stream producer generates and publishes a stream of tuples; a consumer poses a query, by which it requests a stream consisting of all tuples that satisfy the query; a republisher, similar to a consumer, poses a query but also publishes the answers to that query. In order for the components to communicate with each other, there is a registry service, which knows about all components existing at any given point in time. This section summarises the approach for publishing and querying data streams developed in [3]. In this paper, we consider only continuous queries that are selections on a relation. This is similar to the class of continuous queries currently supported by the R-GMA system, where continuous queries are used to control the flow of data and more complex queries are posed over the caches held by the republishers. 2.1 Publishing Relational Data Streams We assume that there is a global relational schema against which consumers and republishers pose their queries. The attributes of a relation in the global schema are split into three parts: key attributes, measurement attributes, and a timestamp attribute. As an example, taken from a grid monitoring application, consider the relation ntp ( network throughput ) with the schema ntp(from, to, tool, psize, latency, timestamp), which records the time it took, according to some particular tool, to transport packets of a specific size from one node to another. The underlined attributes make up the primary key of ntp, while latency is the measurement attribute. Producers inform the registry about the data they publish by registering a selection query σ D (r) or view with the registry service. This view is built up

4 using the usual operators in such queries, such as equalities and comparisons, and combining them by boolean connectives. If the relation r does not yet exist in the global schema, it is added to it. For example, a producer S 1 that publishes a data stream consisting of network latency measurements, originating at Heriot-Watt University, made with the UDPmon tool would register the view σ from= hw tool= udpmon (ntp). The meaning of such a registration is that the producer promises to publish only tuples that satisfy the view. We say that such a producer publishes for r. Thus, the producer S 1 promises to publish tuples which record the latency of packets being sent from Heriot-Watt University measured with the UDPmon tool. The view registered by a producer is only a sound, but not a complete description of its data. It is possible, therefore, that different producers register identical or overlapping views. For our discussion, we adopt a sequence-based model of streams. A stream may be infinite or end after a finite time. We capture this by defining a stream s for relation r as a partial function from the natural numbers N to the set T r of all tuples satisfying the schema of r, s: N T r, such that, if s(n) is defined for some n N, the tuple s(m) is defined for all m < n. Thus, s(n) denotes the n th tuple of s. We assume that each producer publishes a stream of tuples satisfying its descriptive view. To specify further assumptions, we need two shorthands for the subtuples of s(n). We write s κ (n) for the values of the key attributes and s τ (n) for the timestamp. We say that a stream s 1 is a substream of s 2 if s 1 can be obtained from s 2 by deleting zero or more tuples from s 2. A channel of s is a maximal substream whose tuples agree on the key attributes of s. For a tuple t occurring in s, where t κ is the subtuple of t that contains the values of the key attributes, the substream of s consisting of the tuples with s κ (n) = t κ is the channel of t. We require that the conditions D in producer views only restrict the key attributes. Thus, the view restricts the channels of a producer, but not the possible measurements. We say a stream s is duplicate free if for all m, n with m n we have that s(m) s(n). A stream s is weakly ordered if for all m, n with s κ (m) = s κ (n) and m < n we have that s τ (m) < s τ (n). This means that in every channel of s, tuples appear in the order of their timestamps. Two streams s 1 and s 2 are channel disjoint if for all m, n we have that s κ 1(m) s κ 2(n), that is, if s 1 and s 2 have no channels in common. In addition to satisfying the descriptive views, we require that the streams published by producers in a network are duplicate free and weakly ordered. Many complex queries over streams, e.g. aggregate queries, are defined for streams with some degree of order. Since it is impractical in a distributed setting to achieve that streams are completely ordered w.r.t. their timestamps, we only guarantee that each channel is ordered. Distinct producers must publish streams that are channel disjoint, although their views may overlap.

5 2.2 Queries and Query Plans Consumers and republishers pose arbitrary selection queries over the global schema, which have the form σ C (r). For example, a consumer interested in all latency measurements for packets of size at least 1024 bytes that have been sent from Heriot-Watt University would pose the query q 1 := σ from= hw psize 1024 (ntp). Similarly, a consumer interested in links with a low latency measured by the ping tool would pose the query q 2 := σ tool= ping latency 10.0 (ntp). The only assumption we make is that satisfiability and entailment of such conditions is decidable. Both consumers and republishers register their queries with the registry service. The query of a republisher also serves as a complete description of the data stream that it publishes, i.e. its view. We will now consider how to answer a consumer selection query q = σ C (r). Since there is no well-defined stream r, we have to define what an answer to such a query should be. An answer stream for q is any duplicate free and weakly ordered stream that consists of those tuples satisfying C that occur in streams of producers that publish for r. Note that, according to this definition, there can be infinitely many different answer streams for a query q. Any two answer streams consist of the same tuples, but differ regarding the order in which they appear. A query referring to a relation r in the global schema is called a global query. A global query cannot be answered by accessing r directly, since r stands only for a virtual stream. Instead, a global query has to be translated into a local query, which accesses producers and republishers, which publish physical streams. We refer jointly to producers and republishers as publishers, denoted as P, and to the set of all publishers as a publisher configuration, denoted as P. To answer global selection queries it is sufficient to consider local queries Q that are multiset unions of selections over publishers P 1,..., P m, written Q = σ C1 (P 1 ) σ Cm (P m ). An answer to Q is any stream that is obtained by selecting, for each i = 1,..., m, the tuples satisfying C i from the stream published by P i, and then merging the resulting streams. A local query Q is a plan for a global query q if every answer stream for Q is also an answer stream for q. Thus, Q is a plan for q if and only if all possible answer streams for Q have four properties. They have to be sound and complete w.r.t. q, that is, they have to contain only tuples satisfying q and they have to contain all such tuples. Moreover, they have to be duplicate free and weakly ordered. We say that a local query has any of these four properties if its answer stream always has this property. Let us consider a publisher configuration P 1 consisting of five producers measuring the network latency from three sites, Heriot-Watt University (hw), Rutherford Appleton Laboratory (ral), and Agia Napa (an), using two distinct tools. The views registered by these producers are

6 from = hw q1: psize >= 1024 Data Flow Potential answer stream q2: latency <= 10.0 R1: from = hw R3: from = hw /\ R2: from = ral S1: from = hw /\ tool = udpmon S2: from = hw /\ S3: from = ral /\ S4: from = ral /\ tool = UDPmon S5: from = an /\ Fig. 1. The consumer query q 1 being posed at the publisher configuration P 1. S 1 := σ from= hw tool= udpmon (ntp), S 2 := σ from= hw tool= ping (ntp), S 3 := σ from= ral tool= ping (ntp), S 4 := σ from= ral tool= udpmon (ntp), S 5 := σ from= an tool= ping (ntp). The publisher configuration also contains three republishers. The hw and ral sites each have a republisher which collects together all the latencies measured at that site. These would register the views R 1 := σ from= hw (ntp), and R 2 := σ from= ral (ntp) respectively. There is also a republisher which republishes all ping measurements made from hw. This republisher would register the view R 3 := σ from= hw tool= ping (ntp). Now consider the consumer query q 1 being posed at P 1. A suitable query plan for q 1 would be Q 1 = σ from= hw psize>=1024 (R 1 ). (1) Fig. 1 illustrates the flow of data between the publishers in P 1. We will discuss the possible query plans for q 2 in the next section. 2.3 Computing Consumer Query Plans We assume from now on that in global queries and descriptive views the conditions on key and measurement attributes are decoupled, that is, every condition C can be equivalently written as C κ C µ, where C κ involves only key attributes and C µ involves only non-key attributes. In practice, this assumption will usually be satisfied. The general case requires quantifier elimination techniques. We first consider consumer queries. To begin with, we single out the publishers that can contribute to a query plan. We say that a publisher P with view σ D (r), where D = D κ D µ, is relevant for a query q = σ C (r) with C = C κ C µ if it has the following two properties: 1. C D is satisfiable (Consistency); 2. C µ = D µ (Measurement Entailment). The first property states that P can potentially contribute values for some channels requested by q. The second one states that for those channels all measurements requested by q are offered by P. This ensures that all the plans computed

7 generate answer streams which are weakly ordered. Note that if P is a producer, measurement entailment always holds because the conditions in the view describing P do not involve measurement attributes. Next, we rank the relevant publishers for q according to the channels they can contribute to q. Let P be a relevant publisher and R a relevant republisher, where P has the view σ D κ D µ(r) and R has the view σ E κ E µ(r). We say that P is subsumed by R w.r.t. q, and write P q R, if D κ C κ = E κ. We say that P is strictly subsumed by R w.r.t. q, and write P q R, if P q R, but not R q P. Note that a producer can never subsume another publisher. The reason is that producer views provide only a sound description of a stream, not a complete one. We present a method for constructing query plans that consist of publishers that are maximal with regard to the subsumption relation q. We suppose that the publisher configuration and the query q = σ C (r) are fixed. A relevant publisher is maximal if it is not strictly subsumed by another relevant publisher. Let M q be the set of maximal relevant publishers for q. We partition M q into the subsets Mq S and Mq R, consisting of producers and republishers, respectively. We write P 1 q P 2 if P 1 q P 2 and P 2 q P 1. Clearly, if P 1 and P 2 are two distinct maximal relevant publishers, and P 1 q P 2, then P 1 q P 2. Note that a producer is never equivalent to another publisher because it cannot subsume the other publisher. Thus, the relation q is an equivalence relation on the set of republishers Mq R and we say that R 1 is equivalent to R 2 w.r.t. q if R 1 q R 2. We denote the equivalence class of a republisher R w.r.t. q as [R] q. Any two equivalent republishers will contribute the same answer tuples satisfying q. Therefore we need only choose one element of any class [R] q when constructing a plan for q. The set of all equivalence classes of maximal relevant republishers is denoted as M R q = { } [R] q R M R q. We call the pair M q = (M R q, Mq S ) the meta query plan for q. We show next how one can construct actual query plans from M q. A sequence R 1,..., R k of republishers that is obtained by choosing one representative from each class of republishers in M R q is called a supplier sequence for q. Let R 1,..., R k be a supplier sequence for q and S 1,..., S l be the stream producers in Mq S. Suppose the descriptive views of the R i have the conditions D i. We define the canonical republisher query for the sequence as Q R = σ C1 (R 1 ) σ Ck (R k ), where C 1 = C and C i = C (D 1 D i 1 ) for i 2..k. Moreover, we define the canonical stream producer query as Q S = σ C (S 1 ) σ C (S l ),

8 where C = C (D 1... D k ). The selection conditions on the disjuncts in Q R ensure that R i only contributes channels that no R i with i < i can deliver, and the condition C in Q S guarantees that producers only contribute channels that cannot be delivered by the republishers. Note that the conditions C i depend on the order of republishers in the sequence, but once the order is fixed, they do not depend on which republisher is chosen from an equivalence class. Moreover, although syntactically the conditions C in Q S may differ for different supplier sequences, they are all equivalent. Let us again consider q 2 being posed over P 1. The set of relevant publishers is { S 2, S 3, S 5, R 1, R 2, R 3 }, and the set of maximal relevant publishers is ({{ S 5, R 1, R 2, R 3 }. For q 2, we have that R 1 q2 R 3. Thus, we have M q2 = { R1, R 3 }, { R 2 } }, { S 5 } ). In Fig. 1, the equivalence class { R 1, R 3 } is shown by the dotted lines. A cost model may be applied to select between the republishers in an equivalence class, e.g. based on response time. From M q2 we derive Q = σ tool= ping latency 10.0 (R 1 ) σ tool= ping latency 10.0 (from= hw ) (R 2 ) σ tool= ping latency 10.0 (from= hw from= ral ) (S 5 ), as a valid query plan. The meta query plan for q 1 is M q1 = ({ { R 1 } }, ). The following theorem, taken from [3], identifies the local queries Q that are plans for a global query q. Theorem 1. Let q be a global query, Q R be the canonical republisher query, and Q S be the canonical stream producer query for some supplier sequence for q. Then, a plan for q is Q = Q R Q S. 3 Plan Maintenance When a new publisher is introduced or an existing publisher drops off, the query plans of consumers have to be adapted to the new situation. A meta query plan M q depends on two parameters: a global query q, which is explicit in our notation, and a publisher configuration P, which so far was taken to be fixed. However, during the execution period of a global query, which is usually long lived, it is possible that P changes to a new configuration P because new publishers arise or existing ones vanish. As a consequence, the meta query plan for q in the new configuration P may differ from the one in P and the query plan may have to change as well. To make the dependency on the publisher configuration explicit, in this section we will write meta query plans for q w.r.t. P and P as M q (P) and M q (P ), respectively. One possibility to move from M q (P) to M q (P ) would be to compute the new meta query plan from scratch. However, as we outlined in [8], it is likely to be more efficient to (i) identify when at all M q (P) is affected by a change of P, and (ii) to amend M q (P), whenever this is possible, based on the information

9 contained in M q (P) and the publisher involved in the change. In the following we shall investigate formally how adding a publisher to P or deleting one affects meta query plans. Without loss of generality, we assume that all publishers added to or deleted from P are relevant for q, since other changes do not have an effect on the meta query plan. 3.1 Adding a Producer If a relevant producer S 0 is added then we consider two cases. If S 0 is subsumed w.r.t. q by an existing maximal republisher, say R, then all the data coming from S 0 will be republished by R and, similarly, by every republisher in [R] q, the equivalence class of R. Since the current meta query plan contains the class [R] q, no change is needed. However, if S 0 is not subsumed by a maximal republisher, then it has to be added to the set of maximal relevant producers. Proposition 1. Suppose P = P { S 0 }. Then: 1. if there is a class [R] q M R q such that S 0 q R, then M q (P ) = M q (P); 2. if there is no such class, then M q (P ) = (M R q, M S q { S 0 }). 3.2 Deleting a Producer If a relevant producer S 0 is dropped, then the situation is similar to the previous one. If S 0 is not a maximal relevant producer, that is, if it is subsumed by some republisher, then the meta query plan is not affected by the change, otherwise it has to be removed from the set of maximal relevant producers. Proposition 2. Suppose P = P \ { S 0 }. Then: 1. if S 0 / M S q, then M q (P ) = M q (P); 2. if S 0 M S q, then M q (P ) = (M R q, M S q \ { S 0 }). 3.3 Adding a Republisher The situation becomes more complex when a relevant republisher R 0 is added. There are three possible cases to be considered: 1. R 0 is strictly subsumed by some maximal republisher R, that is, R 0 q R; 2. R 0 is equivalent to some maximal republisher R, that is, R 0 q R; or 3. R 0 is not subsumed by any existing maximal republisher. In case 1, R 0 is not needed in the meta query plan, while in case 2, R 0 needs to be added to the class [R] q. In case 3, R 0 will form a new equivalence class of its own. Moreover, it may be the case that R 0 subsumes some existing maximal producers and republishers. If it does, then the subsumption is strict and the publishers concerned have to be removed from the meta query plan. Proposition 3. Suppose P = P { R 0 }. Then:

10 from = hw q1: psize >= 1024 Data Flow Potential answer stream R4: q2: latency <= 10.0 R1: from = hw R3: from = hw /\ R2: from = ral S1: from = hw /\ tool = udpmon S2: from = hw /\ S3: from = ral /\ S4: from = ral /\ tool = UDPmon S5: from = an /\ Fig. 2. Consumer query q 1 being posed at the publisher configuration P if there is a class [R] q M R q such that R 0 q R, then M q (P ) = M q (P); 2. if there is a class [R] q M R q such that R 0 q R, then M q (P ) is obtained from M q = (M R q, Mq S ) by replacing the class [R] q in M R q with [R] q {R 0 }; 3. if there is no class [R] q M R q with R 0 q R, then M q (P ) = (M R q, M S q ) where M R q is obtained from M R q by adding the class { R 0 } and removing all classes [R ] q with R q R 0 Mq S is obtained from Mq S by only keeping the producers that are not subsumed by R 0, i.e. M S q = { S M S q S q R 0 }. Let us illustrate this by adding a republisher R 4 := σ true (ntp), which gathers all tuples published for the ntp relation, to the publisher configuration P 1. With regard to consumer query q 1, we are in case 2 since R 4 q1 R 1. So R 4 would be added to the equivalence class of R 1 in M q1. There is no change to the query plan of q 1 as the old plan is consistent with the new meta query plan. However, for q 2 we are in case 3 as R 4 subsumes w.r.t. q 2 all the maximal relevant publishers. The situation in the new configuration P 2 is illustrated in Fig Deleting a Republisher Similar to the previous situation, we distinguish three cases when a republisher R 0 is dropped: 1. R 0 is strictly subsumed by some maximal relevant republisher; 2. R 0 is equivalent to some other maximal relevant republishers; or 3. R 0 is not subsumed by any existing maximal republisher. In case 1, the meta query plan is not affected, while in case 2, the republisher R 0 needs to be deleted from its equivalence class. Case 3, by contrast, requires more action. The reason is that, intuitively, the deletion of R 0 leaves a hole in

11 the set of data that can be delivered by the remaining republishers in the meta query plan. To patch the hole, those relevant republishers need to be identified that were not maximal in the presence of R 0, but are promoted to maximal ones after the demise of R 0. We define the patch of Mq R for R 0 as the set M consisting of those republishers R relevant for q where (i) R q R 0 and (ii) there is no R Mq R \ { R 0 } such that R q R. Then the new set M R q is obtained by removing the class [R 0 ] q from M R q and adding the classes obtained from the elements of M. Moreover, some producers that were subsumed by R 0 may not be subsumed by the newly promoted maximal republishers and have to be added to the set Mq S to yield Mq S. Proposition 4. Suppose P = P \ { R 0 }. Then: 1. if R 0 / Mq R, then M q (P ) = M q (P); 2. if R 0 Mq R and there is another R Mq R with R 0 q R, then M q (P ) is obtained from M q = (M R q, Mq S ) by replacing the class [R] q in M R q with [R] q \ {R 0 }; 3. if R 0 Mq R and the class [R 0 ] q M R q is a singleton, then M q (P ) =, M S q ) where (M R q M R q is obtained from M R q by removing the class { R 0 } and adding all classes [R ] q such that R M is in the patch M of Mq R for R 0 Mq S is obtained from M S q by adding those producers relevant for q that were subsumed by R 0, but are not subsumed by any republisher in M R q We now consider removing republisher R 1 from the publisher configuration P 2 to create P 3. Republisher R 1 is a maximal relevant publisher for q 1 which is equivalent w.r.t. q 1 to R 4. This means that we are in case 2 above. Hence, we replace the equivalence class { R 1, R 4 } in M q1 (P 2 ) with the equivalence class { R 4 } to give the meta query plan M q1 (P 3 ) = ({ { R 4 } }, ). The situation in configuration P 3 is shown in Fig. 3. We note that in P 3 the consumer query q 1 no longer has a choice in the publisher to contact to retrieve its answer stream in the most efficient manner. It must contact republisher R 3, hence the line showing the data flow from R 3 to q 1 is now solid in Fig. 3. We also note that since the consumer had been using R 1 in its query plan it will need to switch to a new query plan using R 3. Mechanisms on how to switch between query plans are discussed in Section Discussion The propositions above show that plan maintenance is straightforward if producers come or go and is more complicated when the set of relevant republishers changes. The reason is that the streams of producers are only sound w.r.t. their descriptive views, but republisher streams are both sound and complete. As a consequence, a republisher can replace other publishers, which is impossible for

12 from = hw q1: psize >= 1024 Data Flow Potential answer stream R4: q2: latency <= 10.0 R3: from = hw /\ R2: from = ral S1: from = hw /\ tool = udpmon S2: from = hw /\ S3: from = ral /\ S4: from = ral /\ tool = UDPmon S5: from = an /\ Fig. 3. Consumer query q 1 being posed at the publisher configuration P 3. a producer. In Section 5 we discuss the implications of maintaining query plans during the execution of a query. The cost of performing the plan maintenance operations is polynomial in the number of publishers involved, providing that subsumption can be checked in polynomial time. From the cases encountered with the R-GMA system this is often the case since conditions can only contain conjunctions. Of course, if conditions can contain disjunctions then the problem is NP-hard. 4 Maintaining a Hierarchy of Republishers Similar to consumers, republishers should include other republishers in their query plans. This leads to a hierarchy of republishers through which data streams can flow. A straightforward approach would be to construct and maintain plans and meta plans for republishers in the same way as for consumers. However, a simple example shows that this does not work. Consider the publisher configuration P 0 consisting of the publishers S 1, R 1, and R 4, as defined above. Applying the planning and maintenance techniques developed for consumers would result in the republishers having the meta query plans M R1 = ({ { R 4 } }, ), and M R4 = ({ { R 1 } }, ). The only corresponding query plans are Q R1 = σ from= hw (R 4 ), and Q R4 = σ true (R 1 ). The resulting hierarchy is unsatisfying for two reasons: (i) the republishers are not connected to the producer, and (ii) there is a cycle in the dependency relation of the republishers in that R 1 consumes from R 4 and vice versa. Obviously, the first fact prevents the republishers from obtaining any data. Moreover, if there are cyclic dependencies between republishers, tuples could travel an infinite number of times along the cycle. The volume of the resulting stream could grow indefinitely, and the stream would be neither duplicate free nor weakly ordered. 4.1 Requirements for a Publisher Hierarchy To come up with a mechanism for constructing and maintaining query plans for republishers, we identify properties that such a mechanism should have.

13 We expect that, similar to the one for consumer queries, query plans for republishers are unions of selections over publishers and that, in addition, each republisher has a meta query plan, from which actual plans can be formed. Moreover, we expect that the mechanism produces some kind of meta query plan that contains a set of candidate publishers on which actual plans are based. The query plans executed by the republishers define a dependency relation among the publishers which we call the physical hierarchy, that is, one through which the data flows. The meta query plans of the republishers define a more general dependency relation which we call the logical hierarchy. We argue that the following four requirements are essential for any planning and maintenance mechanism for republishers: Correctness: The plan for each republisher should be sound and complete for the defining query as well as duplicate free and weakly ordered. Cycle Freeness: Neither the physical nor the logical hierarchy should contain any cycles. Uniqueness of the Logical Hierarchy: The logical hierarchy should only depend on the publisher configuration P. The way in which it has been created, that is, the order in which publishers have been added and deleted should have no influence on it. Local Query Planning: To create its query plan and meta query plan, a republisher should not need any information about the plans and meta plans of other republishers. Clearly, a plan that is not correct would fail to implement the republisher and can lead to the republishers being disconnected from the producers, as in the example above. The physical hierarchy of the example contains a cycle. We discussed the negative effects of that cycle. Since cycles in the logical hierarchy may give rise to cycles in the physical hierarchy, they need to be ruled out, too. A logical hierarchy will be much easier to understand if it depends only on the structure of a configuration and not on its history. For the the physical hierarchy, which is a subrelation of the logical hierarchy, a republisher should be allowed to form it as it sees fit. If query planning is local, republishers only need to communicate with the registry service and not with other republishers. 4.2 Generating and Maintaining Query Plans for Republishers A general analysis shows that cycles and missing links to producers as in the example above are a consequence of the definition of relevant publishers in Subsection 2.3. To avoid cycles, for two republishers R 1 and R 2 it should be impossible that R 1 is relevant for R 2 and at the same time R 2 is relevant for R 1. To refine the concept of relevance, we introduce a new, general, subsumption relation. Let P be a publisher with the view σ Dκ D µ(r) and R be a republisher with the view σ E κ E µ(r). We say that P is subsumed by R, and write P R, if D κ = E κ and E µ = D µ.

14 Intuitively, this means that R delivers tuples for a channel if P does so, and that for its channels, P delivers all the values that R delivers. We say that P is strictly subsumed by R, and write P R, if P R, but not R P. Clearly, if both R 1 is subsumed by R 2 and R 2 by R 1, then the view conditions of R 1 and R 2 are logically equivalent. We now use this notion of general subsumption to modify the definition of relevance. We say that a producer is strongly relevant if it is relevant for the query of R 0 and that a republisher R is strongly relevant for R 0 if R R 0. One readily verifies that strong relevance implies relevance. Let us reconsider the example from the beginning of the section. It is immediate to see that in P 0, both S 1 and R 1 are strongly relevant for R 4 while only S 1 is strongly relevant for R 1. If instead of relevant publishers, we only admit strongly relevant ones to query planning, the meta query plan for R 1 in P 0 is M R1 (P 0 ) = (, { S 1 } ), while the one for R 3 is M R4 (P 0 ) = ({ { R 1 } }, ). The corresponding query plans are Q R1 = σ from= hw (S 1 ) and Q R4 = σ true (R 1 ). Neither the physical nor the logical hierarchy contain a cycle. The next proposition shows that this is not accidental. Proposition 5. If meta query plans for republishers are only based on strongly relevant publishers, then all plans derived from them are correct. Moreover, for any publisher configuration, there is a unique logical hierarchy, which is cycle free, and meta query plans and plans can be computed locally by each republisher. Intuitively, the result holds for the following reasons. Plans are still correct, as they were for consumer queries, because the relevance criterion for producers has not been changed. A plan using only strongly relevant republishers may have to access more producers than one relying on relevant republishers, because fewer producers are made redundant by republishers. By definition, the logical hierarchy depends only on the publishers and their conditions, which uniquely determine it. Since any strongly relevant publisher for R is strictly subsumed by R, there cannot be any cycles in the logical hierarchy. A plan can be computed by an individual republisher based on information about its strongly relevant publishers, without coordinating the planning with other republishers. The meta query plan for a consumer or republisher query q is defined in terms of relevant or strongly relevant publishers, respectively, that are maximal w.r.t. the quasiorder q. A closer inspection of the results in Section 3 reveals that all four propositions hold, independently of how relevant publishers are defined. Therefore, the maintenance techniques of that section can be applied directly for republisher queries. 5 Implementing the Query Plans The theory developed for generating and maintaining query plans does not prescribe how it should be implemented, i.e. which components are responsible for the various stages of the planning process. We motivated the work with the development of R-GMA [3, 4], a Grid information and monitoring system, which

15 partially implements a stream integration system. However, the current R-GMA system only allows a republisher to collect together data streams and store them. They cannot be used to publish a data stream and so cannot be used to form a publisher hierarchy. The final stage of developing the query planning mechanisms is to decide the responsibilities of the components and develop communication protocols between the components to enable them to (i) plan for a global query, (ii) detect when the publisher configuration is altered and maintain the plans, and (iii) switch between query plans. We do this in the context of an experimental implementation based on the approach followed by the R-GMA system. We anticipate that the results will be used to further enhance the capabilities of R-GMA. 5.1 Computing Query Plans The registry uses a database to store details of every publisher and consumer registered in the system. These details include a structured representation of the conditions of the queries, so they need only be parsed once. This is possible as R- GMA has a limited continuous query language: continuous queries are selections with conditions that are conjunctions of the form attr op value, where op may be <,, =,, >. When a consumer is constructed, it contacts the registry with details of its global query. The registry encodes the satisfiability and entailment tests needed to find the set of relevant publishers as a single SQL query over its database. The registry then returns to the consumer a list of all relevant publishers. From this list of relevant publishers, the consumer first constructs a meta query plan and then derives a query plan, as described in Section Maintaining Query Plans The task of maintaining query plans can be broken down into two stages. The first stage is to detect when the publisher configuration has changed. Once a change has been detected, the maintenance mechanisms of Section 3 can be applied. When a publisher is created, it will contact the registry to make itself known to the system. Thus, the registry will know when a new publisher is created. However, due to the distributed nature of the system, there must be some mechanism that can detect when a publisher is no longer contactable, e.g. due to a network failure. A simple timeout mechanism based on tuples being delivered from a publisher to a consumer is not adequate. For example, it is possible that a consumer should consume from a republisher but the republisher does not have any sources. To avoid unnecessary plan maintenance, we require that every component periodically sends the registry a heartbeat message. Failure of this message to arrive means that the component is no longer available for queries. Once the registry has detected that there is a change in the publisher configuration, it can construct an SQL query over its database to find all the consumers

16 and republishers which are affected, and inform them of the change. The consumers and republishers first check whether the publisher is maximal relevant for its query and if it is they apply the results of Section 3 to test whether they need to (i) amend their meta query plans, and (ii) if they have altered their meta query plan, to check whether their current query plan is consistent with the new meta query plan. Since consuming components are (i) initially informed of all relevant publishers, and (ii) informed of any changes in the set of relevant publishers, they can maintain their meta query plans in all the cases presented in Section 3 without further interaction with the registry. To patch their plan as required by Proposition 4 case 3 the component need only refer to the list of relevant publishers. 5.3 Switching Between Query Plans In developing protocols for switching between query plans we have focused on the properties of the query plan. That is, the protocols must ensure, as far as possible in a distributed setting, that answer streams are sound and complete w.r.t. their defining query, weakly ordered, and duplicate free. There are five scenarios when a query plan is not consistent with the new meta query plan. 1. A producer is added to the meta query plan. 2. A producer is removed from the meta query plan. 3. A republisher is removed from the meta query plan which (i) appears in an equivalence class with other republishers, and (ii) is in the query plan. 4. A republisher is added to the meta query plan which has created a new equivalence class. 5. A republisher is removed from the meta query plan which was in an equivalence class on its own. The situations in cases 1 and 2 have already been implemented in R-GMA. For case 1, each publisher caches a published tuple for a duration defined by the publisher s retention period. This provides the registry with the time needed to contact the consumers and republishers for which the producer is relevant and for them to then contact the producer and start streaming. For case 2, the producer is simply removed from the query plan. The situation in case 3 is the one presented in the example of Section 3.4 when republisher R 1 is removed from publisher configuration P 2. Since q 1 had been using R 1 in its query plan, then it must switch to using republisher R 4. We require that a consumer maintains a latest-state buffer where it stores the most recent tuple received on each channel. When switching from R 1 to R 4, the consumer searches in its latest-state buffer for the oldest tuple t o received from R 1. The consumer then requests that R 4 starts streaming from t τ o, the timestamp of t o. We must use the timestamp of t o rather than the tuple itself as our streams are only weakly ordered. Upon receiving this message, R 4 consults the tuples in its publishing buffer and, providing that t τ o is still within its retention period, starts streaming all

17 tuples with a timestamp equal to, or newer than t τ o. Otherwise it will start streaming from the oldest tuple in its buffer. On receiving the stream from R 4, the consumer must filter, on a per channel basis, the first part of the stream against its latest-state buffer. Only once it starts receiving tuples newer than the ones in its latest-state buffer does its answer stream start getting new tuples. This mechanism ensures that the answers received by the consumers are sound w.r.t. the query. Providing that the tuples are still within the retention periods of the publishers involved, the answer stream will be complete. In the cases where the stream is not complete, a bound in time can be provided on the incompleteness in the answer stream, i.e. the time between t τ o and the republisher s retention period. Due to the filtering based on the latest-state buffer the answer stream will be duplicate free, and weak order is guaranteed by construction. We decided to search for the oldest tuple since the retention period is defined by the publisher, and in R-GMA it is desirable to set these to large periods. The same mechanism can be applied in cases 4 and 5 except on a per publisher basis. Some additional care needs to be taken with the changing of conditions to existing publishers in the query plan. 6 Related Work Publish/subscribe systems provide middleware for managing the communication of events asynchronously [6]. A subscription is a simple filter on the events published to the system. The publish/subscribe system must process every event as it arrives and forward it on to the relevant subscriptions. Several systems have been developed, including Rebecca [7] and siena [2]. Our approach differs as (i) events are streamed from the publisher directly to the consumer, and (ii) we allow more expressive subscriptions. Work on processing and querying data streams has resulted in centralised data stream management systems, e.g. STREAM [1], and Telegraph [10]. The StreamGlobe system [12] looks at processing data streams in a P2P environment. However, it is unclear as to the guarantees of the correctness of the answer streams. Another approach to the distributed filtering of data streams is dquob [11]. However, each data source must then publish for a different relation. 7 Conclusions In this paper, we have built upon earlier techniques for integrating data streams in a publish/subscribe network [3, 8] which allowed consumers to generate a query plan and identified that such plans need to be updated when the set of publishers changes. We have now formalised the techniques for maintaining these query plans when a publisher is added to or removed from the network. We have also discussed, and presented an approach to, the problem of switching between query plans whilst ensuring that the answer stream remains sound and complete w.r.t. the query, duplicate free, and weakly ordered.

18 Other interesting areas of research would be to increase the complexity of allowable queries, e.g. selection queries that join tables together using sliding windows, and to allow more expressive view conditions, e.g. containing joins. References 1. A. Arasu, B. Babcock, S. Babu, J. Cieslewicz, M. Datar, K. Ito, R. Motwani, U. Srivastava, and J. Widom. Data-Stream Management: Processing High-Speed Data Streams, chapter STREAM: The Stanford Data Stream Management System. Springer-Verlag, To appear. 2. A. Carzaniga and A.L. Wolf. Forwarding in a content-based network. In Proceedings of ACM SIGCOMM, pages , Karlsruhe (Germany), August A. Cooke, A.J.G. Gray, and W. Nutt. Stream integration techniques for grid monitoring. Journal on Data Semantics, 2: , A.W. Cooke, A.J.G. Gray, W. Nutt, J. Magowan, M. Oevers, P. Taylor, R. Cordenonsi, R. Byrom, L. Cornwall, A. Djaoui, L. Field, S.M. Fisher, S. Hicks, J. Leake, R. Middleton, A. Wilson, X. Zhu, N. Podhorszki, B. Coghlan, S. Kenny, D. O Callaghan, and J. Ryan. The relational grid monitoring architecture: Mediating information about the grid. Journal of Grid Computing, 2(4): , December K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman. Grid information services for distributed resource sharing. In 10th International Symposium on High Performance Distributed Computing, pages , IEEE Computer Society, June IEEE Computer Society. 6. P.T. Eugster, P.A. Felber, R. Guerraoui, and A. Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys, 35(2): , June L. Fiege, G. Mühl, and F.C. Gärtner. A modular approach to build structured event-based systems. In Proc ACM Symposium on Applied Computing, pages , Madrid (Spain), March ACM Press. 8. A.J.G. Gray and W. Nutt. Republishers in a publish/subscribe architecture for data streams. In Proc. 22nd British National Conference on Databases, volume 3567 of LNCS, pages , Sunderland (UK), July Springer-Verlag. 9. A. Halevy. Answering queries using views: A survey. The VLDB Journal, 10(4): , S.R. Madden and M.J. Franklin. Fjording the stream: An architecture for queries over streaming sensor data. In Proc. 18th International Conference on Data Engineering, pages , San Jose (CA, USA), February IEEE Computer Society. 11. B. Plale and K. Schwan. Dynamic querying of streaming data with the dquob system. IEEE Transactions on Parallel and Distributed Systems, 14(3): , April B. Stegmaier, R. Kuntschke, and A. Kemper. StreamGlobe: Adaptive query processing and optimization in streaming P2P environments. In Proc. of the 1st International Workshop on Data Management for Sensor Networks, pages 88 97, Toronto (Canada), August VLDB. 13. B. Tierney, R. Aydt, D. Gunter, W. Smith, M. Swany, V. Taylor, and R. Wolski. A Grid monitoring architecture. Global Grid Forum Performance Working Group, March Revised January G. Wiederhold. Mediators in the architecture of future information systems. IEEE Computer, 25(3):38 49, March 1992.