Navneet Kumar Pandey 1 Stéphane Weiss 1 Roman Vitenberg 1 Kaiwen Zhang 2 Hans-Arno Jacobsen 2 2 University of Toronto 1 University of Oslo Minimizing the communication cost of aggregation in Publish/Subscribe systems

Aggregation in Pub/Sub systems Motivation: Stock Market Application 2 Content provider: Stock exchanges Content provider: Stock exchanges Aggregate subscription: Stock indicators (e.g. MACD) Aggregate subscription: Stock indicators (e.g. MACD) Content subscriber: Brokers, buyers Content subscriber: Brokers, buyers Non-aggregate subscription: Stock updates

Motivation: Intelligent Transport System (ITS) Information providers: road sensors, crowdsourced mobile apps Information seekers: commuters, police, first responders, radio networks etc. 3 Aggregate subscriptions Count number of cars passing a street light per hour Average speed of cars on a road segment per day Non-aggregate subscriptions Accident reports Traffic violation reports

Objective: Aggregation in Pub/Sub 4 Pub/sub is well known for efficient content filtering and dissemination for distributed event sources and sinks. However, pub/sub does not support aggregation, which is required in emerging applications. Our primary objective is to retain the traditional pub/sub focus on low communication cost, while adding support for aggregation. It is more communication- and computation-efficient than running two separate system for pub/sub and aggregation.

Contributions: aggregation in pub/sub 5 We introduce and formalize the problem of minimizing communication for aggregation in pub/sub. We present a solution which is optimal under complete knowledge of publications and subscriptions by a broker. We evaluate the trade-off between comm. and comp. costs for these two solutions. By reducing the problem to a minimum-vertex-cover over bipartite graphs, we show that it is solvable in polynomial time. We propose an alternative algorithm which is less computationally expensive.

BIBI P[val,8] A[val, >,4] S[val, >,3] BpBp BqBq BSBS BIBI B Broker Subscription Delivery Tree (SDT) Background: Advertisement-based pub/sub model 6 Our design choice: To maximize communication efficiency, we reuse dissemination flow i.e. SDTs.

Proposal: aggregation in Pub/Sub system 7 Aggregate Subscription: {, operator, duration (ω), shift size (δ)} NWR 1 NWR 2 subscription Time (in hours) Notification window ranges (NWR) Pub 1 Pub 2 Pub 3 ω δ Ex: { RoadID = 101, speed > 10, op=‘avg’, ω = 2 hour, δ = 1 hour}

Challenge: Distribute the computation across the brokers 8 Result load 2 Publication load 3 Pub 1 Publication message Result message Aggregation Decision Broker Pub 2 Pub 3 Res 1 Res 2 Pub 1 Pub 2 Pub 3 SDT Broker NWR 1 NWR 2 subscription Time Pub 1 Pub 2 Pub 3 NWR 1 subscription Pub 1 Pub 2 Pub Time NWR 2 NWR 3 NWR 4 Res 1 Res 2 Res 3 Res 4 Result load 4 Publication load 3 Local aggregation decision by each broker on an SDT for each NWR: Aggregate or forward incoming publications for that NWR.

Trade-off: multiple factors affect the decision 9 Increasing parameterFavors Publication matching rateAggregate Number of matched NWRsForward Overlap among aggregate subscriptionsForward Ratio between aggregate and regular subscriptionsAggregate Challenges: No global knowledge about topology. SDTs are beyond control of the aggregation scheme. SDTs get changed dynamically during the execution.

Unique challenges compared to other aggregation systems 10 Aggregation in pub/subOther aggregation systems Topology is not known to individual broker nodes Require global view of the topology Publication sources and sinks are dynamic Require a priori knowledge of publication sources Brokers are loosely coupledNeed control layer SDTs are dynamic and outside of control of aggregation scheme Demand a static query plan Publications come at an irregular rateOptimized for continuous data streams

Problem formulation: Minimum-Notification for Aggregation (MNA) Objective: Given the set of subscriptions and, set of incoming messages which includes both publications and previously aggregated results minimize the number of notifications i.e. publication and aggregation results sent by a broker. 11 : an NWR n : a Publication p NaNa NaNa NbNb NbNb NcNc NcNc P1P1 P1P1 P2P2 P2P2 P3P3 P3P3 P4P4 P4P4 NpNp NpNp PpPp PpPp : matching of a publication to NWR NWR a NWR c P1P1 P2P2 P3P3 P4P4 NWR b

Optimal solution Unrealistic assumption: Brokers have information about, all the matching publications all the NWRs within entire execution this information is available a priori. 12 NaNa NaNa NbNb NbNb NcNc NcNc P1P1 P1P1 P2P2 P2P2 P3P3 P3P3 P4P4 P4P4 NaNa NaNa NbNb NbNb NcNc NcNc Idea: Each broker constructs undirected bipartite graph (matching graph), And computes the minimum vertex cover. a minimum vertex cover = {N a, N b, N c }

Computation cost: Practical solution: Aggregation Decision, optimal with Complete Knowledge (ADOCK) Idea: Making decision with partial knowledge. Decisions are made based on current state of publications, NWRs and their interconnectivity. Implication: suboptimal decision. 13 NaNa NaNa NbNb NbNb NcNc NcNc P1P1 P1P1 P2P2 P2P2 P3P3 P3P3 P4P4 P4P4 #Subscriptions Difference between Optimal and ADOCK in % 3.53%0.88%4.29%3.27% P1P1 P1P1 P2P2 P2P2 Communication cost : Close to the optimal solution in the experiments. |N|: #NWRs, |P|: #publications, deg A (N) : average degree of NWR vertices Scalability issue: Computation cost grows more than quadratically with the number of NWRs. P3P3 P3P3 P4P4 P4P4

14 < 1(2/3) Practical solution: Weighted Aggregation Decision (WAD) NaNa NaNa NbNb NbNb NcNc NcNc P1P1 P1P1 P2P2 P2P2 P3P3 P3P3 P4P4 P4P4 weight 1/3 1/2 Forward Aggregate P1P1 P1P1 P2P2 P2P2 NbNb NbNb NcNc NcNc Low computation cost: O(deg A (N) x |N|) Reduce the number of vertices used for making a decision Vertices within only 2 hops from the NWR will affect the decision. Similar to ADOCK, take a decision per NWR 1.Assign a weight to a publication vertex which is inverse of its degree. 2.Compute cumulative weight of an NWR from matching publications. 3.Aggregate matching publications if cumulative degree ≥ 1. Idea: Steps: ≥ 11 1

Experimental setup Implemented in Java over the PADRES framework Topology: 16 brokers – Combination of publisher-edge only, subscriber-edge only and mixed brokers Real life datasets: Traffic dataset from the ONE-ITS service 1 Yahoo! Finance Stock dataset Metrics: Communication: Number of messages exchanged Computation: Total computation overhead Existing baseline: per Broker Adaptive Technique (BAT) 15 B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B 1

Varying number of publications 16 Setting: Stock dataset Computation costCommunication cost Trade-off between WAD and ADOCK over communication and computation cost. WAD is up-to 73% faster than ADOCK at the expense of up-to 22% increase in communication cost. BAT sends more messages than either of the proposed solutions.

Varying number of subscriptions 17 Computation cost Communication cost ADOCK’s communication cost is around 12% lower than WAD’s. However, ADOCK’s computation overhead is more than twice that of WAD. This is also supported by analytical findings ADOCK WAD

Impact of sliding windows 18 A higher sliding parameter increases the NWR interconnectivity and makes the decision graph big. ADOCK is up-to four times slower than WAD, while WAD is sending up-to 27% extra messages.

Key lessons from experiments Our results confirm that interconnectivity is the key reason for the trade-off between computation and communication cost. Trade-off is substantially affected by these factors: Publication matching rate. Number of matching NWRs. Overlap among aggregate subscriptions. Ratio between aggregate and regular subscriptions. Recommendation ADOCK is preferred, if the system expects moderate amount of subscriptions with high selectivity. Otherwise, WAD is recommended. 19

Conclusions 20 We formalize the MNA problem and reduce it to Minimum Vertex Cover over a bipartite graph. We provide two solutions: communication efficient ADOCK and computation efficient WAD. We experimentally demonstrate the trade-off between computation and communication cost in these approaches.

Thank you! 21 For questions & comments