1 XJoin: Faster Query Results Over Slow And Bursty Networks IEEE Bulletin, 2000 by T. Urhan and M Franklin Based on a talk prepared by Asima Silva & Leena Razzaq

2 Motivation Data delivery issues in terms of: – unpredictable delay from some remote data sources – wide-area network with possibly communication links, congestion, failures, and overload Goal: – Not just overall query processing time matters – Also when initial data is delivered – Overall throughput and rate throughout query process

3 Overview Hash Join History 3 Classes of Delays Motivation of XJoin Challenges of Developing XJoin Three Stages of XJoin Handling Duplicates Experimental Results

4 Hash Join Only one table is hashed key2R tuples key1 R tuples key3R tuples key4R tuples Key5…R tuples… S tuple 1 S tuple 2 S tuple 3 S tuple 4 S tuple 5…. 1. BUILD 2. Probe

5 Hybrid Hash Join One table is hashed both to disk and memory (partitions) G. Graefe. “Query Evaluation Techniques for Large Databases”, ACM1993. Disk Bucket i Bucket i+1 Bucket i+2 Bucket … Bucket j-1 Bucket j R tuples Bucket n Bucket n+1 Bucket n+2 Bucket … Bucket m-1 Bucket m R tuples MemoryS tuple 1 S tuple …

6 Symmetric Hash Join (Pipeline) Both tables are hashed (both kept in main memory only) Z. Ives, A. Levy, “An Adaptive Query Execution”, VLDB 99 Source R OUTPUT Source S Key n Key n+1 Key n+2 Key … Key m-1 Key m R tuples BUILD PROBE R tuple S tuple Key i Key i+1 Key i+2 Key … Key j-1 Key j S tuples BUILD PROBE R tuple S tuple

7 Problem of SHJ: Memory intensive : – Won’t work for large input streams – Wont’ allow for many joins to be processed in a pipeline (or even in parallel)

8 New Problems: Three Delays – Initial Delay First tuple arrives from remote source more slowly than usual (still want initial answer out quickly) – Slow Delivery Data arrives at a constant, but slower than expected rate (at the end, still overall good throughput behavior) – Bursty Arrival Data arrives in a fluctuating manner (how to avoid sitting idle in periods of low input stream rates)

9 Question: Why are delays undesirable? – Prolongs the time for first output – Slows the processing if wait for data to first be there before acting – If too fast, you want to avoid loosing any data – Waste of time if you sit idle while no data is incoming – Unpredictable, one single strategy won’t work

10 Challenges for XJoin Manage flow of tuples between memory and secondary storage (when and how to do it) Control background processing when inputs are delayed (reactive scheduling idea) Ensure the full answer is produced Ensure duplicate tuples are not produced Both quick initial output as well as good overall throughput

11 Motivation of XJoin Produces results incrementally when available – Tuples returned as soon as produced – Good for online processing Allows progress to be made when one or more sources experience delays by: – Background processing performed on previously received tuples so results are produced even when both inputs are stalled

12 Stages (in different threads) M :M M :D D:D

13 Tuple B hash(Tuple B) = n SOURCE-B Memory-resident partitions of source B SOURCE-A D I S K M E M O R Y 1... n n 1 Memory-resident partitions of source A n 1 Disk-resident partitions of source A... n Disk-resident partitions of source B... 1 n k k flush Tuple A hash(Tuple A) = 1 XJoin

14 1 st Stage of XJoin Memory - to - Memory Join Tuples are stored in partitions: – A memory-resident (m-r) portion – A disk-resident (d-r) portion Join processing continues as usual: – If space permits, M to M – If memory full, then pick one partition as victim, flush to disk and append to end of disk partition 1 st Stage runs as long as one of the inputs is producing tuples If no new input, then block stage1 and start stage 2

15 M E M O R Y Partitions of source B i j SOURCE-B hash(record B) = j Tuple B SOURCE-A Tuple A hash(record A) = i i j Partitions of source A Output Insert Probe Insert Probe 1 st Stage Memory-to-Memory Join

16 Why Stage 1? Use Memory as it is the fastest whenever possible Use any new coming data as it’s already in memory Don’t stop to go and grab stuff out of disk for new data joins

17 Question: – What does Second Stage do? – When does the Second Stage start? – Hints: Xjoin proposes a memory management technique What occurs when data input (tuples) are too large for memory? – Answer: Second Stage joins Mem-to-Disk Occurs when both the inputs are blocking

18 2 nd Stage of XJoin Activated when 1 st Stage is blocked Performs 3 steps: 1. Chooses the partition according to throughput and size of partition from one source 2. Uses tuples from d-r portion to probe m-r portion of other source and outputs matches, till d-r completely processed 3. Checks if either input resumed producing tuples. If yes, resume 1 st Stage. If no, choose another d-r portion and continue 2 nd Stage.

19 Output i i M E M O R Y Partitions of source BPartitions of source A D I S K Partitions of source BPartitions of source A i i..... DP iA MP iB Stage 2: Disk-to-memory Joins

20 Controlling 2 nd Stage Cost of 2 nd Stage is hidden when both inputs experience delays Tradeoff ? What are the benefits of using the second stage? – Produce results when input sources are stalled – Allows variable input rates What is the disadvantage? – The second stage must complete a d-r portion before checking for new input (overhead) To address the tradeoff, use an activation threshold: – Pick a partition likely to produce many tuples right now

21 3 rd Stage of XJoin Disk-to-Disk Join Clean-up stage – Assumes that all data for both inputs has arrived – Assumes that first and second stage completed – Makes sure that all tuples belonging in the result are being produced. Why is this step necessary? – Completeness of answer

22 Handling Duplicates When could duplicates be produced? Duplicates could be produced in all 3 stages as multiple stages may perform overlapping work. How address it: – XJoin prevents duplicates with timestamps. When address this: – During processing as continuous output

23 Time Stamping : part 1 2 fields are added to each tuple: – Arrival TimeStamp (ATS) indicates when the tuple arrived first in memory – Departure TimeStamp (DTS) used to indicated time the tuple was flushed to disk [ATS, DTS] indicates when tuple was in memory When did two tuples get joined? – If Tuple A’s DTS is within Tuple B’s [ATS, DTS] Tuples that meet this overlap condition are not considered for joining by the 2 nd or 3 rd stages

24 Tuple B Tuples joined in first stage B1 arrived after A, and before A was flushed to disk Tuple A DTSATS Tuple B Tuples not joined in first stage B2 arrived after A, and after A was flushed to disk Tuple A DTSATS Non-Overlapping Detecting tuples joined in 1st stage Overlapping

25 Time Stamping : part 2 For each partition, keep track off: –ProbeTS: time when a 2 nd stage probe was done –DTSlast: the latest DTS time of all the tuples that were available on disk at that time Several such probes may occur: –Thus keep an ordered history of such probe descriptors Usage: –All tuples before and including at time DTSlast were joined in stage 2 with all tuples in main memory (ATS,DTS) at time ProbeTS

26 Tuple A DTS ATS Tuple B DTS ATS Detecting tuples joined in 2nd stage ProbeTS DTS last Partition 1 Overlap Partition Partition 3 History list for the corresponding partitions Partition Partition 2 All tuples before and including DTSlast were joined in Stage 2 At time ProbeTS All A tuples in Partition 2 up to DTSlast 250, Were joined with m-r tuples that arrived before Partition 2’s ProbeTS.

27 Experiments HHJ (Hybrid Hash Join) Xjoin (with 2 nd stage and with caching) Xjoin (without 2 nd stage) Xjoin (with aggressive usage of 2 nd stage)

28 Case 1: Slow Network Both sources are slow (bursty) XJoin improves delivery time of initial answers -> interactive performance The reactive background processing is an effective solution to exploit intermittant delays to keep continued output rates. Shows that 2 nd stage is very useful if there is time for it

29 Slow Network: both resources are slow

30 Case 2: Fast Network Both sources are fast All XJoin variants deliver initial results earlier. XJoin also can deliver the overall result in equal time to HHJ HHJ delivers the 2nd half of the result faster than XJoin. 2 nd stage cannot be used too aggressively if new data is coming in continuously

31 Case 2: Fast Network Both sources are fast

32 Conclusion Can be conservative on space (small footprint) Can be used in conjunction with online query processing to manage the streams Resuming Stage 1 as soon as data arrives Dynamically choosing techniques for producing results

33 References Urhan, Tolga and Franklin, Michael J. “XJoin: Getting Fast Answers From Slow and Bursty Networks.” Urhan, Tolga, Franklin, Michael J. “XJoin: A Reactively- Scheduled Pipelined Join Operator.” Hellerstein, Franklin, Chandrasekaran, Deshpande, Hildrum, Madden, Raman, and Shah. “Adaptive Query Processing: Technology in Evolution”. IEEE Data Engineering Bulletin, Hellerstein and Avnur, Ron. “Eddies: Continuously Adaptive Query Processing.” Babu and Wisdom, Jennefer. “Continuous Queries Over Data Streams”.