Efficient Scheduling of Heterogeneous Continuous Queries

Efficient Scheduling of Heterogeneous Continuous Queries Mohamed A. Sharaf Panos K. Chrysanthis Alexandros Labrinidis Kirk Pruhs Advanced Data Management Technologies Lab Department of Computer Science University of Pittsburgh VLDB 2006

Motivating Example • Tell me when there are airplane tickets such that: • Itinerary: Pittsburgh -> Korea -> Pittsburgh • Dates: September 8 -> September 16 • Price < $1200 • This is a form of a Continuous Query (CQ): • CQs registered ahead of time • Arrival of new data triggers execution • CQs support monitoring applications: • <insert your favorite monitoring application here>

Data Stream Management System (DSMS) • DSMS = Database system + Online system • Our Goal: Improve the online performance of a DSMS Query Optimizer Memory Manager Output Data Stream Dn Query Scheduler Query Scheduler Load Shedder 1 2 3 Continuous Query Qn Output Data Stream D1 Input Data Streams 1 2 3 Continuous Query Q1

Need for Query Scheduling • The execution order of continuous queries determines the overall behavior of the system • e.g., memory usage [Babcock et. al., SIGMOD’03] • Traditionally: • One operator per thread • Resource management done by OS • Problems: • No objective for optimization • Does not exploit query semantics

Scheduling Multiple Continuous Queries (MCQ) 3  3  3  2  2  2  1 1 1 • Given: • A set of n queries ready to execute (queries with pending updates) • A certain metric to optimize • Then: • The MCQ Scheduler decides the execution order of the n queries so that to optimize the given metric … CQ2 CQn CQ1

Outline • Introduction • Scheduling for Quality of Service (QoS) • Average response time • Average slowdown • Balancing the trade-off between average and worst case • Implementation issues • Conclusions

Response Time • The response time of a tuple is the interval of time between its arrival at the DSMS until its departure • Tuples that are filtered out (discarded) during query processing do not contribute to the metric • Shortest Remaining Processing Time (SRPT) is the policy to optimize response time in Web servers • Would SRPT optimize response time for multiple CQs ?! • No … because it does not exploit CQs characteristics!

Impact of Selectivity • Selectivity of a query (S): is the probability of producing an output tuple after processing an input tuple (i.e., detecting a related event) • S=0.1: 10 input tuples  1 output event • S=1.0: 10 input tuples  10 output events • If two queries have the same cost then: • the one with higher selectivity produces more tuples per time unit (higher Output Rate).

Impact of Output Rate Q1 then Q2 Q1 Q1 Q1 Q1 Q1 Q2 Q2 Q2 Q2 Q2 0 5 10 Q2 then Q1 Q2 Q2 Q2 Q1 Q1 Q1 Q1 Q1 Q2 Q2 0 5 10 • Q1: S1=1.0 and C1=1 mS then OR1=1.0 • Q2: S2=0.2 and C2=1 mS then OR2=0.2 • 5 pending tuples arrived at time 0

Highest Rate Policy 3  2  1 • Assign each query a priority equal to its output rate • The output rate of a query = selectivity/cost • How to compute the output rate of a query with more than one operator ? • At each scheduling point, schedule the query with the highest global output rate…Highest Rate Policy (HR)

Simulation Testbed • Developed a DSMS simulator in C++ • Policies for multi-query scheduling: • Round Robin (RR; Aurora) • Highest Rate (HR) • First Come First Serve (FCFS) • Shortest Remaining Processing Time (SRPT) • Input traces from Internet traffic • Generate 500 continuous queries: select-join-project • Uniform distribution of costs and selectivities • Assigned costs and selectivities determine the system’s utilization (or load)

Results: Average Response Time 73% Avg. Response Time (Sec) 65%

Slowdown • Slowdown (or stretch):[Mehta & DeWitt, VLDB’93] • Ratio between the tuple’s response time to its ideal processing time if it were the only tuple in the system • slowdown is more fair than response time: • It relates response time to demand: tuples for an expensive query are expected to stay longer as they contribute more to the load • Ideally, slowdown = 1 • Slowdown increases with increasing load

SRPT vs. HR • In Web Servers, SRPT is: • Optimal for response time, and • Near optimal for slowdown • Short jobs spend shorter time in the system • In DSMSs: HR minimizes average response time but what about average slowdown ? • Is it possible under HR for short queries to experience high slowdown leading to an overall high slowdown ? • Queries with low selectivity are penalized !

Example HR policy: SD=1 SD=2 SD=3 SD=9.5 Q1 Q1 Q1 Q2 Q2 Q2 5 10 15 17 19 21 Another policy: SD=2 SD=2.2 SD=3.2 SD=4.2 Q2 Q2 Q2 Q1 Q1 Q1 2 4 6 11 16 21 • Q1: S1=1.0 and C1=5 mS then OR1=0.2 • Q2: S2=0.33 and C2=2 mS then OR2=0.17 • 3 pending tuples arrived at time 0

Parameters for Scheduling • Sx = s1 * s2 * s3 • Cxavg = c1 + (c2*s1) + (c3*s1*s2) • Cx = cost of detecting an event = c1+ c2+c3 = ideal processing time • Wx = the current wait time of the oldest tuple in Qx input queue 3  2 ∞ 1 

Scheduling for Slowdown (1) t1’s slowdown t2’s slowdown C1avg C1 C2avg C2 Q1 Q2 • Compute slowdown (H) under two policies: • Policy X: first Q1 then Q2 • Policy Y: first Q2 then Q1 S1 W1 S2 W2 t1 t2 Processing time Extra wait time for Q1 to finish execution Probability that t1 is produced Wait time

Scheduling for Slowdown (2) C1avg C1 C1 C2 C2avg C2 Q1 Q1 Q2 Q2 • Under policy X: first Q1 then Q2 S1 S1 W1 W1 S2 S2 W2 W2 t1 t1 t2 t2 • Under policy Y: first Q2 then Q1 • For HX < HY:

Scheduling for Slowdown (3) • Sx/Cxavg is the output rate (ORx) of Qx • Cx is the ideal processing time of a tuple produced by Qx • Our Highest Normalized Rate (HNR) policy emphasizes the tuple ideal processing time • Inexpensive queries with low productivity are not penalized • For equal costs: Ci = 1HNR = HR • For selectivity 1: Si = 1  HNR = SRPT Priority of Qx = =

Results: Average Slowdown 20% Avg. Slowdown

Worst-Case Performance • Queries/Events may experience starvation • Queries with low selectivity and/or high cost • Typically measured using: • maximum response time, or • maximum slowdown • Maximum slowdown (or response time) is: • A very sensitive metric • It does not consider the average-case performance

Trade-off between Avgerage Case and Worst Case • Maximum slowdown = worst-case performance • Average slowdown = average-case performance • We need to look at both metrics at the same time • Lp norm of slowdowns captures both metrics • L2 norm of N tuples = • it takes into account all values • it penalizes outliers

Scheduling for the L2 Norm of Slowdowns • Balance Slowdown Policy (BSD) • Priority of Qx = • A query is scheduled either because: • It has a high normalized rate, or • Its pending tuples accumulated high slowdown All users are satisfied = Fairness Normalized Rate Current Slowdown

Results: Balancing the trade-off 77% Max. Slowdown 31% Avg. Slowdown

Results: L2 Norm of Slowdowns L2 Norm of Slowdowns 24%

Slowdown per Class (same cost queries)

Outline • Introduction • Scheduling for Quality of Service (QoS) • Implementation issues • Scheduling overhead • Shared operators (details in paper) • Conclusions

Optimization Methods L2 SD of BSD-Logarithmic / L2 SD of BSD-Hypothetical • BSD-Hypothetical = BSD without overhead

Conclusions • In this talk, we presented: • QoS metrics for evaluating the performance of a DSMS • Scheduling policies that exploit the properties of CQs • Policies to improve QoS : • Highest Rate(HR) for average response time • Highest Normalized Rate (HNR)for average slowdown • Balance Slowdown(BSD) for balancing the trade-off between average- and worst-case performance • Addressed implementation issues to ensure the applicability of our proposed policies • We empirically evaluated the gains provided by the proposed policies compared to existing policies

Thank You Questions ? http://db.cs.pitt.edu/streams Thanks: NSF IIS-0534531 (AQSIOS Project)

Efficient Scheduling of Heterogeneous Continuous Queries