Supporting Top-k Join Queries in Relational Databases

Transcription

1 Supporting Top-k Join Queries in Reationa Databases Ihab F. Iyas Waid G. Aref Ahmed K. Emagarmid Department of Computer Sciences, Purdue University West Lafayette IN Abstract Ranking queries produce resuts that are ordered on some computed score. Typicay, these queries invove joins, where users are usuay interested ony in the top-k join resuts. Current reationa query processors do not hande ranking queries efficienty, especiay when joins are invoved. In this paper, we address supporting top-k join queries in reationa query processors. We introduce a new rank-join agorithm that makes use of the individua orders of its inputs to produce join resuts ordered on a user-specified scoring function. The idea is to rank the join resuts progressivey during the join operation. We introduce two physica query operators based on variants of rippe join that impement the rank-join agorithm. The operators are nonbocking and can be integrated into pipeined execution pans. We address severa practica issues and optimization heuristics to integrate the new join operators in practica query processors. We impement the new operators inside a prototype database engine based on PREDATOR. The experimenta evauation of our approach compares recent agorithms for joining ranked inputs and shows superior performance. This work was supported in part by the Nationa Science Foundation under Grants IIS , EIA , IIS and by the NAVSEA/Nava Surface Warfare Center, Crane. Permission to copy without fee a or part of this materia is granted provided that the copies are not made or distributed for direct commercia advantage, the VLDB copyright notice and the tite of the pubication and its date appear, and notice is given that copying is by permission of the Very Large Data Base Endowment. To copy otherwise, or to repubish, requires a fee and/or specia permission from the Endowment. Proceedings of the 29th VLDB Conference, Berin, Germany Introduction Rank-aware query processing has become a vita need for many appications. In the context of the Web, the main appications incude buiding meta-search engines, combining ranking functions and seecting documents based on mutipe criteria [6]. Efficient rank aggregation is the key to a usefu search engine. In the context of mutimedia and digita ibraries, an important type of query is simiarity matching. Users often specify mutipe features to evauate the simiarity between the query media and the stored media. Each feature may produce a different ranking of the media objects simiar to the query, hence the need to combine these rankings, usuay, through joining and aggregating the individua feature rankings to produce a goba ranking. Simiar appications exist in the context of information retrieva and data mining. Most of these appications have queries that invove joining mutipe inputs, where users are usuay interested in the top-k join resuts based on some score function. Since most of these appications are buit on top of a commercia reationa database system, our goa is to support top-k join queries in reationa query processors. The answer to a top-k join query is an ordered set of join resuts according to some provided function that combines the orders on each input. More precisey, consider a set of reations R 1 to R m. Each tupe in R i is associated with some score that gives it a rank within R i. The top-k join query joins R 1 to R m and produces the resuts ranked on a tota score. The tota score is computed according to some function, f, that combines individua scores. Note that the score attached with each reation can be the vaue of one attribute or a vaue computed using a predicate on a subset of its attributes. A possibe SQL-ike notation for expressing a top-k join query is as foows: SELECT * FROM R 1, R 2,..., R m WHERE join condition(r 1, R 2,..., R m) ORDER BY f(r 1.score, R 2.score,..., R m.score) STOP AFTER k;

2 1.1 Motivation The join operation can be viewed as the process of spanning the space of Cartesian product of the input reations to get vaid join combinations. For exampe, in the case of a binary join operation, the Cartesian space of the input reations A and B is a two dimensiona space. Each point is a tupe pair (A i, B j ), where A i is the i th tupe from the first reation and B j is the j th tupe from the second reation. The join condition needs to be evauated for a the points in the space. However, ony part of this space needs to be computed to evauate top-k join queries. This partia space evauation is possibe if we make use of the individua orderings of the input reations. Current join operators cannot generay benefit from orderings on their inputs to produce ordered join resuts. For exampe, in sort-merge join (MGJN) ony the order on the join coumn can be preserved. In nested-oops join (NLJN), ony the orders on the outer reations are preserved through the join, whie in hash join (HSJN), orders from both inputs are usuay destroyed after the join, when hash tabes do not fit in memory. The reason is that these join operators decoupe the join from sorting the resuts. Consider the foowing exampe ranking query: Q1: SELECT A.1,B.2 FROM A,B,C WHERE A.1 = B.1 and B.2 = C.2 ORDER BY (0.3*A.1+0.7*B.2) STOP AFTER 5; where A, B and C are three reations and A.1,B.1,B.2 and C.2 are attributes of these reations. The Stop After operator, introduced in [3, 4], imits the output to the first five tupes. In Q1, the ony way to produce ranked resuts on the expression 0.3 A B.2 is by using a sort operator on top of the join. Figure 1 (a) gives an exampe query execution pan for Q1. Foowing the concept of interesting orders [16] introduced in system R, the optimizer may aready have pans that access reations A and B ordered on A.1 and B.2, respectivey. Interesting orders are those that are usefu for ater operations (e.g., sort-merge joins), and hence, need to be preserved. Usuay, interesting orders are on the join coumn of a future join, the grouping attributes (from the group by cause), and the ordering attributes (from the order by cause). Despite the fact that individua orders exist on A.1 and B.2, current join operators cannot make use of these individua orders in producing the join resuts ordered on the expression 0.3 A B.2. Hence, the optimizer ignores these orders when evauating the order by cause. Therefore, a sort operator is needed on top of the join. Moreover, consider repacing B.2 by B.3 in the order by cause. According to current query optimizers, B.3 is not an interesting order since it does not appear (by itsef) in the order by cause. Hence, generating a pan that produces an order on B.3 is not beneficia for ater operations. On the other hand, B.3 is definitey interesting if we have a rankjoin operator that uses the orders on A.1 and B.3 to produce join resuts ordered on 0.3 A B.3. Having a rank-join operator wi probaby force the generation of base pans for B that has an order on B.3. Top(k) SORT A.1 + B.2 SORT SORT A.1 B.1 A MGJN (a) NLJN B C SORT B.2 B NLJN (b) Top(k) RANK JOIN A.1+B.2 C SORT A.1 Figure 1: Aternative pans for Query Q1. Two major probems arise when processing the previous rank-join query using current join impementations: (1) sorting is an expensive operation that produces a tota order on a the join resuts whie the user is ony interested in the first few tupes. (2) Sorting is a bocking operator and if the inputs are from externa sources, the whoe process may sta if one of the sources is bocked. 1.2 Our Contribution The two aforementioned probems resut from decouping the sorting (ranking) from the join operation and osing the advantage of having aready ranked inputs. We need a ranking-aware join operator that behaves in a smarter way in preserving the interesting orders of its inputs. We need the new rank-join operator to: (1) perform the basic join operation under genera join conditions. (2) conform with the current query operator interface so it can be integrated with other query operators (incuding ordinary joins) in query pans. (3) make use of the individua orders of its inputs to avoid the unnecessary sorting of the join resuts. (4) produce the first ranked join resuts as quicky as possibe. (5) adapt to input fuctuations; a major characteristic in the appications that depend on ranking. We summarize our contribution in this paper as foows: We propose a new rank-join agorithm, with the above desired properties, aong with its correctness proof. A

3 We impement the proposed agorithm in practica pipeined rank-join operators based on rippe join, with better capabiities of preserving orders of their inputs. The new operators can be integrated in query pans as ordinary join operators and hence give the optimizer the chance to produce better execution pans. Figure 1 (b) gives an exampe execution pan for Q1, using the proposed rank-join operator (RANK-JOIN). The pan avoids the unnecessary sort of the join resuts by utiizing the base tabe access pans that preserve interesting orders. Moreover, the pan produces the top-k resuts incrementay. We propose a nove score-guided join strategy that minimizes the range of the Cartesian space that needs to be evauated to produce the topk ranked join resuts. We introduce an adaptive join strategy for joining ranked inputs from externa sources, an important characteristic of the appications that use ranking. We experimentay evauate our proposed join operators and compare them with other approaches to join ranked inputs. The experiments vaidate our approach and show a superior performance of our agorithm over other approaches. The remainder of this paper is organized as foows. Section 2 describes reevant previous attempts and their imitations. Section 3 gives some necessary background on rippe join. Section 4 describes the query mode for answering top-k join queries. Aso, in Section 4, we introduce the new rank-join agorithm aong with its correctness proof. We present two physica rank-join operators in Section 5. In Section 6, we generaize the rank-join agorithm to expoit any avaiabe random access to the input reations. Section 7 gives the experimenta evauation of the new rank-join operator and compares it with aternative techniques. We concude in Section 8 with a summary and fina remarks. 2 Reated Work A cosey reated probem is supporting top-k seection queries. In top-k seection queries, the goa is to appy a scoring function on mutipe attributes of the same reation to seect tupes ranked on their combined score. The probem is tacked in different contexts. In middeware environments, Fagin [7] and Fagin et a. [8] introduce the first efficient set of agorithms to answer ranking queries. Database objects with m attributes are viewed as m separate ists, each supports sorted and, possiby, random access to object scores. The TA agorithm [8] assumes the avaiabiity of random access to object scores in any ist besides the sorted access to each ist. The NRA agorithm [8] assumes ony sorted access is avaiabe to individua ists. Simiar agorithms are introduced (e.g., see [9, 10, 15]). In [2], the authors introduce an agorithm for evauating top-k seection queries over web-accessibe sources assuming that ony random access is avaiabe for a subset of the sources. Chang and Hwang [5] address the expensive probing of some of the object scores in top-k seection queries. They assume a sorted access on one of the attributes whie other scores are obtained through probing or executing some user-defined function on the remaining attributes. A more genera probem is addressed in [14]. The authors introduce the J agorithm to join mutipe ranked inputs to produce a goba rank. J maps the rank-join probem to a search probem in the Cartesian space of the ranked inputs. J uses a version of the A search agorithm to guide the navigation in this space to produce the ranked resuts. Athough J shares the same goa of joining ranked inputs, our approach is more fexibe in terms of join strategies, is more genera in using the avaiabe access capabiities, and is easier to be adopted by practica query processors. In our experimenta study, we compare our proposed join operators with the J and show significant enhancement in the overa performance. The top-k join queries are aso discussed briefy in [5] as a possibe extension to their agorithm to evauate top-k seection queries. Top-k seection queries over reationa databases can be mapped into range queries using high dimensiona histograms [1]. In [13], top-k seection queries are evauated in reationa query processors by introducing a new pipeined join operator termed NRA-RJ. NRA-RJ modifies the NRA agorithm [8] to work on ranges of scores instead of requiring the input to have exact scores. NRA-RJ is an efficient rank-join query operator that joins mutipe ranked inputs based on a key-equaity condition and cannot hande genera join conditions. In [13], it is shown both anayticay and experimentay that NRA-RJ is superior to J for equaity join conditions on key attributes. 3 An Overview on Rippe Join Rippe join is a famiy of join agorithms introduced in [11] in the context of onine processing of aggregation queries in a reationa DBMS. Traditiona join agorithms are designed to minimize the time ti competion. However, rippe joins are designed to minimize the time ti an acceptaby precise estimate of the query resut is avaiabe. Rippe joins can be viewed as a generaization of nested-oops join and hash join. We briefy present the basic idea of rippe join beow. In the simpest version of a two-tabe rippe join, one previousy-unseen random tupe is retrieved from each tabe (e.g., R and S) at each samping step. These new tupes are joined with the previousy-seen tupes and with each other. Thus the Cartesian product R S is swept out as depicted in Figure 2.

4 R R R S S Figure 2: Three steps in Rippe Join The square version of rippe join draws sampes from R and S at the same rate. However, in order to provide the shortest possibe confidence intervas, it is often necessary to sampe one reation at a higher rate. This requirement eads to the genera rectanguar version of the rippe join where more sampes are drawn from one reation than from the other. Variants of rippe join are: (1) Bock Rippe Join, where the sampe units are bocks of tupes of size b (In cassic rippe join, b = 1), (2) Hash Rippe Join, where a the samped tupes are kept in hash tabes in memory. In this case, cacuating the join condition of a new samped tupe with previousy samped tupes is very fast (saving I/O). The second variant is exacty the symmetric hash join [12, 19] that aows a high degree of pipeining in parae databases. When the hash tabes grow in size and exceed memory size, the hash rippe join fas back to bock rippe join. 4 Supporting Top-k Join Queries In this section we address the probem of supporting top-k join queries. We start by defining the query mode and present our approach to support evauating this type of queries in reationa query engines. 4.1 Query Mode In traditiona reationa systems the answer to a join query is a set of m tupe records, where m is the number of joined reations and each join resut is a new tupe that consists of the concatenation of the tupes from the joined reations. There is no order requirement imposed on the join resuts athough the join technique may be abe to preserve partia orders of the inputs. In contrast, the answer to a top-k join query is an ordered set of join resuts according to some provided function that combines the orders on each input. 4.2 The New Rank Join Agorithm Current impementations of the join operator do not make use of the fact that the inputs may be aready ordered on their individua scores. Using these individua orderings, we can perform much better in evauating the top-k join queries by eiminating the need to sort the join resuts on the combined score. S The join operation can be viewed as the process of spanning the space of Cartesian product of the input reations to get vaid join combinations. An important observation is that, ony part of this space needs to be computed to evauate top-k join queries, if we have the inputs ordered individuay. In this section we describe a new join agorithm, termed rank-join. The agorithm takes m ranked inputs, a join condition, a monotone combining ranking function f and the number of desired ranked join resuts k. The agorithm reports the top k ranked join resuts in descending order of their combined score. The rank-join agorithm works as foows: Retrieve objects from the input reations in a descending order of their individua scores. For each new retrieved tupe: 1. Generate new vaid join combinations with a tupes seen so far from other reations, using some join strategy. 2. For each resuting join combination, J, compute the score J.score as f(o 1.score, O 2.score,..., O m.score), where O i.score is the score of the object from the i th input in this join combination. 3. Let the object O (di) i be the ast object seen from input i, where d i is number of objects retrieved from that input, O (1) i be the first object retrieved from input i, and T be the maximum of the foowing m vaues: f(o (d1) 1.score, O (1) 2.score,..., O(1) m.score), f(o (1) 1.score, O(d2) 2.score,..., O m (1).score),..., f(o (1) 1.score, O(1) 2.score,..., O(dm) m.score). 4. et L k be a ist of the k join resuts with the maximum combined score seen so far and et score k be the owest score in L k, hat when score k T. Report the join resuts in L k ordered on their combined scores. The vaue T is an upper-bound of the scores of any join combination not seen so far. An object O p i, where p > d i, not seen yet from input i, cannot contribute to any join combination that has a combined score greater than or equa f(o (1) 1.score,..., O(di) i.score,..., O m (1).score). The vaue T is continuousy updated with the score of the newy retrieved tupes. Theorem 4.2.1: Using a monotone combining function, the described rank-join agorithm correcty reports the top k join resuts ordered on their combined score. Proof: For simpicity, we prove the agorithm for two inputs and r. The proof can be extended to cover the

5 m inputs case. We assume that the agorithm access the same number of tupes at each step, i.e., d 1 = d 2 = d. The two assumptions do not affect the correctness of the origina agorithm. The proof is by contradiction. Assume that the agorithm hats after d sorted accesses to each input and reports a join combination J k = (O (i), O r (j) ), where O (i) is the i th object from the eft input and O r (j) is the j th object from the right input. Since the agorithm hats at depth d, we know that J k.score T (d), where T (d) is the maximum of f(o (1).score, O r (d).score) and f(o (d).score, O r (1).score). Now assume that there exists a join combination J = (O (p), O r (q) ) not yet produced by the agorithm and J.score > J k.score. That impies J.score > T (d), i.e., f(o (p) and f(o (p).score, O (q) r.score, O (q) r.score) > f(o(1).score, O r (d).score) (1).score) > f(o(d).score, O r (1).score) (2) Since each input is ranked in descending order of object scores, then O (p).score O (1).score. Therefore, O r (q).score must be greater than O r (d).score. Otherwise, Inequaity (1) wi not hod because of the monotonicity of the function f. We concude that O r (q) must appear before O r (d) in the right input, i.e., q < d (3) Using the same anaogy, we have O r (q).score O r (1).score. Therefore, O (p).score must be greater than O (d).score. Otherwise, Inequaity (2) wi not hod because of the monotonicity of the function f. We concude that O (p) must appear before O (d) in the eft input, i.e., p < d (4) From (3) and (4), if vaid, the combination J = (O (p), O r (q) ) must have been produced by the agorithm, which contradicts the origina assumption. Theorem 4.2.1: The buffer maintained by the rankjoin agorithm to hod the ranked join resuts is bounded and has a size that is independent of the size of the inputs. Proof: Other than the space required to perform the join, the agorithm needs ony to remember the top k join resuts independent of the size of the input. Foowing this abstract description of the rank-join agorithm, we show how to impement the agorithm in a binary pipeined join operator that can be integrated in commercia query engines. Theoreticay, any current join impementation can be augmented to support the previousy described agorithm. Practicay, the join technique greaty affects the performance of the ranking process. We show the effect of the seection of the join strategy on the stopping criteria of the rank-join agorithm. 4.3 The Effect of Join Strategy The order in which the points in the Cartesian space are checked as a vaid join resut has a great effect on the stopping criteria of the rank-join agorithm. Consider the two reations in Figure 3 to be joined with the join condition L.A = R.A. The join resuts are required to be ordered on the combined score of L.B + R.B. id A B L id A B R Figure 3: Two exampe reations Foowing the new rank-join agorithm, described in Section 4.2, a threshod vaue wi be maintained as the maximum between f(l (1).B, R (d2).b) and f(l (d1).b, R (1).B), where L (d1) and R (d2) are the ast tupes accessed from L and R, respectivey. Figure 4 shows two different strategies to produce join resuts (a) Figure 4: Two possibe join strategies. Strategy (a) is a nested-oops evauation whie Strategy (b) is a symmetric join evauation that tries to baance the access from both inputs. To check for possibe join combinations, Strategy (a) accesses four tupes from L and one tupe from R whie Strategy (b) accesses two tupes from each reation. The rank-join agorithm at this stage computes a different threshod vaue T in both strategies. In Strategy (a), T = max(5 + 2, 5 + 5) = 10, whie in Strategy (b) T = max(5+4, 5+4) = 9. At this stage, the ony vaid join combination is the tupe pair [(1, 1, 5), (2, 1, 4)] with a combined score of 9. In Strategy (a), this join combination cannot be reported because of the threshod vaue of 10 whie the join combination is reported as the top-ranked join resut according to Strategy (b). (b)

6 The previous discussion suggests using join strategies that reduce the threshod vaue as quicky as possibe to be abe to report top ranked join resuts eary on. In the next section, we present different impementations of the rank-join agorithm by choosing different join strategies. 5 New Physica Rank Join Operators The biggest advantage of encapsuating the rank-join agorithm in a rea physica query operator is that rank-join can be adopted by practica query engines. The query optimizer wi have the opportunity to optimize a ranking query by integrating the new operator in ordinary query execution pans. The ony other aternative to deveop a query operator is to impement the rank-join agorithm as a user defined function. This approach wi ose the efforts of the query optimizer to produce a better overa query execution pan. Figure 5 gives aternative execution pans to rank-join three ranked inputs. R Top(k) Sort S L R r Top(k) : Ordinary join operator. : The proposed rank join operator (). r S r L R Sort Top(k) (a) (b) (c) Figure 5: Aternative execution pans to rank-join three ranked inputs. In this section, we present two aternatives to reaize the new rank-join agorithm as a physica join operator. The main difference between the two aternatives is in the join strategy that is used in order to produce vaid join combinations. Reusing the current join strategies (nested-oops join, merge join and hash join) resuts in a poor performance. Nested-oops join wi have a high threshod vaue because we access a the tupes of the inner reation for ony one tupe from the outer reation. Merge join requires sorting on the join coumns (not the scores) of both inputs and hence cannot be used in the rank-join agorithm. Simiary, hash join destroys the order through the use of hashing when hash tabes exceed memory size. The join strategies presented here depend on baancing the access of the underying reations. Since the join operation is impemented in most systems as a dyadic (2-way) operator, we describe the new operators as binary join operators. Foowing common query execution modes, we describe the new physi- S r L Open(L,R,C,f) input L,R: Left and right ranked input C: join condition. f: monotone combining ranking function. begin Aocate a priority queue Q; Buid two hash tabes for L and R; Set the join condition to C; Set the combining function to f; Threshod = 0; L.Open(); R.Open(); end Tabe 1: The Open operation. ca join operators in terms of the three basic interface methods Open, GetNext and Cose. The Open method initiaizes the operator and prepares its interna state, the GetNext method reports the next ranked join resut upon each ca, and the Cose method terminates the operator and performs the necessary cean up. In choosing the join strategy, the discussion in Section 4.3 suggests sweeping the Cartesian space in a way that reduces the threshod vaue. We depend on the idea of rippe join as our join strategy. Instead of randomy samping tupes from the input reations, the tupes are retrieved in order to preserve ranking. One chaenge is to determine the rate at which tupes are retrieved from each reation. We present two variants of our rank-join agorithm. The two variants are based on adopting two rippe join variants: the hash rippe join and the bock rippe join. 5.1 Hash Rank Join Operator () can be viewed as a variant of the symmetrica hash join agorithm [12, 19] or the hash rippe join agorithm [11]. The Open method is given in Tabe 1. The operator is initiaized by specifying four parameters: the two inputs, the join condition, and the combining function. Any of the two inputs or both of them can be another operator 1. The join condition is a genera equaity condition to evauate vaid join combinations. The combining function is a monotone function that computes a goba score from the scores of each input. The Open method sets the state and creates the operator interna state which consists of three structures. The first two structures are two hash tabes, i.e., one for each input. The hash tabes hod input tupes seen so far and are used in order to compute the vaid join resuts. The third structure is a priority queue that hods the vaid join combinations ordered on their combined score. The Open method aso cas the initiaization methods of the inputs. 1 Because is symmetric, we can aow pipeined bushy query evauation pans.

7 The GetNext method encapsuates the rank-join agorithm and is given in Tabe 2. The agorithm maintains a threshod vaue that gives an upper-bound of the score of a join combinations not yet seen. To compute the threshod, the agorithm remembers the two top scores and the two bottom scores (ast scores seen) of its inputs. These are the variabes L top, R top, L bottom and R bottom, respectivey. L bottom and R bottom are continuousy updated as we retrieve new tupes from the input reations. At any time during execution, the threshod upper-bound vaue (T ) is computed as the maximum of f(l top, R bottom ) and f(l bottom, R top ). The agorithm starts by checking if the priority queue hods any join resuts. If exists, the score of the top join resut is checked against the computed threshod. A join resut is reported as the next Get- Next answer if the join resut has a combined score greater than or equa the threshod vaue. Otherwise, the agorithm continues by reading tupes from the eft and right inputs and performs a symmetric hash join to generate new join resuts. For each new join resut, the combined score is obtained and the join resut is inserted in the priority queue. In each step, the agorithm decides which input to po. This gives the fexibiity of optimizing the operator to get faster resuts depending on the joined data. A straight forward strategy is to switch between eft and right input at each step. 5.2 Loca Ranking in Impementing the rank-join agorithm as a binary pipeined query operator raises severa issues. We summarize the differences between and the ogica rank-join agorithm as foows: The tota space required by is the sum of two hash tabes and the priority queue. In a system that supports symmetrica hash join, the extra space required is ony the size of the priority queue of join combinations. As shown in Section 4.2, in the proposed rank-join agorithm (with a inputs processed together), the queue buffer is bounded by k, the maximum number of ranked join resuts that the user asks for. In this case, the priority queue wi hod ony the top-k join resuts. Unfortunatey, in the impementation of the agorithm as a pipeined query operator, we can ony bound the queue buffer of the top operator since we do not know in advance how many partia join resuts wi be pued from the ower-eve operators. The effect of pipeining on the performance is addressed in the experiments in Section 7. Reaizing the agorithm in a pipeine introduces a computationa overhead as the number of pipeine stages increases. To iustrate this probem, we GetNext() output : Next ranked join resut. begin if (Q is not empty) tupe = Q.Top; if (tupe.score T) return tupe; Loop Determine next input to access, I; (Section 5.3) tupe= I.GetNext(); if (I firsttupe) I top = tupe.score; I firsttupe = fase; I bottom = tupe.score; T = MAX(f(L top, R bottom ), f(l bottom, R top )); insert tupe in I Hash tabe; probe the other hash tabe with tupe; For each vaid join combination Compute the join resut score using f; Insert the join resut in Q; if (Q is not empty) tupe = Q.Top; if (tupe.score T) break oop; End Loop; Remove tupe from Q; return tupe; end Tabe 2: The GetNext operation. eaborate on how works in a pipeine of three input streams, say L 1, L 2 and L 3. When the top operator, OP 1, is caed for the next top ranked join resut, severa GetNext cas from the eft and right inputs are invoked. According to the agorithm, described in Tabe 2, at each step, OP 1 gets the next tupe from its eft and right inputs. Hence, OP 2 wi be required to deiver as many top partia join resuts of L 2 and L 3 as the number of objects retrieved by L 1. These excessive cas to the ranking agorithm in OP 2 resut in retrieving more objects from L 2 and L 3 than necessary, and accordingy arger queue sizes and more database accesses. We ca this probem the Loca Ranking probem. Soving The Loca Ranking Probem Another version of rippe join is the bocked rippe join [11]. At each step, the agorithm retrieves a new bock of one reation, scans a the od tupes of the other reation, and joins each tupe in the new bock with the corresponding tupes there. We utiize this idea to sove the oca ranking probem by unbaancing the retrieva rate of the inputs. We issue ess expensive GetNext cas to the input with more operators in its subtree of the query pan. For exampe, in a eftdeep query execution pan, for each p tupes accessed

8 from the right input, one tupe is accessed from the eft input. The idea is to have ess expensive GetNext cas to the eft chid, which is aso an operator. This strategy is anaogous to the bock rippe join agorithm, having the eft chid as an outer and the right chid as inner with a bock of size p. Using different depths in the input streams does not vioate the correctness of the agorithm, but wi have a major effect on the performance. This optimization significanty enhances the performance of the operator as wi be demonstrated in Section 7. Through the rest of this paper, we ca p the baancing factor. Choosing the right vaue for p is a design decision and depends on the generated query pan, but a good choice of p boosts the performance of p=1 (a) p= p= (b) Figure 6: The effect of appying the heuristic to sove the oca ranking probem in. For exampe, in a typica query with three ranked inputs, we compare between the tota number of accessed tupes by the operator before and after appying the heuristic. Figure 6 shows the number of retrieved tupes for each case. In the pan in Figure 6 (a), p is set to 1 for both operators. This query pipeine is appied on rea data to retrieve the top 50 join resuts. The top operator retrieves 328 tupes from both inputs, hence the top 328 partia join resuts are requested from the chid operator. The chid operator has to retrieve 577 tupes from each of its inputs, for a tota of 1482 tupes. In the pan in Figure 6 (b), p is set to 2 for the top operator. Whie retrieving the same answers, the tota number of tupes retrieved is 994 tupes, which is much ess than that of the before appying the heuristic, since the top operator requested ony 102 tupes from its eft chid. 5.3 : -Guided Join Strategy p=2 328 As discussed in Section 4.3, the way the agorithm schedues the next input to be poed can affect the operator response time significanty. One way is to switch between the two inputs at each step. However, this baanced strategy may not be the optima. Consider the two reations L and R to be rank-joined. The scores from L are 100, 50, 25, whie the scores from R are 10, 9, 8, 5,.... After 6 steps using a baanced strategy (three tupes from each input) we wi have the threshod of max(108, 35) = 108. On the other hand, favoring R by retrieving more tupes from R than L (four tupes from R and two tupes from L) wi give a threshod of max(105, 60) = 105. One heuristic is to try to narrow the gap between the two terms in computing the threshod vaue. Reca that the threshod is computed as the maximum between two virtua scores: T 1 = f(l top, R bottom ) and T 2 = f(l bottom, R top ), where f is the ranking function. If T 1 > T 2 more inputs shoud be retrieved from R to reduce the vaue of T 1 and hence the vaue of the threshod, eading to possibe faster reporting of ranked join resuts. This heuristic wi cause the join strategy to adaptivey switch between the hash join and nested-oops join strategies. Consider the previous exampe, since T 1 > T 2, more tupes wi be retrieved from R ti the end of that reation. In this case, L top can be reduced to 50. In fact, because a the scores in L are significanty higher than R, the strategy wi behave exacty ike a nested-oops join. On the other extreme, if the scores from both reations are cose, the strategy wi behave as a symmetric hash join with equa retrieva rate. Between the two extremes, the strategy wi gracefuy switch between nested-oops join and hash join to reduce the threshod vaue as quicky as possibe. Of course, this heuristic does not consider the I/O and memory requirements that may prefer one strategy on the other. In the experimenta evauation of our approach, discussed in Section 7, we impement the new join strategy using the operator. We ca the enhanced operator. shows better performance than those of other rank-join operators incuding the origina. 5.4 An Adaptive Join Strategy When inputs are from externa sources, one of the inputs may sta for some time. An adaptive join agorithm makes use of the tupes retrieved from the other input to produce vaid join resuts. This processing environment is common in appications that dea with ranking, e.g., a mediator over web-accessibe sources and distributed mutimedia repositories. In these variabe environments, the join strategy of the rank-join operators may use input avaiabiity as a guide instead of the aforementioned score-guided strategy. If both inputs are avaiabe, the operator may choose the next input to process based on the retrieved scores. Otherwise, the avaiabe input is processed. can be easiy adapted to use XJoin [18]. XJoin is a practica adaptive version of the symmetric hash join operator. The same GetNext interface wi be used with the ony change that the next input to po is determined by input avaiabiity and rate. The adaptive version of wi inherit the adaptabiity advantage of the underying XJoin strategy with the

9 added feature of supporting top-k join queries over externa sources. 6 Generaizing Rank-Join to Expoit Random Access Capabiities The new rank-join agorithm and query operators assume ony sorted access to the input. Random access to some of these inputs is possibe when indexes exist. Making use of these indexes may give better performance depending on the type of the index and the seectivity of the join operation. We woud ike to give the optimizer the freedom to choose whether to use indexes given the necessary cost parameters. In this section, we generaize the rank-join agorithm to make use of the random access capabiities of the input reations. The main advantage to using random access is to further reduce the upper-bound of the score of unseen join combinations, and hence being abe to report the top-k join resuts earier. For simpicity, we present the agorithm by generaizing the operator to expoit the indexes avaiabe on the join coumns of the ranked input reations. Consider two reations L and R, where both L and R support sorted access to their tupes. Depending on index existence, we have two possibe cases. The first case is when we have an index on ony one of the two inputs, e.g., R. Upon receiving a tupe from L, the tupe is first inserted in L s hash tabe and is used to probe the R index. This version can be viewed as a hybrid between hash join and index nested-oops join. The second case is when we have an index on each of the two inputs. Upon receiving a tupe from L(R), the tupe is used to probe the index of R(L). In this case, there is no need to buid hash tabes. On-the-fy Dupicate Eimination The generaization, as presented, may cause dupicate join resuts to be reported. We eiminate the dupicates on-thefy by checking the combined score of the join resut against the upper-bound of the scores of join resuts not yet produced. Consider the two reations L and R with an index on the join coumn of R. A new tupe from L, with score L bottom, is used to probe R s index and generate a vaid combinations. A new tupe from R, with score R bottom, is used to probe the L s hash tabe of a seen tupes from L. A key observation is that any join resut, not yet produced, cannot have a combined score greater than U = f(l bottom, R bottom ). Notice that L bottom is an upper-bound of a the scores from L not yet seen. A join combinations with scores greater than U were previousy generated by probing R s index. Hence, A dupicate tupe can be detected and eiminated on-the-fy if it has a combined score greater than U. A simiar argument hods for the case when both L and R have indexes on the join coumns. One specia case is when the two new tupes from L and R can join. In this case, ony one of them is used to probe the other reation. Faster Termination Athough index probing ooks simiar to hash probing in the origina agorithm in Tabe 2, it has a significant effect on the threshod vaues. The reason is that since the index contains a the tupes from the indexed reation (e.g., L), the tupe that probes the index from the other reation (e.g., R) cannot contribute to more join combinations. Consequenty, the top vaue of Reation R shoud be decreased to the score of the next tupe. For exampe, for the two ranked reations L and R in Figure 3, assume that reation R has an index on the join coumn to be expoited by the agorithm. In the first step of the agorithm, the first tupe from L is retrieved:(1, 1, 5). We use this tupe to probe the index of R, the resuting join combination is [(1, 1, 5), (2, 1, 4)]. Since the tupe from L cannot contribute to other join combinations, we reduce the vaue L top to be that of the next tupe (2, 2, 4), i.e., 4. In this case we aways have L top = L bottom which may reduce the threshod vaue T = max(l top + R bottom, L bottom + R top ). Note that if no indexes exists, the agorithm behaves exacty ike the origina agorithm. 7 Performance Evauation In this section, we compare the two rank-join operators, and introduced in Section 5, with another rank-join operator based on the J agorithm. The experiments are based on our research patform for a compete video database management system (VDBMS) running on a Sun Enterprise 450 with 4 UtraSparc-II processors running SunOS 5.6 operating system. The research patform is based on PREDATOR [17], the object reationa database system from Corne University. The database tabes have the schema (Id, JC,, Other Attributes). Each tabe is accessed through a sorted access pan and tupes are retrieved in a descending order of the attribute. JC is the join coumn (not a key) having D distinct vaues. We use a simpe ranking query that joins four tabes on the non-key attribute JC and retrieves the join resuts ordered on a simpe function. The function combines individua scores which in this case a weighted sum of the scores (w i is the weight associated with input i). Ony the top k resuts are retrieved by the query. The foowing is a SQL-ike form of the query: Q: SELECT T1.id, T2.id, T3.id, T4.id FROM T1, T2, T3, T4 WHERE T1.JC=T2.JC and T2.JC=T3.JC and T3.JC=T4.JC ORDER BY w 1*T1. + w 2*T2. + w 3*T3. + w 4*T4. STOP AFTER k;

10 One pipeined execution pan for the query Q is the eft-deep pan, Pan A, given in Figure 7. We imit the number of reported answers to k by appying the Stop- After query operator [3, 4]. The operator is impemented in the prototype as a physica query operator Scan-Stop, a straightforward impementation of Stop- After and appears on top of the query pan. Scan-Stop does not perform any ordering on its input. Scan Stop(k) RANK JOIN w1*t1.+w2*t2.+w3*t3.+w4*t4. RANK JOIN w1*t1.+w2*t2.+w3*t3. T4 RANK JOIN w1*t1.+w2*t2. T1 T3 T2 Figure 7: Pan A: A eft-deep execution pan for Q. 7.1 A Pipeined Bushy Tree Pan A is a typica pipeined execution pan in current query optimizers. Pan B is a bushy execution pan given in Figure 8. Note that bushy pans are not pipeined in current query processors because of the current join impementations. Because rank-join is a symmetric operation, a bushy execution pan can aso be pipeined. The optimizer chooses between these pans depending on the associated cost estimates. RANK JOIN w1*t1.+w2*t2. T1 RANK JOIN w1*t1.+w2*t2.+w3*t3.+w4*t4. T2 Scan Stop(k) RANK JOIN w3*t3.+w4*t4. T3 T4 Figure 8: Pan B: A bushy execution pan for Q. Pan B does not suffer from the oca ranking probem, described in Section 5.2, because each operator has amost the same cost for accessing both of its inputs (same number of pan eves). However, having arge variance of the score vaues between inputs, retrieving more inputs from one side may resut in a faster termination. This is a typica case where the operator can perform better, because uses input scores to guide the rate at which it retrieves tupes from each input. 7.2 Comparing the Rank-Join Operators In this section, we evauate the performance of the introduced operators by comparing them with each other and with a rank-join operator based on the J agorithm [14]. We imit our presentation to comparing three rank-join operators: the basic operator, the operator and the J operator. appies the basic symmetric hash join strategy; at each step one tupe is retrieved from each input. The oca ranking minimization heuristic, proposed in Section 5.2, is appied in. The operator uses the score-guided strategy, proposed in Section 5.3, to determine the rate at which it retrieves tupes from both inputs. The J operator is an impementation of the J agorithm. We do not compare with the naïve approach of joining the inputs then sorting since a the rank-join agorithms give a better performance by orders of magnitude. We choose four performance metrics: the tota time to retrieve k ranked resuts, the tota number of accessed disk pages, the maximum queue size, and the tota occupied space. In the foowing experiments, we use Pan A as the execution pan for Q. Using Pan B gave simiar performance resuts. Changing the number of required answers In this experiment, we vary the number of required answers, k, from 5 to 100 whie fixing the join seectivity to 0.2%. Figure 9 (a) compares the tota time to evauate the query. and show a faster execution by an order of magnitude for arge vaues of k. The high CPU compexity of the J agorithm is because it retrieves one join combination in each step. In each step, J tries to determine the next optima point to visit in the Cartesian space. Since both and use symmetric hash join to produce vaid join combinations, more join combinations are ranked at each step. Figure 9 (b) compares the number of accessed disk pages. The three agorithms have a comparabe performance in terms of the number of pages retrieved. J and achieve better performance because retrieving a new tupe is guided by the score of the inputs, which makes both agorithms retrieve ony the tupes that makes significant decrease in the threshod vaue and hence ess I/O. Figure 9 (c) compares the number of maintained buffer space. and have ow space overhead because they use the buffer ony for ranking the join combinations, whie J maintains a the retrieved tupes in its buffer. Had we aso incuded the space of the hash tabes, J wi have a ower overa space requirement. In most practica systems the hash space is aready reserved for hash join operations. Hence, the space overhead is ony the buffer needed for ranking. Changing the join seectivity In this experiment, we fix the vaue of k to 50 and vary the join seectivity

11 Time (seconds) * Number of Accessed Pages * Max. Queue Size (tupes) * K K K (a) (b) (c) Figure 9: Comparing, J and for m = 4 and seectivity = 0.2% Time (seconds) * Number of Accessed Pages * Max. Queue Size (tupes) * Join Seectivity Join Seectivity Join Seectivity (a) (b) (c) Figure 10: The effect of seectivity on, J and for m = 4 and K = Time (seconds) * Number of Accessed Pages * Max. Queue Size (tupes) * Pan Height (m) Pan Height (m) Pan Height (m) (a) (b) (c) Figure 11: The effect of pipeining on, J and for seectivity 0.2% and K = 50. from 0.12% to 2%. Figure 10 (a) compares the tota time to report 50 ranked resuts, whie Figures 10 (b) and 10 (c) compare the number of accessed disk pages and the extra space overhead, respectivey. For a seectivity vaues, shows the best performance. J has a better performance than for high seectivity vaues whie performs better for ow seectivity vaues. The reason is that combines the advantages of J and. Whie uses a score-guided strategy to navigate in the Cartesian space for a faster termination (simiar to J ), it aso uses the power of producing fast join resuts by using the symmetric hash join technique (simiar to ). The effect of pipeining In this experiment, we evauate the scaabiity of the rank-join operators. We

12 vary the number of join inputs, m, from 3 to 6 and fix k = 50 and the join seectivity to 0.2%. Figure 11 (a) gives the effect of pipeining on the tota query time. and show much better scaabiity than that of J by orders of magnitude. The CPU compexity of J increases significanty as m increases. On the other hand, J and show better performance in terms of the number of accessed pages compare to (Figure 11 (b)), because of the scoreguided strategy they are using. is the most scaabe in terms of the space overhead as shown in Figure 11 (c). 8 Concusion In this paper, we address supporting top-k join queries in practica reationa query processors. We introduce a new rank-join agorithm that is independent of the join strategy, aong with its correctness proof. The proposed rank-join agorithm makes use of the ranking on the input reations to produce ranked join resuts on a combined score. The ranking is performed progressivey during the join and hence, there is no need for a bocking sort operation after join. We present a physica query operator to impement rank-join based on rippe join; the hash rank join (). We propose a new join strategy that is guided by the input score vaues. We appy the new strategy on the origina agorithm and ca the new operator. We address expoiting avaiabe indexes on the join coumns. We propose a genera rank-join agorithm that utiizes these indexes for faster termination of the ranking process. We experimentay evauate the proposed join operators and compare their performance with a recent agorithm to join ranked inputs. We conduct severa experiments varying the number of required answers, the join seectivity, and the number of inputs in the pipeine. The experiments prove the concept and show a significant performance enhancement, especiay for ow vaues of join seectivity. References [1] Nicoas Bruno, Surajit Chaudhuri, and Luis Gravano. Top-k seection queries over reationa databases: Mapping strategies and performance evauation. TODS, 27(2), [2] Nicoas Bruno, Luis Gravano, and Ameie Marian. Evauating top-k queries over web-accessibe databases. In ICDE, [3] Michae J. Carey and Donad Kossmann. On saying Enough aready! in SQL. In SIGMOD, Tucson, Arizona, May [4] Michae J. Carey and Donad Kossmann. Reducing the braking distance of an SQL query engine. In VLDB, New York, August, [5] Kevin Chen-Chuan Chang and Seung won Hwang. Minima probing: supporting expensive predicates for top-k queries. In SIGMOD, [6] Cynthia Dwork, S. Ravi Kumar, Moni Naor, and D. Sivakumar. Rank aggregation methods for the web. In Word Wide Web, [7] Ronad Fagin. Combining fuzzy information from mutipe systems. Journa of Computer and System Sciences (JCSS), 58(1), Feb [8] Ronad Fagin, Amnon Lotem, and Moni Naor. Optima aggregation agorithms for middeware. In PODS, Santa Barbara, Caifornia, May [9] Urich Güntzer, Wof-Tio Bake, and Werner Kießing. Optimizing muti-feature queries for image databases. In VLDB, September 10 14, Cairo, Egypt, [10] Urich Güntzer, Wof-Tio Bake, and Werner Kießing. Towards efficient muti-feature queries in heterogeneous environments. In ITCC, [11] Peter J. Haas and Joseph M. Heerstein. Rippe joins for onine aggregation. In SIGMOD, Phiadephia, Pennsyvania, USA, june [12] W. Hong and M. Stonebraker. Optimization of parae query execution pans in XPRS. Distributed and Parae Databases, 1(1), Jan [13] Ihab F. Iyas, Waid G. Aref, and Ahmed K. Emagarmid. Joining ranked inputs in practice. In VLDB, Hong Kong, China, [14] Aposto Natsev, Yuan-Chi Chang, John R. Smith, Chung-Sheng Li, and Jeffrey Scott Vitter. Supporting incrementa join queries on ranked inputs. In VLDB, Rome, Itay, [15] Surya Nepa and M. V. Ramakrishna. Query processing issues in image (mutimedia) databases. In ICDE, Sydney, Austriaia, [16] P. G. Seinger, M. M. Astrahan, D. D. Chamberin, R. A. Lorie, and T. G. Price. Access path eection in a reationa database management system. In SIGMOD, [17] Praveen Seshadri and Mark Paskin. Predator: An or-dbms with enhanced data types. In SIGMOD, May 13-15, Tucson, Arizona, USA, [18] T. Urhan and M. J. Frankin. XJoin: A reactiveyschedued pipeined join operator. IEEE Data Engineering Buetin, 23(2), February [19] Annita N. Wischut and Peter M. G. Apers. Datafow query execution in a parae mainmemory environment. Distributed and Parae Databases, 1(1), 1993.