Subscription Summaries for Scalability and

Subscription Summaries for Scalability and Efficiency in Publish/Subscribe Systems Peter Triantafillou and Andreas Economides Department of Electronics and Computer Engineering Technical University of Crete Chania, 73100 Greece {peter, oikand}@softnet.tuc.gr Abstract A key issue when designing and implementing largescale publish/subscribe systems is how to efficiently propagate subscriptions among the brokers of the system. Brokers require this information in order to forward incoming events only to interested users, filtering out unrelated events, which can save significant overheads (particularly network bandwidth and processing time at the brokers). In this paper we contribute the notion of subscription summaries, a mechanism appropriately compacting subscription information. We develop the associated data structures and matching algorithms. The proposed mechanism can handle event/subscription schemata that are rich in terms of their attribute types and powerful in terms of the allowed operations on them. Our major results are that the proposed mechanism (i) is scalable, with the bandwidth required to propagate subscriptions increasing only slightly, even at huge-scales, and (ii) is significantly more efficient, up to orders of magnitude, depending on the scale, with respect to the bandwidth requirements for propagating subscriptions.

1. Introduction The growth of interconnectivity (internet, peer-to-peer networks, etc.) gives us the ability to access large amounts of distributed information. Traditionally, interested users used searching facilities to find interesting information. However, recently, a new paradigm has emerged which is centered on the notion of personalization: a user declares his interests and receives the appropriate information/events as the events matching these interests take place. By definition, such a mechanism gives users the ability to receive information

dynamically at the time it becomes available. Infrastructures that implement such a facility are known as Publish/Subscribe (pub/sub) systems and actually they connect producers (information providers) with consumers (interested users) delivering personalized information according to the consumer interests. The first such systems were based on the concepts of group (also known as channel-based systems) or subject (also known as topic-based systems). Channel-based systems [14], [17] categorize events into pre-defined groups. Users subscribe to the groups of interest and receive all events for these groups. In subject-based systems [8], [16] each event is enhanced with a tag describing its subject. Subscribers can declare their interests about event subjects flexibly using string patterns for the subject, e.g. all events with a subject starting with "stock". As an attempt to overcome the limitations on subscription declarations, recently the content-based model [3], [5], has been introduced, which allows subscribers to use flexible querying languages in order to declare their interests with respect to the contents of the events. For example, such a query could be "give me the price of stock A when the price of stock B is less than X". A slightly different model than this is the content-based with patterns model [6], [15], with extra functionality on expressing user interests. It is obvious that the implementation of these models can become quite complicated, especially during the matching of events with subscriptions.

2. Problem definition and background 2.1. System architecture A pub/sub system is comprised of three main elements. A consumer, who subscribes his interests to the system, a

provider, who publishes events and the pub/sub infrastructure which has the responsibilities to (i) match each event to all related subscriptions and (ii) to deliver the matching events to the corresponding consumers. The architecture of a basic pub/sub system consists of: 1. One or more Event Sources (ES) / Producers An ES produces events in response to changes to a real world variable that it monitors. 2. An Event Brokering System (EBS) It consists of one or more brokers. The events are published to the EBS, which matches them against a set of subscriptions, submitted by users in the system. 3. One or more Event Displayers (ED) / Consumers If a user’s subscription matches, the event is forwarded to the ED associated with that user. The ED is responsible for alerting the user. A detailed presentation of this model is available on [12]. In order to establish a better framework for our approach, presented in section 3, a brief introduction to Bloom filters, upon which our mechanism is based, is required.

2.2. Bloom filters In [4] Bloom introduced a method according to which a vector V containing m bits, initially all set to 0, is used to compact the information in a set A = { 1, 2,…, n} by hashing each value into V. In general k independent hash functions, h1, h2,…, hk can be used for each element of A producing k values, each varying from 1 to m and setting the corresponding bit in vector V. It is obvious that a specific bit can be set to 1 many times. MD5 [13] can be used to produce the values for the hash functions. To check if an element b belongs to set A the same k hash functions are applied on b and the bits of V in positions of h1(b), h2(b),.., hk(b) are checked. If at least one of these bits is 0, then b does not belong to A. Else, it is conjectured that b belongs to A although this may be wrong (this is referred to as a "false positive"). By tuning k and m we control the probability for false positives, which is given by PFP = (1 - e -kn/m ) k , where n is the number of stored values, m is the size of the bitmap, and k is the number of hash functions. In our approach, we will use Bloom filters to summarize the names of the subscription attributes and the values of string attributes. Changes in the set of subscriptions must be supported (because existing subscriptions can be updated or deleted). This can be done by keeping for each location l in the bit vector, a count c(l) of the number of times that the bit is set to 1. Initially all the counts are set to 0. For every element a which is inserted or deleted, the counts c(h1(a)), c(h2(a)), …, c(hk(a)) are incremented or decremented accordingly.

Bloom filters summarize large sets of information with little storage, with a controllable number of false positives. In fact, bloom filters have been employed for summarizing web cache contents [10]. The size of the bit map implementing the filter is typically equal to the product of n with a value called the load factor, used to decrease the probability of false positives.

2.3. The problem and our contributions A key issue when designing and implementing largescale pub/sub systems is how to efficiently propagate subscriptions among the brokers of the system. Brokers require this information in order to forward incoming events only to interested users, filtering out unrelated events, which can save significant overheads (particularly network bandwidth and processing time at the brokers). In order for a pub/sub system to be able to scale to very large numbers of brokers, events, and subscriptions it is imperative that subscription information be as compact as possible. In this paper we contribute the notion of subscription summaries, a mechanism appropriately compacting subscription information. The subscription summaries will be partly based on Bloom filters. Bloom filters have been straightforwardly applied for similar purposes, storing either string or numeric values and testing whether a given integer or string value matches a value stored in the filter (e.g. [10]). However, it is not straightforward to see how operators, other than equality, can be supported using Bloom filters. Thus, a straightforward application is not possible in pub/sub systems. Our mechanism will support event/subscription schemata that are rich with respect to the attribute types they include (i.e., numeric types, ranges, strings) and powerful with respect to the operators for these attributes (i.e., , =, prefix, suffix, string containment, etc). We develop the summary data structures and the associated matching algorithms, in section 3. Section 4 will conclude the paper.

3. Proposed solution There are two naive solutions for propagating the events to the corresponding subscribers. The first approach requires that (i) each broker sends all of its subscriptions to all other brokers of the system and (ii) when an event reaches a broker, a matching algorithm is executed on the broker receiving the event matching it against all subscriptions it knows of. The second approach requires that when an event is generated, it is broadcasted to all brokers in the system and each receiving broker is responsible to find the subscribers

who are interested in the specific event. Both these two solutions have disadvantages when they are working in large-scale systems. They suffer from very high network bandwidth requirements in order to propagate the subscriptions or the events respectively. Some other approaches [2], [7] are using multicast methods to solve this problem. In this paper we produce a method for minimizing the information needed to represent subscriptions in pub/sub systems. We have developed a basic set of data structures for representing the subscriptions received at a broker. It is this compacted, summarized, per-broker subscription information that is propagated to the other brokers. The latter brokers will use it for filtering incoming events and forwarding them only to brokers, which have users with subscriptions for these events. We have also devised the associated algorithms that process incoming events and perform the filtering operations at each broker, deciding which other brokers should receive the new event. The main advantages that our structures and algorithms introduce are that for large-scale systems, with a high rate of incoming subscriptions, we can ensure great savings in the network bandwidth that would otherwise be consumed for propagating each broker’s subscriptions to the others.

3.1. Event and subscription type Our methodology does not intent to develop a new event or subscription model but will be based on wellestablished models to provide a more efficient event processing in large-scale environments. A. Carzaniga, D. Rosenblum and A. Wolf have produced in Siena [6] a model, which defines two appropriate schemas in order to describe events and subscriptions. 3.1.1. Event schema. The Event Schema of this model is an untyped set of typed attributes. Each attribute consists of a type, a name and a value. Type

Name

Value

string string date float int float float

exchange symbol when price volume high low

= NYSE = OTE = Nov 30 12:05:25 EET 2001 = 8.40 = 132700 = 8.80 = 8.22

Figure 1: An event example The type of an attribute belongs to a predefined set of primitive data types commonly found in most

programming languages. The attribute’s name is a simple string, while the value can be in any range defined by the corresponding type. The whole structure of type – name – value for all attributes constitutes the event itself. 3.1.2. Subscription schema. The data structures compact the subscription information, and the associated algorithms allow for expressing a rich set of subscriptions, containing all interesting subscriptionattribute data types (such as integers, strings, etc.) and all interesting operators (=, , ranges, prefix, suffix, containment, etc.). All the attributes that are applied to the same subscription are interpreded as a conjunction. An event e matches a subscription s if and only if all subscritption’s attributes are satisfied. It is possible in the same subscription to have two or more attribute constraints with the same name. In this case all attributes must be satisfied for a successful matching. On the other hand, it is obvious that the event can have more attributes than those checked by the subscription attributes. Type

Name

string string float float

exchange symbol price price

Value N*SE = OTE < 8.70 > 8.30

Figure 2: A subscription example

3.2. Data structures and operators In this section the four data structures that are used in our proposal are presented. These structures are used to keep the compacted, summarized per-broker subscription information. Four assumptions have been made: (i) A named attribute cannot have two different data types; (ii) The number of supported attributes in the whole system are predefined as well as the specification of these attributes (name – type); (iii) The set of supported attributes is ordered and known from each broker; (iv) String attributes can have at most one "*" operator. Each one of these four per-broker data structures has as its purpose to hold key information about the subscriptions received by a specific broker. 3.2.1. Subscription attribute summary (SAS). SAS is used to hold information about all the attribute names that appear in at least one subscription received by a broker. SAS is a bit vector whose size is the number of all supported attributes by the system (nt) multiplied with a load factor lf (lf>1). For each attribute, appearing in at

least one subscription of a broker, we store (only) its name in SAS. Thus, SAS summarizes information about the attributes of interest for a specific broker. 3.2.2. Attribute association list (AAL). AALs store information about the attributes, which are jointly contained in some subscription. An AAL is created for each distinct first attribute of all the subscriptions received by a broker. It is implemented using an array of bits (initially all 0) with a constant number of columns (nt) and a variable number of rows (ndsf). Columns represent the ordered set of supported attributes (one column for each attribute). The rows represent the unique sets of the other attributes, which follow the specific attribute that appears as first in different subscriptions. The process of constructing this data structure adds a row to the array when it finds a specific attribute that appears first in a subscription (e.g., sub 1 of figure 2) and has a unique association list. Then, it sets the bits in those columns that represent the other attributes of the same subscription. Notice that the attribute itself is included in each row. The example in figure 3, clarifies this process. Attribute’s id in the system Attribute id

exchange

symbol

price

volume

1

2

3

4

AAL for attribute exchange i position of the array

1

2

3

4

For sub 1

1

1

1

0

Figure 3: An attribute association list example 3.2.3. Arithmetic Attribute Constraint Summary (AACS). The AACS structure holds information about the constraints of each different arithmetic attribute of a subscription. AACS is useful because Bloom filters cannot capture the meaning of operators (other than equality) on the stored arithmetic values. An AACS consists of two arrays. The first (AACSSR) is an array with two columns and a variable number (ndsr) of rows. Each row represents non-overlapping sub-ranges of values specified in subscriptions for the specific attribute. The first (second) column shows the lower (upper) bound of such a sub-range. The second array (AACSE) is used when an arithmetic constraint in a subscription has an equality operator for a value that is not in the existing sub-ranges. It has only one column and a variable number of rows (nde) with the same meaning of the first array.

For every constraint of the same arithmetic attribute, if it is not included in the existing sub-ranges or equality values, a new row is added to the appropriate place. AACS for attribute price Range For sub 1

min 8.30

max 8.70

Figure 4: An arithmetical constraint summary example 3.2.4. String Attribute Constraint Summary (SACS). SACS holds information about the constraints of subscriptions’ string attributes. For each different string attribute, which appears in at least one subscription, a broker is implementing a SACS structure using three bit vectors SACSL, SACSR, and SACSX, as Bloom filters. The size (in bits) of each one of these three vectors is equal to the number of different values (ndv) that a specific string attribute can take multiplied by a load factor lf. With max_ndv we denote the maximum ndv number among all string attributes, which defines the greatest bit map. The reason for requiring three bit vectors is in order to ensure accurate matching even when the subscriptions’ constraints for string attributes may include all operators on strings (prefix ">*", suffix "*