Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Ramon Lawrence University of Iowa

Page 2 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Introduction Interactive user querying requires the DBMS produce the first few query answers quickly as well as minimize the total query execution time. Queries that produce a lot of results with large hash joins have a slow response time as the smaller input must be completely partitioned before any output can be generated. It is desirable to have a hash-based join algorithm for centralized databases that: u Has rapid response time to produce the first few results u Has overall execution time comparable to hybrid hash join u Can be dynamically configured by the optimizer

Page 3 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Previous Work Hash joins: u hybrid hash join [DeWitt84] - standard join used in most DBMSs u dynamic hash join [DeWitt95,Nakayama88] - dynamic partitioning u symmetric hash join [Hong93,Wilschut91] - dual hash table u ripple join [Haas99,Luo02] - online aggregation, reading policies u MJoin [Ding03] - purges join state using stream punctuation Mediator-based joins: u Improve overall execution time by executing during delays instead of plan re-ordering/query scrambling [Raman99, Urhan98]. u double pipelined hash join [Ives99] - Tukwila system u XJoin [Urhan00] - probe in-memory partitions when blocked u hash-merge Join [Mokbel04] - sort-merge partitions when blocked u progressive merge join [Dittrich02] - dual sort-based join

Page 4 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Motivation Interactive users of centralized DBMS can benefit from fast response time inherent in dual-hash table joins. Challenge is to ensure overall performance is not signficantly sacrificed for this fast response time. Dual-hash table join has other benefits as the operator is more easily pipelined (since it is symmetric). This is valuable for federated joins when one or more of the inputs may not be local to the database engine.

Page 5 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Reading Strategy A reading strategy is the rules an algorithm uses to decide how to read from the two inputs when both inputs have tuples available. u Reading strategies do NOT apply to streaming (push-based) inputs. u They are useful when the inputs are on a local hard drive or a fast network source (pull-based). Reading strategies have been used before for processing top-k queries and in ripple joins. The reading strategy for hybrid hash join is to read the entire smaller input then the larger input. Another strategy is to read alternately from the inputs.

Page 6 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Flushing Policy The flushing policy determines which tuples in memory are written to disk when memory must be released to accept new input. Previous flushing policies: u Flush the largest single partition (XJoin) u Co-ordinated flushing of a partition pair (Hash-merge join) Flushing policy affects the duplicate detection strategy of the join algorithm. Also affects its performance in two ways: u 1) Join output rate - The number of results generated as input is being received. This depends on the tuples in memory. u 2) Overall execution time - The total time may change depending on the cost of flushing and post-join cleanup.

Page 7 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Early Hash Join (EHJ) Algorithm The Early Hash Join (EHJ) algorithm uses a dual hash table approach. It is specifically designed for a centralized DBMS where overall execution time is dictated by the flushing and partitioning speed and not by the input arrival rates. EHJ uses: u a variable reading strategy that changes when memory is full u a biased flushing policy to favor the smaller input u optimizations to flush join memory state for 1:* joins u simplified duplicate detection that requires no timestamps for 1:* joins and only one timestamp for *:* joins u a background process when used for mediator joins or with slow network-based inputs

Page 8 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Early Hash Join (EHJ) Algorithm Start Join Read tuple from R or S (policy) Yes Input left? Tuple of R? Insert in R table Probe S table Output results Insert in S table Probe R table Output results Yes No Memory full? No Initialize 1st cleanup phase Close S file. Delete on-disk partitions. No On-disk S no R? Yes In phase 1? No Join complete Yes Load R to memory On-disk R? No Read S tuple TSProbe R table Output results Input left in S file? Initialize probe file for S partition Yes Bias Flush Initialize 2nd cleanup phase No

Page 9 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Biased Flushing Policy The biased flushing policy is designed to keep as much of the smaller input in memory as possible (similar to hybrid hash join). Biased flushing policy: u Flush largest non-frozen partition of S (larger input). u If no such partition of S exists, flush smallest, non-frozen partition of R (smaller input). Idea of freezing a partition is from dynamic hash join [DeWitt95]. A frozen partition does not accept input once it has been flushed and is not probed. u XJoin and HMJ do not freeze partitions. u Freezing partitions and using biased flushing simplifies the duplicate detection strategy.

Page 10 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Duplicate Detection Duplicate detection is required so that join results are not re- generated during the cleanup pass. For common 1:* joins, no timestamps are needed: u With a *-side probe tuple, it is discarded if matched. u With a 1-side probe tuple, delete from the hash table any matching tuples on the *-side. For *:* joins a single timestamp representing the tuples arrival order is kept. In cleanup pass, result tuple of (T R,T S ) passes timestamp check (and is output) if one of these is true: u 1) T S arrived before its partition of S was flushed and T R arrived after its corresponding partition of S was flushed. u 2) T S arrived after its partition of S was flushed but before the matching partition of R was flushed and T R arrived after T S. u 3) T S arrived after partition of R was flushed.

Page 11 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Performance Analysis Parameters: u Two input relations R and S with |R|  |S|. u Join memory M where M  |R|. Let f = M / |R|. u Reading policy before memory is full is A 1 :B 1. Let q 1 =A 1 /(A 1 +B 1 ). u Reading policy after memory is full is A 2 :B 2. Let q 2 =A 2 /(A 2 +B 2 ). Number of I/O operations: (not counting reading inputs) u where u Note for hybrid hash join, leftS = |S|.

Page 12 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Background Process A background process can be used when the inputs are from sources other than the hard drive used for flushing. u This includes mediator and federated joins. u As shown in previous work, most valuable for slow or bursty networks. Not as useful for high speed networks. Similar to XJoin, use an on-disk partition of S to probe the matching partition of R currently in memory. Designed as a background process that runs concurrently with main join process. This can boost join output rate, but still must be careful not to needlessly tie up CPU when background process may only generate a few results. u Duplicate detection is slightly modified when using BG process.

Page 13 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Experimental Evaluation The performance of early hash join was compared with dynamic hash join, XJoin, and hash-merge join. u All algorithms were implemented in Java and tested on a TPC-H 1 GB size data set (raw text files). All dual hash table algorithms used the same table structure. Summary of results: u EHJ is 10-35% faster than HMJ/XJoin for many-to-many joins and 25-75% faster for one-to-many joins. u EHJ is faster over all memory sizes except for very small memory (less than 10% of smaller relation size). u EHJ performs better when the difference in the relative sizes of the relations is large. u EHJ is within 10% of overall time of DHJ, but with a response time that is an order of magnitude faster. Intelligent buffering may be able to further reduce this difference.

Page 14 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Many-to-Many Join Experiment Query: SELECT * FROM PartSupp P1, PartSupp P2  WHERE P1.p_partkey = P2.p_partkey u P1 and P2 were randomly permuted as sorted on p_partkey. u Memory size = 300,000 tuples (37.5% of 800,000 tuples)

Page 15 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results One-to-Many Join Experiment Query: SELECT * FROM Customer C, Orders O WHERE C.c_custkey = O.o_custkey u Memory size = 75,000 tuples (50% of 150,000 tuples)

Page 16 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Multi-Join Experiment SELECT c_custkey, c_name, c_address, o_orderkey, o_custkey, o_totalprice, o_orderdate, l_orderkey, l_partkey, l_suppkey, l_quantity, l_extendedprice FROM Customer C, Orders O, LineItem LI WHERE C.c_custkey=O.o_custkey and O.o_orderkey = LI.l_orderkey u Memory size = 90,000 tuples (60% of 150,000 tuples) (C+O) u Memory size = 450,000 tuples (30% of 1,500,000) (C/O + LI)

Page 17 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Mediator Experimental Evaluation The performance of early hash join was compared with dynamic hash join, XJoin, and hash-merge join for mediator joins. u All algorithms were implemented in Java and tested on a TPC-H 100 MB size data set with queries processed by SQL Server. u DHJ downloaded from both inputs in parallel. Summary of results: u Both overall execution time and join output rate is dictated by speed of inputs. Little variation in execution time for algorithms. u All early algorithms have response time an order of magnitude faster than DHJ especially when left input is slow. u For 1:* joins, EHJ is 5%-15% faster overall than HMJ/XJoin and equivalent to DHJ. It also has a slightly faster join output rate. u For *:* joins, EHJ was only marginally faster in overall time with a very similar join output rate.

Page 18 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Applications The primary application is interactive querying on a centralized database. EHJ has a response time an order of magnitude faster than hybrid hash join with little execution overhead. EHJ is also more suitable for pipelining within and outside DBMS as it is a symmetric operator that tolerates source delays. This may be especially valuable for federate queries. EHJ can be used with LIMIT queries to produce the first few results without the overhead of partitioning the smaller input. However, any query with blocking operators such as ordering and grouping cannot benefit from its fast response time. Further, it is not order preserving without additional modifications.

Page 19 The University of Iowa. Copyright© 2005 Ramon Lawrence - Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Future Work and Conclusions EHJ is a useful algorithm for interactive querying and a good candidate for inclusion into the set of join algorithms for a centralized DBMS. EHJ is dynamically configurable using a reading policy and can adapt to slow input arrival. In a centralized environment, it significantly outperforms previous early join algorithms. Future work: u Implement and test performance of EHJ in PostgreSQL. u Expand algorithm for a N-way join. u Investigate possibility of making order preserving and optimized for distributed/mediator joins.

Early Hash Join: A Configurable Algorithm for the Efficient and Early Production of Join Results Ramon Lawrence University of Iowa Thank You!