Excution parallle de requtes relationnelles et quilibrage de charge

Luc Bouganim
Projet Rodin - INRIA Rocquencourt 78153 Le Chesnay Cedex
* Travail effectu dans le GIE Dyade (Bull Inria)

RSUM : Lutilisation de machines parallles pour les systmes de gestion de bases de donnes constitue une solution aux besoins de performances de ces applications. Afin dexploiter le paralllisme, les requtes sont dcoupes en plusieurs tches, excutes sur plusieurs processeurs. A cet effet, le paralllisme inter-oprateurs (plusieurs oprateurs sont excuts en parallle sur plusieurs processeurs) et intra-oprateur (un oprateur est clon sur plusieurs processeurs) sont utiliss. Un des obstacles majeur lobtention de bonnes performances rside dans lquilibrage de la charge entre les diffrents processeurs. En effet, le temps de rponse dune excution parallle est gal au temps de rponse du processeur le plus charg. Une mauvaise distribution de la charge de travail peut donc entraner une chute de performance importante. Aprs une prsentation des diffrentes architectures multiprocesseurs pour les SGBD, nous exposons, les techniques mises en oeuvres pour lexcution parallle de requtes ainsi que les solutions existantes au problme de lquilibrage de charge. ABSTRACT : The use of parallel machines for database management system is the solution for high performance aplications. There are two dimensions for parallelizing queries : horizontally (i.e. intra-operator parallelism) by distributing each operator among several processors, and vertically (i.e. inter-operator parallelism) by distributing all operators of the query among several processors. However, query response time can be hurt by several barriers, the major one being poor load balancing, i.e. some processors are overloaded while some others remain idle. As the response time of a set of parallel activities is that of the longest one, this can severely degrade performance. After presenting parallel architectures for database systems, we describe technics for parallel query execution. Afterwards, we present existing solutions for load balancing. MOTS-CLS : bases de donnes, paralllisme, quilibrage de charge KEYWORD : databases, parallelism, load balancing

Lobjectif spcifique dun systme parallle de gestion de bases de donnes est de profiter au mieux des caractristiques de la machine multiprocesseur sur laquelle il sexcute. Son efficacit est directement fonction de sa rapidit traiter lensemble des transactions sappliquant sur les donnes de la base. On distingue deux types de transactions qui conduisent exploiter le paralllisme de manire diffrente. Le paralllisme interrequte vise amliorer le dbit transactionnel de transactions courtes de type OLTP (On Line Transaction Processing). Nous ne considrons pas ici cette forme de paralllisme potentiellement prsent dans les systmes de bases de donnes multi-utilisateurs. Dans le cas de transactions longues de type aide la dcision, le paralllisme intra-requte, consistant excuter en parallle diffrentes parties dune mme requte, est utilis pour rduire le temps de rponse de chaque transaction. La Figure 1 prsente larchitecture standard dun SGBD exploitant ce type de paralllisme. Les requtes de lutilisateur sont envoyes au prprocesseur qui vrifie sa

validit syntaxique et smantique laide dinformations stockes dans le schma de la base. La requte est alors transforme en algbre relationnelle puis optimise. Loptimiseur value un certain nombre de stratgies dexcution potentiellement efficaces, et choisi celle qui optimise lutilisation des ressources de la machine, tout en produisant le meilleur temps de rponse. Le plan dexcution parallle ainsi produit, dcrit la dcomposition de la requte en fragments quil est ensuite possible dexcuter en parallle. Lexcution est finalement prise en charge par le moteur dexcution dont le rle est dobtenir les meilleures performances sur larchitecture multiprocesseur cible.
Requte SQL Prprocesseur Algbre Relationnelle Optimiseur parallle Plan dexcution parallle Moteur dexcution Excution Informations schma Schma de la Base Informations physiques

Compilation

.... Machine parallle

Figure 1. Architecture Standard dun SGBD Parallle Cet article prsente lensemble des techniques ainsi que les principaux travaux relatifs au problme de lexcution parallle de requtes. Dans la section 1, nous dcrivons en dtail les architectures matrielles, leurs avantages et inconvnients, ainsi que les principaux prototypes ou produits existants pour chaque architecture. La section 2 prsente les diffrentes approches possibles pour la mise en oeuvre du paralllisme. La section 3 prsente les plans dexcution parallle et en particulier, les diffrentes formes darbres dexcution. La section 4 dcrit les mtriques permettant de quantifier le gain dune excution parallle. Les problmes lis lexcution parallle sont dcrit dans la section 5. Le problme de la rpartition de charge est plus largement abord, et les solutions existantes sont dcrites. La section 6 conclut cette tude.

1. Architectures matrielles
Dans cette section, nous prsentons les architectures parallles les plus courament utilises pour les systmes de gestion de bases de donnes. 1.1. Architectures mmoire partage ou shared-memory Dans les architectures mmoire partage, la mmoire est accessible et partage par lensemble des processeurs de la machine. Chaque processeur a un cot uniforme daccs la mmoire, on parle alors de machine UMA (Uniform Memory Access). Une architecture UMA est constitue par un bus reliant entre eux tous les lments matriels de la machine : processeurs, modules mmoire et disques. Appele aussi SMP (Symetric MultiProcessor), cette architecture a t adopte sur des plate-formes diverses, depuis les stations de travail

quatre processeurs jusquaux plus grosses configurations comme les machines MULTIMAX srie 500 fabriques par ENCORE ou la srie SYMMETRY fabrique par SEQUENT [Lov88].
P1 cache Pn cache Bus Mmoire1 Mmoirek Disque1 Disquep

Figure 2. Architecture UMA Larchitecture UMA (c.f. Figure 2) permet un accs rapide aux donnes mais limite le nombre de processeurs du systme. En effet, le bus, lment matriel partag par tous les processeurs constitue le goulot dtranglement dune telle architecture. Sa bande passante limite interdit de trs grosses configurations. Ce type de systme reprsente cependant un excellent rapport cot/performance pour des applications de bases de donnes de taille moyenne. De plus, la rpartition de la charge de travail sur les diffrents processeurs peut tre efficacement ralise grce lutilisation de la mmoire partage. Enfin, le modle de programmation des architectures mmoire partage facilite grandement le portage dune application dveloppe pour un systme monoprocesseur. Pour ces raisons, larchitecture UMA a t largement adopte par lensemble des constructeurs du march. Les prototypes de systmes parallles de gestion de bases de donnes sexcutant sur des machines mmoire partage sont principalement XPRS [Sto88], Volcano [Gra94], DBS3 [Ber93] et Monet [Bon96]. Pour les systmes commerciaux, Oracle [Dav92] et Informix [Dan92] proposent des solutions sur ce type darchitecture. 1.2. Architecture distribues ou shared-nothing (SN) Dans larchitecture SN, except le rseau dinterconnexion, rien nest partag entre les processeurs. Ainsi, chaque noeud de la machine consiste en un processeur avec ses disques et sa mmoire locale. Les noeuds communiquent entre eux par envois de messages via un rseau dinterconnexion permettant des changes haut dbit (Figure 3).
Rseau dinterconnexion P1 Mmoire locale Disque(s) P2 Mmoire locale Disque(s) Pn Mmoire locale Disque(s)

Figure 3. Architecture shared-nothing Les partisans de larchitecture shared-nothing [Bor88] [DeW92b] considrent que lextensibilit de cette architecture est un facteur dcisif justifiant ladoption des machines SN pour les systmes parallles de gestion de bases de donnes. En effet, sur ce type de machines, chacun des processeurs gre directement une portion de la base. Le partage des ressources matrielles et logicielles entre les diffrents processeurs est donc limit au

minimum. Ainsi, une machine parallle adoptant une architecture SN peut thoriquement monter jusqu quelques centaines de processeurs. Cependant, la rpartition de la charge de travail entre les processeurs de la machine SN est complexe et coteuse. De nombreux systmes parallles de gestion de bases de donnes exploitent ce type darchitecture comme TANDEM [Che93], Bubba [Bor88], Gamma [DeW90], Teradata [Ter83], EDBS [Lop89] et PRISMA/DB [Ape92]. 1.3. Architectures disques partags ou shared disks Larchitecture disques partags est illustre Figure 4. Cette architecture a t notamment adopte dans Oracle partir de la version 6.0 (Oracle Parallel Server [Dav92]). Larchitecture disques partags tente de faire un compromis entre larchitecture mmoire partage et shared-nothing. Les disques sont partags pour faciliter la rpartition de la charge de travail tandis que la mmoire reste distribue pour ne pas trop pnaliser lextensibilit. De plus, contrairement larchitecture shared-nothing, le partage des disques permet une grande disponibilit des donnes puisque la totalit de la base de donnes continue tre accessible mme si lun des nuds devient indisponible.
P1 Mmoire locale P2 Mmoire locale Rseau dinterconnexion Disque Disque Disque Pn Mmoire locale

Figure 4. Architecture shared-disks Comme la mmoire nest pas partage, une page disque peut se retrouver duplique dans plusieurs noeuds de la machine. Il est ncessaire de garantir la cohrence entre toutes les copies dune mme page. Le surcot de maintenance de cette cohrence est bien sr le point faible de ce type darchitecture, et cela dautant plus que le nombre de mises jour est important. Larchitecture disques partags est dcrite de manire plus dtaille dans .

2. Formes de paralllisme.
Le modle relationnel se prte bien la paralllisation des requtes. Une requte relationnelle, sous sa forme algbrique, est forme par un graphe doprateurs sappliquant sur de grands ensembles de donnes ou relations. En excutant en parallle plusieurs oprateurs du graphe de la requte, il est possible de gnrer du paralllisme de type interoprateur. En fragmentant les oprandes dun seul oprateur, il est possible de la dcomposer en sous-oprateurs identiques conduisant gnrer du paralllisme de type intra-oprateur. Ces deux types de paralllisme peuvent tre combins ou non pour amliorer le temps de rponse de la requte. Dans la section 2.1, nous prsentons la mise en oeuvre du paralllisme intra-et interoprateur pour des modles dexcutions bass sur la fragmentation, i.e., o chaque processeur naccde qu un sous ensemble des relations accdes. Lapproche non fragmente, prsente dans la section 2.2, est uniquement applicable sur des architectures

mmoire partage. Elle est une simple paralllisation dune excution centralise. Dans ce cas, on ne peut parler rellement de paralllisme intra ou inter-oprateur. 2.1. Modle dexcution fragment Dans un modle dexcution fragment, lensemble des relations (de base ou temporaires) sont fragmentes grce une fonction de fragmentation. Chaque processeur naccde alors qu un sous ensemble des donnes. Cette approche est la seule possible sur une architecture shared-nothing, sans quoi les accs aux donnes, souvent distant entranerait des surcots de communication prohibitifs.
2.1.1 Paralllisme intra-oprateur

Le paralllisme intra-oprateur repose sur la dcomposition dun oprateur relationnel en un ensemble de sous-oprateurs indpendants, gnralement appeles instances de loprateur initial. Cette dcomposition est rendue possible grce la fragmentation statique et/ou dynamique des relations de la base, consistant fragmenter horizontalement chaque relation en paquets. Il existe trois mthodes basiques de fragmentation des donnes. Ces mthodes, illustres la Figure 5, sont round-robin, par hachage et par intervalle (range).
... ... ... Hachage ... a-g h-m ... ... u-z

Round-Robin

Intervalle

Figure 5. Mthodes de Fragmentation des Donnes La mthode round-robin place le iime tuple de la relation sur le disque numro i mod n o n est le nombre disque. La mthode par hachage associe les tuples aux disques selon une fonction de hachage applique lun des attributs de la relation. Enfin, la mthode par intervalle place les tuples sur les disques par intervalles de valeurs. Chacune de ces mthodes a ses avantages et inconvnients. La mthode round-robin permet de rpartir uniformment les tuples contrairement la mthode par hachage ou par intervalle. Ainsi, elle garanti une bonne paralllisation des entres/sorties lors de la lecture des relations. Elle na cependant pas dintrt pour les relations intermdiaires (sauf si elles sont stockes sur disque). Les deux dernires mthodes permettent, elles, de restreindre, dans certains cas, un calcul un sous-ensemble de paquets, mais peuvent gnrer des fragments de taille trs diffrente. Dans [Ber92], cette proprit est utilise afin de rduire la complexit dune requte. Une technique appele task elimination permet de supprimer, dans une requte multi-jointure lensemble des sous-jointure ne produisant aucun rsultat. Notons que, pour cet algorithme, une mauvaise distribution est un avantage, dans la mesure o elle permet plus dlimination. Bas sur la fragmentation des donnes, le mcanisme gnral de paralllisation intraoprateur consiste alors dcomposer loprateur initial en sous-oprateurs utilisant chacun, un paquet de chaque relation en entre. Souvent, la dcomposition de loprateur peut bnficier de la rpartition initiale des donnes, sinon, une redistribution pralable des donnes est requise avant lexcution de loprateur. Pour illustrer le paralllisme intraoprateur, prenons successivement le cas dun oprateur de slection puis dun oprateur de jointure.

Un oprateur de slection sur une relation R peut tre directement dcompos en n oprateurs de slection identiques, chacun deux tant appliqu sur lun des paquets de la relation initiale. Dans ce cas, aucune redistribution nest requise et lon a directement SEL (R) = SELi(Ri) quelque soit la mthode de fragmentation (c.f Figure 6). Notons que cela est indpendant de lalgorithme de slection (avec ou sans index). Dans le cas dune slection avec index, lindex est fragment de la mme manire.
S S1 S2 S3 Sn n = degr de paralllisme intra-oprateur Sel. Sel.i oprateur Linstance i de loprateur

Sel.

Sel.1

Sel.2

Sel.3

Sel.n

R1

R2

R3

Rn

Figure 6. Paralllisme Intra-oprateur Le cas dun oprateur de jointure, oprateur binaire, est plus complexe que celui dun oprateur de slection. Pour ramener lexcution de la jointure lexcution de n sousjointures utilisant un paquet de chaque relation en entre, il faut que chaque paquet de la deuxime relation contienne tous les tuples de cette relation susceptibles de joindre avec le paquet correspondant de la premire relation. Ceci nest possible quavec la fragmentation par hachage ou par intervalle si lattribut utilis pour la fragmentation est lattribut de jointure. Dans le cas contraire, une redistribution de lune, ou des deux relations (suivant lattribut de jointure) est ncessaire. Enfin, il faut noter que la mthode de fragmentation (hachage, round-robin, range) na aucun rapport avec lalgorithme local utilis pour effectuer la jointure (boucle imbrique, tri-fusion, hachage, etc..). Par exemple, dans le cas dune jointure par hachage utilisant une fragmentation par hachage, deux fonctions de hachage distinctes seront utilises. La premire h1, permettra de fragmenter les relations de bases en paquet, la seconde h2 (qui peut tre diffrente pour chaque instance) permettra deffectuer la jointure par hachage.
2.1.2 Paralllisme inter-oprateur

Le paralllisme inter-oprateur consiste excuter en parallle des oprateurs dune mme requte. Il existe deux formes de paralllisme inter-oprateur. Le paralllisme inter-oprateur indpendant consiste excuter en parallle deux oprateurs indpendants du graphe de la requte. Les plans dexcution de type bushy-tree offrent de nombreuses opportunits pour mettre en uvre cette forme de paralllisme. Sur lexemple de la Figure 7a, OP1 et OP2 peuvent profiter de ce type de paralllisme. OP3 OP1
R

OP2 OP2
S S T

OP1
R

(a)

(b)

Figure 7. Paralllisme inter-oprateur indpendant (a) et pipeline (b) Le paralllisme inter-oprateur pipeline consiste excuter deux oprateurs du graphe ayant un lien producteur-consommateur. Le rsultat du producteur (OP1 sur la Figure 7b)

nest pas matrialis mais envoy en pipeline loprateur suivant (OP2) sur le mme principe quun pipe unix. Cela vite notamment la matrialisation complte de la relation intermdiaire (T). On appelle une chane pipeline lensemble des oprateurs excuts en pipeline (OP1 et OP2 dans lexemple). Peu de systmes exploitent le paralllisme inter-oprateur. Par exemple, certains systmes mmoire distribue comme Teradata [Ter83] ou Gamma [DeW86] forcent chaque relation tre fragmente sur lensemble des noeuds de la machine parallle (fulldeclustering). Le paralllisme intra-oprateur met alors contribution lensemble des processeurs, ne laissant plus aucun intrt au paralllisme inter-oprateur. De plus, la possibilit dexploiter le paralllisme inter-oprateur complexifie la fois le systme dexcution et loptimiseur de requtes qui doit considrer un nombre beaucoup plus important de plans dexcution. 2.2. Modle dexcution non fragment On parle dune approche non fragmente lorsque la mise en oeuvre du paralllisme revient la simple paralllisation dune excution mono-processeur. Sur un mono-processeur, lexcution de plusieurs oprateurs successifs peut aussi tre faite en utilisant le pipeline. Cette approche a lintrt de supprimer la matrialisation des relations intermdiaires. Dans ce cas, le pipeline est implment grce des appels de procdure. Par exemple, une slection dune relation R suivie de deux jointures avec S puis T se droulera comme suit : Pour chaque tuple de R, sil satisfait le prdicat de slection, un appel sera fait la procdure join1 avec comme argument le tuple (ou sa projection). Ce tuple sera alors test avec la relation S. Sil joint, un appel sera fait la procdure join2 avec comme argument le tuple rsultat. Si de nouveau, ce tuple joint, il sera insr dans la relation rsultat, et ainsi de suite. Conceptuellement, nous avons donc les appels de procdures suivant : join2(T, join1(S, select(R))). Sur un multiprocesseur mmoire partage, il est possible de parallliser cette stratgie en utilisant une forme de paralllisme intra-oprateur. Plusieurs threads1 sont cres au dbut de la lexcution. Chaque thread traite alors un sous ensemble de la relation racine (R dans lexemple) et excute lensemble des oprateurs grce au pipeline synchrone. Bien quil y ait une fragmentation des donnes pour les relations de bases (stockes sur disque), ce nest pas le cas pour les autres relations. Chaque thread accde potentiellement lensemble des relations S et T. Cette stratgie appele pipeline parallle synchrone est dcrite dans [Hon92] [She93]. Ainsi, dans le cas du pipeline synchrone, on ne peut plus vraiment parler de paralllisme inter-oprateur puisque lexcution pipeline est justement squentielle. Par contre, le paralllisme indpendant peut encore tre mis en oeuvre en excutant plusieurs chanes pipelines indpendantes concurremment.

3. Arbre doprateurs
Larbre doprateur provient de la macro-expansion de larbre de jointure [Has94]. Les
1. Un thread est un processus lger. Plusieurs threads peuvent tre crs dans un mme processus. Leur ordonnancement est alors moins coteux que pour des processus.

noeuds reprsentent les oprateurs atomiques de l'algbre relationnelle et les arcs reprsentent les flots de donnes. Ces arcs peuvent tre de deux types : bloquants ou pipelines. Un arc bloquant indique que les donnes doivent tre entirement produites avant de pouvoir commencer loprateur consommateur. Ainsi, un oprateur ayant une entre bloquante doit attendre la matrialisation complte de l'oprande avant de commencer. Un arc pipeline indique que les donnes peuvent tre consommes au fur et mesure. Ainsi, le consommateur peut dbuter ds que le premier tuple consommer a t produit. Plusieurs formes darbres peuvent tre considres : linaires (gauches ou droits) [Sch90], zigzag [Zia93] ou bushy [She93]. La Figure 8 prsente les arbres droits, gauches et bushy pour une requte effectuant la jointure de 4 relations R, S, T et U. Dans un arbre droit, toutes les jointures sont effectues en pipeline. On peut ainsi dire que tous les oprateurs sexcutent en parallle. En fait, lexcution seffectue souvent en au moins en deux phases. Dans une premire phase, les relations gauche (S, T et U sur la figure) sont charges en mmoires (et ventuellement indexes, haches ou tries). Dans la deuxime phase, les tuples de R sont testes successivement avec les relations S, T et U en pipeline. Lavantage dun arbre droit est quil permet de ne pas matrialiser les relations intermdiaires et produit rapidement le premier rsultat (pipeline). Toutefois, pour obtenir de bonnes performances, il faut que toutes les relations gauche puissent tenir en mmoire. Dans le cas contraire, lexcution pipeline gnrera du swapping. Dans un arbre gauche, les jointures sont toutes excutes en squence. Ainsi, lexcution se fait en autant de phases quil y a de relations joindre. Dans chaque phase une relation intermdiaire (ou le rsultat final) est matrialise. Cette stratgie dexcution est utilise lorsque la mmoire est limit car elle ne matrialise jamais plus de deux relations simultanment : une relation intermdiaire gauche et le rsultat de sa jointure, la relation droite tant lue page page. Les arbres gauches et droits sont deux stratgies extrmes dexcution dun arbre linaire. les arbres zigzag, introduits dans [Zia93], donnent une stratgie intermdiaire entre les arbres gauches et droits. Dans un arbre zigzag, une relation intermdiaire peut tre matrialise ou pipeline selon la quantit de mmoire disponible. Larbre linaire droit est ainsi dcoup en plusieurs sous-arbres droits excuts squentiellements. Lintrt de cette stratgie est quelle permet deffectuer plus de pipeline que les arbres gauches mais consomme moins de mmoire que les arbres droits.

U T R S R S T U

U T S R

(c) (a) (b) Figure 8. Arbres linaire gauche (a), bushy (b) et linaire droit (c) Les arbres bushy sont les plus gnraux. Ils nimposent aucune contrainte sur les liens entre les oprateurs (bloquant, non-bloquant). Ils permettent dobtenir du paralllisme indpendant [Lan93]. De plus, ils offrent un bon compromis entre le degr de paralllisme inter-oprateur et la consommation mmoire [She93]. Enfin, la considration des arbres

bushy lors de loptimisation augmente considrablement lespace de recherche, permettant, de ce fait, lobtention potentielle de meilleurs plans dexcution.

4. Mesure de performances
Le but de lexcution parallle de requtes est dobtenir un gain de performance. En plus du temps de rponse, il existe plusieurs mtriques permettant de quantifier le gain obtenu par une excution parallle. Les plus connues sont le speed-up et le scale-up (voir par ex. ). Un systme parallle idal est celui qui permet dobtenir la fois un speed-up linaire et un scale-up constant. De manire informelle, un speed-up idal indique quune tche peut tre excute deux fois plus vite si lon dispose de deux fois plus de ressources matrielles (processeurs, disques, mmoire,...). Un scale-up idal signifie quune tche deux fois plus grosse peut tre excute dans le mme temps si lon dispose de deux fois plus de ressources matrielles. La dfinition formelle du speed-up est la suivante : soit une tche de taille fixe excute de manire squentielle en un temps Ts puis excute en parallle sur p processeurs en un temps Tp, le speed-up obtenu par lexcution parallle est alors dfini par : Ts speed up ( p ) = ----Tp et le speed-up est idal si speed-up (p) = p. On peut dduire du speed-up lefficacit Ep de lalgorithme parallle, cest dire le rapport entre le speed-up effectif et le speed-up idal : Ts Ep = --------------Tp p Par exemple, si lon considre un problme rsolu en 120 secondes sur une machine squentielle alors quil faut 10 secondes sur une machine parallle avec 16 processeurs, le speed-up est gal 12 et lefficacit du traitement parallle est de 75%. Il est important de remarquer quil est plus facile dobtenir de bon speed-up avec des algorithmes de jointures peu efficaces (p. ex. boucles imbriques). En effet, la part des surcots dexcution est dautant plus grande que le temps de rponse est petit. La mesure de speed-up ne peut donc tre prise pour comparer deux systmes ou deux stratgies dexcution. Il est dans ce cas, important de mesurer aussi les performances relatives des deux systmes ou stratgies. La dfinition formelle du scale-up est la suivante : soient deux problmes P1 et P2 avec P2 n fois plus gros que P1 et T(Pi, p) le temps dexcution du problme Pi sur un systme avec p processeurs, le scale-up est dfini par la formule suivante : T ( P1, p ) scale up = -----------------------------T ( P2, p n ) Le scale-up est idal si il reste toujours gal 1. Notons quun problme n fois plus gros est obtenu par augmentation du volume de donnes traiter. Par exemple, supposons que lon dsire mesurer le scale-up dun oprateur de slection. Pour obtenir une slection n fois plus grosse, il suffit simplement de multiplier

le volume des donnes slectionner par n. Ceci nest plus vrai pour un oprateur de jointure dont la complexit nest pas linairement proportionnelle la taille de ses oprandes. Cest pour cette raison que la mesure de speed-up, plus facile mettre en oeuvre, est souvent prfre celle du scale-up.

5. Problmes lis lexcution parallle

Un ensemble de facteurs limite les gains obtenus lors dune excution parallle. Dans cette section, nous montrons quels sont ces facteurs. Nous insistons particulirement sur les problmes de rpartition de charge et prsentons les solutions existantes. 5.1. Initialisation et mise en place du paralllisme Avant que lexcution parallle ne dbute rellement, toute une phase dinitialisation et de mise en place du paralllisme est ncessaire. La phase dinitialisation consiste par exemple ouvrir les relations impliques dans la requte, crer la relation rsultat, initialiser le contexte dexcution propre chaque oprateur. La phase de mise en place du paralllisme consiste, par exemple, crer les processus ou les threads impliqus dans lexcution parallle et tablir les connexions entre ceux-ci pour mettre en place les communications inter-oprateur. Ce processus est, en gnral squentiel et prcde lexcution parallle proprement dite. Le temps dinitialisation et de mise en place du paralllisme explique en grande partie les mauvais speed-up obtenus pour les requtes de faible complexit comme un oprateur de slection sur une relation. Par exemple, les mesures de performance effectues dans PRISMA/DB [Wil92] montrent un effondrement du speed-up sur les petites slections, et cela ds que le nombre de processeurs utiliss devient suprieur 8. Le degr de paralllisme doit tre choisi en fonction de la complexit de la requte. [Wil92] prsente une formule permettant de dterminer le speed-up maximal atteignable lors de lexcution dun seul oprateur et den dduire le nombre de processeur optimal pour son excution. Considrons lexcution dun oprateur traitant N tuples avec n processeurs, le temps de traitement de chaque tuple tant c et le temps dinitialisation de lexcution par processeur a. Le temps de rponse peut scrire avec la formule suivante : cN R = an + -----n Le temps de rponse minimum (correspondant au speed-up maximum) sobtient alors facilement en drivant cette formule par rapport n et en lgalant 0. On obtient alors : 1 cN S 0 = -- n 0 le speed-up maximal tant gal n 0 = -----2 a Dans le cas des systmes grande mmoire, le temps dinitialisation (an) nest pas ngligeable devant le temps de rponse. Ce qui limite le nombre de processeurs optimal. Pour des systmes lisant les relations sur disque, le temps dinitialisation limite aussi le nombre maximum de processeurs mais dans dautres proportions. Ces quations montrent, entre autres, quil ne semble pas judicieux dexcuter chaque oprateur sur lensemble des processeurs (utilisant alors uniquement le paralllisme intra-oprateur). Il faut plutt combiner paralllisme inter et intra-oprateur afin de diminuer le degr de paralllisme de

chaque oprateur et den augmenter le speed-up. 5.2. Contrle de lexcution parallle Lors de lexcution parallle dune requte, des messages de contrle sont changs entre les diffrentes entits dexcution (ex. processus) mises en jeu pour lexcution parallle. Ces messages de contrle permettent par exemple de dmarrer les oprateurs de la requte ou de signaler leur fin. Ainsi, plus le degr de paralllisme est lev et plus le nombre de messages de contrle est important. Pour les premiers systmes parallles de bases de donnes, le surcot li au contrle de lexcution parallle tait lun des obstacles majeurs lobtention de bons speed-up. Un cas typique est le prototype DIRECT [Bor82], anctre de Gamma. Dans DIRECT, chaque page de donnes traite donnait lieu lchange dau minimum 1 message de contrle vers un scheduler centralis. Lchange de ces messages constituait le goulot dtranglement du systme et contre-balanait tous les gains de lexcution parallle. Depuis lexprience de DIRECT, de nombreuses solutions ont t proposes visant limiter le nombre de messages changs pour la synchronisation et le dclenchement tout en liminant la ncessit dun contrleur centralis. Le travail le plus complet dans ce domaine est certainement celui effectu dans le cadre du projet EDS [EDS90] au travers du langage dexpression des plans dexcution parallle LERA-par [Cha92]. Lide de base est dintroduire directement dans le code de la requte lensemble des oprateurs de contrle ncessaires pour assurer une excution parallle correcte. De plus, les stratgies de contrle sont construites partir dune bibliothque doprateurs o chaque oprateur reprsente une fonctionnalit de contrle lmentaire. Cette approche apporte une grande souplesse car la combinaison des fonctions lmentaires de contrle disponibles dans la bibliothque [Dag91][BoS91] permet llaboration de stratgies optimises et adaptes chaque requte, qui conduisent une rduction du nombre de messages changs. 5.3. Interfrences et effets de convoi Une excution hautement parallle peut tre freine par lapparition de phnomnes dinterfrences. Ces phnomnes apparaissent lorsque plusieurs processeurs accdent simultanment une mme ressource non partageable (ou peu partageable). Certains processeurs doivent alors tre mis en attente, freinant ainsi lexcution parallle. Les phnomnes dinterfrence peuvent survenir tant au niveau matriel (i.e. la ressource est matrielle) que logiciel (i.e. la ressource est une donne partage). Un exemple typique dinterfrence matrielle est la contention cre au niveau du bus dune machine mmoire partage lors des accs mmoire effectus par les processeurs. Plus le nombre de processeurs augmente et plus les conflits au niveau de ce bus augmentent. Cest la raison pour laquelle le nombre de processeurs est limit quelques dizaines sur ce type darchitecture. Il en est de mme pour les disques. Lorsque deux processus effectuent une entre/sortie sur le mme disque, ils sont squentialiss au niveau du systme. Notons que la multiplication des ressources matrielles permet de limiter les conflits daccs. Par exemple, au niveau dun disque, ladoption de disques RAID (Redondant Array of

Inexpensive Disks [Pat88]), permet de limiter ces interfrences. Quant aux interfrences logicielles, elles apparaissent lorsque plusieurs threads ou processus accdent en parallle une mme donne [Fon89]. Pour prvenir tout risque dincohrence, une variable verrou [Lam86] est gnralement utilise afin de squentialiser les accs la donne (c.f. Figure 9). Lorsquun processus tente de prendre un verrou sur une donne et que celui-ci est dtenu par un autre processus, il est mis en attente. Ces interfrences logicielles peuvent alors devenir le goulot dtranglement du systme et cela dautant plus rapidement que des effets de convoi peuvent survenir. Un effet de convoi [Bla79] survient lorsquun processus est de-schedul par le systme alors quil dtient un verrou. Cela peut survenir suite lpuisement de son quantum de temps sur le processeur ou cause dune entre-sortie. Ce temps allonge la priode de prise du verrou, augmentant du mme coup la probabilit de conflits. Plus cette probabilit augmente et plus les processus en attente du verrou vont saccumuler conduisant un effet boule de neige. Un exemple typique dinterfrence logicielle survient lors des accs aux tampons de la base de donnes par les diffrentes entits dexcutions (threads ou processus). Pour prvenir tout risque dincohrence, une variable verrou squentialise laccs ces tampons. Comme le montre ltude sur le rglage dune requte de tri effectue dans Volcano [Gra92], laccs aux tampons peut alors devenir rapidement le goulot dtranglement du systme et cela mme lorsque le nombre de processeurs est peu lev. Par exemple, cette tude a montr que pour 16 processeurs, le surcot occasionn par les interfrences logicielles reprsentaient 45% du temps total dexcution. Ce problme de contention lors de laccs aux tampons de la base a aussi t report dans [Hon91] comme un des facteurs limitant le degr de paralllisme.
Variables partages Variables partages

Verrou Threads Accs incontrol Accs squentiel ccs parallle

Figure 9. Accs des structures partages La solution gnrale pour remdier aux problmes dinterfrences consiste parallliser la ressource partage, cest dire la dcomposer en sous-ressources indpendantes. Deux sous-ressources distinctes peuvent alors tre accdes en parallle, limitant ainsi la probabilit dinterfrence (c.f. Figure 9). Cette solution a t adopte dans DBS3 [Cas94] la structure daccs aux tampons de la base, ce qui permet leur accs simultan par un grand nombre de threads. 5.4. Le problme de la rpartition de la charge de travail Ce problme est certainement celui qui affecte le plus la mesure de speed-up dune

excution parallle. Nous avons prsent dans la section prcdente les diffrentes techniques pour gnrer du paralllisme intra-requte. Ces techniques sont le paralllisme inter-oprateur et intra-oprateur. Utilises conjointement ou non, elles permettent de fragmenter le code squentiel dune requte pour constituer plusieurs fragments ou tches quil est ensuite possible dexcuter en parallle. Pour obtenir de bonnes performances, il est ncessaire que les tches ainsi formes soient rparties quitablement entre les diffrents processeurs allous pour lexcution. Dans le cas contraire, certains processeurs vont recevoir plus de travail que dautres et le temps de rponse de la requte sera alors gal au temps de rponse du processeur le plus charg. Lalgorithme de rpartition des tches sur lensemble des processeurs impliqus dans lexcution est rendu difficile car le temps dexcution peut grandement varier dune tche lautre. Cela est principalement d deux raisons. Premirement, si le paralllisme interoprateur est exploit, ces tches sont issues doprateurs diffrents du graphe de la requte conduisant des cots dexcution trs divers. Deuximement, mme en ne considrant que le paralllisme intra-oprateur, une rpartition biaise des donnes (ou data skew) peut conduire des diffrences de temps dexcution entre les instances dun mme oprateur. La section 5.4.1 et 5.4.2 dtaillent le problme de la rpartition de charge intra et interoprateur et donnent un aperu des solutions existantes pour chaque forme de paralllisme.
5.4.1 Rpartition de charge intra-oprateur

Walton et al. [Wal91] a classifi les effets dune mauvaise rpartition des donnes lors dune excution parallle avec un modle dexcution fragment. Ceux-ci sont rsums sur un exemple, prsent la Figure 10.
JPS JPS Res1 Join1 S2 AVS/TPS R2 RS/SS Scan1 RS/SS Scan2 R1 Res2 AVS/TPS Join2 S1 AVS/TPS

AVS/TPS

Figure 10. Exemple de problmes de mauvaises distributions de donnes Cet exemple dcrit lexcution dune requte de slection-jointure applique deux relations R et S mal distribues fragmentes en deux paquets. La mauvaise fragmentation de R et S provient soit des donnes elles-mmes (skew de valeur des attributs ou AVS), soit de la fonction de fragmentation (skew de placement des tuples ou TPS). Les temps de traitement du paquet R1 ne sera alors pas gal celui du paquet R2. Sur cet exemple, pour obtenir une rpartition quitable de la charge de travail, il est ncessaire de mettre plus de puissance de calcul sur linstance scan2 que sur linstance scan1. Pour loprateur de jointure, cest encore pire. Dune part, la taille ingale des paquets de la relation S (due lAVS et au TPS) entrane des temps de traitement diffrents pour chaque tuple transmis depuis loprateur de scan. De plus, le nombre de tuples transmis varie dune

instance lautre suite la mauvaise redistribution des paquets de R (skew de redistribution ou RS) ou une slectivit variable suivant le paquet de R trait (skew de slectivit ou SS). Finalement, la slectivit de la jointure peut aussi varier dune instance lautre (skew de slectivit de la jointure ou JPS). Une solution de rpartition statique de la charge, i.e. base sur une estimation de la complexit de chaque instance doprateur, semble donc complexe mettre en oeuvre. En effet, pour que lestimation soit correcte, il faut maintenir des statistiques du type histogramme sur les attributs de jointure, les attributs de fragmentation, les attributs participant un prdicat (slection ou jointure), donc potentiellement sur tous les attributs de la relation. Il semble plus raisonnable de tenter de redistribuer la charge de travail dynamiquement. Wolf et al. [Wol93] proposent de modifier les algorithmes classiques de jointure parallle par tri-fusion et par hachage pour y ajouter une phase dite de scheduling. Cette phase, place aprs la phase de tri ou de hachage, vise balancer le travail entre les diffrents processeurs impliqus dans la phase ultrieure de jointure. Pour ce la jointure est dcompose en un nombre de sous-jointures plus important que le nombre de processeurs effectifs. Le cot dexcution de chacune des sous-jointures est alors estim et est utilis pour les rpartir sur les processeurs de manire ce que lcart la moyenne de la charge de travail affecte un processeur ne dpasse pas un seuil de tolrance fix par avance. Si aucune rpartition ne satisfait ce prrequis, la mthode est itre en modifiant la phase de tri ou de hachage de manire gnrer un plus grand nombre de sous-jointures, offrant ainsi plus dopportunits la phase de scheduling. Notons que la phase de scheduling utilise lheuristique dite de LPT (Longest Processing Time first [Gra69]) pour rpartir au mieux les sous-jointures entre les processeurs. Kitsuregawa et al. [Kit90] proposent un algorithme supportant les mauvaises distributions de donnes et conu spcifiquement pour la machine SDC (Super Database Computer) bas sur une architecture distribue. Lide est de refragmenter chaque paquet de relation en un grand nombre de sous-paquets. Ceux-ci sont alors temporairement distribus sur les processeurs. Un mcanisme matriel, intgr au rseau dinterconnexion (appel rseau Omga) est alors utilis pour redistribuer dynamiquement les sous paquets ainsi forms, de manire obtenir une bonne rpartition de charge. Omiecinski [Omi91] propose une approche similaire pour une architecture mmoire partage et utilise lheuristique first fit decreasing pour redistribuer les sous-paquets aux processeurs. Cependant, cette redistribution ne ncessite pas un mcanisme matriel particulier. Dewitt et al. [DeW92a] suggrent lutilisation de plusieurs algorithmes, chacun deux tant spcialiss pour un certain degr de skew. Pour cela, une premire phase dchantillonnage des relations est ralis afin de dterminer le degr de skew et permet de choisir un algorithme plus ou moins insensible au mauvaises distributions. Quatre algorithmes spcifiques sont proposs et implments, en plus de lalgorithme de jointure par hachage Hybrid hash join [Sch89]. Lvaluation de performances, mene sur le prototype GAMMA, montrent quune telle approche permet dobtenir un bon support des mauvaises distributions sans surcot lorsque les relations sont bien distribues. Shatdal et al. [Sha93] proposent dutiliser la mmoire virtuellement partage (SVM), implmente par logiciel, sur un environnement shared-nothing, afin de raliser

dynamiquement une redistribution de la charge de travail. Lalgorithme propos combine lutilisation de la mmoire virtuellement partage et lenvoi de messages afin dviter des rplications de donnes intensives qui saturerait la mmoire de chaque processeur. Lorsquun processeur est inactif, il vole une partie de la charge de travail un processeur actif grce la mmoire virtuellement partage. Une simulation est ralise afin de comparer cette stratgie avec celle dvelopp dans [DeW92a]. Lajout dune phase dchantillonnage pralable des relations permet damliorer encore les performances. Plus rcemment, Brunie et al. [Bru95] [Bru96] ont propos de dterminer statiquement lallocation des processeurs aux oprateurs et de permettre une rallocation dynamique des processeurs en cours dexcution en cas de mauvaises distributions des donnes. Pour cela, des oprateurs spcifiques, appels control operators sont insrs dans le plan dexcution parallle afin de dterminer si les estimations statiques ne diffrent pas trop des valeurs relles. Si la diffrence est trop grande, le control operator dclenche une phase de redistribution des donnes afin de prvenir le skew de redistribution et le skew de produit de jointure. Notons que cet oprateur peut aussi modifier le degr de paralllisme intraoprateur de loprateur suivant si besoin est. Il ralise ainsi dynamiquement la rpartition de charge intra et inter-oprateur.
5.4.2 Rpartition de charge inter-oprateur

Afin dobtenir une bonne rpartition de charge au niveau inter-oprateur, il est ncessaire de dterminer, pour chaque oprateur, son degr de paralllisme intra-oprateur et de choisir judicieusement les processeurs allous pour son excution. Supposons quun modle de cot nous permette de dterminer, sans erreur, le temps dexcution squentiel de chaque oprateur. Il nous faut alors trouver une mthode dassignation des processeurs aux oprateurs afin dobtenir la meilleure rpartition de charge. Chen et al. [Che93] proposent deffectuer lallocation des processeurs en utilisant uniquement le paralllisme intra-oprateur et inter-oprateur de type indpendant. Il ny a donc pas dexcution pipeline. Les processeurs sont alors allous rcursivement de la racine aux feuilles de larbre doprateur de manire deux sous arbre dun noeud terminent leur excution au mme moment. Ainsi tous les processeurs sont allous la dernire jointure (racine de larbre) puis rcursivement allous chaque sous-arbre en fonction de leur complexit. Hsiao et al. [Hsi94] utilisent la mme mthode que prcdemment mais lapplique sur ce quils appellent larbre dallocation au lieu de lappliquer sur larbre doprateur. Larbre dallocation est dduit de larbre doprateur. Il faut dabord identifier les chanes pipelines existantes dans larbre doprateur. Chaque chane pipeline devient alors un noeud de larbre dallocation. Les arcs entre ces noeuds reprsentent les contraintes de prcdence entre les chanes pipelines. Ainsi, les processeurs sont allous pour une chane pipeline et non plus pour un oprateur. La distribution des processeurs allous pour une chane pipeline sur chaque oprateur est dcrite dans [Lo93]. Cette stratgie dallocation privilgie lexcution pipeline en essayant de produire toutes les donnes ncessaires lexcution dune chane pipeline de manire synchrone. Wilshut et al. [Wil95] utilisent lalgorithme de jointure par hachage non bloquant pour autoriser lexcution de tous les oprateurs dun arbre bushy simultanment (puisque cet

algorithme nentrane pas de blocages). Ils rpartissent les processeurs sur les oprateurs en fonction de leur complexit estime. Cette technique appel Full Parallel permet un degr de paralllisme inter-oprateur maximum. Dans cette mme tude, les auteurs tudient les performances des stratgies prsentes prcdemment. Ils montrent que ces approches (y compris la jointure non bloquante) souffrent des problmes suivant : Problmes de partie entire (discretization error) : Comme les processeurs et les oprateurs sont des entits discrtes, les arrondis invitables entranent des problmes de rpartition de charge. Dlai dans les pipelines (pipeline delays) : Lors dune excution pipeline, les processeurs associs loprateur du haut de la chane sont inactifs tant que le premier tuple nest pas produit. Les dlais dans les pipelines entranent donc aussi une sous utilisation des processeurs. Erreurs du modle de cot : Enfin, et cest sans doute le plus grave, il est clair quun modle de cot ne peut fournir que des rsultats trs approximatifs puisquils ne prennent pas en compte les aspects dynamiques de lexcution (interfrences, contexte de lexcution) et peut difficilement valuer le cot dun oprateur affect par le skew. Toutes ces stratgies sont donc dpendantes de la qualit du modle de cot Metha et al. [Meh95] propose de dterminer dynamiquement (juste avant lexcution) le degr de paralllisme ainsi que lensemble des processeurs utiliss pour chaque oprateur. Lalgorithme Rate Match est dcrit, il utilise un modle de cot pour choisir le degr de paralllisme de chaque oprateur. Toutefois, au lieu de se baser sur une estimation de la taille des oprandes, lalgorithme Rate Match tente de faire correspondre le taux de production des tuples rsultat dun oprateur avec le taux de consommation des tuples de loprateur suivant. Laspect multi-utilisateur est pris en compte en rduisant dans le modle de cot, la vitesse des processeurs dun facteur dpendant de son utilisation. Enfin, six algorithmes sont proposs pour le choix des processeurs qui excuteront un oprateur (bass sur la capacit mmoire, lutilisation des processeurs, des disques, etc..). Rahm et al. [Rah95] proposent dautres algorithmes pour le choix du degr de paralllisme et des processeurs. Les algorithmes proposs cherchent rpartir efficacement les oprateurs de manire maximiser lutilisation des ressources (disques, CPU, mmoire), grce des statistiques sur lutilisation des processeurs et de la mmoire, maintenus par un noeud de contrle. Les algorithmes proposs sont valus dans un contexte multi-utilisateurs sur une simulation. Sur des architectures mmoire partage, lutilisation de modles non fragments change la nature du problme de rpartition de charge inter-oprateur. En effet, chaque processeur participant lensemble des oprateurs dune chaine pipeline, il ny a pas rellement de paralllisme inter-oprateur sauf en considrant deux chanes pipelines indpendantes. Hong et al. [Hon92] proposent, lors de lexcution concurrente de plusieurs chanes pipeline, dajuster dynamiquement le degr de paralllisme intra-oprateur de chacune afin doptimiser lutilisation des ressources disques et CPU. Pour cela, ils proposent dexcuter concurremment deux chanes pipeline, les performances de chacune tant limites par des facteurs diffrents (i.e., CPU bound et I/O bound). Le processus de contrle de lexcution

parallle dtermine alors le point dutilisation maximum des ressources, (i.e. le degr de paralllisme optimal de chaque chane pipeline pour maximiser lutilisation des ressources) et modifie le degr de paralllisme de chaque chane pipeline dynamiquement (en cours dexcution).

6. Conclusion
Nous avons donc, dans cet article prsent un ensemble de notions et techniques relatives lexcution parallle de requtes : architectures matrielles, formes de paralllisme, plans dexcution parallle, ainsi que les mtriques permettant de quantifier le gain dune excution parallle. Nous avons alors montr les problmes lis lexcution parallle et plus particulirement insist sur le problme de la rpartition de charge lors dune excution parallle. Les diffrentes solutions existante ont t dcrites. Elles se divisent en deux catgories. Dune part, les solutions au problme de la rpartition de charge au niveau intraoprateur, gnralement dynamiques, cherchent redistribuer la charge durant lexcution. Les solutions au niveau inter-oprateur, sont elles, statiques et utilisent des techniques bases sur un modle de cot. Nous avons alors dcris lapproche que nous avons suivi pour raliser une rpartition dynamique de la charge au niveau intra-oprateur et inter-oprateur lors de lexcution sur des architectures hybrides car elles nous semblent tre des architectures cls pour les besoins en performances des nouvelles applications.

7. Bibliographie
[Ape92] P. M. G. Apers, C. A. van den Berg, J. Flokstra, P. W. P. J. Grefen, M. L. Kersten, A. N. Wilschut, PRISMA/DB : A Parallel Main Memory Relational DBMS. IEEE Transaction on Knowledge and Data Engineering, 4(6), 1992. C. A. van den Berg, M, L, Kersten, Analysis of a Dynamic Query Optimization Technique for Multi-join Queries. Int. Conf. on Information and Knowledge Engineering, 1992. B. Bergsten, M. Couprie, P. Valduriez, Overview of Parallel Architectures for Databases. Computer Journal, 36(8), 1993. M. Blasgen, J. Gray, M. Mitoma, T. Price, The Convoy Phenomenon. Operating Systems Review 13(2), 1979. Peter A. Boncz, Fred Kwakkel, Martin L. Kersten : High Performance Support for OO Traversals in Monet. BNCOD, 1996. H. Boral, D. DeWitt, D. Friedland, N. Jarrell, W. Wilkinso, Implementation of the Database Machine DIRECT. IEEE Transaction on Software Engineering, 8(6), 1982. H. Boral, Parallelism and data management. Int. Conf. on Data and Knowledge Engineering, 1988. P. Borla-Salamet, C. Chachaty, B. Dageville, Compiling Control into Database Queries for Parallel Execution Management. Int. Conf. on Parallel and Distributed Information Systems, 1991.

[Ber92] [Ber93] [Bla79] [Bon96] [Bor82] [Bor88] [BoS91]

[Bou96a] L. Bouganim, D. Florescu, P. Valduriez, Dynamic Load Balancing in Hierarchical Parallel Database Systems. Int. Conf. on Very Large Data Bases, 1996.

[Bou96b] L. Bouganim, D. Florescu, P. Valduriez : Parallel Query Execution in NUMA Multiprocessors. Soumis la publication. 1996. [Bru95] [Bru96] [Cas94] [Cha92] L. Brunie, H. Kosch, A. Flory, New static scheduling and elastic load balancing methods for parallel query processing. BIWIT 95, IEEE Computer Society Press, 1995 L. Brunie, H. Kosch, Control strategies for complex relational query processing in shared nothing systems. ACM Sigmod Records, 25(3), 1996. P. Casadessus, B. Dageville, P. Borla-Salamet, Evaluation du SGBD parallle DBS3 sur la machine KSR1. Ingnierie des Systmes dInformation (ISI), 2(4), 1994. C. Chachaty, P. Borla-Salamet, M. Ward, A Compositional Approach for the Design of a Parallel Query Processing Language. Int. Conf. on Parallel Architectures and Language Europe, 1992. A. Chen, Y. F. Kao, M. Pong, D. Sak, S. Sharma, J. Vaishnav, H. Zeller, Query Processing in NonStop SQL. IEEE Data Engenering Bulletin, 16(4), 1993. B. Dageville, P. Borla-Salamet, C. Chachaty, Compiling Control Into Database Queries For Parallel Execution Management. Journes Bases de Donnes Avances, BDA91, 1991. D. D. Davis, Oracles Parallel Punch for OLTP. Datamation, 1992. W. Davison, Parallel Index Building in Informix OnLine 6.0. ACM-SIGMOD Int. Conf., 1992.

[Che93] [Dag91]

[Dav92] [Dan92]

[DeW86] D. J. DeWitt, R. H. Gerber, G. Graefe, M. L. Heytens, K. B. Kumar, M. Muralikrishna, GAMMA - A High Performance Dataflow Database Machine. Int. Conf. on Very Large Data Bases, 1986. [DeW90] D. J. DeWitt, S. Ghandeharizadeh, D. Schneider, A. Bricker, H. Hsiao, R. Rasmussen, The Gamma Database Machine Project. IEEE Trans. on Knowledge and Data Engineering, 2(1), 1990. [DeW92a] D.J. DeWitt, J.F. Naughton, D.A. Schneider, S. Seshadri, Practical Skew Handling in Parallel Joins. Int. Conf. on Very Large Data Bases, 1992. [DeW92b] D.J. DeWitt, J. Gray, Parallel Database Systems : The Future of High Performance Database Processing. Communications of the ACM, 35(6), 1992. [EDS90] [Fon89] [Gra92] [Gra94] [Gra69] [Has94] EDS Database Group, EDS - Collaborating for High Performance Parallel Relationnal Database. Esprit Conf., 1990. M. Fontenot, Software Congestion, Mobile Servers, and the Hyperbolic Model. IEEE Transactions on Software Engineering 15, 1989. G. Graefe, S. Thakkar, Tunning a Parallel Database Algorithm on a Shared-memory Multiprocessor. Software - Practice and Experience, 22(7), 1992. G. Graefe, Volcano, An Extensible and Parallel Dataflow Query Evaluation System. IEEE Trans. on Knowledge and Data Engineering, 6(1), 1994. R. L. Graham, Bounds on Multiprocessing Timing Anomalies. SIAM Journal of Applied Mathematics, V17, 1969. W. Hasan, R. Motwani, Optimization Algorithms for Exploiting the Parallel Communication Tradeoff in Pipelined Parallelism. Int. Conf. on Very Large Data Bases, 1994. W. Hong, M. Stonebraker, Optimization of Parallel Query Execution Plans in XPRS. Int. Conf. on Parallel and Distributed Information Systems, 1991. W. Hong, Exploiting Inter-Operation Parallelism in XPRS. ACM-SIGMOD Int. Conf., 1992.

[Hon91] [Hon92]

[Hsi94] [Kit90]

H. Hsiao, M. S. Chen, P. S. Yu, On Parallel Execution of Multiple Pipelined Hash Joins. ACM-SIGMOD Int. Conf., 1994. M. Kitsuregawa, Y. Ogawa, Bucket Spreading Parallel Hash : A New, Robust, Parallel Hash Join Method for Data Skew in the Super Database Computer. Int. Conf. on Very Large Data Bases, 1990. L. Lamport, The Mutual Exclusion Problem : Part II - Statement and Solutions. Journal of ACM, 33(2), 1986. R. Lanzelotte, P. Valduriez, M. Zait, On the Effectiveness of Optimization Search Strategies for Parallel Execution Spaces. Int. Conf. on Very Large Data Bases, 1993. M-L. Lo, M-S. Chen, C. V. Ravishankar, P. S. Yu, On Optimal Processor Allocation to Support Pipelined Hash Joins. ACM-SIGMOD Int. Conf., 1993. M. Lopez, The EDS Database Server. EDS Working Report EDS.D901.B, 1989. T. Lovett, S. S. Thakkar, The Symmetry Multiprocessor System. Int. Conf. on Parallel Processing, 1988. M. Metha, D. DeWitt, Managing Intra-operator Parallelism in Parallel Database Systems. Int. Conf. on Very Large Data Bases, 1995. E. Omiecinski, Performance Analysis of a Load Balancing Hash-Join Algorithm for a Shared-Memory Multiprocessor. Int. Conf. on Very Large Data Bases, 1991. D. A. Patterson, G. Gibson and R. H. Katz, A Case for Redundant Arrays of Inexpensive Disks (RAID). ACM-SIGMOD Int. Conf., 1988. E. Rahm, R. Marek, Dynamic Multi-Resource Load Balancing in Parallel Database Systems. Int. Conf. on Very Large Data Bases, 1995. D. Schneider, D. DeWitt, A Performance Evaluation of Four Parallel Join Algorithms in a Shared-Nothing Multiprocessor Environment. ACM-SIGMOD Int. Conf., 1989. D. Schneider, D. DeWitt, Tradeoffs in processing complex join queries via hashing in multiprocessor database machines. Int. Conf. on Very Large Data Bases, 1990. A. Shatdal, J. F. Naughton, Using Shared Virtual Memory for Parallel Join Processing. ACM-SIGMOD Int. Conf., 1993. E. J. Shekita, H. C. Young, Multi-Join Optimization for Symmetric Multiprocessor. Int. Conf. on Very Large Data Bases, 1993. M. Stonebraker, R. Katz, D. Patterson & J. Ousterhout, The design of XPRS. Int. Conf. on Very Large Data Bases, 1988. Teradata, DBC/1012 Data Base Computer, Concepts and Facilities. 1983. C.B. Walton, A.G. Dale, R.M. Jenevin, A taxonomy and Performance Model of Data Skew Effects in Parallel Joins. Int. Conf. on Very Large Data Bases, 1991. A. N. Wilschut, J. Flokstra & P. M. G. Apers, Parallelism in a main-memory system : The performance of PRISMA/DB. Int. Conf. on Very Large Data Bases, 23-27, 1992. A. N. Wilshut, J. Flokstra, P.G Apers, Parallel Evaluation of multi-join queries. ACMSIGMOD Int. Conf., 1995. J. L. Wolf, D. M. Dias, P. S. Yu, J. Turek, Algorithms for Parallelizing Relational Database Joins in the Presence of Data Skew. Research Report RC19236. IBM. 1993. M. Ziane, M. Zait, P. Borla-Salamet, Parallel Query Processing With Zig-Zag Trees. VLDB Journal, 2(3), 1993.

[Lam86] [Lan93] [Lo93] [Lop89] [Lov88] [Meh95] [Omi91] [Pat88] [Rah95] [Sch89] [Sch90] [Sha93] [She93] [Sto88] [Ter83] [Wal91] [Wil92] [Wil95] [Wol93] [Zia93]