Competitive Online Comparison for Parallel Joins

151

XVII Simpósio Brasileiro de Banco de Dados

Competitive Online Comparison for Parallel Joins

Sergio Lifschitz�and Michelle Sa

Departamento de Informatica

Pontifıcia Universidade Catolica do Rio de Janeiro (PUC-Rio)

Rua Marques de Sao Vicente 225

Rio de Janeiro, RJ 22453-900 - Brasil

Phone: (55)(21) 31141500 ext. 4346 Fax: (55)(21) 3114 1530

e-mail:�sergio,michelle � @inf.puc-rio.br

Abstract

Different approaches for the parallel execution of the relational join operator were proposed in

the literature. Implementations were developed in order to compare and evaluate these strategies in

a parallel environment. However, there is no consensus concerning the behavior of these strategies,

which may take into account load balancing issues, with respect to several real conditions where

these strategies are executed. This paper presents an approach based on the online algorithms

theory point of view. We use competitive analysis to evaluate and compare the proposed parallel

join methods with the optimal (offline) strategy. Instead of the usual analytical study, common to the

online context, we illustrate our ideas presenting an actual implementation to evaluate an online

parallel join method with respect to workload distribution. As adversaries, we consider a variation

in the number of parallel processors available and the skew degree on join attribute data values.

1 Introduction

Multiprocessor systems have been proposed for large, complex and usually slow computationaltasks. For these systems, a possible strategy could be to split a task in a number of parts and runthese parts in parallel. This way we expect a reduction in the task execution time, somewhatproportionally to the number of processing sites considered. These ideas happen not only inthe general computer science area of algorithms but also in the database management systems(DBMS) context.

As join processing is one of the most complex operations in DBMSs, it is natural to studyhow to deal with the join operator execution in parallel. Many parallel join approaches havebeen proposed [20, 12, 7, 17, 13, 15].�Supported in part by CNPq under grant 300048/94-7.

152


In order to compare the existing strategies in practice, a number of parallel evaluation envi-ronments were developed and implemented. While the focus in some cases was to compare agiven and single strategy with others (e.g., [7, 17]), for others the idea was to investigate alreadyexisting proposals (e.g., [20, 11]). Due to the fact that each researcher or research group usedistinct hardware and software platforms, the actual performance comparison is very difficult[9].

The work presented in [20] was the first one to evaluate the most popular algorithms at thattime. However, there is still no consensus with respect to the behavior evaluation of the mul-tiple parallel join strategies and all different real conditions these strategies are to be executed.Besides, the load-balancing problem must be considered and some strategies simply avoid it,what makes the comparison even more complicated.

The goal of this work is to study the parallel join performance evaluation problem in adifferent and more general way. Indeed, we propose to use the online algorithms theory, throughcompetitive analysis [1, 2], to understand and compare the existing parallel join methods andtheir performance with respect to workload distribution.

The online context is directly related to data stream systems, a new research topic for thedatabase community (see [3] for an overview). In this case there are transient data streamsthat cannot be loaded directly into a conventional DBMSs, since these are not designed forunpredictable and continuous arrival of data.

In our paper we consider a similar situation for dealing with parallel joins. These have beenalready studied as an online problem [21]. The use of competitive analysis in this context wasfirst introduced in [14]. Besides extending and exploring further this idea here, we have alsoimplemented it and some experimental comparisons are made in order to show the efficacy ofour proposal.

We have considered competitiveness of an online parallel join strategy that take into accountload balancing issues and compare it to an optimal (offline) strategy. The latter correspondsto the execution of the parallel join with complete knowledge of the relevant information forload distribution. The parallel join strategy considered here is based on an implementation ofthe VAST-PJ architecture [13], a demand-driven distributed tasks approach that tries to avoiduneven workloads preventively by controlling tasks sizes and the speed of processing nodes.

The remainder of the paper is organized as follows: in the next Section we discuss theparallel join performance comparison problem and give an overview of the online algorithmsand competitive analysis context. Then, in Section 3, we propose to view the parallel joinevaluation as an online problem and list the main parameters that must be considered to makethe comparison. In Section 4 we illustrate the use of the proposed methodology in practice,giving a sample of all experimental results that we have obtained. We conclude in Section 5enumerating the expected contributions and some future work.

153


2 Parallel Joins and Online Problems

We present here an overview of the main approaches for processing relational joins in parallel.Particularly, we briefly discuss the data skew problem and its effects with respect to balancingthe load during parallel join evaluation. Then, we describe online algorithms and competitiveanalysis, explaining the idea of comparing parallel join strategies and load distribution withinthe online context. We will comment also previous works on comparing parallel joins as amotivation for the methodology proposed here.

Parallel Join Evaluation and Comparison

When the relational join operator has to be evaluated, we can obtain considerable performanceimprovements by executing it in a parallel environment. If there are � processors, these willcooperate to get, if possible, the result of the evaluation in a time proportional to � . In general,join processing involves three main steps [17]:

(i) task decomposition into � tasks - usually �� ;

(ii) assignment of these � tasks to the � processors; and

(iii) partial results assembly from all the processors.

If one wants to join two relations, the parallel execution would join sub-relations that weregenerated by an horizontal decomposition of both input relations [6].

The parallel response time corresponds to the time the slowest processing node ends runningits tasks. Sometimes there is also a need to build up the global solution. Thus, in order tominimize the response time, we have to distribute tasks in such a way that each processing nodegets approximately the same number of tasks/processing units. This way we obtain an evenworkload balance and we can make full use of the available computational resources. However,in a multi-user/transaction environment, this is not enough since the concurrency level at eachprocessor may not be the same, what can be harmful to the global parallel time.

Another problem is related to the data skew phenomenon, which can appear in many levels.The basic situation is the non-uniformity of the join attribute values. When this happens, thetasks subsets generated may have different sizes and the work assigned to each processor maybe different. So, this has led to multiple proposals that started to take into account this skewproblem [12, 20]. In [22] this data skew concept is formalized and a distinction between intrin-sic skew - related to the input data - and partitioning skew, that appears due to task spliting andprocessing, is given. It becomes clear that an even evaluation of the join operator is not simplydue to an equal initial data distribution. Furthermore, the goal is to reduce the parallel executiontime, not to balance the load. That is, a perfect load balanced may not correspond to the bestparallel execution time [16].

154


In spite of all different parallel join methodologies, whether or not considering load balanc-ing issues, so far there is no consensus about an approach for comparing strategies or algorithmsand, consequently, nothing can be said considering the choice an DBMS optimizer would makein practice [14]. It is important to remember at this point that for single processor join methods,it is possible to decide upon which would be the best one for a given data set, using the metadataand join selectivity.

In order to compare parallel join strategies, the work in [20] has tried to compare the mostcommon approaches at that moment in a single hardware and software environment. The prob-lem here is that it could not be considered a non-biased environment and also, many parallelstrategies were developed for specific conditions, making comparisons virtually impossible.While some use specific hardware components, others use software for particular applications.In [11] this problem of comparing distinct strategies, which were originally proposed for dif-ferent environments, was also considered. The authors implemented some of the most knownparallel methods using again specific parallel hardware. There is also the problem of definingappropriate parameters to be used in the comparisons. In [5], the authors define a list of relevantfactors that must be evaluated completely if one wants to discuss parallel join performances.But no actual implementation was done.

Online algorithms and Competitive Analysis

When we study algorithms for a particular application, it is always considered that we have thecomplete knowledge of the input data. This assumption is not always true in practice and thereare many problems that are said to be ”online”, that is, input data is only partially available, noteverything is known from the beginning. An online algorithm must define which steps to gothrough to solve the problem without knowing the characteristics of the complete data set.

Therefore, an online algorithm may be viewed as the one that gets input information incre-mentally, a small part at a time. The algorithm must generate a partial output even if it doesnot know what is the next part to evaluate. There are many well known online problems, likethe pagination (or buffer replacement policy) problem [8], that is related to the database con-text. The available storage is divided into a fast (but small) first level memory (e.g., RAM) anda relatively slow but large second level memory (e.g., Hard Disk). The CPU access only thefirst level and the system must keep in this level all data needed by the applications currentlyrunning. As the hard disk contains all data, this data has to be eventually transferred to the fastmemory, when required. As not all pages can be kept in memory at the same time, there is aneed for a page replacement policy so that new pages can be placed. Usually the transfer unit iscalled a page and transfers are called paginations. The goal here is to reduce the number of datatransfers from one level to another. But this has to be done without knowing which applicationor query, over which data, will run next. So, online strategies like LRU (Least-Recently-Used),MRU (Most-Recently-Used) and FIFO (First-in-First-out) has to be chosen.

155


Formally, and briefly, an online algorithm is presented as a sequence of requests

�� where each request �� , ��! "�$# , must be answered in its sequence order. Specifically, whenthe algorithm is dealing with the %'&( *) request, it has no information at all about the nextrequest, %+&-,.) , with ,0/1 . There is a cost associated to each request being solved and the goal isto minimize the total cost corresponding to the whole sequence [2]. In the case of the paginationproblem, the requests sequence is actually a ”page requests” sequence. The cost is given by thenumber of page faults, as this is the case when pages from fast memory must be replaced withpages from slow memory.

In this paper we will study parallel joins as online problems and this will lead us to anapproach for comparing the existing parallel join methods. But first, we will introduce thenotion of competitive analysis.

In [2] the competitive analysis is defined as the comparison between an online algorithm and another algorithm 243"5 known as optimal or offline. An offline algorithm is the one thatknows the complete sequence of input data/requests and is, then, able to produce an optimal(less costly) output. An offline algorithm is always considered optimal. Thus, when an onlinealgorithm gets closer to an optimal solution, it is called more competitive. An offline algorithmfor the pagination problem is the one that knows in advance all page requests and is able todefine which pages will leave the fast memory in order to minimize page faults.

Formally speaking, let 687 and 6�9.:�; be, respectively, the costs associated to algorithms (online) and 2<3=5 (offline), for processing an input sequence . The algorithm is calledc-competitive if and only if there exists a constant > for which

6�7�� 6@?�6�9.:A;CBD%�)FEG>��for every input sequence . The 6 factor is called the competitive ratio [1]. Again in thepagination problem, it was shown in [8] that the FIFO and LRU pagination strategies are H -competitive, where H is the number of fast memory pages.

The competitiveness of an online algorithm is define with respect to an adversary. Thiscan be seen as another algorithm that builds up an input sequence for the online algorithm.Basically, the idea behind adversaries is to create different situations for the online algorithm soto test its ability in dealing with unexpected requests.

3 Online View of Parallel Joins

The parallel join operation may be seen as a set of multiple tasks to be executed concurrently,where each task corresponds, for example, to the comparison of different tuple subsets of thetwo operand relations. Therefore, we have an independent tasks processing. One way to gener-ate this task set is tuple splitting with respect to join attribute values [20]. When the initial task

156


set is ready, the parallel join strategy must allocate each task or a group of tasks to the availableprocessors, following some distribution rule.

The online characteristics of the parallel join operation is due to the fact that the task divisionand its subsequent clustering must be done with no exact knowledge of all the data needed tobuild an evenly balanced task set. It is important to observe that most previous works alreadydeal with the parallel join in an online manner. Indeed, the most known methods first partitionand then divide tasks among processors. This approach is acceptable to balance the load at eachprocessor and obtain an even number of comparisons at each node, since relation cardinalitiesare given. The problem that remains is that the tuples generation (output load) is not considered,as join selectivity and external application loads are often not known in advance when thepartitioning phase is executed.

Thus, an online algorithm for the parallel join taking into account workload balancing issueswill try to assign each task to a given processor using all input relation information that arepartially available. On the other hand, an offline algorithm is the one that generates the taskset with the exact information about relevant parameters in order to obtain an optimal loaddistribution among processing nodes.

In the online case, the missing information needed to build a good task set is due to:

(a) the lack of precise join selectivity estimation;

(b) incomplete knowledge about the initial task set defined by the chosen parallel strategy;and

(c) the presence of external workloads - other DBMS transactions or even system processes.

All of these are potential problems for the online algorithm and its decision making on taskspartitioning and grouping, leading to non-optimal situations. This is further explained in [19].

VAST-PJ Architecture

In order to show the feasibility of a competitive online comparison approach for parallel joins,we propose to use these ideas to evaluate the load distribution performance of an online paralleljoin strategy, namely, VAST-PJ (VAriable Sized Tasks - Parallel Join) [13]. Actually, VAST-PJ is an architecture since it is a strategy that permits multiple components’ implementations.VAST-PJ is a dose-driven strategy, e.g., a parallel processors demand-driven approach wheretasks may vary in their sizes, in order to deal with load unbalancing dynamically and in apreventive fashion.

We can briefly explain the VAST-PJ architecture through its 3 main modules: the ExecutionManager, the Tasks Manager and the Local Join components. The first one is the controller andruns in the coordinating processing node. It is responsible for choosing which buckets will beevaluated at each node such that no node is overloaded. The Execution Manager may choose

157


one or more buckets to build a task for a demanding node that is idle. It may as well break tasksinto smaller subtasks. The Task Manager is the local coordinator of all processing nodes andis responsible for bucket communication, that is, sending buckets to be processed at a differentnode and receiving buckets to be evaluated locally. Last but not least, the Local Join componentwill compute the chosen buckets at a given site. This module makes use of a local DBMS toevaluate the buckets efficiently.

A critical point here is to estimate the task sizes that will be distributed to the processingnodes. In [9], the task is determined by the number of buckets to be processed by a task. Anotherpossibility is to consider the number of I/O pages, the initial join selectivity estimated, amongothers. In this paper we will use a cost model that is based in (i) the number of tuples that areread; (ii) the number of tuples produced by the join; (iii) the number of comparisons and (iv) thenumber of tuples received to complete a join bucket. Details of this cost model may be foundin [19].

Adversaries and Evaluation Parameters

The competitive analysis is based on the comparison of the solution produced by online andoffline algorithms. Thus, it is important to define a metric for quality of solutions. In [14], therewere basically 3 parameters to be considered: a tuple comparison ratio - the number of outputtuples produced with respect to the number of comparisons -, the workload difference - betweenthe most and the less overloaded processors - and the mean tuple transfer, which is related toI/O cost.

In this paper we will evaluate the workload at each node in a slightly different way. Wewill take into account (i) the tuple comparison rate; (ii) the tuples fetched rate; and (iii) theproduced (output) tuples rate. Even if these seem to be quite simple, they can get enoughrelevant information in a database system context. We will be able, as shown in Section 4, tocompare the load balancing efficacy of both online and offline (optimal) strategies.

With these 3 values, we will compute the differences between online and offline strategiesand their efficacy in balancing the load. The values will be obtained dividing the total numberof tuples read from disk or written to disk on all nodes. This way we obtain a percentage ofthe total number of tuples involved in I/O at each processor. For the comparison ratio, we willcount the number of comparisons actually done with the total number of comparisons neededto execute the join. We will compute the maximum difference between the value obtained inpractice and the value given by the offline strategy.

As adversaries, we will consider some situations that may complicate the online algorithmtask to evenly distribute to the processing nodes buckets to be processed. Ideally we have tobuild a number of real conditions over input data and the chosen environment.

With respect to the operand relations, we will produce uniform and non-uniform join at-tribute values, using a Zipf-based formula [23]:

158


IKJLIMON�P ?�QSRTVU � �TXW P �

where Y is the number of distinct values and Z\[ is a distribution factor. When ZC[@�]� , datadistribution follows the Zipf law (a non-uniform distribution close to ^ _ � function) and whenZa[��cb , we get the uniform data distribution. As most previous practical works in this area,we have chosen this Zipf function to define possible data adversaries because the distributionsit generates are often found in real data sets.

We will also consider another kind of adversary based on the environment conditions,mainly heterogeneity and processors concurrency. The first one may be used by an adversaryto configure a parallel machine with different processor capacities. Concurrency can be used toreduce power of a processor in a given moment, to simulate external load to this node.

4 Case Study

We will describe here some experimental results with the VAST-PJ architecture. Again, due tospace limitations, we will only briefly describe the main results. It is worth noting that our focushere is not the execution time of the parallel join. Rather, we will evaluate the above mentionedparameters and examine the VAST-PJ efficacy with respect to load balancing. Anyhow, ourgeneral goal remains the same: we propose the use of competitive online analysis to study oneor more aspects, analytically and in practice, for comparing parallel join strategies.

Test Environment

We have worked out the implementations using ARCOJP, an architecture for (practical) com-parison of parallel joins proposed and detailed in [9]. This architecture uses components suchas the Minibase relational DBMS [18] to execute basic database operations. Thus, it enables adirect implementation of VAST-PJ, with a straightforward configuration of the tasks managerfollowing the cost model proposed here.

The ARCOJP architecture is shown in Figure 1. It intends to give a high-level of abstractionto a comparison environment, using off-the-shelf components and a real DBMS for dealingwith data. The architecture was built in layers to enable independent communication and datamanagement, besides distinct physical configurations for the parallel environment.

ARCOJP runs in a 32 PC cluster, with Linux RedHat 5.2 (Apollo) 2.0.36 kernel version. Allcode was done in C++, on a GNU gcc compiler v2.9 and debugger gdb. The communicationwas realized using LAM-MPI v6.3b. Each node is a Pentium II 400MHz IBM PC 300GL, eachwith own 6.3GB disk, connected through a Ethernet network via a IBM8274 switch, whichpermits 32 segments at 10Mbps. We have used only up to 8 processors in our experiments sincethe results obtained with these were good enough to clarify our contributions.

159


COMMUNICATOR

DATA MANAGER

Execution Manager

Task Manager

Relation Ri Relation Si

Processing Nodes Layer

Local Join Manager

Figure 1: The ARCOJP Architecture

0

2000

4000

6000

8000

10000

12000

1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97

Buckets

d efg hijkl emn ho

S.C10

p�q r's

S.C0

R.C0

Figure 2: Initial Load Distribution

160


Database size 300MB at each processing node Tuples initial distribution Round robin

Tuples per transfer 8 Local Buffer Pool 2000 pages Page size 1KB Tuple max size 1KB Tuples size 34 bytes in R

74 bytes in S

Buckets 100

Number of pages fetched per read 1

Figure 3: Test Environment Characteristics

As most joins are done with primary keys in one table and its correspondent foreign key inthe other, we have followed the same ideas presented in [11] to define the input relations. Wehave then 2 relations R and S, with the S cardinality being bigger than R’s. Table R has a tvucolumn that is its primary key and table S has also a twu column as a foreign key referencingR. In R’s txu attribute, there 50,000 distinct values and these values are distributed in columnstyu to tw�*b in S. Each of this 10 attributes were created with a 0.1 variation in the Zipf factor.Then, column tz�*b has a complete Zipf distribution while column twu has actually an uniformdistribution. Both tables have other columns that were used only to configure reasonable sizesfor tuples. While R has 50,000 tuples, S have 100,000 tuples, with all values in relevant columnsof the integer type.

In Figure 2 we show a sample of the initial tuple distribution for input tables right after itsgeneration. As explained, the t{u attributes are uniform and as long as the Zipf factor gets closerto 1, we obtain a complete Zipf distribution (attribute t@�|b of S).

Other test data are given in Figure 3, such as page and tuple sizes and the number of tuplesthat are sent at each transfer. The round-robin distribution initially considered has influencedour cost model in the estimation of task sizes. This is due to the fact that each node has in thebuckets locally stored a cardinality that is proportional to the total number of tuples divided bythe number of processors that participate in the parallel join execution.

As we have mentioned before, we have considered 3 different data adversaries (distribu-tions): uniform, complete Zipf and Zipf with factor 0.5. We have also changed the numberof available nodes: 2, 4 and 8. The experimental results are compared to the optimal (offline)values, that can be calculated by many different heuristics, considering a complete knowledgeof the whole environment and data distribution (e.g., [19, 10]).

161


474849505152

1 2processing nodes

%

%R%C%W%O

Figure 4: Uniform Distribution and 2 Processing Nodes

Experimental Results

In our evaluations, we have tried to count the workload actually distributed by the VAST-PJonline strategy and the offline corresponding values. In all figures, we show %R, %C and%W, that are respectively the percentage of tuples read, compared and written down to disk, asexplained in the last section.

Due to space limitations, we only show the results for 2 and 8 processing nodes respectivelyin Figure 4 and Figure 5. In this case, we show the results obtained for a uniform distribution.The %O value is the offline/optimal reference.

When one wants to compare the workload differences, Figure 6 give the largest differencebetween the online and offline strategies. As all previous figures can show, for a uniform distri-bution the online values for the 3 operations considered are very close to the offline values. Thenumber of processing nodes did not influence much in the results. The 1% average differencedoes not mean that the VAST-PJ execution time would be close to the optimal time. However,it is clear that our VAST-PJ implementation reaches a good load balancing.

We also show some experimental results for a Zipf distribution in the join attribute values,for 2 and 8 processing nodes. The values can be observed in Figure 7 and Figure 8.

Even if in the presence of such an adversary the difference between the online and offlineapproaches are bigger, we get a 10% average difference, which is still not much. Indeed, themaximum values were 12% for tuples compared and fetched, with a 7% difference for outputwritten-to-disk tuples.

When a complete Zipf distribution is considered, most values are concentrated in a givenvalue range and, consequently, a few buckets get most of the tuples in the input relations. Then,when a processing node gets one of these buckets, its tuple comparison ratio naturally increaseswith respect to the global value. That is why there is a bigger read percentage, increasing also

162


0

5

10

15

1 2 3 4 5 6 7 8processing nodes

%

%R%C%W%O

Figure 5: Uniform Distribution and 8 Processing Nodes

0

0.5

1

1.5

2 4 8number of processing nodes

%

%Dif C%Dif R%Dif W

Figure 6: Largest Uniform Workload Differences versus Offline

010203040506070

1 2processing nodes

%

%R%C%W%O

Figure 7: Complete Zipf Distribution and 2 Processing Nodes

163


05

10152025

1 2 3 4 5 6 7 8processing nodes

%

%R%C%W%O

Figure 8: Complete Zipf Distribution and 8 Processing Nodes

0

5

10

15

2 4 8number of processing nodes

%

%Dif C%Dif R%Dif W

Figure 9: Largest Complete Zipf Workload Differences versus Offline

the number of possible output tuples.

5 Conclusions

We have proposed in this paper to use an approach based on the online algorithms theory andcompetitive analysis to compare parallel joins. Instead of the usual analytical study, we illustrateour ideas presenting an actual implementation to evaluate an online parallel join method withrespect to workload distribution. As adversaries, we have considered a variation in the numberof parallel processors and the skew degree, based on Zipf functions, on join attribute data values.

Our main goal is to show that competitive analysis may be effectively used to compareonline parallel joins with respect to an offline (optimal) strategy. A DBMS optimizer, enablinga future choice of a best execution plan in the presence of a given adversary, could use theseresults. The efficacy of the VAST-PJ architecture (for the implemented version chosen) with

164


respect to load balancing issues is also given. Although the competitive factor cannot be inferredfrom the practical results obtained, it is possible to have a good idea of what it could be. Indeed,even for situations where the online (VAST-PJ) strategy would have trouble to balance the load,the values were close to those obtained from an offline evaluation.

We intend to continue with this evaluation for other strategies like the work that was donein [11]. This way we would have stronger results about efficacy when uneven workloads arepresent. We plan to use also some other comparison parameters. Moreover, we want to eval-uate (in a competitive analysis manner) those selectivity estimation algorithms in sequentialenvironments, being able to compare the results to the known metrics used by popular DBMSs.

Finally, we might also adopt the approach presented here to other applications that dealwith uneven workload. This is the case of genomic databases and the parallel evaluation oflocal alignment programs like BLAST [4].

References

[1] S. Albers. Competitive Online Algorithms. Optima Mathematical Programming SocietyNewsletter, 54:1–8, 1997.

[2] S. Albers and S. Leonardi. Online Algorithms. ACM Computing Surveys, 31(3):1–6, 1997.

[3] B. Babcock, S. Babu, M. Datar, R. Motwani, and J. Widom. Models and Issues in DataStream Systems. In Procs. ACM SIGMOD Conference, 2002.

[4] R.L.C. Costa and S. Lifschitz. Database Allocation Strategies for Parallel BLAST Eval-uation on Clusters. Journal of Distributed and Parallel Databases, 2002. (accepted forpublication).

[5] P. Cremonesi, E. Rosti, G. Serazzi, and E. Smirni. Performance Evaluation of ParallelSystems. Parallel Computing, 25:1677–1698, 1999.

[6] D. DeWitt and J. Gray. Parallel Database Systems: The Future of High PerformanceDatabase Systems. Communications of the ACM, 35(6):85–98, 1992.

[7] D.J. DeWitt, J.F. Naughton, D.A. Schneider, and S. Seshadri. Pratical Skew Handling inParallel Joins. In Procs. VLDB Conference, pages 27–40, 1992.

[8] A. Fiat, R.M. Karp, M. Luby, L.A. McGeoch, D.D. Sleator, and N.E. Young. Competitivepaging algorithms. Journal of Algorithms, 12:685–699, 1991.

[9] F. Freitas, S. Lifschitz, and J.A.F. Macedo. ARCOJP: An Architecture for ComparingJoins in Parallel. In Procs Brazilian Symposium on Databases (SBBD), pages 286–300,2001. (in portuguese).

165


[10] M. R. Garey and D. S. Johnson. Computers and Intractability: A Guide to the Theory ofNP-Completeness. W. H. Freeman and Company, 1979.

[11] K. A. Hua, W. Tavanapong, and Y. L. Lo. Performance of Load Balancing Techniques forJoin Operations in Shared-nothing Database Management Systems. Journal of Paralleland Distributed Computing, 56:17–46, 1999.

[12] M.S. Lakshmi and P.S. Yu. Efectiveness of Parallel Joins. IEEE Transactions on Knowl-edge and Data Engineering, 2(4):410–424, 1990.

[13] A. Lerner and S. Lifschitz. A Study of Workload Balancing Techniques on Parallel JoinAlgorithms. In Procs. Intl. Conf. on Parallel and Distributed Processing Techniques andApplications (PDPTA), pages 966–973, 1998.

[14] A. Lerner, S. Lifschitz, and M.V. Poggi. An Online Approach for Parallel Join AlgoritmsAnalysis. Technical report, Pontifıcia Universisdade Catolica do Rio de Janeiro, ComputerScience Department, MCC01, 1999.

[15] W. Li, D. Gao, and R.T. Snodgrass. Skew Handling Techniques in Sort-Merge Join. InProcs. ACM SIGMOD Conference, 2002.

[16] S. Lifschitz, A. Plastino, and C.C.C. Ribeiro. Exploring Load Balancing in Parallel Pro-cessing of Recursive Queries. In Procs. Intl. Conf. Parallel Processing LNCS 1300, pages1125–1129, 1997.

[17] H. Lu and K-L. Tan. Load-Balanced Join Processing in Shared-Nothing Systems. Journalof Parallel and Distributed Computing, 23(1):382–398, 1994.

[18] R. Ramakrishnan and J. Gehrke. Database Management Systems. McGraw-Hill, 2002.

[19] M.S. Sa. An Online Approach for Comparing Parallel Joins. Master’s thesis, PUC-RioDepartamento de Informatica, 2000. (in portuguese).

[20] D.A. Schneider and D.J. DeWitt. A Performance Evaluation of Four Parallel Join Algo-rithms in a Shared-nothing Multiprocessor Environment. In Procs ACM SIGMOD IntlConf, pages 110–121, 1989.

[21] A. Swami and H.C. Young. Online Algorithms for Handling Skew in Parallel Join. InProcs. Intl. Conference on Parallel Processing, pages 253–257, 1993.

[22] C.B. Walton, A.G. Dale, and R.M. Jenevein. A Taxonomy and Performance Model ofData Skew Effects in Parallel Joins. In Procs. VLDB Conference, pages 537–548, 1991.

[23] G. K. Zipf. Human Behavior and Principle of Least Effort: an Introduction to HumanEcology. Addison-Wesley, 1949.

Documents

Competitive Online Comparison for Parallel Joins