1. Adaptive Query Processing with Eddies Amol Deshpande University of Maryland

2. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

3. Query Processing in Database Systems Database System Declarative Query Results We will focus on traditional select-project-join queries

4. Query Processing: Example Database System StudentsEnrolledCourses NameLevel JoeJunior JenSenior NameCourse JoeCS1 JenCS2 CourseInstructor CS2Smith select * from students, enrolled, courses where students.name = enrolled.name and enrolled.course = courses.course

5. Query Processing: Example NameLevel JoeJunior JenSenior NameCourse JoeCS1 JenCS2 CourseInstructor CS2Smith select * from students, enrolled, courses where students.name = enrolled.name and enrolled.course = courses.course Students Enrolled NameLevelCourse JoeJuniorCS1 JenSeniorCS2 Enrolled Courses StudentsEnrolled Courses NameLevelCourseInstructor JenSeniorCS2Smith

6. Example Query: Execution Plans Students Enrolled Courses E CS E A Query Execution Plan S E C SESE SECSEC Courses Enrolled Students E SC E An alternate Execution Plan C E S CECE SECSEC

7. Cost-based Query Optimization Students Enrolled Courses E CS E A Query Execution Plan S E C SESE SECSEC Estimate cost of each plan and choose the best Cost = f(|S|, |E|, R) Runtime Parameters Input sizes Cost = g(|SE|, |C|, R) Cost (Plan) = +

8. Cost-based Query Optimization Declarative Query Results Query Optimizer Query Executor Compiled Query Plan Disk(s)

9. Cost-based Query Optimization Declarative Query Results Network Query Optimizer Query Executor Compiled Query Plan Disk(s) Wide area data sources: e.g. remote tables, web data sources

10. Cost-based Query Optimization Declarative Query Results Network Query Optimizer Query Executor Compiled Query Plan Disk(s) Streaming data e.g. Stock tickers Network logs Sensor networks

11. Estimation Errors Students Enrolled Courses E CS E A Query Execution Plan S E C SESE SECSEC Cost = g(|SE|, |C|, R) Input sizes may not be available Erroneous estimation of intermediate result sizes

12. Effect on the cost function may be unpredictable Estimation Errors Students Enrolled Courses E CS E A Query Execution Plan S E C Cost = g(|SE|, |C|, R) Unknown runtime parameters SESE SECSEC

13. How to solve this problem ? More sophisticated estimation techniques Sophisticated summary structures e.g. MHists [PI’97], Wavelets [VWI’98] Feedback loop in the optimization process e.g. [SLMK’01, BC’02] Adaptive query processing Can’t always build and maintain synopses Runtime environments can be very unpredictable So…adapt query plans mid-way during execution

14. Eddies: Extreme Adaptivity Telegraph & TelegraphCQ (at UC Berkeley) Eddies [AH’00] SteMs [RDH’03] Continuous queries [MSHR’02, CF’02, C+’03, K+’03] Implementation in PostgreSQL [Des04] Fault-tolerance and load balancing [SHB’04] STAIRs [DH’04] Other work Distributed eddies, Content-based Routing [BB’05] Dynamic QEP, Parametric, Competitive static plans late binding inter- operator per tuple Traditional DBMS Query Scrambling, MidQuery Re-opt Eddies XJoin, DPHJ Convergent QP intra- operator

15. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

16. Eddies [AH’00] Plans considered by the optimizer pred2(S) SOutput select * from S where pred1(S) and pred2(S) pred1(S) SOutput pred2(S) Decision made apriori based on statistics Sort by (1-s)/c, where s = selectivity, c = cost Once this decision is made, all tuples are processed using the same order

17. Eddies [AH’00] Executing the query using an Eddy select * from S where pred1(S) and pred2(S) pred2(S) pred1(S) Eddy S Output An eddy operator Intercepts tuples from source(s) and output tuples from operators Query executed by routing tuples between the operators Uses feedback from the operators to route Change routing ==> Change query execution plan used

18. Per-tuple State Executing the query using an Eddy select * from S where pred1(S) and pred2(S) pred2(S) pred1(S) Eddy S Output Two Bitmaps 1)Ready bits - which operators can a tuple be routed to next 2)Done bits - which operators has a tuple already been through Example: Ready(t1) = [1, 1] - can be routed to either Done(t1) = [0, 0] - not done either Example: Ready(t2) = [1, 0] - can be routed to pred1 Done(t2) = [0, 1] - done pred2 For selection queries, ready is a bit- complement of done

19. Eddies: Routing Policy Choosing which operator to route a given tuple to The brain of the eddy Lottery Scheduling [Avnur 00] Simplified Description 1. Maintain for each operator: tuples sent tuples returned cost per tuple 2. Choose (roughly) based on the above 3. Explore by randomly sending tuples in the wrong orders sent = 100 received = 2 sent = 30 received = 20 Pred2 is more selective Send here 99% of the time Send to the other operator 1% of the time pred2(S) pred1(S) Eddy S Output

20. A Join Query NameLevel JoeJunior JenSenior NameCourse JoeCS1 JenCS2 CourseInstructor CS2Smith select * from students, enrolled, courses where students.name = enrolled.name and enrolled.course = courses.course Students Enrolled NameLevelCourse JoeJuniorCS1 JenSeniorCS2 Enrolled Courses StudentsEnrolled Courses NameLevelCourseInstructor JenSeniorCS2Smith

21. Eddies [AH’00] A traditional query plan Query execution using an eddy S E E C S E Output C Eddy S E E C S E C Output A key difference: Tuples can’t be arbitrarily routed to any operator E.g. S tuples can’t be routed to E Join C Use ready bits to identify this

22. Eddies w/ Joins Traditional join operators typically consume one relation entirely and then start reading the second relation E.g. hash join operator builds a hash table on one relation first, and then reads in the other relation This is problematic for eddies An eddy needs to see tuples from different relations in order to make its routing decisions Also, if the inner relations are pre-decided, not much options left for adapting the join order [Avnur, Hellerstein 00] discusses this issue in detail for traditional join operators

23. Symmetric Hash Join We will use a new join operator called symmetric hash join operator Also called doubly pipelined Other variants include ripple joins, Xjoins (disk-based) S E HashTable S.Name HashTable E.Name SE When a new S tuple arrives: (1)It is built into S.name hashtable (2)Probed into E.name hash table to find matches with already arrived E tuples (3)Matches are immediately output Symmetric Operation !!

24. Query Execution using Eddies Eddy S E C Insert with key hash(joe) Probe to find matches S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJunior JoeJunior JoeJr No matches; Eddy processes the next tuple Output

25. Query Execution using Eddies Eddy S E C Insert Probe S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJr JenSr JoeCS1 JoeCS1 JoeCS1 JoeJrCS1 JoeJrCS1 JoeJrCS1 Output CS2Smith

26. Query Execution using Eddies Eddy S E C Output Probe S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJr JenSr CS2Smith JenCS2 JoeCS1 JoeJrCS1 JenCS2 JenCS2 JenCS2Smith Probe JenCS2Smith JenCS2Smith JenSr.CS2Smith JenSr.CS2Smith

27. Per-tuple State Here also we need to keep track of what operators a tuple has already been through Again use Ready bits - operators that can be applied next Done bits - operators that have already been applied Unlike selections, these are not bit- complements of each other

28. Per-tuple State Eddy S E C S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJunior Output S Join EE Join C Ready10 Done00

29. Per-tuple State Eddy S E C S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJr JenSr JoeCS1 Output CS2Smith S Join EE Join C Ready11 Done00

30. Per-tuple State Eddy S E C S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJr JenSr JoeCS1 JoeJrCS1 Output CS2Smith S Join EE Join C Ready01 Done10

31. Execution Postmortem Can we talk about what exactly the eddy did during the execution ? Yes !

32. Execution Postmortem StudentsEnrolled Output Courses E C S E CoursesEnrolled Output Students E S C E Eddy executes different query execution plans for different parts of data CourseInstructor CS2Smith CourseInstructor CS2Smith NameCourse JoeCS1 NameLevel JoeJunior JenSenior NameLevel JoeJunior JenSenior NameCourse JenCS2

33. Execution Postmortem Can we talk about what exactly the eddy did during the execution ? Yes ! Eddy executes different plans for different parts of data This is where the adaptivity comes from

34. Routing policy Lottery scheduling unfortunately doesn’t work well with joins Just because a join operator does not return tuples right now doesn’t mean it won’t return more tuples later In other words, a join operator is state-ful Selection operators are state-less

35. Example: Delayed Data Sources SETUP: |S E| |E C| >> E CS E S E C E SC E C E S Execution plan 1 Execution plan 2 Cost (Plan 1) > Cost (Plan 2) SESE SECSEC CECE SECSEC

36. SETUP: E and C arrive early; S is delayed Example: Delayed Data Sources time |S E| |E C| >> S E C

37. S0S0 SETUP: E and C arrive early; S is delayed time |S E| |E C| >> S E C E C Eddy S E C Output S E HashTable S.Name HashTable E.Name HashTable E.Course HashTable C.Course S0S0 E C S0ES0E Eddy decides to route E to E C Eddy learns the correct sizes Too Late !! S SESE S –S 0 (S –S 0 )E sent and received suggested (so far) that S Join E is better option for E tuples

38. E C Eddy S E C Output S E HashTable S.Name HashTable E.Name HashTable E.Course HashTable C.Course S SETUP: E and C arrive early; S is delayed |S E| |E C| >> Query is executed using the worse plan. E C Too Late !! SESE E CS E S E C Execution Plan Used State got embedded as a result of earlier routing decisions

39. Joins and Lottery Scheduling Lottery scheduling doesn’t work well with joins Not clear how any routing policy can work without reasonable knowledge of future Whatever the current state in the join operators, an adversary can send tuples to make it look very bad Two possible solutions: Allow manipulation of state (STAIRs) [DH’04] Don’t embed state in the operators (SteMs) [RDH’03]

40. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

41. STAIRs [DH’04] Expose join state to the eddy Provide state management primitives That guarantee correctness of execution That can be used to manipulate embedded state in the operators Also allow support for cyclic queries etc

42. New Operator: STAIR E C Eddy S E C Output S E HashTable S.Name HashTable E.Name HashTable E.Course HashTable C.Course

43. New Operator: STAIR Storage, Transformation and Access for Intermediate Results HashTable E.Name STAIR HashTable S.Name STAIR HashTable E.Course STAIR HashTable C.Course STAIR Eddy S E C Output

44. HashTable E.Name STAIR HashTable S.Name STAIR HashTable E.Course STAIR HashTable C.Course STAIR Eddy S E C Output Query execution using STAIRS Similar to using Join Operators s1 Probe into E.Name STAIR Build into S.Name STAIR s1

45. STAIR: Operations Build (insert): Insert the given tuple into the STAIR Probe (lookup): Find matching tuples for the given tuple State Management Operations: Demotion Promotion

46. State Management Primitive: Demotion Replace a tuple in a STAIR with a projection of that tuple HashTable E.Name STAIR Eddy S E C Output HashTable S.Name STAIR HashTable E.Course STAIR HashTable C.Course STAIR s1 s1e1 e2 e2c1 c1 e1 e2 Demoting e2c1 to e2 e2 Can be thought of as undoing work e2c1 s1e1

47. e1c1 State Management Primitive: Promotion Replace a tuple in a STAIR with the result of joining it with other tuples HashTable E.Name STAIR Eddy S E C Output HashTable S.Name STAIR HashTable E.Course STAIR HashTable C.Course STAIR s1 s1e1 e2 e2c1 c1 e1 Two arguments: A tuple A join to be used to promote this tuple Can be thought of as precomputation of work Promoting e1 using E C e1 e1c1

48. STAIRs: Correctness Theorem: For any sequence of applications of the state management operations, STAIRs will produce the correct query output. STAIRs will produce every result tuple There will be no spurious duplicates

49. Lifting Burden of History: Delayed Data Sources

50. SETUP: E and C arrive early; S is delayed time |S E| |E C| >> S E C E C Eddy S E C Output S E HashTable S.Name HashTable E.Name HashTable E.Course HashTable C.Course S0S0 S0S0 E C S0ES0E Eddy decides to route E to E C Eddy learns the correct selectivities

51. SETUP: E and C arrive early; S is delayed time |S E| |E C| >> S E C Eddy S E C Output S0S0 HashTable S0S0 S.Name STAIR HashTable E E.Name STAIR HashTable S0ES0E E.Course STAIR HashTable C C.Course STAIR Eddy decides to route E to E C Eddy learns the correct selectivities Eddy decides to migrate E E C E C E E E E C E By promoting E using E C

52. SETUP: E and C arrive early; S is delayed time |S E| |E C| >> S E C Eddy S E C Output HashTable S0S0 S.Name STAIR HashTable E.Name STAIR HashTable S0ES0E E.Course STAIR HashTable C C.Course STAIR E C E S S –S 0 (S –S 0 ) E C

53. Eddy S E C Output HashTable S.Name STAIR HashTable E.Name STAIR HashTable SESE E.Course STAIR HashTable C C.Course STAIR E C E S S0S0 E C E C S E UNION E C S – S 0 S E E C Most of the data is processed using the correct plan

54. Further Motivating Adaptive State Management Eager pre-computation for faster response times Query scrambling [UFA’98] Partial results [RH’02] Selective caching of intermediate results Continuous queries over streams Cyclic queries Adapting the join spanning tree used

55. Making State Migration Decisions Another policy question Optimal migration decisions Requires knowledge of future selectivities and the sizes of relations

56. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

57. Alternative: SteMs [RDH’03] Don’t embed the state in the operators at all Note: Not the original motivation for SteMs Focus was on increasing opportunities for adaptivity by breaking up the join operators We will focus on a very simplistic version of the operator

58. Query Execution using SteMs Eddy S E C S SteM E SteM C SteM Store S tuples Allow probes using E tuples ie. If an E tuple is routed to it, find matching S tuples Could use any indexing technique to find matches Store E tuples Allow probes using S and C tuples Need to build two internal indexes

59. Query Execution using SteMs Eddy S E C Insert Probe S SteM JoeJr JenSr JoeCS1 CS2Smith E SteM C SteM JenCS2 JenCS2Smith JenSr.CS2SmithJenCS2 JenCS2 JenCS2 JenCS2 JenCS2Smith JenSr.CS2Smith Probe

60. Query Execution using SteMs State inside the operators is independent of previous routing decisions Because no intermediate tuples are ever stored Doesn’t have the same problem as the join or STAIR operators Optimal routing policy easy to write down Similarities to queries with only selections But not storing intermediate results increases the computation cost significantly

61. SteMs: Drawbacks Recomputation of intermediate result tuples Constrained plan choices Available plans depend highly on the arrival order

62. Eddy S E C S SteM E SteM C SteM S0S0 SETUP: E and C arrive early; S is delayed time |S E| |E C| >> S E C S0S0 E C S –S 0 can only be routed to E SteM for probing and is forced to be executed as (S Join E) Join C Under the mechanism, there is no way to execute the other plan for this setup

63. SteMs: Drawbacks Recomputation of intermediate result tuples Constrained plan choices Available plans depend highly on the arrival order Though more subtle, the second drawback might be the more important one

64. Recap An eddy operator Can affect the query execution plan(s) used by routing different tuples differently Eddy w/ Selections: Well understood Even if selections are correlated Babu, Munagala et al [SIGMOD 2004, ICDT 2005]

65. Recap Eddies for multi-way joins Opportunities for adaptivity depend on the join operators used Higher adaptivity tends to push logic into the eddy ==> Routing policies very important Similarities to selections Sort-merge Hybrid-Hash Index-nested loop joins Nested-loop Joins SteMs/ STAIRs Blocking opeators Little adaptivity See [AH’00] Suffers from state accumulation problems Pipelined/ Symmetric Hash Join Policy issues not well-understood

66. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

67. Implementation Details In PostgreSQL Database System code base In the context of TelegraphCQ project Highly efficient implementation [SIGREC’04] Eddy, SteMs, STAIRs export get_next() functions Routing decisions are made per batch Can control batch size Routing decisions made for all possible ready bitmaps Decisions are encoded in arrays that are indexed with ready bits Efficiently find the operator to route to

68. Results - Overheads (1) All plans have identical costs, so adaptivity plays no role

69. Results - Overheads (2)

70. Policies used for experiments Routing policy: Observe: Selectivities of predicates on base tables Domain sizes of join attributes Compute join selectivities and use them to route tuples Migration policy: Tie state migration decisions to routing decisions Follow the routing policy decisions to make sure that most tuples are routed correctly Caveats : May end doing migrations late in the query execution May thrash

71. State Migration: Illustrative Example select * from customer c, orders o, lineitem l where c.custkey = o.custkey and o.orderkey = l.orderkey and c.nationkey = 1 and c.acctbal > 9000 and l.shipdate > date ’1996-01-01’ Setup: lineitem arrives sorted on shipdate ==> selectivity(l.shipdate > …) very low initially ==> orders routed to join with lineitem (bad) No explicit delays introduced

72. Illustrative Example (1)

73. Illustrative Example (2)

74. Experiments: Synthetic Workload Modeled after the Wisconsin Benchmark 20 Tables for varying sizes Randomly generated queries Environment Rates proportional to table sizes; no delays or Random initial delays introduced or Random data rates

75. Traditional vs STAIRs

76. SteMs vs STAIRs

77. Joins vs STAIRs

78. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

79. Continous Query Processing Eddies ideal for executing continuous queries over data streams Dynamic runtime conditions make a static plan unsuitable Queries typically executed over sliding windows Find average over last one week Note: Continuous vs Multi-query processing Not identical Data streams literature does not make this difference explicit Application environments tend to have a large number of simultaneous queries

80. Continuous Query Processing CACQ [Madden et al 2002] Focus on sharing work as much as adaptivity Uses SteMs augmented with a deletion operator To handle sliding windows Also uses predicate indexes For handling a large number of queries on the same set of streams but with different predicates E.g. millions of stock alerts over a few streams

81. Roadmap Adaptive Query Processing: Motivation Eddies [AH’00] STAIRs [DH’04] and SteMs [RDH’03] Experimental Study Implementation in PostgreSQL [Des’03] Continuous queries [MSHR’02] (very briefly) Open problems

82. Some open problems (1) Eddies for continuous query processing Much work since CACQ, but not a solved problem E.g. computational inefficiency of SteMs Many other proposed CQ architectures face the same problem MJoins (NiagaraCQ) Stanford STREAM processor (earlier version)  Later added intermediate result caches Note: These two don’t use eddies explicitly Routing policies for CQ still an open question Different from routing policies for non-CQ queries

83. Some open problems (2) Routing policies Whether eddies will succeed depends on the routing policies Little work so far... SteMs, STAIRs Theoretical analysis of optimization space, and practical viability analysis needed Especially in the context of continuous query processing

84. Some open problems (3) Eddies for multi-query processing (non-CQ) SteMs may be sufficient for CQ processing, but not for normal multi-query processing Parallel, distributed environments, P2P, Grid.. Disk: Flexibility demanded by adaptive techniques at odds against the careful scheduling typically done by DBMSs XJoins Very little work on understanding this

85. Some open problems (4) Optimization with expanded plan space Eddies can explore a plan space much larger than traditional plan space They allow relations to be broken into pieces, with each piece executed separately Can we explore this plan space in a non- adaptive setting ? Recent work on: Conditional Planning [Deshpande et al, ICDE 2005] Content-based Routing [Babu et al, VLDB 2005]

86. Summary Increasing need for adaptivity Eddy: A highly adaptive query processor Executes queries by routing tuples through operators SteMs, STAIRs New operators proposed to handle problems with traditional join operators Very promising especially for continuous and wide-area query processing Exciting research lies ahead…

87. The End Questions ?

88. Fatal Flaw: Burden of Routing History Eddy S E C Output S E HashTable S.Name HashTable E.Name E C HashTable E.Course HashTable C.Course JoeJr JenSr CS2Smith JoeCS1 JoeJrCS1 JenCS2 JenCS2Smith Routing decisions get embedded in the state Future adaptibility is severly constrained

89. Example: Delayed Data Sources SETUP: |S E| |E C| >> E CS E S E C E SC E C E S Execution plan 1 Execution plan 2 Cost (Plan 1) > Cost (Plan 2) SESE SECSEC CECE SECSEC

90. SETUP: E and C arrive early; S is delayed Example: Delayed Data Sources time A plan may have to be chosen without any statistical information about the data Earliest time sufficient information may be available to choose optimal plan |S E| |E C| >> S E C

91. Tricky State Configurations: 1 Want to undo the decision to route E1 to S E E C Eddy S E C Output S E HashTable S.Name HashTable E.Name HashTable E.Course HashTable C.Course S0S0 E1 C S 0 E1 E2 E2C Result S 0 EC already produced

92. Eddy S E I E C HashTable E.Course HashTable C.Course C1 SE1 E2 S E HashTable S.Name HashTable E.Name S E1 E2C1 C I HashTable C.Intstructor HashTable I.Instructor I C E2C2I C2I C2 SE1C1 SE2C1 Tricky State Configurations: 2