1996 - Equilibrage de Charge Lors de L Execution de Requetes Sur Des Architectures Multiprocesseurs Hybrides

THSE
prsente LUNIVERSIT de VERSAILLES-SAINT-QUENTIN-EN-YVELINES pour obtenir le titre de DOCTEUR Spcialit INFORMATIQUE par
Luc BOUGANIM
Sujet de la thse :
QUILIBRAGE DE CHARGE LORS DE LEXCUTION DE REQUTES SUR DES ARCHITECTURES MULTIPROCESSEURS HYBRIDES
Soutenue le 13 dcembre 1996 devant le jury compos de M. Georges GARDARIN FLORY KERSTEN Prsident Rapporteurs
MM. Andr Martin
Claude DELOBEL Examinateurs Philippe PUCHERAL Patrick VALDURIEZ
Anaenza et Tana, mes parents et mes beaux-parents...
- i-
- ii-
Remerciements
Cette thse na quun auteur mais elle est le fruit de la collaboration et du travail de plusieurs personnes que je voudrais remercier chaleureusement: Andr Flory et Martin Kersten, pour avoir accept la tache ingrate dtre rapporteur de cette thse. Merci pour la lecture attentive du premier manuscrit et pour les remarques qui ont permis de lamliorer. Georges Gardarin, pour mavoir accueilli dans son DEA, puis en thse et enfin pour avoir prsider le jury. Merci de ta confiance. Tu ne devais pas trop tre en forme le jour de la soutenance car tu ne mas pas trop tortur avec les questions. Je mattendais au pire... Patrick Valduriez, coauteur de plusieurs publications et directeur de thse. Merci de mavoir suivi tout au long de ma thse. Je pense avoir bien fait de choisir un sujet qui te tient coeur: Le paralllisme Claude Delobel, pour mavoir fait lhonneur dassister une prsentation en priv. Je naurais, sans doute, plus jamais un tel pourcentage de professeurs experiments (et attentif) dans mon auditoire. Cette soutenance prive, 10 jours avant la date finale maura permis de prendre du recul. Philippe Pucheral, pour avoir participer au jury de thse et pour limmense plaisir quil ma fait, la veille de la thse, en dclarant ton tat de lart pourra, sans doute, me servir pour un cours. Preuve qucrire une thse est toujours utile. Merci pour tes encouragements et pour ton amiti. Les personnes qui mont fais dcouvrir lenseignement et mont permis denseigner: Michel Couprie, Frederic Voisin, Franoise Schlienger, Albin Morelle, Jean-Marc Saglio, Brigitte Safar. Vous mavez tmoign votre confiance en me proposant des cours, td ou tp. Jespre ne pas vous avoir deu. Les personnes du GDR Transaction anim par Philippe Pucheral et ceux du GDR Bases de donnes parallles et rparties anim par Mr. Hameurlain. Merci de maintenir vivante cette ouverture profitable tous. Nos collgues d'outre-Atlantique, car ils aiment le vin franais et lambiance du projet RODIN. Mike Franklin, pour les parties de petque. Claude Mohan, qui lui seul a puis tout les membres du projet. Alon Levy pour son humour lgendaire. Sans oublier Louiqua Rachid, Tamer Oszu, Denis Shasha. Les ex-membres de lquipe de recherche bases de donnes avances de BULL pour tout ce quils mont appris et pour leur amiti. Alex, Benoit, Carla, Pascale, Patrick, merci davoir t prsent du dbut la fn de ma thse. Sans oublier les grenoblois, Mauricio et Pascal.
- iii-
Les membres (et anciens membres) de lequipe RODIN pour lambiance rgnant dans le projet: Antony, le photographe. Claude, caviste. Linfatigable Dana (!!). Dimi et son parcours du thsard. Elisabeth, G.O. des sminaires Rodin. Bonjour Eric Simon. Esther, carioca da gema. Florian, shellman. Franois et son saucisson rcursif. Franoise, conseillre gnrale. Frederic, le dieu du PC. Hubert, le dictionnaire, merci de ton aide. Lincroyable JRO (!!). Laurent A., ramasseur de miettes. Laurent D., passager dAir India. Maja et ses gteaux. Lantenne Marcin. Marie-Joe et Barcelonne. Mikal, mon secrtaire particulier, Mokrane A. et Balaton. Mokrane B., et ses incroyables histoires. Olga et ses coups de poings. Les inclassables pour qui on ne peut faire une section mais quon voudrait remercier quand mme. Jean-Paul Chieze, matre de la KSR1. Les membres du personnel administratif de lINRIA, pour leur comprhension. Abdel Redouane, Christophe Masse, Paul Lebailly pour avoir fait leffort de venir ma soutenance. Enfin, je voudrais remercier mes parents, pour mavoir toujours pouss vers les tudes, mes beaux-parents qui prenaient le relais chaque veille de deadline, ma femme, Anaenza, pour sa patience. Jespre qu'un jour, je ne mentirais plus en disant demain jaurais du temps libre. Merci mon tout petit bout de fille, Tana, de me rappeler chaque soir quil faut que je rentre 7. Jespre que ton futur petit frre ou petite soeur sera moins exigeant(e). Luc Bouganim
- iv-
Table des matires

Chapitre I : Introduction .............................................1
1. Architectures matrielles ............................................... 1 2. Problmatique .................................................................. 2 3. Contexte ............................................................................. 4 4. Principales contributions ............................................... 4 5. Organisation de la thse ................................................. 6
Chapitre II : Excution parallle de requtes relationnelles.............................................9

1. Architectures matrielles ............................................... 10
1.1. Architectures mmoire partage ou shared-memory....... 11 1.2. Architecture distribues ou shared-nothing (SN) ............... 12 1.3. Architectures disques partags ou shared disks .............. 13 1.4. Architecture mmoire non uniforme ou NUMA ............. 14 1.5. Architectures hirarchiques .................................................... 15
2. Formes de paralllisme. .................................................. 16

2.1. Modle dexcution fragment .............................................. 17 2.1.1. paralllisme intra-oprateur .......................................... 17 2.1.2. Paralllisme inter-oprateur .......................................... 19 2.2. Modle dexcution non fragment........................................ 20
3. Oprateur de jointure : algorithme et paralllisation 21

3.1. Jointure par hachage mono-processeur ................................ 21 3.2. Jointure par hachage sur un modle dexcution fragment21 3.3. Jointure par hachage sur un modle non fragment ......... 22 3.4. Jointure par hachage non bloquant (pipeline hash join) .... 23
4. Arbre doprateurs .......................................................... 24 5. Mesure de performances ................................................ 26 6. Problmes lis lexcution parallle ......................... 28
- v-
6.1. Initialisation et mise en place du paralllisme ..................... 28 6.2. Contrle de lexcution parallle ........................................... 29 6.3. Interfrences et effets de convoi ............................................ 30 6.4. Le problme de la rpartition de la charge de travail ........ 32 6.4.1. Rpartition de charge intra-oprateur ......................... 33 6.4.2. Rpartition de charge inter-oprateur ......................... 36
7. Quelques modles dexcution parallle .................... 38

7.1. Gamma ...................................................................................... 38 7.2. PRISMA/DB ............................................................................. 41 7.3. Volcano ...................................................................................... 41 7.4. XPRS .......................................................................................... 45
8. Conclusion ........................................................................ 46
Chapitre III : Excution parallle et rpartition de charge dans DBS3.....................................47

1. Introduction ...................................................................... 47 2. Le modle dexcution parallle de DBS3 .................. 50
2.1. Plans dexcution parallles: le langage LERA-par ............. 50 2.2. Mise en uvre sur une architecture mmoire partage . 53
3. Analyse du modle .......................................................... 55 4. Etude de performance ..................................................... 57

4.1. Plate-forme dexprimentation .............................................. 58 4.1.1. Impact du modle Allcache sur DBS3 ......................... 59 4.2. Base de tests .............................................................................. 60 4.3. Impact du data skew ............................................................... 62 4.4. Degr de paralllisme et rpartition de charge ................... 63 4.5. Degr de fragmentation et rpartition de charge ............... 65 4.5.1. Surcots dun haut degr de fragmentation ............... 65 4.5.2. Un haut degr de fragmentation pour un meilleur support du skew ...................................................................................... 66
5. Conclusion ........................................................................ 68
- vi-
Chapitre IV : Excution parallle sur une architecture hirarchique .......................71

1. Introduction ...................................................................... 71 2. Problmatique .................................................................. 74
2.1. Systme dexcution ................................................................ 74 2.2. Plan dexcution parallle ....................................................... 75 2.3. Dfinition du problme ........................................................... 77
3. Le modle dexcution parallle DP ............................ 77

3.1. Concepts .................................................................................... 78 3.2. Rpartition de la charge .......................................................... 81 3.3. Exemple ..................................................................................... 83
4. Techniques dimplmentation ...................................... 84 5. Etude de performances ................................................... 87

5.1. Plate-forme dexprimentation .............................................. 87 5.1.1. Configuration de la plate-forme ................................... 88 5.1.2. Plans dexcution parallle ............................................ 89 5.1.3. Mthodologie ................................................................... 90 5.2. Rpartition locale de la charge ............................................... 90 5.2.1. Comparaison des performances ................................... 90 5.2.2. Impact des mauvaises distributions de donnes (data skew) ............................................................................................ 93 5.3. Rpartition globale de la charge ............................................ 94
6. Conclusion ........................................................................ 96
Chapitre V : Excution parallle sur une architecture NUMA .................................99

1. Introduction ...................................................................... 99 2. Modle fragment/non fragment ............................... 102 3. Plan dexcution parallle .............................................. 104 4. Problmes du pipeline synchrone en NUMA. ........... 105
4.1. Le pipeline synchrone ............................................................. 105 4.2. Impact du data skew ............................................................... 106
- vii-
5. Le modle dexcution parallle Progressive Sharing 109

5.1. Concepts .................................................................................... 110 5.2. Excution en mode normal .................................................... 111 5.3. Excution en mode dgrad ................................................... 113 5.4. Exemple ..................................................................................... 114 5.5. Excution darbres bushy ....................................................... 115
6. Etude de performance ..................................................... 117

6.1. Plate-forme dexperimentation .............................................. 117 6.1.1. La machine multiprocesseur KSR1 .............................. 117 6.1.2. Plans dexcution parallle ............................................ 119 6.2. Comparaisons avec SP sans data skew ................................ 120 6.3. Impact du data skew ............................................................... 121 6.4. Excution concurrente de plusieurs chanes pipelines ...... 123
7. Conclusion ........................................................................ 124
Chapitre VI : Conclusion ................................................127
Chapitre VII : Bibliographie ...........................................131
- viii-
Liste des gures

Fig. 1 Fig. 2 Fig. 3 Fig. 4 Fig. 5 Fig. 6 Fig. 7 Fig. 8 Fig. 9 Fig. 10 Fig. 11 Fig. 12 Fig. 13 Fig. 14 Fig. 15 Fig. 16 Fig. 17 Fig. 18 Fig. 19 Fig. 20 Fig. 21 Fig. 22 Fig. 23 Fig. 24 Fig. 25 Fig. 26 Fig. 27 Fig. 28 Fig. 29 Fig. 30 Fig. 31 Fig. 32 Fig. 33 Fig. 34 Fig. 35 Fig. 36 Fig. 37 Fig. 38 Fig. 39 Fig. 40 Architecture Standard dun SGBD Parallle .................................... 10 Architecture UMA ............................................................................ 11 Architecture shared-nothing .......................................................... 12 Architecture shared-disks .............................................................. 13 Architecture COMA .......................................................................... 15 Architecture Hirarchique ................................................................. 16 Mthodes de Fragmentation des Donnes ........................................ 17 Paralllisme Intra-oprateur .............................................................. 18 Paralllisme inter-oprateur indpendant .......................................... 19 Paralllisme inter-oprateur pipeline ................................................ 19 Jointure par hachage de deux relations R et S .................................. 22 hachage simple / hachage non bloquant ............................................ 23 Arbre de type linaire droit (right deep tree) .................................... 25 Arbre de type linaire gauche (left deep tree) ................................... 25 Arbre de type bushy (bushy tree) ...................................................... 26 Protection par verrou ......................................................................... 31 Paralllisation des Structures Partages ............................................ 32 Exemple de problmes de mauvaises distributions de donnes ........ 33 Processus oprateur ........................................................................... 39 Fonctionnement dun processus oprateur ........................................ 40 Requte slection suivie dune jointure ............................................ 43 Mise en oeuvre du pipeline dans volcano ......................................... 44 Graphe LERA-par de la requte filter-join ....................................... 51 oprateur dclench ........................................................................... 52 Oprateur pipelin ............................................................................. 53 Association des threads aux instances doprateurs. ........................ 53 Structure de donnes pour le modle dexcution de DBS3 ............. 54 Principe de Conception de la machine KSR1 ................................... 58 Impact des accs distant sur une slection de 200K tuples ............... 60 Diffrence des temps dexcution distants et locaux ........................ 60 Plan dexcution Ideal-Join ............................................................... 61 Plan dexcution Assoc-Join ............................................................. 61 Dgradation avec Assoc-Join ............................................................ 63 Dgradation avec Ideal-Join .............................................................. 63 Assoc-Join: Speed-up ........................................................................ 64 Ideal-Join: Speed-up ......................................................................... 64 Surcot de la fragmentation pour lIdeal-Join et lAssoc-Join (sans index temporaire) ..................................................................... 66 Temps de rponse de lIdeal-Join et Assoc-Join (Avec index temporaire) .................................................................... 66 Dgradation due au skew avec Ideal-Join ......................................... 67 Un arbre de jointure et le plan dexcution parallle associ. .......... 76
- ix-
Fig. 41 Fig. 42 Fig. 43 Fig. 44 Fig. 45 Fig. 46 Fig. 47 Fig. 48 Fig. 49 Fig. 50 Fig. 51 Fig. 52 Fig. 53 Fig. 54 Fig. 55 Fig. 56 Fig. 57 Fig. 58 Fig. 59 Fig. 60
Clich dune excution ..................................................................... 79 Exemple simple dexcution ............................................................ 83 Liste circulaire de files dactivations ................................................ 85 Performances relatives de SP, FP et DP ........................................... 91 Impact des erreurs du modle de cot avec FP ................................ 91 Speed-up de SP, FP, DP ................................................................... 93 Impact du skew sur DP ..................................................................... 93 Performance relative de FP et DP ..................................................... 95 Un arbre de jointure et larbre doprateur associ .......................... 105 Traitement dun tuple de R1 ............................................................. 106 Speed-up maximal thorique ............................................................ 108 Configuration initiale du PS ............................................................. 111 Exemple simple dune excution avec PS ........................................ 114 Architecture de la KSR1 ................................................................... 118 Speed-up de SP et PS (Pas de skew) ................................................ 120 Performance de PS relative SP ...................................................... 120 Speed-up de SP (skew) ..................................................................... 122 Speed-up de PS (skew) ..................................................................... 122 Acces privs / publiques en fonction du skew .................................. 123 Gain apport par des excutions concurrentes ................................. 123
- x-
Chapitre I
I
Introduction
Les nouvelles applications des Systmes de Gestion de Bases de Donnes
(SGBD), dont le but est dobtenir des statistiques partir de la consultation dun grand volume de donnes (entrepts de donnes), rendent incontournable lutilisation de machines multiprocesseur. An de rduire le temps de rponse des requtes dcisionnelles, celles-ci sont paralllises, cest dire dcoupes en sous tches, excutes sur des processeurs distincts. 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. Dans cette thse, nous proposons de nouvelles mthodes pour raliser lquilibrage de charge sur diffrentes architectures multiprocesseurs. Ce chapitre prsente rapidement le problme abord, le contexte et les principales contributions de cette thse. Il est organis comme suit. La section 1 prsente succinctement les diffrentes architectures multiprocesseurs. La section 2 dcrit la problmatique lie lexcution parallle dune requte. La section 3 xe le contexte de cette thse. La section 4 rsume les contributions. Enn, la section 5 dcrit lorganisation de ce document.
Architectures matrielles
De manire simpliste, une machine parallle est construite partir de plusieurs
processeurs, disques et modules mmoire. La diffrence dune architecture
- 1-
2 Problmatique
matrielle une autre dpend du partage ou non des ressources mmoire et/ou disque entre les diffrents processeurs de la machine. Suivant que linterconnexion processeurs/disques et processeurs/modules mmoire est totale ou partielle, on obtient diffrentes combinaisons darchitectures multiprocesseurs. Parmi ces combinaisons possibles, [Stonebraker86] propose de classier les architectures multiprocesseurs en trois grandes classes. (i) Larchitecture mmoire partage, o chaque processeur peut accder lensemble de la mmoire. Ces machines permettent dobtenir de bonnes performances et sont faciles programmer et congurer. Toutefois, les interfrences matrielles entre les processeurs lors de laccs la mmoire limitent leur extensibilit. (ii) Larchitecture shared-nothing, o chaque processeur dispose de sa propre mmoire et de ses propres disques. A linverse de la mmoire partage, larchitecture shared-nothing permet une grande extensibilit mais est complexe programmer et congurer. (iii) Larchitecture disques partags, o la mmoire reste prive mais les disques sont partags entre les processeurs. Elle tente de faire un compromis entre les deux architectures prcdentes mais prsente le problme de la cohrence des diffrentes copies dune mme page disque prsente dans plusieurs mmoires. Rcemment, plusieurs types darchitectures hybrides ont vu le jour:
Larchitecture mmoire non uniforme (NUMA) conue an de rpondre aux problmes dextensibilit de larchitecture mmoire partage. La mmoire y est physiquement distribue mais virtuellement partage par un mcanisme matriel. Dans le mme but dextensibilit, larchitecture hirarchique connecte plusieurs noeuds mmoire partage par un rseau rapide.
Problmatique
Une requte relationnelle, sous sa forme algbrique, est forme par un graphe
doprateurs sappliquant sur de grands ensembles de donnes ou relations. La paralllisation dune requte peut tre effectue selon deux axes: (i) horizontalement grce au paralllisme intra-oprateur, en distribuant un oprateur sur un ensemble de processeurs; un oprateur est donc dcompos en sous-oprateurs identiques, appels instances, sappliquant sur des donnes distinctes; et (ii) verticalement, grce au paralllisme inter-oprateur, en excutant plusieurs oprateurs de la requte sur diffrents processeurs. Les solutions proposes pour la rpartition de charge sont gnralement spciques un type de paralllisation et une architecture (mmoire partage, disques partags ou compltement distribues).
- 2-
Chapitre I
Introduction
Sur une architecture shared-nothing, le paralllisme intra-oprateur est obtenu grce la fragmentation des donnes [Boral90], [Apers92], [DeWitt90b]. Les mauvaises distributions de donnes (data skew), frquentes en pratique [Walton91], peuvent entraner une mauvaise rpartition de la charge. Ce problme a t trait en dveloppant des algorithmes de jointure spciques supportant diffrents types de skew [Kitsuregawa90], [DeWitt92a], [Shatdal93], [Berg92] et qui sont bass sur une redistribution dynamique. Avec le paralllisme inter-oprateur, la distribution des oprateurs sur les processeurs peut aussi entraner une mauvaise rpartition de la charge. Plusieurs tudes sont ddies ce problme [Rahm93], [Mehta95], [Rahm95], [Garofalakis96]. La rpartition de charge est faite statiquement pendant la phase doptimisation ou juste avant lexcution. Notons lapproche originale propose dans [Brunie95] qui permet de redistribuer dynamiquement la charge, au niveau intra et inter-oprateur, dans le cas o les estimations du modle de cot diffrent des valeurs relles. Larchitecture disques partags permet plus de exibilit puisque lensemble des processeurs ont un mme cot daccs tous les disques. Le paralllisme intraoprateur ne ncessite pas une fragmentation statique des oprandes qui peut tre ralise dynamiquement [Davis92][Lu91]. De plus, nimporte quel processeur peut, a priori, excuter nimporte quel oprateur, simpliant ainsi la rpartition de charge inter-oprateur [Lo93], [Hsiao94]. Enn, sur une architecture mmoire partage, les solutions aux problmes de rpartition de charge peuvent tre plus dynamiques puisque la redistribution du travail peut tre faite un cot minime, lensemble des processeurs ayant un accs quivalent la mmoire [Murphy91], [Hong92], [Shekita93]. Le problme de la rpartition de charge a donc t largement tudi pour des architectures classiques, tels que dnies par Stonebraker. Il nen est pas de mme pour des architectures hybrides comme les architectures hirarchiques ou ayant un accs non uniforme la mmoire. Ladaptation des techniques dveloppes pour les architectures classiques ne semble pas sufsante car elles risquent de ne pas proter pleinement des avantages de ces nouvelles architecture. Il nous faut donc, et cest lobjectif de cette thse, reconsidrer le problme dans ce nouveau contexte.
- 3-
3 Contexte
Contexte
Cette thse sinscrit dans le contexte de plusieurs projets ESPRIT. Tout dabord le
projet EDS (European Declarative System) entre 1989 et 1993, entrepris par Bull, ICL, Siemens, lECRC et lINRIA et dont le but tait de construire une machine parallle mmoire distribue ainsi que le logiciel associ. Outre cette machine, un SGBD relationnel a galement t conu. Deux implmentations de ce SGBD ont t ralises. La premire, EDBS, est ddie la machine de type shared-nothing EDS. La seconde, DBS3, a t dveloppe pour valider lapproche utilise pour EDBS sur une architecture mmoire partage. DBS3 et EDBS partagent le compilateur de requtes qui se base sur un modle distribu lors des phases doptimisation et de paralllisation des requtes. La principale diffrence entre les deux prototypes se situe donc au niveau de la phase dexcution. Cette premire tude est le point de dpart de cette thse car, contrairement aux prototypes existants [Hong91][Graefe90], DBS3 utilise un modle dexcution distribu sur une architecture mmoire partage. Nous avons donc cherch, dans un premier temps, tendre le modle dexcution de DBS3 an de proter de la souplesse de larchitecture mmoire partage. Le modle dexcution de DBS3 a alors t largement tendu an de supporter larchitecture hirarchique, architecture cible du projet ESPRIT III IDEA [IDEA92] dont un des objectifs tait la construction dun SGBD parallle orient objet.
Principales contributions
Dans cette thse, nous nous intressons donc au problme de rpartition de
charge pour des architectures non-conventionnelles. Nous avons propos, mis en oeuvre et valu une stratgie dexcution de requtes permettant dobtenir un bon support des mauvaises distributions de donnes sur le prototype DBS3 conu pour une architecture mmoire partage. Nous avons alors tendu les concepts de DBS3 dans le but de prendre en compte une architecture hirarchique. Un modle dexcution permettant une rpartition dynamique de la charge deux niveaux (locale sur un noeud-SMP et globale entre les noeuds) a t dvelopp puis valu. Le principal atout de ce modle dexcution est quil permet de maximiser la rpartition de charge locale (peu coteuse) et
- 4-
Chapitre I
Introduction
rduire ainsi le besoin de rpartition de charge globale entranant des surcots de communication. Finalement, nous avons reconsidr lexcution parallle de requtes complexes sur une architecture mmoire non uniforme et montr quun modle dexcution non fragment (i.e. tous les processeurs accdent potentiellement lensemble des donnes) semble plus adapt ce genre darchitecture. Nous avons identi deux consquences des mauvaises distributions de donnes et propos un nouveau modle dexcution, adapt cette architecture, permettant de supporter ces problmes. Notre principale contribution a donc t, partir de lexprience acquise et des concepts de bases utiliss dans le prototype DBS3, de concevoir, implmenter et valuer deux modles dexcution, chacun adapt une architecture spcique. Dans ces deux modles, les processeurs ne sont pas assigns lexcution dun seul oprateur. Ils peuvent excuter nimporte quel oprateur du graphe doprateur, pourvu que les donnes traiter soient disponibles. Lassociation processeur/ oprateur est donc compltement dynamique. A notre connaissance, les modles dexcution existant associent statiquement les processeurs aux oprateurs, cest dire, que pendant une phase de lexcution de la requte, un processeur ne peut excuter quun et un seul oprateur. Les consquences ngatives de cette association rigide sur les performances sont mis en vidence dans [Wilshut95]. Premirement, lallocation des processeurs se fait statiquement, gnralement lors de loptimisation de la requte, et est base sur un modle de cot. Les invitables erreurs du modle de cot peuvent alors entraner une mauvaise rpartition de la charge. Mme en supposant parfait le modle de cot, nous ne pouvons allouer une fraction de processeur un oprateur. Les approximations dues au problme des parties entires (les processeurs et les oprateurs sont des entits discrtes) sont donc une seconde source de mauvaise rpartition de la charge. Enn, lorsque plusieurs oprateurs sexcutent en parallle et ont un lien producteur-consommateur, certains processeurs sont inactifs, attendant la production du premier tuple traiter (pipeline delays). Grce lassociation dynamique existant entre les processeurs et les oprateurs dans nos deux modles dexcution, lensemble des problmes voqus ci-dessus disparaissent. De plus, ils permettent de conserver de bonnes performances en cas de mauvaises distributions de donnes.
- 5-
5 Organisation de la thse
Organisation de la thse
Cette thse est organise comme suit. Nous prsentons en dtail, dans le chapitre
II, lensemble des notions ncessaires la comprhension de cette thse: les architectures matrielles, les diffrentes formes de paralllisme, les algorithmes de jointures parallle par hachage, les diffrentes stratgies dexcution de requtes, ainsi que les mtriques permettant de quantier le gain obtenu par une excution parallle. Les diffrents obstacles pour lobtention de bonnes performances sont introduit. Nous insistons sur le problme de rpartition de charge, objet dtude de cette thse, et prsentons les diffrentes approches existantes. Finalement, les principaux modles dexcution existants sont dcrit. Le Chapitre III est consacr ltude du modle dexcution de DBS3, point de dpart de notre recherche. Aprs avoir rapidement dcrit le prototype, nous prsentons le modle de paralllisation et le modle dexcution de DBS3. Nous ralisons une analyse de ce modle face de mauvaises distributions de donnes, et identions trois paramtres inuant sur les performances. Une srie de mesures mene sur la machine KSR1 munie de 72 processeurs montrent linuence de ces paramtres. Ce chapitre est bas sur le papier intitul Skew handling in the DBS3 parallel Database System prsent la confrence ACPC96 [Bouganim96d]. Le Chapitre IV prsente un modle dexcution de requtes multi-jointures dans une architecture parallle hirarchique. Nous proposons une approche dynamique qui maximise l'quilibrage local de charge (sur un noeud) et minimise ainsi le besoin de redistribution du travail entre les noeuds. Nous effectuons une valuation de performances en utilisant une implmentation de notre modle sur la machine KSR1. Ce chapitre est bas sur le papier intitul Dynamic Load Balancing in Hierarchical Database Systems prsent au VLDB96 [Bouganim96c]. Dans le chapitre V, nous reconsidrons les modles dexcutions adapts la mmoire partage dans le contexte des architectures mmoire non uniforme. Nous montrons, tout dabord, quun modle dexcution pour ce type darchitecture ne doit pas utiliser la fragmentation des donnes (comme pour les systmes sharednothing), mais plutt exploiter des stratgies conues pour la mmoire partage comme le pipeline synchrone (SP). Nous montrons alors quune mauvaise distribution des donnes pnalise srieusement SP, et proposons un nouveau modle dexcution qui rpond ce problme. De nouveau, nous validons notre approche sur la machine KSR1. Ce chapitre est bas sur le papier intitul Parallel Query Execution in NUMA
- 6-
Chapitre I
Introduction
multiprocessors soumis la publication [Bouganim96e]. Le chapitre VI conclut cette thse par une analyse critique des rsultats obtenus et une proposition dextension pour de futurs travaux sur les modles dexcutions parallles.
- 7-
5 Organisation de la thse
- 8-
Chapitre II Excution parallle de requtes relationnelles

II
Lobjectif spcique dun systme parallle de gestion de bases de donnes est de proter au mieux des caractristiques de la machine multiprocesseur sur laquelle il sexcute pour satisfaire de gros besoins en performance. Son efcacit est directement fonction de sa rapidit traiter la charge de travail constitue par 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 inter-requte vise amliorer le dbit transactionnel de transactions courtes de type OLTP (On Line Transaction Processing). La mise en oeuvre du paralllisme inter-requte requiert essentiellement des modications au niveau du noyau du SGBD [Casadessus93]. Nous ne considrons pas ici cette forme de paralllisme potentiellement prsent dans les systmes de bases de donnes multiutilisateurs. 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 mis en oeuvre pour rduire le temps de rponse de chaque transaction. La gure 1 prsente larchitecture standard dun SGBD exploitant ce type de paralllisme. Les requtes de lutilisateur sont envoyes au prprocesseur qui vrie 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 efcaces, 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
- 9-
1 Architectures matrielles
dexcuter en parallle. Lexcution est nalement prise en charge par le moteur dexcution dont le rle est dobtenir les meilleures performances sur larchitecture multiprocesseur cible.
Requte SQL Compilation

Prprocesseur
Algbre Relationnelle Informations schma
Schma de la Base
Informations physiques
Optimiseur parallle
Plan dexcution parallle
Excution
Moteur dexcution
....
Machine parallle
Figure 1 : Architecture Standard dun SGBD Parallle
Ce chapitre prsente lensemble des notions ncessaires la comprhension de cette thse 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 dtaille les algorithmes de jointures par hachage, utiliss tout au long de cette thse. La section 4 prsente les plans dexcution parallle et en particulier, les diffrentes formes darbres dexcution. La section 5 dcrit les mtriques permettant de quantier le gain dune excution parallle. Les problmes lis lexcution parallle sont dcrit dans la section 6. Le problme de la rpartition de charge est plus largement abord, et les solutions existantes sont dcrites. Enn, la section 7 dcrit les principaux modles dexcution existants. La section 8 conclut ce chapitre et positionne notre tude.
Architectures matrielles
Dans cette section, nous prsentons dabord les architectures conventionnelles
(mmoire partage, disques partags ou compltement distribue) puis nous
- 10-
Chapitre II
Excution parallle de requtes relationnelles
intressons aux architectures hybrides qui tentent de combiner les avantages de chaque architecture.
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 congurations comme les machines MULTIMAX srie 500 fabriques par ENCORE ou la srie SYMMETRY fabrique par SEQUENT [Lovett88].
P1 cache
Pn cache
Mmoire1
Mmoirek
Disque1
Disquep
Bus
Figure 2 : Architecture UMA
Larchitecture UMA (c.f. gure 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 congurations. Pour augmenter lextensibilit de cette architecture, un cache priv est associ chacun des processeurs. Le cache vite au processeur daccder la mmoire commune, et donc au bus, lorsque la donne demande est cache. Cependant, dans la mesure o plusieurs copies dune mme donne peuvent rsider simultanment dans des caches diffrents, la cohrence entre ces copies doit tre assure. Elle garantit que lorsquun processeur lit une donne, il obtient une valeur correcte. Une description plus complte des diffrents mcanismes de gestion de la cohrence des caches peut tre trouve dans [Lilja93] ou [Dubois92]. Malgr lajout de caches entre le bus et les processeurs, lextensibilit des
- 11-
architectures UMA est trs limite, et ne dpasse pas quelques dizaines de processeurs (une trentaine en gnral)1. Au-del, les performances scroulent rapidement du fait des contentions sur le bus. 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 efcacement ralise grce lutilisation de la mmoire partage. Enn, le modle de programmation des architectures mmoire partage facilite grandement le portage dune application dveloppe pour un systme mono-processeur. 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 [Stonebraker88], Volcano [Graefe94], DBS3 [Bergsten93] et Monet [Boncsz96]. Pour les systmes commerciaux, Oracle [Davis92] et Informix [Davison92] 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 (gure 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 [Boral88a] [DeWitt92b] considrent

1. Remarquons tout de mme quactuellement, des architectures mmoire partag avec 64 processeurs sont commercialises (comme la Cray Researchs 6400)
- 12-
Chapitre II
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 [Chen93], Bubba [Boral88a], Gamma [DeWitt90b], Teradata [Teradata83], EDBS [Lopez89] et PRISMA/DB [Apers92].
1.3.
Architectures disques partags ou shared disks
Larchitecture disques partags est illustre gure 4. Cette architecture a t notamment adopte dans Oracle partir de la version 6.0 (Oracle Parallel Server [Davis92]). 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 Pn Mmoire locale
Disque
Disque
Disque
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
- 13-
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 [Pirahesh90].
1.4.
Architecture mmoire non uniforme ou NUMA
A linverse de larchitecture UMA, larchitecture NUMA (Non Uniform Memory Access) noffre pas un cot uniforme pour laccs la mmoire. En effet, pour rpondre au problme dextensibilit de larchitecture UMA, chaque processeur possde ici sa propre mmoire locale et accde aux autres modules mmoire via un rseau dinterconnexion. Ce rseau peut, par exemple, tre constitu dun ensemble hirarchique de bus. Dans ce cas, le temps daccs la mmoire dpend du nombre de bus traverss. Dune manire gnrale, la bande passante de ce type de rseau augmente en fonction du nombre de processeurs, permettant une bien meilleure extensibilit de larchitecture NUMA (quelques centaines de processeurs) comparativement larchitecture UMA. Notons enn que les disques sont gnralement attachs aux processeurs pour ne pas limiter lextensibilit de la machine. Ils sont donc physiquement distribus, mais laspect mmoire partage de la machine permet leur partage virtuel puisque les donnes stockes sur disques sont copies en mmoire (accs DMA) avant dtre accdes par les processeurs. Un exemple type de machine adoptant une architecture mmoire partage de type NUMA est donn par la machine KSR1 fabrique par la socit Kendall Square Research. Dans cette machine, chaque mmoire locale associe un processeur est gre comme un cache. Ainsi, la rfrence une adresse mmoire provoque automatiquement le dplacement physique de son contenu et sa matrialisation dans lespace cache associ au processeur. Si le contenu de la mmoire est dj matrialis localement, la navigation de la donne dun cache vers un autre est inutile, laccs tant alors direct. Bien sr, une donne accde en lecture peut se retrouver duplique dans plusieurs caches et le systme doit donc garantir la cohrence entre les diffrentes copies comme sur une architecture UMA. Cette ralisation particulire de larchitecture NUMA, illustre gure 5, est aussi connue sous le nom darchitecture COMA (Cache Only Memory Architecture). Notons que sur cette architecture la gestion de la cohrence de caches peut constituer le goulot dtranglement du systme, et cela mme si cette cohrence est ralise par le matriel garantissant des performances bien suprieures aux systmes de mmoire virtuellement partage par logiciel [Carter91][Li89].
- 14-
Chapitre II
Disque(s) P1 Mmoire cache
Disque(s) P2 Mmoire cache
Disque(s) Pn Mmoire cache
Gestion des caches
Figure 5 : Architecture COMA
De nombreux prototypes de machine NUMA [Cheriton91] [Lenoski92] [Goodman88] [Hagersten92] ont vu le jour. Des exemples rcents de machines commerciales architecture NUMA sont la NUMA-Q de Sequent et la Convex SPP1200 qui peuvent supporter quelques centaines de processeurs.
1.5.
Architectures hirarchiques
Une architecture de type hirarchique est en fait une combinaison de larchitecture mmoire partage et mmoire distribue. Lide est ici de construire une machine mmoire distribue dont chaque noeud adopte une architecture parallle mmoire partage. Cette architecture a dabord t propose par Bhide [Bhide88] puis reprise par Pirahesh [Pirahesh90] et Boral [Boral90]. [Hua91b] effectue une comparaison de cette architecture avec les architectures mmoire partage et shared-nothing. Une description dtaille en est propose par Graefe [Graefe93a] et reprise par la figure 6 Les avantages dune telle architecture sont vidents. Elle permet dobtenir lextensibilit dune architecture shared-nothing en gardant une partie de la exibilit apporte par la mmoire partage. En effet, elle permet linterconnexion dun grand nombre de noeuds mmoire partage, pouvant eux-mmes tre de puissant multiprocesseur. Dans chaque noeud, les communications entre les processeurs se font efcacement grce la mmoire partage. Ceci a deux consquences. Dune part, les performances obtenues lors de lexcution dune requte sur une telle architecture seront meilleures que sur une machine shared-nothing. Dautres part, la rpartition de la charge entre les processeurs peut tre faite de manire efcace. Ce
- 15-
2 Formes de paralllisme.
point est lobjet du chapitre IV.

Rseau dInterconnexion P1 P2 P3 P1 P2 P3 P1 P2 P3
Disque Disque Disque
Disque Mmoire
Pn
Disque Mmoire
Pk
Disque Mmoire
Pm
Figure 6 : Architecture Hirarchique
Formes de paralllisme.
Le paralllisme intra-requte rsulte, de lexcution en parallle de diffrents
fragments dune mme requte obtenus lors de la phase de paralllisation de la requte. 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 inter-oprateur. 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 inter-oprateur 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.
- 16-
Chapitre II
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 gure 7, sont round-robin, par hachage et par intervalle (range).
... ... ... Hachage ... a-g ... h-m ... Intervalle u-z
Round-Robin
Figure 7 : 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. Enn, 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 sousensemble de paquets, mais peuvent gnrer des fragments de taille trs diffrente. Dans [Berg92], cette proprit est utilise an de rduire la complexit dune requte. Une technique appele task elimination permet de supprimer, dans une requte multijointure lensemble des sous-jointure ne produisant aucun rsultat. Notons que, pour
- 17-
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 intra-oprateur consiste alors dcomposer loprateur initial en sous-oprateurs utilisant chacun, un paquet de chaque relation en entre. Souvent, la dcomposition de loprateur peut bncier de la rpartition initiale des donnes, sinon, une redistribution pralable des donnes est requise avant lexcution de loprateur. Pour illustrer le paralllisme intra-oprateur, 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 gure 8). 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.1
Sel.2
Sel.3
Sel.n
Sel. Sel.i
oprateur Linstance i de loprateur
R1
R2
R3
Rn
Figure 8 : 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 sous-jointures 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.
- 18-
Chapitre II
Enn, 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.
OP3 OP1
R
OP2
S
Figure 9 : Paralllisme inter-oprateur indpendant
Le paralllisme inter-oprateur indpendant consiste excuter en parallle deux oprateurs indpendants du graphe de la requte. Les plans dexcution de type bushy-tree (voir section 4) offrent de nombreuses opportunits pour mettre en uvre cette forme de paralllisme. Sur lexemple de la gure 9, OP1 et OP2 peuvent proter de ce type de paralllisme.
OP2
S T
OP1
R
Figure 10 : Paralllisme inter-oprateur pipeline
Le paralllisme inter-oprateur pipeline consiste excuter deux oprateurs du graphe ayant un lien producteur-consommateur. Le rsultat du producteur (OP1 sur la gure 10) nest pas matrialis mais envoy en pipeline loprateur suivant (OP2)
- 19-
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 [Teradata83] ou Gamma [Dewitt86] forcent chaque relation tre fragmente sur lensemble des noeuds de la machine parallle (full-declustering). Le paralllisme intra-oprateur met alors contribution lensemble des processeurs, ne laissant plus aucun intrt au paralllisme interoprateur. De plus, la possibilit dexploiter le paralllisme inter-oprateur complexie 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 threads2 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
2. 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 [Posix].
- 20-
Chapitre II
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 [Pirahesh90] [Hong92] [Shekita93] et reprise dans le chapitre V. 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.
Oprateur de jointure : algorithme et paralllisation

Dans cette thse, nous nous intressons plus spcialement lexcution de
requtes multi-jointures. Bien que cette tude ne soit pas spcique un algorithme de jointure particulier, nous utilisons la jointure par hachage car elle offre gnralement de meilleures performances. Dans cette section, nous prsentons le principe de la jointure par hachage puis montrons comment celle-ci peut tre paralllise dans un modle fragment et non fragment. Enn, nous dcrivons un nouvel algorithme de jointure par hachage propos dans [Wilshut91].
3.1.
Jointure par hachage mono-processeur
Une jointure par hachage est effectue en deux phases squentielles. Dans la premire phase, dite phase de construction ou build, la relation interne est hache en un grand nombre de paquets (typiquement gale au nombre de tuples). Une fois que la table de hachage est entirement construite, la deuxime phase dite de probe commence. La mme fonction de hachage est applique chaque tuple de la relation externe, puis le tuple qui est test avec le paquet correspondant an de produire le rsultat qui peut tre envoy en pipeline loprateur suivant. Il faut noter que, si la table de hachage est sufsamment grande, il y a beaucoup de chance pour que chaque paquet contienne peu de tuples ou mme aucun.
3.2.
Jointure par hachage sur un modle dexcution fragment
Dans un modle dexcution fragment, pour que la jointure puisse seffectuer paquet paquet, il faut que les deux relations joindre soient fragmentes sur lattribut de jointure. Supposons le cas le plus gnral, cest dire lorsque les deux relations doivent tre redistribues. Il y a donc quatre oprateurs qui sexcuteront en deux phases squentielles (voir gure 10). Pour la simplicit de la prsentation,
- 21-
3 Oprateur de jointure : algorithme et paralllisation
nous supposons que p processeurs sont allous pour chaque oprateur et que le degr de fragmentation est gal au degr de paralllisme3. Lexcution se passe comme suit. Les processeurs excutant le scan1 vont lire en parallle les paquets de la relation R distribus sur les p disques correspondant. Pour chaque tuple lut, une fonction de hachage h1 est applique sur lattribut de jointure et permet de fragmenter en p paquets la relation R. Le tuple est envoy au processeur (du build) correspondant la valeur de hachage. Sur rception dun tuple, chaque processeur calcule une seconde fonction de hachage h2 sur le mme attribut et insre le tuple dans la table de hachage locale. Lorsque lensemble des tuples ont t lus sur le disque et redistribus, p tables de hachage sont construites et la phase de build est termine.
Probe
Build Scan2 Scan1 R S
Figure 11 : Jointure par hachage de deux relations R et S
Les p processeurs du scan2 vont alors lire les tuples de la relation S et appliquer la mme fonction de hachage h1. Chaque tuple est envoy au processeur du probe correspondant sa valeur de hachage. Chaque processeur va alors appliquer la seconde fonction de hachage, h2 pour tester le tuple avec lentre de la table de hachage de R correspondante et produire, ventuellement le rsultat.
3.3.
Jointure par hachage sur un modle dexcution non fragment
Dans un modle non fragment, et donc sur une architecture mmoire partage, lexcution se passe diffremment. Les processeurs excutant le scan1, vont lire en parallle les paquets de la relation R distribus sur les disques correspondant (les relations sont fragmentes sur les disques pour parallliser les entres/sorties). Ils appliquent alors une fonction de hachage h chaque tuple sur lattribut de jointure et linsre dans une table de hachage commune tous les processeurs. Lorsque toute la relation R a t lue, les processeurs vont lire la relation S et appliquer la mme
3. Le degr de fragmentation nest pas forcment gale au degr de paralllisme, bien que ce soit gnralement le cas sur les architectures shared-nothing (voir chapitre III).
- 22-
Chapitre II
fonction de hachage h an de dterminer lentre de la table de hachage de R correspondant chaque tuple an de produire, ventuellement le rsultat. Les avantages et les inconvnients des modles fragments et non fragments se remarquent facilement sur cet exemple et sont rsums dans le tableau suivant:
Modle fragment Fonctionne sur toutes les architectures Pas dinterfrence entre les processeurs (chacun travaille dans son coin) Surcot de redistribution Synchronisation producteur/consommateur Assignation des processeurs aux oprateurs Modle non fragment (pipeline synchrone) Restreint la mmoire partage Interfrences entre les processeurs (construction et consultation de la table de hachage) Pas de redistribution Pas de synchronisation Assignation des processeurs aux chanes pipeline
Tableau 1 : Comparaison dun modle fragment et non fragment
3.4.
Jointure par hachage non bloquant (pipeline hash join)
Dans [Wilshut91], un nouvel algorithme est dvelopp an de supprimer laspect bloquant de la jointure par hachage classique. Cet algorithme, dit de jointure par hachage non-bloquant utilise le mme principe que la jointure par hachage classique mais supprime la premire phase de build. Elle fonctionne de faon symtrique pour la relation interne et externe, et deux tables de hachage sont construites au fur et mesure de lexcution. Ainsi, chaque tuple dune relation, R par exemple, est hach et test avec la table de hachage de S existante un instant donn. Il est ensuite insr, quel que soit le rsultat du test, dans la table de hachage de R. De la mme manire, un tuple de S est test avec la table de hachage de R puis insr dans la table de hachage de S. Insertion dans la table de hachage table de hachage Test Test avec la table de hachage R S Test table de hachage S
table de hachage
Figure 12 : hachage simple
hachage non bloquant
- 23-
4 Arbre doprateurs
Par exemple, supposons quun tuple tR de R joigne avec un tuple tS de S. A un instant donn, tR sera test avec la table de hachage de S. Deux cas se prsentent. Soit tS a dj t insr dans la table de S et le tuple rsultat est produit, soit ce nest pas le cas, et, le tuple rsultat sera de toute faon produit. En effet, tS sera forcment test avec la table de hachage de R o tR aura t insr. La gure 12 illustre les deux stratgies. Cet algorithme de hachage non-bloquant se paralllise facilement et permet dexcuter lensemble des oprateurs concurremment (en pipeline). De plus, il permet de produire les premiers tuples rsultat immdiatement. Toutefois, il entrane une consommation mmoire plus importante puisquil ncessite la matrialisation complte de toutes les relations.
Arbre doprateurs
Larbre doprateur provient de la macro-expansion de larbre de jointure
[Hasan94]. Les noeuds reprsentent les oprateurs atomiques de l'algbre relationnelle et les arcs reprsentent les ots 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. Considrons un arbre d'oprateur utilisant la jointure par hachage. Trois oprateurs sont ncessaires: scan pour lire chaque relation de base, build et probe. L'oprateur de build produit la table de hachage de manire bloquante. Le probe produit, en pipeline, les tuples rsultats. Ainsi, pour une jointure par hachage, il y a toujours un arc bloquant entre le build et le probe. Plusieurs formes darbres peuvent tre considres: linaires (gauches ou droits) [Schneider90], zigzag [Ziane93] ou bushy [Shekita93]. Les gures 13,14 et 15 prsente respectivement les arbres droits, gauches et bushy pour une requte effectuant la jointure de 4 relations R, S, T et U. Sur chaque gure, nous reprsentons larbre de jointure et larbre doprateurs. Nous suivons la convention prise dans [Schneider90]: les tables de hachage sont gauche, i.e., les ches en gras de gauche droite reprsentent des arcs bloquants, les ches nes de droite gauche sont des
- 24-
Chapitre II
arcs pipeline.
Probe 3 Build 3 Probe 2 Build 2 Scan T Probe 1 Build 1 Scan S Scan R
U T S R
Scan U
Figure 13 : Arbre de type linaire droit (right deep tree)
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 au moins en deux phases. Dans la premire phase, toutes les tables de hachage sont construites en parallle (celles-ci peuvent aussi tre construites en squence). Dans la deuxime phase, tous les probes (ainsi que le premier scan) sont excutes 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 tables de hachage puissent tenir en mmoire. Dans le cas contraire, lexcution des probes en parallle gnrera du basculement de tampon (swapping).
Probe 3 Build 3 Scan U Probe 2 Build 2 Probe 1 Build 1 Scan R Scan S Scan T
U T R S
Figure 14 : Arbre de type linaire gauche (left deep tree)
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
- 25-
5 Mesure de performances
phase une relation intermdiaire (ou le rsultat nal) est matrialise. Cette stratgie permet donc du paralllisme pipeline restreint puisque seules 3 oprateurs peuvent tre excuts en pipeline un instant donn (e.g. scanS, Probe1 et Build2). Cette stratgie dexcution est utilise lorsque la mmoire est limit car elle ne matrialise jamais plus de deux relations simultanment (une relation intermdiaire de base et le rsultat de sa jointure avec une relation de base qui est pipeline). Les arbres gauches et droits sont deux stratgies extrmes dexcution dun arbre linaire. les arbres zigzag, introduits dans [Ziane93], 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. 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 [Lanzelotte93]. De plus, ils offrent un bon compromis entre le degr de paralllisme inter-oprateur et la consommation mmoire (voir [Shekita93]). Enn, la considration des arbres bushy lors de loptimisation augmente considrablement lespace de recherche, permettant, de ce fait, lobtention potentielle de meilleurs plans dexcution.
Probe 3 Build 3 Probe 1 Build 2 Scan T Build 1 Scan S Scan R Probe 2 Scan U
Figure 15 : Arbre de type bushy (bushy tree)
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 quantier
- 26-
Chapitre II
le gain obtenu par une excution parallle. Les plus connues sont le speed-up et le scale-up (voir par ex. [Singh93]). 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 dnition formelle du speed-up est la suivante: soit une tche de taille xe 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 dni par :
speed up ( p )
= --------
Ts Tp
et le speed-up est idal si speed-up (p) = p. On peut dduire du speed-up lefcacit Ep de lalgorithme parallle, cest dire le rapport entre le speed-up effectif et le speed-up idal :
Ep
= -----------------Tp p
Ts
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 lefcacit 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 efcaces (e.g. 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 dnition 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 dni par la formule suivante :
- 27-
6 Problmes lis lexcution parallle
scale up
T ( P1, p ) = ------------------------------------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 suft 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.
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, puisque cest le thme central de ce mmoire. Les solutions mises en oeuvre pour la rpartition de charge sont notamment dcrites dans cette section.
6.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. Le processus dinitialisation et de mise en place du paralllisme est un processus en gnral squentiel prcdant 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 [Wilschut92] montrent un effondrement du speed-up
- 28-
Chapitre II
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. [Wilschut92] 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: R = an + -----cN 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 : n 0 =
cN -----a
le speed-up maximal tant gal
1 S 0 = -- n 0 . 2
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 an de diminuer le degr de paralllisme de chaque oprateur et den augmenter le speed-up.
6.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 n. 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 [Boral82], 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.
- 29-
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 [Chachaty92]. 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 [Dageville91][Borla-Salamet91b] permet llaboration de stratgies optimises et adaptes chaque requte, qui conduisent une rduction du nombre de messages changs.
6.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 conits 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 conits daccs. Par exemple, au niveau dun disque, ladoption de disques RAID (Redondant Array of Inexpensive Disks [Patterson88]), permet de limiter ces interfrences. Quant aux interfrences logicielles, elles apparaissent lorsque plusieurs threads ou
- 30-
Chapitre II
processus accdent en parallle une mme donne [Fontenot89]. Pour prvenir tout risque dincohrence, une variable verrou [Lamport86] est gnralement utilise an de squentialiser les accs la donne (c.f. gure 16).
Variables partages
Verrou Threads
Figure 16 : Protection par verrou
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 [Blasgen79] 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 [Graefe92], 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 [Hong91] comme un des facteurs limitant le degr de paralllisme. La solution gnrale pour remdier aux problmes dinterfrences consiste
- 31-
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. gure 17).
Variables partages Paralllisation des Structures Verrou Variables partages
structure squentielle
structure Parallle
Figure 17 : Paralllisation des Structures Partages
Cette solution a t adopte dans DBS3 [Casadessus94] la structure daccs aux tampons de la base, ce qui permet leur accs simultan par un grand nombre de threads.
6.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 difcile car le temps dexcution peut grandement varier dune tche lautre. Cela est principalement d deux raisons. Premirement, si le paralllisme inter-oprateur 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
- 32-
Chapitre II
rpartition biaise des donnes (ou data skew) peut conduire des diffrences de temps dexcution entre les instances dun mme oprateur. La section 6.4.1 et 6.4.2 dtaillent le problme de la rpartition de charge intra et inter-oprateur et donnent un aperu des solutions existantes pour chaque forme de paralllisme.
6.4.1.
Rpartition de charge intra-oprateur
Walton et al. [Walton91] a classi les effets dune mauvaise rpartition des donnes lors dune excution parallle avec un modle dexcution fragment4. Ceux-ci sont rsums sur un exemple, prsent la gure 18. 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.
JPS JPS AVS/TPS
Res2
AVS/TPS
Res1 Join1 Join2
S2
AVS/TPS RS/SS RS/SS
S1
AVS/TPS
Scan1 R2
Scan2 R1
Figure 18 : Exemple de problmes de mauvaises distributions de donnes
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
4. Voir chapitre V pour une analyse sur un modle non fragment.
- 33-
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. [Wolf90],[Wolf91],[Wolf93] proposent de modier 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 x par avance. Si aucune rpartition ne satisfait ce prrequis, la mthode est itre en modiant 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 rst [Graham69]) pour rpartir au mieux les sous-jointures entre les processeurs. Kitsuregawa et al. [Kitsuregawa90] proposent un algorithme supportant les mauvaises distributions de donnes et conu spciquement 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. Ceuxci 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.
- 34-
Chapitre II
Omiecinski [Omiecinski91] propose une approche similaire pour une architecture mmoire partage et utilise lheuristique rst t decreasing pour redistribuer les sous-paquets aux processeurs. Cependant, cette redistribution ne ncessite pas un mcanisme matriel particulier. Dewitt et al. [DeWitt92a] 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 an de dterminer le degr de skew et permet de choisir un algorithme plus ou moins insensible au mauvaises distributions. Quatre algorithmes spciques sont proposs et implments, en plus de lalgorithme de jointure par hachage Hybrid hash join [Schneider89]. 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. [Shatdal93] proposent dutiliser la mmoire virtuellement partage (SVM), implmente par logiciel, sur un environnement shared-nothing, an de raliser dynamiquement une redistribution de la charge de travail. Lalgorithme propos combine lutilisation de la mmoire virtuellement partage et lenvoi de messages an 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 an de comparer cette stratgie avec celle dvelopp dans [DeWitt92a]. Lajout dune phase dchantillonnage pralable des relations permet damliorer encore les performances. Plus rcemment, Brunie et al. [Brunie95] [Brunie96] 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 distribution des donnes. Pour cela, des oprateurs spciques, appels control operators sont insrs dans le plan dexcution parallle an 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 an de prvenir le skew de redistribution et le skew de produit de jointure. Notons que cet oprateur peut aussi modier le degr de paralllisme intra-oprateur de loprateur suivant si besoin est. Il ralise ainsi dynamiquement la rpartition de charge intra et inter-oprateur.
- 35-
6.4.2.
Rpartition de charge inter-oprateur
An dobtenir une bonne rpartition de charge au niveau inter-oprateur, il est ncessaire de dterminer, pour chaque oprateur, son degr de paralllisme intraoprateur 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 an dobtenir la meilleure rpartition de charge. Chen et al. [Chen93] 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. [Hsiao94] 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 identier 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. [Wilshut95] 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
- 36-
Chapitre II
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. Par exemple, si nous voulons rpartir 5 processeurs sur 3 oprateurs de mme cot, il y aura une mauvaise rpartition puisque 2 des oprateurs seront excuts sur 2 processeurs et resteront inactifs en attente de la n du traitement du dernier oprateur excut par un seul processeur.
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: Enn, 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 difcilement 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. [Mehta95] 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. Enn, 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. [Rahm95] proposent dautres algorithmes pour le choix du degr de paralllisme et des processeurs. Les algorithmes proposs cherchent rpartir efcacement 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
- 37-
7 Quelques modles dexcution parallle
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. [Hong92] proposent, lors de lexcution concurrente de plusieurs chanes pipeline, dajuster dynamiquement le degr de paralllisme intra-oprateur de chacune an 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 modie le degr de paralllisme de chaque chane pipeline dynamiquement (en cours dexcution).
Quelques modles dexcution parallle

Nous allons maintenant considrer les principaux modles dexcution adopts
dans les systmes parallles de gestion de base de donnes pour mettre en uvre lexcution parallle des requtes.
7.1.
Gamma
Gamma, dvelopp luniversit du Wisconsin, est lun des systmes pionniers pour les architectures parallles mmoire distribue. Il en est aussi lun des plus reprsentatifs. Le premier prototype (version 1.0) oprationnel ds la n 1985, a t implment sur un serveur parallle compos de 20 processeurs VAX 11/750. Puis, en 1989, Gamma fut port sur un hypercube Intel iPSC/2 compos de 32 processeurs (version 2.0). Dans Gamma, toutes les relations sont fragmentes horizontalement sur lensemble des nuds du systme, permettant ainsi de proter pour chaque relation de toute la bande passante I/O du systme matriel. Trois mthodes de fragmentation des donnes sont disponibles: round-robin, par hachage et par intervalle de valeurs (range).
- 38-
Chapitre II
Le modle dexcution des requtes introduit par Gamma est le modle bracket: Un modle gnrique de processus est utilis pour chaque type doprateurs (slection, jointure,...). Chaque processus peut recevoir et envoyer des donnes pour loprateur quil contient et ne peut excuter plus dun oprateur la fois. Un processus gnrique avec son oprateur associe est appel Processus oprateur. La gure 19 schmatise la construction dun tel processus dans le cas de loprateur de jointure.
paralllisme, contrle,...
Entre
Processus gnrique pour les oprateurs de jointure Sortie
Code de loprateur de jointure
Figure 19 : Processus oprateur
Le code du processus gnrique ( gauche sur la gure 19) fournit au code de loprateur tous les services lis lexcution parallle: contrle de lexcution (synchronisation, dtection de n,...), envoi et rception de messages. Loprateur est ainsi compltement dconnect de lenvironnement dexcution parallle. De ce fait, les algorithmes pour tous les oprateurs relationnels sont crits comme sils devaient tre excuts sur un seul processeur. Lentre et la sortie dun processus oprateur est un ot de tuples. Le ot en sortie est dmultiplex grce une structure particulire appele split table. Cette table dfinit une correspondance entre un ensemble de valeurs et un ensemble de processus destination. Lorsquun processus produit un tuple, il utilise cette table comme un index afin dobtenir ladresse (numro) du processus destination mme de consommer le tuple produit. Trois types de split table sont utiliss suivant que les processus destination utilisent une relation stocke en round-robin, par hachage ou par intervalle de valeurs. Le mcanisme gnral de fonctionnement dun processus oprateur est illustr figure 20.
- 39-
Flot de tuples en entre
Code oprateur
Split table
Flot de tuples en sortie
Processus oprateur
Figure 20 : Fonctionnement dun processus oprateur
Au moment de lexcution dune requte, chaque oprateur relationnel donne lieu lallocation de tout un ensemble de ces Processus oprateur. En fait, un processus est allou pour chacun des noeuds touchs par loprateur. Cependant, la fragmentation par hachage ou par intervalle de valeurs permet dans certains cas (en protant des critres de qualication) de limiter le nombre de noeuds impliqus. En plus de tous les processus oprateur allous pour lexcution dune requte, un processus particulier appel scheduler est charg den contrler lexcution. Ce processus permet lactivation et la dtection de n des Processus oprateur de la requte: il active tous les processus lis au premier oprateur, attend leur n, dclenche les processus de loprateur suivant et ainsi de suite jusquau dernier oprateur. Ainsi, comme nous lavons dj dit, seul le paralllisme intra-oprateur est exploit dans Gamma. Le point faible du modle dexcution bracket est que chaque instance dun oprateur de la requte donne lieu lallocation dun processus. Cela est dautant plus vrai que toutes les relations sont fragmentes sur lensemble des disques, amenant (en gnral) allouer, pour chaque oprateur de la requte, autant de processus quil y a de noeuds dans le systme. En plus du surcot dallocation de ces processus5, cette mthode prsente linconvnient dobliger tous les changes interoprateur tre implments par des communications inter-processus. Celles-ci sont particulirement coteuses car implmentes base dappels systme. Lors de communications locales (c.a.d. lintrieur dun mme nud) ce surcot pourrait tre vit en valuant (par exemple) plusieurs oprateurs dans le mme processus.
5. Ce surcot est limit dans Gamma grce la pr-allocation dun pool de processus dans chaque nud
- 40-
Chapitre II
Ceci nest pas ralisable dans le modle Gamma.
7.2.
PRISMA/DB
PRISMA/DB est un prototype complet de SGBD ddi des architectures sharednothing grande mmoire. Il a t implment sur la machine POOMA, qui comporte 100 noeuds. Chaque noeud est compos dun processeur (68020), dun disque et de 16 Mo de mmoire vive, donnant un total de 1.6 Go de mmoire. Le moteur dexcution de PRISMA/DB consiste en un scheduler et plusieurs processus-oprateurs sur chaque processeur. Les processus-oprateurs peuvent accder aux donnes stockes en mmoire et y appliquer les oprateurs relationnels. Les tuples rsultats peuvent tre stocks en mmoire ou envoys dautres processus-oprateurs. Le scheduler initialise les processus-oprateurs avec les oprateurs quils devront excuter. Il ny a pas de coordination centralise des processus-oprateurs, ils se coordonnent eux-mmes. Ainsi, les cots de coordination sont parallliss. Les requtes sont reprsentes grce une algbre relationnelle tendue avec des oprateurs de groupage et de rcursivit. Chaque oprateur relationnel peut tre excut sur un nombre arbitraire de processeurs, le rsultat de cet oprateur pouvant tre redistribu sur un nombre arbitraire de destinataires. Les oprateurs peuvent tre explicitement distribus aux processeurs. Ceci permet de mettre en oeuvre le paralllisme intra-oprateur et inter-oprateur en distribuant les oprateurs indpendants ou dpendants sur plusieurs processeurs. La exibilit du moteur dexcution de PRISMA/DB a permis son utilisation comme plate-forme de recherche dans diverses directions: [Apers92] [Wilshut91] [Wilschut92] [Wilschut93] [Wilshut95]. Une partie des rsultats de ces tudes ont dj t exposs dans ce chapitre (sections 3.4, 6.1, et 6.4.2).
7.3.
Volcano
Volcano est dvelopp luniversit Boulder dans le Colorado. Contrairement Gamma ou XPRS (prsent plus loin), Volcano nest pas un prototype complet de systme parallle de gestion de bases de donnes, mais un systme dvaluation parallle de requtes destin la mmoire partage. Ainsi, Volcano ninclut ni langage de requtes, ni modle de donnes. Il a t dvelopp dans le but doffrir une plate-forme dexprimentation pour la recherche de nouvelles techniques dexcution parallle, permettant aussi la mise au point dheuristiques doptimisation.
- 41-
Loriginalit de Volcano rside dans son modle dvaluation des requtes, appel modle oprateur. Lide de base de ce modle est dencapsuler tous les aspects lis au paralllisme dans un seul oprateur, loprateur exchange [Graefe90]. Dune manire gnrale, chaque oprateur dni dans Volcano est implment sous la forme dun itrateur, cest dire quil supporte un protocole simple du type ouverture-suivant-fermeture de manire semblable ce qui se fait lors du parcours squentiel dun chier. Ainsi, il existe trois primitives spciques constituant linterface de chacun des oprateurs du systme:
ouverture:
cette primitive permet dinitialiser loprateur, ce qui consiste
gnralement ouvrir les relations (ou oprateurs) en entre. De plus, il est possible ce moment-l dallouer toutes les structures de donnes ncessaires pendant lexcution de loprateur (ex. une table de hachage).
suivant:
cette primitive permet dobtenir le tuple suivant ou un EOS (End Of
Stream) indiquant que loprateur na plus rien produire.

fermeture:
fonction exactement symtrique la primitive ouverture permettant
de fermer les relations (ou oprateurs) en entres et de faire le nettoyage des donnes temporaires alloues pour lexcution. Dans ce contexte, le plan dexcution dune requte est dcrit Volcano sous la forme dun graphe (cod en C) dont chaque nud reprsente un oprateur auquel est associ une variable dtat. Cette variable contient les arguments spciques de loprateur. Par exemple, pour une jointure par hachage, il sagit de la taille de la table de hachage allouer louverture de loprateur. Plus important, la variable dtat peut contenir des pointeurs anonymes sur des fonctions de support comme une fonction de qualication dans le cas dun oprateur de slection. Un exemple type de graphe doprateurs est prsent gure 21. Cette requte consiste slectionner puis joindre avec la relation <S> tous les tuples de la relation <R> vriant la qualication <qualication()>. Le concept ditrateur facilite grandement lvaluation de la requte. Son initialisation est effectue de manire rcursive par louverture de loprateur racine du graphe (ici le join). Pour obtenir un un tous les tuples rsultats, il suft ditrer sur ce mme oprateur (ici, grce la fonction next_join()). Enn, lorsquun EOS est gnr, la requte est termine rcursivement par la fermeture de loprateur racine
- 42-
Chapitre II
du graphe.
oprateur join open_join() next_join() close_join() oprateur scan open_lter() next_lter() close_lter()
Argument
Entre
Argument
Entre
id(relation_S)
qualication() + id(relation_R)
Figure 21 : Requte slection suivie dune jointure
Le paralllisme est introduit dans ce systme grce un oprateur particulier, appel exchange. Celui-ci, comme tous les autres oprateurs, fonctionne suivant le protocole ouverture-suivant-fermeture. Dun point de vue logique, cest une Non opration (no-op) car son rle nest pas deffectuer un traitement particulier sur les donnes quil traite. En consquence, un ou plusieurs de ces oprateurs exchange peuvent tre insrs dans le plan dexcution squentiel dune requte de manire crer du paralllisme tant intra-oprateur quinter-oprateur de type pipeline et cela sans affecter le comportement des autres oprateurs de cette requte. Plac entre deux oprateurs de la requte, la premire fonction de loprateur exchange est de gnrer du paralllisme de type pipeline. A louverture, il cre un nouveau processus (appel fork()) aprs avoir allou une zone de mmoire partage pour lchange de donnes et la synchronisation entre les processus pre et ls. Dans le processus pre, il agit alors comme un itrateur standard sauf quil reoit ses donnes depuis la zone de mmoire partage. Dans le processus ls, son rle est dalimenter en donnes cette zone de mmoire partage en valuant le sous-arbre infrieur de la requte. Ce procd est illustr gure 22 o linsertion dun oprateur exchange entre un oprateur join et lter permet une excution en pipeline de ces deux oprateurs. Le paralllisme intra-oprateur est introduit en tendant lgrement ce mcanisme. Pour cela, un paramtre est ajout loprateur exchange. Celui-ci prcise
- 43-
le degr de paralllisme intra-oprateur dsir. A louverture de loprateur, il est utilis par le processus ls pour dterminer le nombre de fois o celui-ci doit forker pour crer chacune des instances de loprateur producteur. Chaque clone du processus ls cr va ensuite traiter un fragment diffrent des donnes.
pre Join processus Join ouverture de loprateur exchange Exch-pre
Exchange
Zone dEchange ls
Filter
Exch-ls
Filter
Figure 22 : Mise en oeuvre du pipeline dans volcano
Compar au modle bracket dvelopp dans Gamma, le modle oprateur propos par Volcano permet une sparation plus complte entre manipulation des donnes dune part et gestion du paralllisme (contrle des processus, communication inter-processus) dautre part. Cette approche permet, en ne modiant que loprateur exchange, de supporter des environnements dexcution parallle divers. Par exemple, Graefe dans [Graefe93a] propose de gnraliser loprateur exchange de manire prendre en compte des architectures matrielles distribues. Un autre avantage du modle oprateur provient de sa grande souplesse dutilisation. Ainsi, il est possible pour un mme plan squentiel dexprimenter de nombreuses stratgies dexcution parallle. A lextrme, il est possible dexcuter toute la requte de manire squentielle en nintroduisant aucun oprateur exchange. Plus gnralement, il est possible de rgler le degr de paralllisme de chaque requte en jouant la fois sur lendroit o les oprateurs dexchange sont insrs et sur le degr de dcomposition de chacun deux.
- 44-
Chapitre II
7.4.
XPRS
XPRS (eXtended Postgres on Raid and Sprite) a t dvelopp luniversit de Berkeley. Une prsentation gnrale en a t faite dans [Stonebraker88]. XPRS est un systme parallle mmoire partage bas sur la nouvelle gnration du systme de gestion de bases de donnes POSTGRES [Stonebraker91]. Actuellement, XPRS est oprationnel sur un SEQUENT Symmetry disposant de 12 processeurs et 7 disques. Pour attnuer le cot des entres/sorties, XPRS se base sur une organisation RAID des disques de la machine (Redundant Arrays of Inexpensive Disks [Patterson88]). Dans ce systme, les donnes sont clates en round-robin, page par page, sur lensemble des disques de faon utiliser toute la bande passante I/O disponible sur la machine parallle. Cependant, bien que les donnes soient physiquement fragmentes, aucune fragmentation logique (en paquets) nest effectue. Cela est original compar aux autres systmes parallles de gestion de bases de donnes et sexplique probablement par le fait que XPRS est bas sur POSTGRES, un systme non parallle. Dans la mesure o XPRS ne fragmente pas statiquement les relations en paquets (pas de modle parallle de stockage des donnes), le paralllisme intra-oprateur est cr dynamiquement en fonction du nombre de processus allous pour lexcution de loprateur. Notons au passage que cela est comparable ce qui est fait dans Oracle V7. Le paralllisme intra-oprateur est de deux types: page ou intervalle [Hong91]. Dans le paralllisme intra-oprateur de type page, un sous-ensemble des pages disques de la relation est affect chaque processus selon une stratgie de type round-robin. Plus prcisment, si n processus sont allous pour lexcution, le processus i traite toutes les pages disques de numro { p | p mod n = i } avec i variant de 0 n-1. Dans le paralllisme intra-oprateur de type domaine, les processus se partagent les traitements selon un critre logique. Par exemple, si 2 processus sont allous pour effectuer la slection de la relation employ, le premier processus effectue la slection sur tous les employs dont le salaire est infrieur X (emp.salaire < X) et le second sur tous les employs tel que (emp.salaire
X). Notons que X peut-tre choisit
judicieusement (utilisation de statistiques de type histogramme) de manire ce que chaque fragment dynamique soit de taille gale.
- 45-
8 Conclusion
Dans XPRS, le paralllisme intra-oprateur de type page est mis en uvre pour tous les oprateurs de slection par balayage tandis que le paralllisme intraoprateur de type domaine est utilis pour la slection par index. La structure dindex est alors utilise pour dcomposer dynamiquement la relation par domaine, chaque processus prenant en charge un sous-arbre de lindex.
Conclusion
Nous avons donc, dans ce chapitre prsent un ensemble de notions de bases
ncessaires la comprhension de cette thse: architectures matrielles, formes de paralllisme, algorithmes de jointures, plans dexcution parallle, ainsi que les mtriques permettant de quantier 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. Plusieurs remarques peuvent tre faite sur les solutions proposes pour la rpartition de charge: (i) notre connaissance, aucune tude na cherch rsoudre le problme de la rpartition de charge dans son ensemble, cest dire, au niveau intra-oprateur (problme de mauvaises distributions des donnes) et inter-oprateur (problme dallocation des processeurs aux oprateurs). (ii) les solutions au problme des mauvaises distributions de donnes sont gnralement des solutions dynamiques (i.e. durant lexcution), cherchant redistribuer la charge quitablement. Lallocation des processeurs aux oprateurs est, lui, effectu statiquement ou juste avant lexcution. (iii) enn aucune tude na considr les architectures hybrides comme larchitecture hirarchique ou NUMA. Ce sont ces trois points qui ont motiv notre travail dans le cadre de cette thse. En effet, nous nous sommes attachs proposer des solutions permettant la rpartition dynamique de la charge au niveau intra-oprateur et inter-oprateur. De plus nous avons considr, dans cette tude, des architectures hybrides car elles nous semblent tre des architectures cls pour les besoins en performances des nouvelles applications.
- 46-
Chapitre III Excution parallle et rpartition de charge dans DBS3.

III
Un ensemble de facteurs limite les gains obtenus lors dune excution parallle: temps dinitialisation, interfrences entre les entits dexcution et mauvaise rpartition de la charge de travail. Dans ce chapitre, nous prsentons une solution qui rduit ces limitations dans DBS3, un SGBD parallle pour une architecture mmoire partage. Celle-ci combine un modle de paralllisation bas sur la fragmentation statique des donnes avec un modle dallocation dynamique des processeurs an de sadapter chaque contexte dexcution. Cette exibilit permet de xer le degr de paralllisme indpendamment du degr de fragmentation, mais aussi de rpartir nement la puissance de calcul ainsi alloue an de supporter efcacement des charges de travail non uniformment rparties (Data Skew). Une analyse nous permet de dgager trois importants facteurs modiant le comportement de notre modle dexcution: degr de biaisage, de paralllisme et de fragmentation. Nous prsentons plusieurs mesures de performances en variant ces trois paramtres effectues avec le prototype DBS3 sur la machine KSR1 munie de 72 processeurs. Les mesures montrent des gains importants mme en cas de donnes fortement biaises.
Introduction
DBS3 (DataBase Server for Shared Store) [Bergsten93] est un systme de gestion
de base de donnes parallle dvelopp dans le cadre du projet Esprit EDS [EDS90]. Ce projet a donn lieu la ralisation dune machine parallle mmoire distribue, la machine EDS, actuellement commercialise par ICL sous le nom de Goldrush. Outre cette machine, un SGBD relationnel a galement t conu. Deux implmentations de ce SGBD ont t ralises. La premire, EDBS, est ddie la machine distribue EDS. La seconde, DBS3, a t dveloppe pour valider lapproche sur les architectures de type mmoire partage. DBS3 et EDBS partagent le compilateur de requtes qui se base sur un modle distribu lors des phases doptimisation et de paralllisation des requtes. DBS3 vise obtenir de trs bonnes performances pour les charges de travail mixtes combinant des requtes de faible
- 47-
1 Introduction
complexit comme les requtes OLTP (On Line Transaction Processing) et des requtes de complexit moyenne (aide la dcision). En plus du paralllisme inter-requtes permettant daugmenter le dbit transactionnel, DBS3 supporte le paralllisme intrarequte qui permet damliorer les temps de rponse [Borla-Salamet91b]. DBS3 a t ralis sur une machine ENCORE Multimax (10 processeurs, 96 Mo de mmoire) puis a t port sur une machine KSR1 (72 processeurs, 2 Go de mmoire) [Dageville94]. Les performances dune excution parallle peuvent tre freines par un ensemble de facteurs [DeWitt92a] qui limite le gain obtenu. La qualit dun systme parallle dpend donc grandement de sa capacit minimiser ces facteurs:
Le temps de mise en place du paralllisme: avant que lexcution parallle ne dbute rellement, une phase dinitialisation est ncessaire. La dure de cette phase est proportionnelle au degr de paralllisme choisi et peut tre non ngligeable pour des requtes de faible complexit. Le degr de paralllisme doit donc tre x en fonction de la complexit de la requte.
Les surcots lis aux interfrences: une excution parallle peut tre freine par lapparition dinterfrences lors daccs simultans une mme ressource matrielle ou logicielle non partageable (disques, structures de donnes, etc...). Il est ncessaire disoler au maximum lexcution de chaque fragment de requte an de minimiser leurs interactions.
La mauvaise rpartition de la charge de travail: le temps de rponse dune requte est gal au temps de rponse du processeur le plus charg. Le scheduler doit pouvoir rpartir la puissance de calcul en tenant compte de la complexit de chaque fragment de la requte et de la distribution des donnes.
La paralllisation dune requte peut tre effectue selon deux axes: horizontalement (paralllisme intra-oprateur), en distribuant chaque oprateur sur un ensemble de processeurs, et verticalement (paralllisme inter-oprateur indpendant ou pipeline) en distribuant tous les oprateurs de la requte sur diffrents processeurs. Deux approches peuvent tre utilises pour mettre en oeuvre le paralllisme. Dans un modle fragment, le paralllisme est obtenu travers la fragmentation des donnes, i.e. les relations sont physiquement fragmentes sur les disques ou en
- 48-
Chapitre III
Excution parallle et rpartition de charge dans DBS3.
mmoire, en utilisant une fonction de fragmentation comme le hachage. La fragmentation des relations en paquets est alors utilise pour diriger la fragmentation des traitements. Cest lapproche la plus rpandue. Elle est mise en uvre dans les systmes commerciaux tels Informix [Davison92], Sybase, Teradata [Neches88], Tandem [Chen93] et dans les prototypes de recherche comme Gamma [DeWitt90b], Bubba [Boral90], Volcano [Graefe94]. Cette approche rduit les risques dinterfrences entre les processeurs puisque chacun deux accde seulement un sous ensemble des donnes. Elle peut tre adapte toutes les architectures matrielles, de larchitecture shared-everything shared-nothing. Dun autre ct, la fragmentation statique des donnes complique la tche dadministration de la base; ladministrateur doit dcider de la mthode, de lattribut et du degr de fragmentation de chaque relation. De plus, le degr de fragmentation des relations dtermine gnralement le degr de paralllisme intra-oprateur [Mehta95]. Ces choix ont un impact direct sur les performances du systme parallle, notamment pour la rpartition de la charge de travail entre les diffrents processeurs de la machine. Ces points sont mis en avant par XPRS [Hong91] et Oracle V7 [Davis92] pour justier un modle dexcution non-fragment (voir chapitre V, section 2). Ainsi, ces deux systmes nont pas de modle de stockage de donnes parallle. Le paralllisme intra-oprateur y est cr dynamiquement en fonction du nombre de processeurs allous pour lexcution de loprateur. Il est alors possible de choisir le degr de paralllisme en fonction de la complexit de la requte et des ressources disponibles. De plus, des mthodes de rajustement dynamique du paralllisme peuvent tre misent en place [Hong92] pour quilibrer dynamiquement la charge de travail entre les processus. Cependant, cette solution est rserve aux architectures mmoire partage et peut souffrir de surcots dinterfrences car tous les processeurs accdent potentiellement toutes les donnes. Dans DBS3, lapproche que nous avons adopte et qui est expose dans cet article, tente de combiner les avantages des deux approches prcdentes. Ainsi, la paralllisation du code repose sur un modle dexcution fragment an de rduire les interfrences. De plus, nous avons choisi de dcoupler le modle dallocation des processeurs du modle de paralllisation pour tre en mesure dassocier dynamiquement les processeurs aux fragments de la requte. Cette exibilit permet ensuite au scheduler parallle non seulement de xer le degr de paralllisme indpendamment du degr de fragmentation, mais aussi de rpartir nement la
- 49-
2 Le modle dexcution parallle de DBS3
puissance de calcul ainsi alloue sur les diffrents fragments de la requte en tenant compte de la complexit des traitements et dventuelles rpartitions biaises. Notons que la tche de ladministrateur est alors simplie puisque le degr de fragmentation na plus de rapport direct avec le degr de paralllisme. Ce chapitre est organis de la manire suivante. La section 2 prsente le modle dexcution de DBS3. Une description des principes de base du modle de paralllisation nous permet dintroduire le mcanisme dexcution des fragments de requte obtenus. Dans la section 3, nous spcions la mthode dallocation des processeurs pour une excution parallle sur une architecture mmoire partage. Dans la section 4, nous analysons les effets de mauvaises distributions de donnes (data skew) sur les performances de DBS3. Cette analyse nous permet de dgager trois importants facteurs modiant le comportement de notre modle dexcution: degr de biaisage, de paralllisme et de fragmentation. La section 5 prsente les mesures de performances effectues en variant ces trois paramtres avec le prototype DBS3 sur la machine KSR1. La section 6 conclut.
Le modle dexcution parallle de DBS3

Dans DBS3, les requtes utilisateurs sont exprimes en ESQL [Gardarin90]. La
phase de compilation des requtes consiste optimiser [Lanzelotte94] puis parallliser [Borla-Salamet91b] la requte originale pour obtenir un programme LERA-par [Chachaty92]. Celui-ci dcrit un ensemble doprateurs communiquant par envoi de messages ainsi que les mcanismes de contrle ncessaires pour activer et synchroniser ces oprateurs. Le modle dexcution que nous proposons ici dnit des schmas pour la mise en uvre des plans dexcution parallle exprims dans ce langage. Aussi, la dnition de notre modle dexcution passe par la comprhension des principes de base du langage LERA-par (une description appronfondie du langage LERA-par est donne dans [Chachaty91]). Ce langage est bas sur le paradigme de programmation dataow. Dans ce paradigme, les donnes naviguent au travers dun rseau de noeuds. Chaque nud effectue un traitement sur les donnes quil reoit, et produit de nouvelles donnes en sortie. Ainsi, dans LERA-par, lexcution parallle dune requte est reprsente par un graphe o les nuds sont les oprateurs de la requte tandis que les arcs reprsentent lchange de signaux dactivations. Un signal dactivation est soit un tuple (activation de donnes), soit un message de contrle (activation de contrle). Dans les deux cas, quand un oprateur reoit un signal dactivation, le code de
- 50-
Chapitre III
loprateur qui lui est associe est activ pour traiter le signal reu. Chaque signal dactivation reprsente donc un travail lmentaire squentiel. Le modle LERA-par est fortement coupl au modle de stockage parallle. Les relations sont fragmentes statiquement par une fonction de hachage applique lun de leurs attributs. Les paquets rsultants de cette tape de fragmentation sont ensuite distribus de manire circulaire sur les disques du serveur parallle. La dcomposition de chaque oprateur du graphe de donnes en un ensemble dinstances identiques (paralllisme intra-oprateur) est ralise de la mme manire que la dcomposition des relations en paquets. Ce graphe devient alors un graphe de donnes tendu, o chaque nud reprsente un ensemble dinstances dun oprateur excutant le mme code sur une portion diffrente de donnes. Lexcution pipeline entre les nuds du graphe est aussi exploite. Dans ce cas, chaque signal dactivation chang entre le nud producteur et le nud consommateur porte des donnes (i.e. tuples).
Vue non tendue Vue tendue
join S
activations de donnes
join1
join2
joinn
OP OPi
oprateur Linstance i de loprateur Signaux dactivations Redistributions ventuelles
S1 lter1
S2 lter2 R2
Dclenchement
Sn ltern Rn
lter R
activations de contrle
R1
Dclenchement
Relation matrialise
Figure 23 : Graphe LERA-par de la requte lter-join
La gure 23 illustre les mcanismes de bases dun programme LERA-par sur une requte effectuant une slection sur la relation R puis une jointure du rsultat avec la relation S. Lexcution de cette requte se droule comme suit: une activation de dclenchement est envoye toutes les instances de loprateur de slection. Ces activations ont pour effet de dclencher chaque instance du lter. Ces dernires vont alors parcourir (en parallle) le fragment de relation qui leur correspond en appliquant le critre de qualication. Les tuples rsultats de cette slection sont envoys au fur et mesure (en pipeline), loprateur de jointure. Chaque tuple
- 51-
2 Le modle dexcution parallle de DBS3
envoy va automatiquement activer lexcution de linstance join destinataire. Celleci effectue alors la jointure du tuple reu avec le paquet de donnes de la relation S qui lui correspond. Notons pour conclure cet exemple que la transmission des tuples entre les deux oprateurs peut tre fait avec ou sans redistribution, suivant que lattribut choisi pour la fragmentation des relations est gal ou non lattribut de jointure. Une le dattente de type FIFO (First In First Out) est associe chaque instance doprateur LERA-par pour recevoir les activations qui lui sont adresses. Nous pouvons distinguer dans LERA-par deux types de les dactivations: les files de donnes dclenches et les files de donnes pipelines. Le premier type de les est associ aux oprateurs LERA-par dclenches par un oprateur de contrle. Durant son cycle de vie, une le dclenche ne reoit quune activation, destine dmarrer linstance de loprateur de donnes qui lui est attache. Toujours avec notre exemple, la gure 24 reprsente les les de type dclenches associes loprateur lter.
Vue non tendue Vue tendue
T1
T2
Tn
OP OPi
oprateur Linstance i de loprateur Activation de Dclenchement File dactivation
Filter R
Dclenchement
Filter1 R1 R2
Filter2 Rn
Dclenchement
Filtern
Figure 24 : oprateur dclench
A linverse, les les de donnes pipelines sont associes aux oprateurs de donnes recevant une de leur oprande en pipeline (gure 25). Dans ce cas, chaque activation transporte un tuple et chaque le peut contenir simultanment plusieurs activations, toutes destines la mme instance.
- 52-
Chapitre III
Vue non tendue
Vue tendue
Res Join S T Op
Res1 Join1 S1 S2
Res2 Join2 Sn
Resn Joinn OP OPi

oprateur Linstance i de loprateur Tuples de T File dactivation
Tuples de T
Figure 25 : Oprateur pipelin
Mise en uvre sur une architecture mmoire partage

Dans une architecture mmoire partage, il est possible de dcoupler le modle
de paralllisation de celui dallocation des processeurs. Au lieu dassocier classiquement un seul thread1 par instance doprateur, nous attribuons un pool de threads lensemble de loprateur. Cela est ralis en allouant les les de travail de chaque instance doprateur dans un segment de mmoire partage. Tous les threads dun pool peuvent alors accder toutes les les de leur oprateur. De cette faon, ils peuvent excuter le code correspondant nimporte quel signal dactivation (c.f. gure 26). La cardinalit de chaque pool de thread est choisie indpendamment du degr de fragmentation des oprandes.
pool de threads 2 Instance doprateur File dactivation Signal dactivation pool de threads 1 Thread
Join1
OPi Join2 Join3
Filter1
Filter2
Filter3
Dclenchement
Figure 26 : Association des threads aux instances doprateurs.

1. Dans DBS3, lallocation des processeurs est faite de manire indirecte en utilisant des threads (ou processus lgers) [Posix].
- 53-
3 Mise en uvre sur une architecture mmoire partage
La mise en oeuvre dun tel modle est assez simplement ralise dans une architecture mmoire partage. La gure 27 dcrit les structures de donnes utilises. Chaque noeud du graphe dataow est dcrit par une structure oprateur. A cette structure, est associe une table de les dactivations et une table de threads, consommateurs des activations. Chaque structure tant accde en parallle, est protge par une variable dexclusion mutuelle. Des variables conditions sont utilises pour synchroniser les consommateurs et les producteurs. Enn, un mcanisme de cache interne dactivations est utilis dans le but de limiter les interfrences entre les threads et de favoriser la localit des accs.
oprateur:
int File ** int int thread ** void * Strategy etc... NbFiles TblFiles TailleCache NbThreads TblThreads DBFunc Strategie Nombres de les (instances) pour cet oprateur Table des les (pointeurs vers les les) Taille du cache dactivations interne de chaque thread Nombre de threads consommateurs de loprateur Table des threads consommateurs (pointeurs) Pointeur vers le code de loprateur (e.g. join, lter, etc..) Stratgie de consommation,
File:
condition mutex char * etc... NonPleine Protect Buffer Variable condition pour rveiller les producteurs Mutex de protection de la le Buffer dactivations
Thread:
condition mutex bool * char * etc... NonVide Protect FilePrinc IntCache Variable condition pour rveiller les consommateurs Mutex de protection du thread Table de boolens indiquant si la ime le est une le principale Cache dactivations interne
File dactivations Activation File principale du thread File secondaire du thread
T C
Thread Cache dactivations interne Mutex
Figure 27 : Structure de donnes pour le modle dexcution de DBS3

Les conits daccs aux les dactivations sont aussi limits en dnissant, pour chaque thread, deux type de les: les les principales et secondaires. Pour chaque oprateur, les les dactivations sont quitablement distribues sur lensemble des threads associs loprateur et sont dnis comme les principales. Ainsi une le
- 54-
Chapitre III
principale nest associe qu un et un seul thread. Par contre, un thread peut dtenir plusieurs les principales. Un thread cherche toujours consommer des activations dans son pool de les principales avant daccder aux les secondaires. Tant quil y a un ot continu dactivations, il ny a donc entre les threads, aucun conit daccs aux les, et les threads allous pour lexcution sont utiliss leur maximum. Ce modle dallocation des threads sur les oprateurs nous permet dliminer, du moins de limiter lensemble des problmes lis lexcution parallle. Il offre trois degrs de libert qui lui permettent de sadapter chaque contexte dexcution (requte, distribution des donnes, charge de la machine, etc...). En effet, il est possible de dnir indpendamment le degr de fragmentation et le degr de paralllisme pour lexcution de la requte. De plus, en jouant sur la cardinalit de chaque pool de threads, nous pouvons effectuer une meilleure rpartition de la puissance de calcul entre les diffrents oprateurs. Enfin, chaque thread peut dynamiquement choisir dans quelle file il va consommer des activations. Intuitivement, il est vident que si le thread favorise dans son choix telle file plutt que telle autre, il va indirectement mettre plus de puissance de calcul sur telle instance de loprateur plutt que sur telle autre. Cette possibilit permet dobtenir une bonne rpartition de la charge au niveau du paralllisme intra-oprateurs.
Analyse du modle
Dans cette section, nous analysons les effets des rpartitions de donnes biaises
(skew) sur le modle dexcution de DBS3, lors de lexcution dun oprateur. Lobjectif est dobtenir une formule donnant le surcot induit par une rpartition biaise dans le but de comprendre quels en sont les paramtres et comment attnuer ce surcot. Dans DBS3, chaque thread peut accder toutes les les dactivations dun oprateur. Par dfaut, lorsquun thread cherche consommer une nouvelle activation, il la retire dans une le choisie au hasard parmi le sous-ensemble des les non vides associes son oprateur (mthode de consommation Random). Ainsi, au niveau de chaque oprateur, lutilisation des threads est maximum jusqu ce quil ny ait plus aucune activation disponible. Toutefois, entre le moment o le premier thread sarrte et la fin complte de lexcution de loprateur, il faut quand mme attendre que tous les autres threads aient termin de traiter leur activation courante.
- 55-
4 Analyse du modle
Considrons lexcution dun oprateur recevant a activations, prises en charge par n threads2. P reprsente la dure moyenne de traitement de chaque activation, Pmax, la dure de traitement des activations de linstance la plus chre (en cas de mauvaise distribution de donne). Tidal reprsente le temps dexcution idal de loprateur, lorsque tous les threads nissent leur traitement simultanment. Tpire, le temps dexcution de loprateur dans la pire des situations, qui est expos cidessous. Dans le cas pessimiste, un thread consomme la dernire activation au moment o tous les autres finissent leur traitement courant. Ainsi durant le traitement de cette activation, un seul thread est actif et lutilisation de la puissance de calcul est minimale sur toute cette priode. En prsence dune rpartition biaise des donnes, le temps de traitement des activations est diffrent dune instance lautre. Les carts par rapport la moyenne P peuvent tre dans ce cas trs important. En considrant toujours le pire des cas, la dernire activation traite par un seul thread aura un Pmax correspondant au temps dexcution de linstance la plus chre. Nous allons calculer, dans ce cas pessimiste, la dgradation v du temps dexcution de loprateur Tpire par rapport au temps dexcution idal Tidal. La dnition de p nous donne:
aP T pire = ( 1 + v ) T ideal = ( 1 + v ) ------------ n
Le temps dexcution idal est obtenu en divisant le temps dexcution squentiel axP par le nombre de threads.
Dans une premire phase, toutes les activations sauf la plus chre sont traites. Avec un speed-up idal, La dure de cette phase est
( ( a P ) P max ) n
Dans une seconde phase, un seul thread traite la dernire activation dont le cot est Pmax. nous obtenons donc une nouvelle quation donnant le temps dexcution de loprateur au pire des cas:
( a P ) P max T pire ------------------------------------ + P max n
En substituant Tpire dans avec lquation , nous pouvons calculer la dgradation v du temps dexcution en fonction de P et Pmax, respectivement le temps moyen et maximum de traitement dune activation, du nombre a dactivations changes et du nombre n de threads allous pour lexcution de loprateur:
2. Notons quil est ncessaire quun oprateur reoive plus dactivations quil ny a de threads pour les traiter (n a). Dans le cas contraire, nous aurons n-a threads inactifs.
- 56-
Chapitre III
Lquation
P max ( n 1 ) v ---------- -----------------P a
montre que la dgradation du temps dexcution dpend de trois
facteurs: le degr de biaisage (Pmax/P), le degr de paralllisme (n) et le nombre dactivations (a). Pour le dernier paramtre, nous avons deux cas de gure, suivant que le nombre dactivations est grand ou petit.
Le nombre dactivations est grand. Ce cas correspond une excution pipeline dans laquelle beaucoup de tuples transitent. Le nombre dactivations (a) correspond alors la cardinalit de la relation consomme en pipeline. Nous avons alors une dgradation v toujours petite. Le temps dexcution de loprateur est trs proche du temps idal quelle que soit la mthode de consommation des threads dans les les, mme en considrant des cas de mauvaise rpartition des donnes.
Le nombre dactivations est petit. Ce cas correspond soit une excution pipeline o peu de tuples sont transmis, soit au dclenchement de loprateur par le contrle (dans ce dernier cas, une seule activation est envoye chaque instance de loprateur). La dgradation peut, dans ces deux cas, tre assez importante. Il est alors ncessaire dutiliser une mthode de consommation spcique. Une heuristique simple, connue sous le nom de LPT (Longest Processing Time rst) [Graham69], consiste consommer en priorit les activations les plus chres. Pour mettre en oeuvre une telle heuristique, il nest pas ncessaire destimer le temps de traitement de chaque activation. Il nous suft dordonner les instances de loprateur en fonction du cot de leur excution. Cet ordonnancement peut seffectuer statiquement partir dinformations sur la taille du (ou des) paquet(s) trait(s) par ces instances. Notons que dans le cas dun pipeline, il est possible de rajuster dynamiquement ces estimations en se basant sur les temps mesurs des premires excutions.
Etude de performance
Dans cette section, nous montrons, dans quelles mesures le modle dexcution
de DBS3 peut sadapter plusieurs contextes dexcution. Nous prsentons tout dabord lenvironnement dexprimentation, notamment la machine KSR1 et les requtes testes. Nous varions alors trois paramtres inuenant le comportement de
- 57-
5 Etude de performance
notre modle: degr de biaisage, de paralllisme et de fragmentation.
5.1.
Plate-forme dexprimentation
La machine KSR1 tente de combiner les avantages dun modle de programmation mmoire partage et dune architecture extensible [Frank93]. Larchitecture de la machine KSR1 est donc de type hybride dans la mesure o la mmoire est physiquement distribue mais virtuellement partage grce un mcanisme matriel. Chaque processeur possde sa propre mmoire de 32Mo appele cache local. Le systme matriel de gestion de la mmoire AllCache Technology fournit lutilisateur un espace de mmoire virtuellement partage qui correspond lensemble de toutes les mmoires locales. Ainsi, une donne accde par un processeur peut tre stocke dans le cache dun autre processeur. Compar une architecture mmoire partage conventionnelle (comme la machine ENCORE Multimax, machine cible lorigine pour DBS3), lorganisation de la mmoire sur la KSR peut avoir quelques aspects ngatifs qui seront tudis dans la section suivante. La gure 28 prsente les diffrences entre lorganisation mmoire de KSR1 et celles de machines conventionnelles de type mmoire partage ou mmoire distribue.
Architecture Mmoire Partage (Machine Encore) Architecture Mmoire Distribue
P1
Pn
mmoire
P1
P2
Pn
Modle de programmation simple Bonne rpartition de la charge de travail
Extensibilit importante
KSR AllCache Shared memory
cache local
cache local
cache local
P1
P2
Pn
Figure 28 Principe de Conception de la machine KSR1
- 58-
Chapitre III
La conguration de la KSR1, utilise dans les mesures comporte 72 processeurs de 40 MIPS, avec une mmoire vive totale de 2,3 Go. Comme un seul disque tait disponible pour nos exprimentations, nous avons simul les entrs-sorties lors de laccs aux relations de bases avec les paramtres suivant
Paramtres des disques Nb Disques Temps de latence Seek Taux de transfert Cache dI/O Valeur 1 par processeur 17 ms 5 ms 6 Mo/s 8 pages Buffer de cache pour les lectures squentielles Commentaires Nombre de disques simuls Temps de rotation Temps de placement du bras
Tableau 2 : Paramtres de simulation des disques
5.1.1. Impact du modle Allcache sur DBS3

Dans une architecture distribue, le code est en gnral excut l o se trouvent les donnes et ceci an dviter les cots lis aux transferts des donnes entre les diffrents processeurs. Sur la machine KSR1, la vue mmoire partage est lie au fait que les donnes peuvent bouger dun cache un autre. Il est ainsi difcile, voire impossible, de garantir que du code excut par un processeur va trouver toutes ses donnes localement. Lorsquune donne accde est stocke dans le cache dun autre processeur, elle doit naviguer dun cache lautre, induisant un surcot qui peut savrer pnalisant (laccs une ligne de cache distante est 6 fois plus lente que laccs une ligne locale). De plus, la taille relativement limite dun cache local (quand mme 32Mo) peut tre insufsante pour cacher un grand volume de donnes, entranant alors des dfauts de cache rpts. Dans cette section, nous nous attachons quantier les pertes de performances induites par lutilisation de la machine KSR1, dues la structuration htrogne de la mmoire virtuellement partage. Nous dsirons mesurer limpact de la localit des donnes sur lexcution parallle dune requte. La requte considre est une slection sur la relation DewittA du benchmark du Wisconsin [Bitton83] contenant 200K tuples. Le but de cette exprience est de mesurer le temps dexcution de la requte lorsque les donnes sont accdes localement compar la mme excution quand les donnes sont distantes. Pour garantir que les donnes sont toujours accdes dans le cache des processeurs o elles sont stockes, lexcution est
- 59-
dclenche plusieurs fois, et toujours sur les mmes processeurs. Le cas distant (cest dire quand les donnes ne sont pas caches), est obtenu en dplaant lexcution dun groupe de processeurs lautre. Le nombre de threads allous pour effectuer la slection varie de 5 30. Au-dessous de 5 threads, le volume de donnes devient trop important pour tenir dans un cache local (puisque chacun des n processeurs traite 1/ nme). Soit Tl le temps dexcution dans le cas local et Td le temps dans le cas distant. Les gures 29 et 30 prsentent les courbes Tl (resp. Td) en fonction du nombre de threads affects la requte, ainsi que la diffrence Td-Tl toujours en fonction du nombre de threads.
300 6 5 4 3 2 1
Excution distante (Td) (Td - Tl) (ms)

30
Temps de rponse (s)
Excution locale (Tl)
250 200 150 100 50 0 5 10 15 20 25 30
10
15
20
25
Nombre de threads
Nombre de threads
Figure 29 : Impact des accs distant sur une slection de 200K tuples
Figure 30 : Diffrence des temps dexcution distants et locaux
Ces gures permettent de constater que la diffrence entre Td et Tl est petite devant le temps dexcution total. Les dfauts de cache ne sont donc pas trop pnalisants. Ceci est dautant plus vrai que, dans cet exemple, le temps de traitement sur chacun des tuples est faible. Pour des requtes plus complexes (jointure par exemple), la diffrence Td-Tl devient proportionnellement plus petite. La gure 30 montre que Td-Tl diminue linairement en fonction du nombre de threads. Ce rsultat nest pas surprenant dans la mesure o les dfauts de cache (et leur surcot) sont rpartis entre les threads. Ainsi, le paralllisme attnue limpact des accs distants.
5.2.
Base de tests
Dans tous les tests suivants, nous utilisons les tables du Wisconsin Benchmark [Bitton83]. Ces tables sont fragmentes sur les disques par une fonction de hachage. Les mesures sont effectues avec les relations caches en mmoire pour la simple raison quun seul disque tait disponible. Toutefois, les accs aux disques ont t
- 60-
Chapitre III
simuls de la manire suivante. Lorsquune page disque est requise, une procdure est appele et effectue une attente active calcul avec les paramtres du tableau 2. Pour nos expriences, nous avons utilis deux plans dexcutions Lera-par effectuant tous les deux la jointure de deux relations A et B du Wisconsin Benchmark. Dans le plan ideal join [Casadessus94], les oprandes sont fragmente (sur le disque) sur lattribut de jointure et avec le mme degr de fragmentation. Il ny a donc aucune redistribution de donnes lors de lexcution. Dans le plan AssocJoin [Casadessus94], une des oprandes, B, doit tre redistribue (car elle nest, par exemple, pas fragmente sur lattribut de jointure). Les gures 31 et 32 prsentent ces deux plans dexcution parallles.
R1
Join1
R2
Join2
Rn
Joinn
R1
Join1
R2
Join2
Rn
Joinn
A1
Transmit1
A2
Transmit2
An
Transmitn
A1
B1
A2
B2
An
Bn
B1
B2
Bn
Dclenchement
Dclenchement
Figure 31 : Plan dexcution Ideal-Join
Figure 32 : Plan dexcution Assoc-Join
Ltude des rpartitions biaises et du degr de fragmentation nous a amen gnrer un grand nombre de bases3. La taille des disques que nous avions notre disposition (1.2 Go) tant relativement limite, il nous tait impossible de faire nos tests sur de grosses bases. Avec des bases de taille limite (i.e. 100 200K tuples), la jointure avec index est trop rapide et rend lanalyse difcile car le temps dexcution est du mme ordre que les erreurs de mesures. Ainsi, lorsque lalgorithme de jointure (local) na pas dimportance, nous avons utilis lalgorithme par boucles imbriques an dobtenir des temps dexcution sufsamment grand. Dans les autres cas, nous avons utilis des bases plus importantes (500 Kilo-tuples) et utilis une jointure base dindex temporaires. Chaque mesure est faite six fois, le rsultat moyen est pris en compte.
3. Pour lensemble des exprimentations, nous avons gnr plus de 50 bases de 2 100 Mo
- 61-
5.3.
Impact du data skew
An de vrier les rsultats de la section 4, nous avons ralis un ensemble de mesures sur lIdealJoin et lAssocJoin en variant le degr de biaisage. Nous avons cr plusieurs bases de caractristiques identiques sur lesquelles nous avons fait varier la rpartition des tuples dans les paquets. Pour xer la cardinalit de chaque paquet, nous utilisons une fonction de Zipf [Zipf49] dont le degr varie entre 0 (nonbiaise) et 1 (trs biaise). En effet, les phnomnes de rpartitions biaises de donnes, largement tudis dans la ralit par Lynch [Lynch88] sur des bases de donnes textuelles, peuvent tre modliss par ce type de fonction. Chaque base contient deux relations, A et B, de respectivement 100 et 10Ktuples. Chaque relation est fragmente statiquement en 200 paquets (voir section 5.5). Seule la relation A est mal distribue. En effet, un biaisage des deux relations entrane le changement de la taille des rsultats. Cependant, nous avons vri que le biaisage de deux relations est quivalent un degr de biaisage plus grand sur une des deux relations. Pour chaque base (obtenue en changeant le degr de biaisage, nous avons mesur le temps dexcution des requtes AssocJoin et IdealJoin excutes par 10 threads. Dans le cas de lAssocJoin, la relation B est redistribue. 10000 tuples transitent donc le long des pipelines. Les rsultats prsents sur la gure 33 conrment les prvisions thoriques. Les variations des rsultats dune mesure lautre sont ngligeables (< 1%). Nous avons aussi report sur la gure 33 la courbe calcule avec la formule de la dgradation maximale (Tpire). Mme dans ce cas, nous obtenons une variation maximale de 3%. Ces mesures conrment donc que nous obtenons un temps dexcution idal quel que soit le coefcient de biaisage4. LIdealJoin est un oprateur dclench. Le nombre dactivation transmises est donc gal au nombre dinstances. Nous avons compar le temps dexcution de cet oprateur en faisant varier les mthodes de consommation des threads (Random ou LPT). Deux sries de mesures ont donc t ralises. De plus, la gure 34 montre, en pointills, la courbe calcul du pire des cas. Pour des coefcients de biaisage moyens (infrieur 0.4), nous obtenons de bons rsultats quelle que soit la mthode de consommation utilise. Comme nous avons
4. Dans la limite du raisonnable. Avec une Zipf de coefcient 1 sur 200 instances, le plus gros paquet est 160 plus grand que le plus petit et 34 fois plus grand que la moyenne.
- 62-
Chapitre III
fragment la relation en 200 paquets, la taille de chaque paquet est relativement petite et permet, mme avec une mthode Random, dobtenir une bonne rpartition de la charge de travail.
Dgradation relative des perfs. Dgradation relative des perfs. Stratgie RANDOM Cas extrme Stratgie RANDOM Stratgie LPT Cas extrme
1.05 1.04 1.03 1.02 1.01 1
2.6 2.4 2.2 2 1.8 1.6 1.4 1.2 1 0
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Degr de skew (Zipf)
Degr de skew (Zipf)
Figure 33 : Dgradation avec Assoc-Join
Figure 34 : Dgradation avec Ideal-Join
Cependant, avec un biaisage plus fort, la mthode LPT savre meilleure. Elle permet dobtenir un temps de rponse quasiment idal tant que le coefcient de biaisage reste infrieur 0.8 (moins de 2% de dgradation par rapport au temps idal). Linexion autour de 0.8 sexplique par le cot de traitement de lactivation la plus chre. En effet, partir de 0.8, le cot de traitement de cette seule activation dpasse le temps idal de traitement de loprateur ( P max > ( a P ) n ). Avec lheuristique LPT, cette activation est consomme en premier. Pendant son traitement, toutes les autres activations sont traites par les autres threads. Le temps dexcution total est nalement gal au temps de traitement de cette premire activation.
5.4.
Degr de paralllisme et rpartition de charge
Les mesures prcdentes ont t ralises avec un nombre relativement faible de threads. Dans cette section, nous nous intressons limpact dun haut degr de paralllisme intra-oprateur conjugu de mauvaises distributions de donnes. Nous avons utilis des bases de donnes similaires, avec un plus grand nombre de tuples (200K et 20K tuples) an de minimiser les erreurs de mesures. Nous avons excut les plans AssocJoin et IdealJoin (jointure par boucles imbriques) sur un ensemble de bases comportant des distributions biaises. Pour chaque base, nous avons vari le nombre de threads de 1 (excution squentielle) 100 en utilisant au plus, 70 processeurs de la KSR1. Les gures 35 et 36 prsentent les
- 63-
rsultats en termes de speed-up. Avec une distribution uniforme, les rsultats sont bons, avec un speed-up suprieur 60 avec 70 processeurs pour les deux plans dexcutions. De plus, les gures conrment quil nest pas utile, pour ce genre de requte dallouer plus de threads que de processeurs. Avec des rpartitions biaises, les rsultats diffrent suivant que loprateur est dclench ou pipelin. Dans le cas pipeline (AssocJoin), le grand nombre dactivations (20 000) absorbent les mauvaises distributions, mme avec un grand nombre de threads. Selon lquation , avec 70threads et le biaisage le plus fort (Zipf = 1), le temps dexcution se dgrade au maximum de 12%. Nos mesures montrent que cette estimation est pessimiste puisque la dgradation nexcde pas 5%. Dans le cas de loprateur dclench (IdealJoin), les rsultats ne sont pas si bons. Avec des distributions biaises, le speed-up atteint un palier dpendant du degr de biaisage. De nouveau, ceci est d au traitement de lactivation la plus chre Pmax. Lorsque P max > ( a P ) n , le temps dexcution de loprateur est gal celui de cette seule activation, indpendamment du nombre de threads.Il ny a alors pas dintrt utiliser un degr de paralllisme plus grand que n max = ( a P ) P max , i.e. le temps dexcution de loprateur divis par le temps dexcution de lactivation la plus chre. Cette formule nous permet de calculer nmax pour chaque degr de biaisage. Nous obtenons nmax = 6, 19 et 40 pour respectivement Zipf = 1, 0.6 et 0.4. Ces valeurs thoriques sont conrmes sur la gure 36.
70 60 50
Thorique Zipf = 0.0 Zipf = 1 Speed-up
70 60 50 40 30 20 10
Thorique Zipf = 0.0 Zipf = 0.4 Zipf = 0.6 Zipf = 1
Speed-up
40 30 20 10
10
20
30
40
50
60
70
80
90 100
10
20
30
40
50
60
70
80
90 100
Nombre de threads
Nombre de threads
Figure 35 : Assoc-Join: Speed-up
Figure 36 : Ideal-Join: Speed-up
En rsumant, la fragmentation dun oprateur en un grand nombre dunits squentielles de travail (activations) permet dabsorber les mauvaises distributions de donnes et dobtenir de bien meilleures performances quavec un petit nombre dactivations (oprateurs dclenchs).
- 64-
Chapitre III
5.5.
Degr de fragmentation et rpartition de charge
Habituellement, le degr de fragmentation des relations est intimement li au degr de paralllisme. Pour cette raison, la plupart des tudes sur le placement font cette hypothse et limitent donc les possibilits aux Full declustering [Mehta95] (utilis dans Teradata, Tandem et Gamma) ou au partial declustering [Copeland88][Rahm93]. Dans DBS3, le degr de fragmentation initial peut tre augment
indpendamment du degr de paralllisme. Cela permet daugmenter le nombre dactivations et donc de raliser une meilleure distribution de la charge de travail. Cependant un haut degr de fragmentation entrane des surcots (cration et gestion des les) qui peuvent dpasser les gains obtenus. Dans cette section, nous valuons exprimentalement ce surcot et mesurons les gains obtenus par lutilisation dun haut degr de fragmentation.
5.5.1. Surcots dun haut degr de fragmentation

Pour estimer ce surcot, nous avons cr un ensemble de bases pour lesquelles nous avons fait varier le degr de fragmentation des deux relations (100K x 10Ktuples). Les requtes utilises sont lIdealJoin et lAssocJoin an dvaluer le surcot pour une jointure dclenche (Ideal) et pipeline (Assoc). Il a t calcul comme la diffrence du temps mesur avec le temps thorique5 pour lIdeal et lAssoc join sans index (gure 37). Cette diffrence nest pas dpendante de lalgorithme de jointure mais du type de loprateur. Ces mesures sont ralises avec 20 threads, le degr de fragmentation varie de 20 1500. Pour les deux mesures, il semble que ce surcot puisse tre reprsent par une droite (en pointills sur la gure) de coefcient 0.45 ms/degr pour lIdealJoin et de 4 ms/degr pour lAssocJoin. La diffrence entre ces deux valeurs sexplique simplement: Pour lIdeal join, une seule activation est produite et consomme. le cot est donc relatif la cration des les. Pour lAssocJoin, deux groupes de les sont cres (une pour loprateur de redistribution, lautre pour la jointure). De plus, 10000 activations transitent sur ces les entranant des surcots de synchronisation et de recherche dactivations dans les les.
5. Le temps thorique est calcul en divisant le temps mesur avec un degr de 20 par le rapport des degrs (algorithme par boucle imbriqu). Pour un degr d, nous avons donc Td = T20*20 / d.
- 65-
6 5
AssocJoin
AssocJoin Temps de rponse (s)

12
IdealJoin
IdealJoin
surcot (s)
4 3 2 1 0 250 500 750
4m
e /d
gr
10
0.45 ms/degr
1000 1250 1500 4 250 500 750 1000 1250 1500
Degr de fragmentation
Figure 37 : Surcot de la fragmentation pour lIdeal-Join et lAssoc-Join (sans index temporaire)
Figure 38 : Temps de rponse de lIdeal-Join et Assoc-Join (Avec index temporaire)
Le surcot dans le cas dun oprateur pipelin nest pas ngligeable. Cependant, il permet denvisager avec peu (ou pas) de dgradation, un degr de fragmentation de lordre du millier. En effet, les gains entranes par la simplication algorithmique (R
S=
U Ri
Si ) permettent dabsorber, au moins partiellement, le surcot de
fragmentation. Ceci est vident pour lalgorithme par boucles imbriques. Nous avons cherch le vrier pour des oprateurs avec index. Ainsi, la gure 38 prsente les temps dexcution des mmes requtes, excuts cette fois avec un index temporaire et sur des relations de 500 x 50Ktuples. Pour ces requtes, le surcot domine le gain quand D>~1000 (Assoc) et D >~1400 (Ideal). Ces mesures montrent donc linuence limite du surcot occasionn par un haut degr de fragmentation. Dans la section suivante, nous utilisons cette proprit du modle (et de son implmentation) pour essayer damliorer le support de mauvaises rpartitions dans le cas doprateurs dclenchs.
5.5.2. Un haut degr de fragmentation pour un meilleur support du skew

Thoriquement, laugmentation du degr de fragmentation des relations doit permettre damliorer les performances de DBS3 dans le cas doprateurs dclenchs. Nous avons voulu le vrier en mesurant les temps dexcutions (sur 20 threads) dun IdealJoin, avec et sans index temporaire, appliqu respectivement des relations de 500 x 50 Ktuples et de 100 x 10 Ktuples. Le degr de fragmentation des relations varie de 20 1500. Les mesures ont t faites sur des donnes bien rparties puis avec une rpartition Zipf de degr 0,6. Les threads utilisent une mthode de consommation LPT.
- 66-
Chapitre III
Nous avons, grce ces mesures, pt calculer le coefcient (v) rel de dgradation du temps dexcution (T0.6) par rapport au temps sans biaisage (T0) que nous obtenons ainsi:
T 0.6 v 0.6 = -------- 1 T0
La gure 39 prsente les valeurs de v0.6 pour les deux requtes. Ces deux courbes sont quasiment identiques, conrmant que le comportement de notre modle est indpendant de lalgorithme de jointure. La dernire courbe prsente la valeur calcule de v dans le cas le pire.
3
Dgradation duue au skew (v)
Ideal Join (boucles imbriques) Ideal Join (index temporaire) vpire
2.5 2
1.5 1
0.5 0 250
500
750
1000
1250
1500
Figure 39 : Dgradation due au skew avec Ideal-Join
Dans le cas dun oprateur dclench sappliquant sur des donnes mal rparties, lintrt dun haut degr de fragmentation apparat clairement. En augmentant le degr de fragmentation, nous diminuons le granule de traitement squentiel des oprateurs dclenchs (une activation = un paquet). La mthode LPT peut alors mieux rpartir la charge de travail sur les threads associs loprateur. Dans le cas doprateurs pipelins, le granule de traitement squentiel est trs petit, (une activation = un tuple). Une fragmentation leve nentrane alors que des surcots puisquil ne modie en rien le nombre dactivations transmises. Ceci a t vri en effectuant les mmes mesures sur la requte AssocJoin. Dans ce cas, T0.6 ~= T0 quelque soit le degr de fragmentation (v0.6 < 0.03). Une requte complexe comprend, en gnral plusieurs oprateurs dclenchs et pipelins. Le choix dun haut degr de fragmentation permet de mieux supporter les mauvaises rpartitions pour les oprateurs dclenchs, mais entranent un surcot
- 67-
6 Conclusion
non ngligeable pour les oprateurs pipelins. Toutefois, les gains obtenus sur les oprateurs dclenchs contrebalancent largement ces surcots.
Conclusion
Dans ce chapitre, nous avons montr comment les problmes de rpartition de
charge en cas de mauvaises distributions de donnes sont pris en charge par le modle dexcution de DBS3, un SGBD parallle destin une architecture mmoire partage et implment sur une KSR1 munie de 72 processeurs. Notre solution associe une fragmentation statique des donnes une allocation dynamique des processeurs aux fragments de requtes. La fragmentation statique des donnes permet de rduire les interfrences, lallocation dynamique des processeurs, de raliser une meilleure rpartition de la charge de travail. De plus, cette approche simplie le travail dadministration de la base de donnes puisque le degr de paralllisme nest plus li au degr de fragmentation des relations. Lavantage principal de cette solution est de supporter efcacement les mauvaises distributions de donnes en permettant chaque thread de choisir dynamiquement quelle instance doprateur il va excuter et en utilisant un haut degr de fragmentation. An de quantier les gains de cette approche, nous avons ralis des mesures de performances sur notre prototype avec plusieurs bases du Wisconsin Benchmark. Le comportement de notre modle face aux mauvaises distributions de donnes dpend fortement du type doprateur excuter. Dans DBS3, les oprateurs pipelins sont naturellement insensibles au skew. Ceci est d au grand nombre dunits de traitement squentielles (activations) produites par lexcution pipeline et permet une bonne rpartition de la charge, mme dans des situations difciles (haut degr de biaisage et de paralllisme) Pour les oprateurs dclenchs, le nombre dactivations dpend du degr de fragmentation des oprandes. Des heuristiques peuvent tre utilises pour rduire le surcot du au biaisage. Cependant, avec un haut degr de biaisage, le temps dexcution est au moins gal au temps de traitement de lactivation la plus chre. Dans ce cas, il ny a pas dintrt augmenter le degr de paralllisme. Une solution efcace est daugmenter le degr de fragmentation des relations, ce que permet le modle de DBS3 avec un surcot ngligeable.
- 68-
Chapitre III
Cette approche est rendue possible par larchitecture mmoire partage sousjacente de DBS3. Si, conguration gale, on peut considrer que la mmoire partage surclasse la mmoire distribue [Bhide88], il nen demeure pas moins vrai que le besoin en puissance de calcul peut dpasser la limite dextensibilit de la mmoire partage. Une conguration matrielle distribue devient alors incontournable. En runissant plusieurs machines parallles mmoire partage par un rseau rapide, nous obtenons une architecture offrant la fois lextensibilit dune architecture distribue et les performances de larchitecture partage [Graefe93a]. Nous avons donc cherch tendre le modle dexcution de DBS3 de manire prendre en compte efcacement ce type darchitecture. Le modle de fragmentation statique adopt dans DBS3 facilite grandement cette extension. Il nous suft simplement de permettre aux signaux dactivations dtre envoys sur le rseau pour tre dposs dans des les dactivations distantes. Il est, cependant, ncessaire de revoir la stratgie de rpartition de charge pour ladapter cette architecture. Ce travail est expos dans le chapitre suivant.
- 69-
6 Conclusion
- 70-
Chapitre IV
IV
Excution parallle sur une architecture hirarchique

Dans ce chapitre, nous nous intressons l'excution de requtes multi-jointures dans une architecture parallle hirarchique, consistant d'un ensemble de noeuds multiprocesseurs mmoire partage, relis par un rseau rapide. Dans ce contexte, l'quilibrage de charge doit tre effectu deux niveaux, localement entre les processeurs de chaque noeud mmoire partage puis globalement entre les diffrents noeuds. Nous proposons un modle d'excution dynamique qui maximise l'quilibrage local de charge et minimise ainsi le besoin de redistribution du travail entre les noeuds. Cela est obtenu en permettant chaque processeur d'un noeud d'excuter n'importe quel oprateur pouvant tre traite localement, tirant ainsi parti du paralllisme inter et intra-oprateur prsent dans les requtes complexes. Nous effectuons une valuation de performances en utilisant une implmentation de notre modle sur une machine KSR1 comprenant 72 processeurs. Les mesures effectues sur un ensemble de requtes mettant en jeu de grandes relations montrent de bonnes performances, mme dans le cas de mauvaises rpartitions des donnes. Nous montrons que notre modle se comporte, sur un noeud mmoire partage, aussi bien que des modles ddis et prend en compte efcacement plusieurs noeuds.
Introduction
Les concepteurs de bases de donnes parallles ont longtemps opposs les
architectures mmoires partages (shared-memory) et distribues (shared-nothing). La mmoire partage permet dobtenir de bonnes performances pour un nombre limit de processeurs. A linverse, les architectures distribues autorisent des congurations avec un grand nombre de processeurs [DeWitt92b][Valduriez93]. Larchitecture hirarchique consiste en un ensemble de noeuds multiprocesseurs mmoire partage, relis par un rseau rapide. Elle permet de combiner les avantages des deux approches prcdentes [Graefe93b]. Les multiprocesseurs symtriques (SMP), e.g., Sequent, voluent vers des architectures extensibles alors que les machines massivement parallles (MPP), e.g., NCRs Teradata, se tournent vers la mmoire partage. La PowerCluster de Bull est un autre exemple
- 71-
1 Introduction
darchitecture
hirarchique
compose
dun
ensemble
de
multiprocesseurs
symtriques Power-PC dvelopps par IBM. Nous nous intressons l'excution de requtes multi-jointures dans une architecture parallle hirarchique. Ces requtes sont de plus en plus frquentes d lutilisation de vues, notamment dans les nouvelles applications dcisionnelles, e.g. entrepts de donnes. Lobjectif dune excution parallle est de rduire le temps de rponse en distribuant la charge dune requte sur plusieurs processeurs. Le principal obstacle cet objectif est la mauvaise distribution de la charge, lorsque des processeurs sont surchargs alors que dautres sont inactifs. Les performances dune excution parallle peuvent alors se dgrader fortement puisque le temps de rponse correspond celui du processeur le plus charg. La paralllisation dune requte peut tre effectue selon deux axes: horizontalement (paralllisme intra-oprateur), en distribuant chaque oprateur sur un ensemble de processeurs, et verticalement (paralllisme inter-oprateur indpendant ou pipeline) en distribuant tous les oprateurs de la requte sur diffrents processeurs. Les solutions proposes pour la rpartition de charge sont gnralement spciques un type de paralllisation et une architecture (mmoire partage, disques partags ou compltement distribues). Sur une architecture shared-nothing, le paralllisme intra-oprateur est obtenu grce la fragmentation des donnes [Boral90], [DeWitt90b], [Apers92]. Les mauvaises distributions de donnes, frquente en pratique, [Walton91], peuvent entraner une mauvaise rpartition de la charge. Ce problme a t trait en dveloppant des algorithmes de jointure spciques supportant diffrents types de skew [Kitsuregawa90], [DeWitt92a], [Shatdal93], [Berg92] et qui sont bass sur une redistribution dynamique. Avec le paralllisme inter-oprateur, la distribution des oprateurs sur les processeurs peut aussi entraner une mauvaise rpartition de la charge. Plusieurs tudes sont ddies ce problme [Rahm93], [Mehta95], [Rahm95], [Garofalakis96]. La rpartition de charge est faite statiquement pendant la phase doptimisation ou juste avant lexcution. Les raisons potentielles dune mauvaise rpartition de charge sur une architecture shared-nothing sont tudies dans [Wilshut95]. Premirement, le degr de paralllisme et lallocation des processeurs aux oprateurs, dcid statiquement pendant la phase doptimisation, est base sur un modle de cot pouvant tre imprcis. Deuximement, le choix du degr de paralllisme est sujet des erreurs de
- 72-
Chapitre IV
partie entire car les processeurs et les oprateurs sont des entits discrtes. Finalement, les processeurs associs aux oprateurs en haut de la chane pipeline peuvent rester inactifs pendant un certain temps, cause des dlais dans une chane pipeline (pipeline delays). Ces problmes sont dus une association rigide entre processeurs et oprateurs, inhrente larchitecture shared-nothing. En mmoire partage, il y a plus de exibilit puisque tous les processeurs ont un accs uniforme la mmoire et aux disques. Les techniques de rpartition de charge [Murphy91], [Hong92], [Shekita93] peuvent alors tre plus dynamique (i.e., pendant lexcution) puisque la redistribution de la charge peut tre faite faible cot. Une stratgie dexcution trs efcace en mmoire partage est le pipeline synchrone (SP) [Pirahesh90], [Hong92], [Shekita93]. Chaque processeur lit des tuples dans des buffers dI/O et excute les jointures le long de la chane pipeline en utilisant des appels de procdure. A notre connaissance, le problme de la rpartition de charge sur une architecture hirarchique na jamais t trait. Dans ce contexte, la rpartition de charge est plus complexe puisquelle doit tre effectue deux niveaux, localement, entre les processeurs de chaque noeud mmoire partage, et globalement entre les noeuds. Les approches prsentes ci-dessus ne peuvent tre facilement adaptes une architecture hirarchique. Les approches ddies une architecture shared-nothing ne proteraient pas de la exibilit de l'architecture mmoire partage, et leurs problmes inhrents ne feraient que s'aggraver (complexit et inexactitude du modle de cot). Pour les approches destines la mmoire partage, laspect distribu de larchitecture hirarchique entranerait des surcots de communications prohibitifs. Dans ce chapitre, nous proposons un modle dexcution pour une architecture hirarchique qui ralise dynamiquement la rpartition de la charge au niveau inter et intra-oprateur. Compar lapproche dveloppe dans DBS3, les entits dexcutions ont ici la possibilit dexcuter nimporte quelle instance de nimporte quel oprateur. De manire intuitive, un processeur peut ainsi se dplacer horizontalement et verticalement le long de la requte. Lavantage principal de cette mthode, dans une architecture hirarchique, est quelle permet de minimiser les cots de communications en maximisant la rpartition de charge inter et intraoprateur au niveau de chaque noeud. Pour valider ce modle dexcution, nous avons dvelopp un prototype du modle sur la machine KSR1 et tudi ses performances sur un ensemble de requtes complexes.
- 73-
2 Problmatique
Ce chapitre est organis comme suit. La section 2 prsente la problmatique aborde en xant de manire plus prcise le contexte. La section 3 prsente les concepts de base de notre modle ainsi que la stratgie de rpartition de charge. La section 4 complte la description du modle par des dtails dimplmentation. La section 5 compare les performances de notre modle deux autres modles dexcution, grce une implmentation sur la KSR1. La section 6 conclut.
Problmatique
Le fait de considrer une architecture hirarchique change les dcisions prises par
loptimiseur pour la gnration des plans dexcution parallle [Srivastava93]. Dans cette section, nous dnissons plus prcisment le systme dexcution (architecture sous jacente, modle de paralllisation, etc.) et les plans dexcution parallle, paramtre dentre de notre modle.
2.1.
Systme dexcution
Nous considrons un systme de bases de donnes distribu comportant un ensemble de noeuds mmoire partage, appels par la suite noeud-SMP et composs de plusieurs processeurs, plusieurs disques et une mmoire partage. Les communications inter-noeuds se font par envoi de messages alors que dans chaque noeud, la mmoire partage est utilise pour raliser efcacement la communication inter-processeurs. Cette architecture est gnrale et peut supposer un petit nombre de puissants noeuds-SMP (e.g, 4 noeuds de 16 processeurs) ou un grand nombre de noeuds moins puissant (e.g, 16 noeuds de 4 processeurs). Les relations sont fragmentes horizontalement sur chaque noeud, et dans chaque noeud, sur les disques. A cet effet, une fonction de hachage est applique un ou plusieurs attributs. Le degr de fragmentation dune relation dpend de sa taille et de son usage [Copeland88]. Le home dune relation reprsente simplement lensemble des noeuds SMP stockant ses fragments. Nous considrons ici les algorithmes de jointure parallle par hachage puisquils offrent gnralement des performances suprieures [Valduriez84][Schneider89]. La jointure par hachage permet deux types de paralllismes: (i) plusieurs jointures peuvent tre excutes en mode pipeline (paralllisme inter-oprateur); et (ii) chaque jointure peut tre effectue en parallle sur des fragments de relations (paralllisme intra-oprateur). Les deux relations mises en jeu sont fragmentes (dynamiquement) en un mme nombre de fragments avec la mme fonction de hachage applique
- 74-
Chapitre IV
l'attribut de jointure. La jointure parallle par hachage seffectue alors en deux phases squentielles. Dans la premire phase, une table de hachage est construite, en parallle, pour chaque fragment de la relation interne. Dans la deuxime phase, les fragments de la relation externe sont lus en parallle et leurs tuples sont joints par hachage avec la table de hachage du fragment correspondant de la relation interne.
2.2.
Le rsultat de la phase doptimisation parallle est un plan dexcution parallle consistant dun arbre doprateur, de lordonnancement de ces oprateurs et de lallocation des ressources aux oprateurs. Plusieurs formes darbres peuvent tre considres: gauches, droits, zigzag [Ziane93] ou bushy. Les arbres bushy sont les plus intressants car ils offrent plus dopportunits pour minimiser la taille des rsultats intermdiaires [Shekita93] et pour exploiter diffrents types de paralllisme [Lanzelotte93]. Aussi, dans ce chapitre, nous nous concentrons sur l'excution darbres bushy. Larbre doprateur provient de la macro-expansion de larbre de jointure [Hasan94]. Les noeuds reprsentent les oprateurs atomiques de l'algbre relationnelle et les arcs reprsentent les ots 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. Considrons un arbre d'oprateur utilisant la jointure par hachage. Trois oprateurs sont ncessaires: scan pour lire chaque relation de base, build et probe. L'oprateur de build produit la table de hachage de manire bloquante. Le probe produit, en pipeline, les tuples rsultats. Ainsi, pour une jointure par hachage, il y a toujours un arc bloquant entre le build et le probe. Larbre d'oprateur n'entrane pas de contraintes entre deux oprateurs indpendants et permet donc leur excution parallle. Toutefois, an doptimiser le partage des ressources disponibles (mmoire, disques, processeurs), loptimiseur peut ajouter de nouvelles contraintes an de rendre leur excution squentielle. Ainsi, lordonnancement des oprateurs, dcid par loptimiseur rete les contraintes doptimisation ainsi que les contraintes inhrentes lutilisation de la jointure par
- 75-
2 Problmatique
hachage. Il est exprim par un ordre partiel sur lensemble des oprateurs. O1 < O2 indique que l'oprateur O2 ne peut commencer avant la n de O1 Un arbre d'oprateur peut tre dcompos en un ensemble de chanes pipeline maximum, i.e., avec le plus grand nombre doprateurs pipeline, appeles aussi fragments [Shekita93] ou tasks [Hong92]. Pour des raisons de simplicit, nous supposons que chaque chane pipeline peut tre entirement excute en mmoire. Dans le cas contraire, loptimiseur devrait ajouter de nouveaux arcs bloquants entre les oprateurs dune chane pipeline, an de forcer la matrialisation de relations intermdiaires (arbres zigzag [Ziane93]). Classiquement, loptimiseur parallle choisi lensemble des processeurs qui seront allous pour l'excution de chaque oprateur. En mmoire partage, cette dcision se rduit au nombre optimal de processeurs, puisque chaque processeur a un mme cot d'accs la mmoire et aux disques. En shared-nothing, lallocation des processeurs dpend fortement de la localisation des donnes. Chaque processeur est gnralement assign lexcution dun et un seul oprateur. Larchitecture hirarchique introduit une nouvelle dimension ce problme. Dans ce cas, il semble plus important de dcider du sous ensemble de noeuds-SMP o sera excut un oprateur, que nous appellerons le home de loprateur, plutt que le sous ensemble des processeurs. Ainsi, le plan dexcution parallle contiendra le home de chaque oprateur, celui-ci devant respecter deux contraintes videntes: (i) le home dun oprateur scan est gal au home de la relation lue; et (ii) deux oprateurs build et probe conscutifs ont forcment le mme home.1
Arc piquant Arc pipeline Chane pipeline
S T U R Arbre de jointure Ordonnancement des oprateurs

Contraintes (hachage) : Build1<Probe1, Build2<Probe2, Build3<Probe3 Heuristique 1: Build1<Scan2, Build2<Scan4, Build3<Scan4 Heuristique 2: Build3<Scan3
Probe 3 Build 3 Probe 1 Build 1 Scan 1 Scan 2 Build 2 Scan 3 Probe 2 Scan 4
Localisation des oprateurs

home(Scan1) = Noeud A home(Build1, Probe1, Scan2, Scan3) = Noeud B home(Scan 4) = Node C home (Build3, Build2, Probe2, Probe3) = Noeud B,C
Arbre doprateur
Figure 40 : Un arbre de jointure et le plan dexcution parallle associ.
- 76-
Chapitre IV
La gure 40 montre un arbre bushy mettant en jeu 4 relations, ainsi que le plan dexcution parallle associ. Celui-ci consiste en un arbre doprateur tiquet avec lordonnancement des oprateurs et les informations de localisation (home). Outre les contraintes temporelles impliques par lutilisation de la jointure par hachage, lordonnancement prsent contient dautres contraintes, correspondant deux heuristiques possibles: (i) une chane pipeline ne dbute que lorsque toutes les tables de hachage sont construites; et (ii) les chanes pipelines sont excutes une par une. Un tel plan dexcution parallle est lentre de notre modle dexcution. Les dcisions doptimisations et dordonnancement des oprateurs, supposes bonnes, sont strictement suivies.
2.3.
Dnition du problme
Avec les dnitions et hypothses prcdemment nonces, nous pouvons maintenant poser le problme. Etant donn un plan dexcution parallle compos dun arbre doprateur, de son ordonnancement et du home des oprateurs, le problme consiste produire une excution sur une architecture hirarchique minimisant le temps de rponse. Pour cela, il est ncessaire dviter l'inactivit des processeurs en effectuant une distribution dynamique de la charge de travail. Celleci doit se faire deux niveaux: (i) sur chaque noeud-SMP, la rpartition de charge peut tre ralise efcacement grce la mmoire partage; (ii) entre les noeudsSMP, un mcanisme, plus coteux, bas sur des envois de messages doit alors tre mis en place. Nous voulons donc proposer un modle d'excution qui permet une rpartition dynamique de la charge deux niveaux dans lequel lutilisation du mcanisme local est maximise alors que lutilisation dun mcanisme global, plus coteux, est minimise.
Le modle dexcution parallle DP

Conceptuellement, la paralllisation dune requte revient dcouper le travail
total suivant deux axes. Dune part, chaque oprateur est horizontalement fragmente an dobtenir du paralllisme intra-oprateur. Dautres part, la requte est verticalement fragmente en oprateurs dpendants ou indpendants an dobtenir du paralllisme inter-oprateur. Nous appelons activation un travail lmentaire squentiel, i.e., ne pouvant plus tre fragment. La principale proprit
1. Il est relativement ais de fournir un tel plan dexcution parallle en utilisant un optimiseur shared-nothing. Chaque noeud-SMP sera considr par loptimiseur comme un puissant processeur.
- 77-
3 Le modle dexcution parallle DP
de notre modle est de permettre tous les threads dexcuter n'importe quelle activation localise sur son noeud-SMP. Ainsi, il ny a pas dassociation statique entre les threads et les oprateurs. Ceci doit nous permettre dobtenir une rpartition de charge au niveau intra-oprateur comme inter-oprateur sur chaque noeud-SMP. De cette manire, le besoin dune rpartition de charge globale est rduit au minimum. Elle est uniquement mise en oeuvre lorsquil ny a plus de travail sur un noeud-SMP. Dans cette section, nous prsentons les concepts de base de notre modle et la stratgie de rpartition de charge que nous illustrons par un exemple.
3.1.
Concepts
Notre modle d'excution est bas sur quelques concepts: activations, les dactivations, fragmentation, et threads. Activations. Une activation reprsente un travail lmentaire squentiel. Comme les activations peuvent tre traites par nimporte quel thread, elles doivent rfrencer lensemble des informations ncessaires leur traitement: le code excuter et les donnes accdes. Les activations de dclenchement ou trigger activation sont utilises pour dclencher l'excution dun oprateur feuille, i.e., un scan. Elle est constitue par un doublet (Oprateur, Fragment) rfrenant loprateur de scan ainsi que le fragment de la relation de base lire. Les activations de donnes ou data activation sont relatives aux tuples produits en mode pipeline et sont constitues dun triplet (Oprateur, Tuple, Fragment) rfrenant loprateur excuter (build ou probe), le tuple trait et le fragment correspondant. Pour un build, l'excution dune data activation revient insrer le tuple dans la table de hachage associe au fragment. Pour un probe, elle consiste tester le tuple avec la table de hachage associe au fragment. La qualit de l'quilibrage de charge obtenue dpend du grain de paralllisme [Bouganim96d]. Avec un grain trs n, (data activations) nous obtenons une trs bonne rpartition de la charge mais avec un haut surcot. A linverse, l'utilisation dun grain plus grossier, (trigger activation) a un surcot limit mais peut entraner des mauvaises rpartitions de charge. An d'obtenir une bonne rpartition de la charge un cot limit, nous diminuons le grain des activations de dclenchement en remplaant un fragment par une ou plusieurs pages du fragment2, et augmentons le grain des activations de donnes par lutilisation de caches. Files dactivations. La transmission des activations de donnes le long des
- 78-
Chapitre IV
pipelines est effectue grce des les dactivations associes aux oprateurs. Ces envois sont effectus travers la mmoire partage quand le producteur et le consommateur sont sur le mme noeud et travers le rseau dans le cas contraire. An dunier le modle, nous utilisons des les dactivations pour les activations de donnes (build et probe) et pour les activations de dclenchement (scan) Chaque oprateur utilise une le pour recevoir des activations. Comme chaque thread peut accder lensemble des les localises sur son noeud-SMP, lutilisation dun nombre restreint de les (par exemple, une par oprateur) entranerait des contentions. An de rduire ces contentions, nous associons pour chaque oprateur une le par thread. Lensemble des les dactivations alloues un thread constitue lensemble des les primaires de ce thread. An de rduire encore plus les contentions, un thread consomme dabord des activations de ses les primaires avant de chercher dans les autres les accessibles sur le noeud-SMP. Pendant l'excution, lordonnancement des oprateurs induit le blocage de certains oprateurs dans lattente de la n des oprateurs prcdents. Dans ce cas, les les des oprateurs bloqus sont aussi bloques, i.e., leurs activations ne peuvent tre consommes. Elles peuvent toutefois tre produites. Lorsque tous les oprateurs bloquant sont termins, la le bloque devient consommable, i.e., les threads peuvent consommer ses activations. Ceci est illustr dans la gure 41 qui prsente un clich de lexcution pour larbre doprateur de la gure 40. Probe3 Probe2 Scan4 Build2 Scan3 Build3 Probe1 Scan2 Build1 Scan1
T T Noeud A T T Noeud B T T T Noeud C T
Files primaires Files termines Files bloques Files actives Thread
Figure 41 : Clich dune excution

2. Compar lapproche dveloppe dans le chapitre prcdent (haut degr de fragmentation), cette approche prsente lavantage de nentraner que des surcots trs limits (pas de surcots en rapport avec les les dactivations). par contre, elle ne permet pas de proter de simplications algorithmiques.
- 79-
Les threads peuvent librement consommer des activations de nimporte quelle le non bloque. Sans aucune restriction sur la faon dont les activations sont slectionnes, la consommation mmoire peut considrablement augmenter. Considrons par exemple, lexcution pipeline de deux oprateurs. Si la stratgie de slection favorise le producteur, la relation intermdiaire peut tre entirement matrialis (plus de pipeline!), risquant alors de saturer la mmoire. An dviter cette situation, nous avons choisi de limiter la taille des les dactivations et utilisons un mcanisme de contrle de ux [Graefe93b][Pirahesh90], pour synchroniser les producteurs et les consommateurs dans les chanes pipeline. Fragmentation. Appelons degr de fragmentation, le nombre de paquets des relations mises en jeu. Dans le chapitre 3, nous avons vu que lutilisation dun haut degr de fragmentation permet de rduire les effets ngatifs des rpartitions biaises (data skew) mais peut entraner des surcots non ngligeables, dus un grand nombre de fragments grer. Comme nos activations sont autonomes, et rfrencent le fragment considr, nous pouvons mlanger des activations correspondantes diffrents fragments dans la mme le, rduisant alors les surcots de gestion de les. Dune faon plus gnrale, dans notre modle dexcution, lusage dun haut degr de fragmentation facilite lquilibrage de charge. Threads. An d'quilibrer la charge de travail, sur un noeud-SMP, une stratgie simple consiste allouer un nombre de threads bien plus grand que le nombre de processeurs, et de laisser le systme dexploitation raliser lordonnancement des threads. Le problme dune telle stratgie est quelle entrane beaucoup dappels au systme dexploitation dus lordonnancement des threads, aux interfrences entre les threads et aux effets de convoi [Blasgen79] [Pirahesh90] [Hong92]. Au lieu de compter sur le systme dexploitation pour raliser lquilibrage de charge, nous avons choisi dallouer un seul thread par processeur et par requte. Ceci est possible dans notre modle, puisquun thread peut excuter nimporte quel oprateur localis sur son noeud-SMP. Lavantage de cette stratgie un-thread-parprocesseur est de rduire, de faon signicative les surcots dinterfrences et de synchronisation. Sur chaque noeud-SMP, nous crons alors une le par thread et par oprateur, donnant alors le mme degr de paralllisme potentiel chaque oprateur. De plus, comme il ny a quun thread par processeur pour lensemble de la requte, nous rduisons fortement les surcots dinitialisation. Cette stratgie un-thread-par-processeur peut raliser une bonne rpartition de la
- 80-
Chapitre IV
charge de travail si les threads ne se bloquent jamais. En effet, le blocage dun thread, en lattente dun vnement, entranerait une inactivit du processeur. Pendant le traitement dune activation, un thread peut tre bloqu dans les situations suivantes:
le
thread ne peut insrer une activation dans une le car celle-ci est pleine
(contrle de ux);
lutilisation
dI/O asynchrones, permettant de raliser les accs disques et les
traitements en parallle, peuvent crer des situations bloquantes, notamment en dbut dexcution;
avec
plusieurs transactions, le traitement dune activation rfrenant une
donne partage peut entraner le blocage dun thread sur une demande de verrou transactionnel. Les problmes de blocages sont gnralement rsolus laide de primitives de synchronisation du systme dexploitation (e.g., signaux). Cette solution nest pas optimale car elle entrane des surcots de synchronisation et de changement de contexte. Elle est cependant acceptable lorsque plus de threads que de processeurs ont t allous, puisque le systme excute les threads non bloqus an de maximiser lutilisation des processeurs. Dans notre modle, ces situations dattentes entraneraient l'inactivit du processeur. Nous avons rsolu ce problme comme suit: un thread, dans une situation bloquante, suspend son excution, en faisant un appel de procdure, an de trouver dautres activations traiter durant lattente. Lavantage est que la sauvegarde du contexte dexcution est fait par lappel de procdure, ce qui est bien moins coteux que des primitives systmes. Ce mcanisme est dtaill un peu plus loin.
3.2.
Rpartition de la charge
La rpartition de la charge, dans chaque noeud-SMP, est obtenue en allouant les les dactivations dans un segment de mmoire partage et en permettant tous les threads de consommer des activations dans nimporte quelle le. An de limiter les interfrences entre les threads, chaque thread consommera, autant que possible, dans ses les primaires avant de considrer dautres les sur le mme noeud-SMP. Ainsi, un thread ne devient inactif que lorsquil ny plus aucune activation daucun oprateur, cest dire quil ny a plus rien faire sur ce noeud (situation dite de famine). Lorsquun noeud est en famine, i.e., il ny a plus dactivations dans les les non
- 81-
bloques, nous appliquons une technique de load sharing ou partage du travail, en transfrant une partie de la charge dun autre noeud-SMP, i.e., des activations distantes. Cependant, le transfert dactivations (en utilisant des envois de messages) entrane des surcots de communications. De plus, il faut aussi transfrer les donnes associes (tables de hachage). Il est donc ncessaire destimer dynamiquement le gain obtenu par cette opration. Appelons demandeur le noeud-SMP en famine et fournisseur le noeud-SMP fournissant une partie de son travail au demandeur. Il nous faut choisir le nombre (combien ?) et le type dactivations transfrer (quels oprateurs, quelles les ?). Il y a un compromis entre le gain potentiel apport par la redistribution de la charge et le surcot occasionn. Ce compromis peut sexprimer par les conditions suivantes: (i) le demandeur doit disposer de sufsamment de mmoire pour stocker les activations et les donnes associes; (ii) sufsamment de travail doit tre transfr an damortir le surcot d'acquisition; (iii) il ne faut pas transfrer trop de travail, au risque de surcharger le demandeur; (iv) seules les activations de probe peuvent tre transfres puisque les activations de scan ncessitent des accs aux disques et que les activations de build entranent la construction de tables de hachage locales; (v) il ny a pas dintrt transfrer des activations dune le bloque puisquelles ne pourront pas tre traites immdiatement. Enn, (vi) pour respecter les dcisions de loptimiseur, un noeud-SMP nexcutera pas dactivations dun oprateur quil ne possde pas, i.e., le noeud-SMP nest pas dans le home de loprateur. Plus de dtails sur la stratgie de rpartition de charge globale sont donns dans la section 4. La qualit de la rpartition de charge obtenue dpend du nombre doprateurs excuts concurremment puisquils fournissent des opportunits de trouver du travail en cas dinactivit. Il est possible daugmenter le nombre doprateurs concurrents en excutant concurremment plusieurs chanes pipelines ou en utilisant des algorithmes de jointures par hachage non bloquant [Wilshut95]. La stratgie full parallel dcrite dans [Wilshut95] est base sur cet algorithme, et permet dexcuter tous les oprateurs de larbre bushy concurremment. Cependant, lexcution concurrente de plusieurs oprateurs peut entraner une augmentation de la consommation mmoire. Lordonnancement statique des oprateurs, effectu par loptimiseur doit viter le dpassement de capacit mmoire et rsoudre ce compromis.
- 82-
Chapitre IV
3.3.
Exemple
Nous allons maintenant illustrer ces concepts sur un exemple simple. Bien que le modle dexcution soit conu pour des requtes multi-jointures, un exemple sur de telles requtes serait incomprhensible. Nous considrons donc simplement la jointure de deux relations R et S excut sur deux noeuds-SMP A et B, chacun possdant deux processeurs et donc deux threads dexcution. La relation R est stocke sur le noeud A, et S sur le noeud B. La gure 42 prsente le plan dexcution parallle ainsi quun clich de lexcution son dbut.
Node B
Probe BuildR ScanR

Node A
ScanS BuildR < Probe
ScanR BuildR ScanS Probe TA1 TA2
c1
c2
TB1
TB2
Node A
Node B
Arbre de jointure Plan dexcution parallle
Clich de lexcution
Figure 42 : Exemple simple dexcution
Sur le noeud A, les threads TA1 et TA2 consomment des activations dclenchantes de loprateur de scanR dans les les associes. Pour chaque activation, ils excutent loprateur de scan sur un fragment de R, lisant les tuples du disque et envoyant les tuples slectionns en pipeline loprateur build sur le noeud B. Si TA1 et TA2 se bloquent, car une des les de loprateur de build est pleine, comme il ny a pas dautre oprateur traiter sur le noeud A, ils devront attendre que les les du build se vident. Si un thread, TA1 par exemple, termine le traitement de toutes les activations de sa le, il consommera des activations de la le de TA2 an dquilibrer la charge de travail. Loprateur scanR se termine lorsquil ny a plus dactivations traiter. Sur le noeud B, les threads TB1 et TB2 consomment des activations dclenchantes de loprateur de scanS dans les les associes. Pour chaque activation, ils excutent loprateur de scanS sur un fragment de S, lisant les tuples du disque et envoyant les tuples slectionns en pipeline loprateur de probe. An dillustrer le changement de contexte dexcution par les threads, nous supposerons que le traitement des activations C1 et C2 produisent plus de tuples slectionns que les les du probe ne peuvent stocker. Ainsi, lors du traitement de C1, TB1 remplit les les du probe. An
- 83-
4 Techniques dimplmentation
dviter dattendre, TB1 suspend le traitement de C1 en appelant une procdure qui cherchera dautres activations traiter. Ainsi, le contexte dexcution de C1 est sauvegard dans la pile dappel de procdure. Comme le traitement dautres activations du scanR rsulterait en un nouveau blocage de TB1, et comme loprateur de probe est bloqu (puisque le build nest pas termin), TB1 slectionnera des activations du build produites par TA1 et TA2. TB2 fera de mme lors du traitement de C2. TB1 et TB2 traitent donc les activations du build jusqu la n de loprateur de build (i.e., les tables de hachage sont entirement construites), dbloquant ainsi loprateur de probe. Ils peuvent donc maintenant consommer les activations du probe, vidant ainsi les les du probe et permettant la reprise du traitement de C1 et C2. Le traitement dautres activations du scanS peut, de nouveau, saturer les les du probe, entranant un changement de contexte par appel de procdure et le traitement dactivations du probe, et ainsi de suite jusqu la n de loprateur scanS. Cet exemple simple montre lintrt des activations et du mcanisme de changement de contexte par appel de procdure. Les threads TB1 et TB2 sont toujours actifs pendant le traitement de la requte, et la charge du noeud B est parfaitement quilibre. Les threads TA1 et TA2 ont pu rester inactif (si les les du build restent satures). Cela est d aux dcisions de loptimiseur qui restreint le champ daction des threads TA1 et TA2 au seul oprateur de scanR. Dans le cas de requtes multijointures, dautres oprateurs pourraient tre excuts durant cette attente.
Techniques dimplmentation
Dans cette section, nous prsentons les techniques de bases utilises pour mettre
en oeuvre notre modle dexcution. Cette prsentation se fait en suivant les diffrentes tapes de lexcution dune requte sur une architecture hirarchique. Initialisation. Soit s le nombre de noeuds-SMP, ayant chacun p processeurs. Lexcution est initialise en crant, sur chaque noeud-SMP participant la requte, p threads dexcution, et, pour chaque oprateur non bloqu, localis sur ce noeud, p les dactivations. De plus, un thread additionnel, appel scheduler est cr sur chaque noeud-SMP an de recevoir et transmettre les messages entre les noeuds. Pendant lexcution, le scheduler reoit les messages (activations) des noeuds distants et les redirige vers les les destinataires sur le noeud-SMP. Le scheduler traite aussi les messages de synchronisation globale ncessaires pour la rpartition de charge globale et la dtection de la n des oprateurs. Localement, le scheduler communique avec les autres threads en utilisant la mmoire partage (pour lenvoi dactivations)
- 84-
Chapitre IV
ou par envoi de signaux pour la synchronisation. Excution de la requte. Elle dbute par lenvoi dactivations de dclenchement tous les oprateurs de scan non bloqus. Chaque thread traite alors des activations les consommant par priorit dans ses les primaires. Si toutes les les primaires dun thread sont vides, il cherchera des activations dans les les primaires des autres threads localiss sur le mme noeud, i.e. les les secondaires. Sil ny a plus dactivations disponibles sur le noeud, les threads consommeront des activations dautres noeuds (voir plus loin). Conceptuellement, chaque thread effectue une simple boucle qui se nit lorsque le dernier oprateur de la requte termine. A chaque itration, une activation est traite. Si aucune activation, locale ou distante ne peut tre consomme, le thread est endormi. Lorsque de nouvelles activations arrivent, ou lorsquun oprateur est dbloqu, le scheduler rveille le thread qui reprend son excution. Slection locale dactivations. An de maximiser la rpartition de charge locale, la slection des activations doit permettre l'accs lensemble des les, en respectant les priorits, minimiser les interfrences entre les threads lors des accs aux les et viter de chercher dans des les associes des oprateurs termins ou bloqus. Notre solution repose sur une liste circulaire rfrenant lensemble des les actives, i.e., ni termines ni bloques (voir gure 43). Cette liste est accde par tous les threads pendant la slection des activations.
j indique la le prioritaire i de loprateur i pour le Thread 4
3 4 3 Q3 Q1 4 Q2 Q2 3 4 Q3 Q1 2 1 Q3 Q1 1 2 Q2 2 1 Q2 Q1 Q3
thread j
Thread 3
Thread 1 Slection dactivations
Thread 2
Figure 43 : Liste circulaire de les dactivations
An dviter les interfrences, chaque thread accde la liste circulaire une position diffrente correspondant sa premire le primaire. Cette liste est cre au dbut de la requte, et mise jour la terminaison de chaque oprateur an de supprimer les les associes de la liste. De plus, si la n de cet oprateur entrane le
- 85-
4 Techniques dimplmentation
dblocage dautres oprateurs, les les dbloques sont insres dans la liste circulaire. Si aucune activation nest trouve dans les les de la liste circulaire, cela signie quil ny a plus de travail effectuer sur ce noeud. Des activations distantes doivent tre alors slectionnes. Slection dactivations distantes. La slection dactivations distantes permet de raliser la rpartition globale de la charge. Lorsquun thread ne trouve pas dactivations traiter localement, il envoie un signal son scheduler local, qui, son tour envoie un message de famine aux autres noeuds. Ce message indique la mmoire disponible du noeud demandeur. Sur rception de ce message, le scheduler de chaque noeud va valuer les les candidates. La section 3.2 numre les conditions ncessaires pour quune queue soit candidate, i.e., les conditions qui assurent que le transfert des activations de cette queue est possible et apportent un gain. Sur chaque noeud, le scheduler choisit la queue candidate prsentant le meilleur rapport gain/surcot. Le gain obtenu par le transfert dune queue est proportionnel au nombre dactivations dans la le. Le surcot est proportionnel la taille des donnes transmises (tables de hachage et activations). Le scheduler renvoi alors au demandeur des informations sur la le slectionne (sil y en a une) ainsi quune estimation de sa charge. Aprs avoir reu des rponses de tous les noeuds, le demandeur slectionne le noeud le plus charg et demande alors le transfert des activations et des donnes associes, i.e., les tables de hachage. Sur rception des donnes, le scheduler du noeud demandeur rveil les threads an de traiter les activations transmises. An doptimiser lexcution dans le cas de famine rptitive sur le mme noeud, une liste de les transmises est maintenue sur le noeud demandeur. Lors de la situation de famine suivante, le noeud en famine cherchera transfrer des activations des les dont il possde dj les donnes associes. Traitement des activations. Une activation rfrence le code devant tre excut (scan, build ou probe). Ainsi, le traitement dune activation est simplement effectu en faisant un appel au code associ. Cependant, lors de lexcution de ce code, un thread peut effectuer une action bloquante, par exemple en effectuant une entre/sortie sur le disque ou en crivant dans une le pleine. Pour viter ce genre de situation, le code de chaque action potentiellement bloquante est modi de la manire suivante.
Si (je ne peux effectuer (Action bloquante)) alors TraiterUneAutreActivation //effectuer laction bloquerais le thread //cherche une autre activation
tantque (je ne peux effectuer (Action bloquante)) faire
- 86-
Chapitre IV
n tantque nsi
La procdure TraiterUneAutreActivation ne recherchera pas dactivations venant du mme oprateur an dviter de nouveaux blocages. Cette technique permet dviter les blocages et maximise lutilisation des processeurs sans ncessiter dappels au systme.
Etude de performances
Lvaluation des performances dun modle dexcution parallle pour des
requtes multi-jointures est rendue difcile par la ncessit dutiliser un grand ensemble de requtes de test mettant en jeu de grosses relations. Une solution classique est dutiliser une simulation qui facilite la gnration de requtes et des relations, et permet de tester diverses congurations. Cependant, une simulation ne nous permettrait pas de prendre en compte des paramtres importants comme les surcots dinterfrences entre les threads. Dun autre ct, lutilisation dun prototype complet et de jeu de tests rels restreindrait le nombre de requtes testes et rendrait la gnration des donnes difcile. Nous avons donc choisi dimplmenter compltement notre modle dexcution sur une machine multiprocesseur et de simuler lexcution des oprateurs, ignorant ainsi le contenu des relations. Lexcution des requtes ne dpend alors plus du contenu des relations mais de paramtres affects chaque relation (cardinalit, slectivit, distribution, etc...). Dans la suite de cette section, nous dcrivons la plate-forme dexprimentation et prsentons des mesures de performances en deux tapes: localement sur un seul noeud-SMP puis sur plusieurs noeuds.
5.1.
Dans cette section, nous prsentons la conguration de la machine multiprocesseur utilise dans les exprimentations et la faon dont nous avons gnr les plans dexcution parallles et les relations. Nous prsentons aussi la mthodologie utilise pour la prsentation des rsultats.
5.1.1.
Conguration de la plate-forme
Nous avons implment notre modle dexcution sur la machine KSR1, munie de 72 processeurs [Frank93] car sa composante mmoire (virtuellement) partage et
- 87-
5 Etude de performances
le grand nombre de processeurs disponible permettent une organisation de type hirarchique. An de simuler une architecture hirarchique, nous avons divis lensemble des processeurs en groupes. Chaque groupe reprsente un noeud-SMP 3, entre ces groupes, nous avons simul des communications inter-noeuds en utilisant des paramtres classiques des rseaux dinterconnexion.
Paramtres rseau Bande passante (bas sur [Mehta95]) Dlai de transmission point point Cot CPU pour lenvoi dun message de 8 Ko Cot CPU pour la rception dun message de 8 Ko Innie 0,5 ms 10000 instructions 10000 instructions Valeur
Tableau 3 : Paramtres de simulation du rseau Enn, pour pouvoir excuter des requtes mettant en jeu plusieurs disques, nous avons simul les accs aux disques avec les paramtres suivants:
Paramtres des disques Nb Disques Temps de latence Seek Taux de transfert Cot I/O asynchrones Cache dI/O Valeur 1 par processeur 17 ms 5 ms 6 Mo/s 5000 instructions. 8 pages Cot CPU pour initialiser une I/O asynchrone Buffer de cache pour les lectures squentielles Commentaires Nombre de disques simuls Temps de rotation Temps de placement du bras
Tableau 4 : Paramtres de simulation des disques
5.1.2.
Plans dexcution parallle
Lentre de notre modle dexcution est un plan dexcution parallle obtenu aprs compilation et optimisation de la requte. Pour gnrer les requtes, nous avons utilis lalgorithme propos par [Shekita93] avec trois types de relations: petite
3. An de simuler une architecture mmoire partage et dviter linuence de larchitecture NUMA de la KSR1, nous avons rendu locales toutes les lectures et criture de tuples, i.e., dans le cache local de chaque processeur.
- 88-
Chapitre IV
(10K-20K tuples), moyenne (100K-200K tuples) et grande (1M-2M tuples). Tous dabord, nous gnrons alatoirement le graphe de connexion des prdicats. Comme, en pratique, la plupart des requtes multi-jointures ont des prdicats de jointure simple, nous navons considr que des graphes acycliques. La cardinalit de chaque relation mise en jeu dans la requte est alors choisi alatoirement dans les intervalles des petites, moyennes ou grandes relations. Enn, la slectivit de chaque arc entre deux relations du graphe de connexion des prdicats est choisie alatoirement dans lintervalle [0.5 min ( R , S ) R S ,1.5 max ( R , S ) R S ] Le rsultat de la gnration des requtes est un graphe acyclique tiquet avec les cardinalits des relations et la slectivit des arcs. Nous avons produit 20 requtes, portant chacune sur 12 relations. Nous avons alors optimis chaque requte grce loptimiseur de DBS3 [Lanzelotte93]. Le fait que cet optimiseur ait t dvelopp dans notre quipe nous permet de contrler de faon trs ne cette tape. Pour chaque requte, les deux meilleurs arbres bushy sont retenus. Pour produire automatiquement des plans d'excution parallles partir darbres doprateurs, nous avons fait un certain nombre d'hypothses. Premirement, les relations sont fragmentes sur tous les noeuds-SMP. Deuximement, tous les oprateurs du plan sexcutent sur tous les noeuds-SMP. Troisimement, les chanes pipelines sont excutes une par une. Bien que ces hypothses ne produisent pas un plan d'excution optimal, elles nous semblent raisonnables. De plus, notre objectif est dobtenir la meilleure excution pour un plan parallle donn. Sans aucune contrainte sur la gnration des requtes, nous obtiendrions des excutions trs diffrentes et nous aurions alors bien du mal en tirer des conclusions pertinentes. Cest pourquoi nous avons contraint la gnration des arbres doprateurs de telle sorte que le temps de rponse squentiel soit compris entre 30mn et une heure. Ainsi, nous avons produit 40 plans d'excution parallle portant en moyenne sur 1.3 Go de relations de base et gnrant environ 40 Go de rsultats intermdiaires. Puisque nous ne tenons pas compte du contenu des relations, nous avons pu gnrer automatiquement de ces relations avec des cardinalits donnes.
5.1.3.
Mthodologie
Dans les exprimentations suivantes, chaque point dune courbe est obtenu partir dun calcul effectu sur le temps de rponse de 40 plans dexcution parallle.
- 89-
Comme les plans dexcution parallle correspondent 20 requtes diffrentes, la moyenne des temps de rponse na pas de sens. Les rsultats seront donc toujours prsents en termes de rapports de temps de rponse. Par exemple, dans une mesure du speed-up (rapport du temps de rponse avec p processeurs et du temps de rponse avec un processeur), chaque point sera calcul comme la moyenne des speed-ups de chaque plan. Plus gnralement, chaque point dun graphe obtenu avec n mesures, chacune sur un plan dexcution diffrent, sera calcul grce la formule suivante:
1 -- n
i=1
----------------------------------------------------------TempsRep (P )
Reference i
TempsRep Mesure ( P i )
Le temps de rponse de rfrence sera indiqu pour chaque exprimentation. An dobtenir des mesures plus prcises, chaque temps de rponse sera calcul comme la moyenne de 5 mesures successives.
5.2.
Rpartition locale de la charge
An dtudier les performances de notre modle dexcution sur un seul noeudSMP, nous le comparons avec deux autres modles dexcution puis tudions son comportement face des mauvaises distributions de donnes (data skew).
5.2.1.
Comparaison des performances
Nous avons donc choisi et implment sur la KSR1 deux modles dexcution bien connus. Le pipeline parallle synchrone (Synchronous Pipeline ou SP) [Shekita93], est conue pour une architecture mmoire partage. Chaque processeur est multiplex en deux threads, un pour les entres/sorties (thread I/O) et un pour les traitements (thread CPU). Chaque thread CPU participe tous les oprateurs de la chane pipeline. Les threads I/O sont utiliss pour lire les relations de bases et placer les tuples dans des buffers. Chaque thread CPU lit alors les tuples de ces buffers et les teste successivement avec les tables de hachage le long de la chane pipeline en utilisant des appels de procdures (voir chapitre suivant). A moins dune distribution de donnes trs irrgulire (qui pourrait entraner de grandes variations dans le temps de traitement dun tuple dune relation de base), ce modle dexcution obtiendra une rpartition de charge parfaite. Cependant, SP ne peut tre raisonnablement implment sur une architecture distribue car la
- 90-
Chapitre IV
redistribution des donnes entre deux oprateurs successifs entranerait de haut surcots de synchronisation. La deuxime stratgie t conue pour des architectures shared-nothing [Davison92][Boral82]. Pour chaque chane pipeline, les processeurs sont statiquement allous aux oprateurs. Le nombre de processeurs pour chaque oprateur est dtermin par le rapport de la complexit estim de chaque oprateur (cot CPU et I/O) sur la complexit de lintgralit de la chane pipeline. Cette stratgie permet dobtenir une assez bonne rpartition de charge dans la mesure o le modle de cot est able. Nous avons adapt cette stratgie, dans le cas dune architecture mmoire partage, en permettant une redistribution dynamique de la charge de travail au niveau intra-oprateur et lavons appel Fixed Processing (FP) puisque chaque processeur est assign un et un seul oprateur. Cette stratgie t mise en oeuvre partir de notre modle dexcution en restreignant chaque thread au traitement dactivations associs un seul oprateur. An de nous comparer SP et FP, nous avons appel notre modle Dynamic Processing (DP) pour reter le fait que les processeurs sont allous dynamiquement aux oprateurs de la chane pipeline.
Dgradation relative des performances
1.5 1.4
SP DP FP
2 1.8 1.6 1.4 1.2 1 0.8 0.6 0.4 0 5 10 20
Performances relatives
1.3 1.2 1.1 1 0.9 0.8 0.7 0.6 16 32 64
8 procs 16 procs 32 procs 64 procs

30
Nb de processeurs
taux derreurs du modle de cot (%)
Figure 44 : Performances relatives de SP, FP et DP
Figure 45 : Impact des erreurs du modle de cot avec FP
La Figure 44 compare les performances relatives des trois stratgies en faisant varier le nombre de processeurs et en utilisant une distribution uniforme des donnes. Le temps de rponse de rfrence est celui de SP qui est toujours meilleur. Les performances de notre modle dexcution sont trs proches de celles de SP entre 8 et 32 processeurs et un peu moins bonnes avec un plus grand nombre de processeurs. La diffrence vient des surcots dinterfrences et de gestion des les
- 91-
avec DP. FP est toujours le moins bon cause des erreurs de partie entire (voir [Wilshut95]) qui saggravent lorsque le nombre de processeurs dcrot. Les performances de FP dpendent fortement de la prcision du modle de cot utilis et nous voulions connatre l'impact des erreurs du modle de cot sur ses performances. La gure 45 montre la dgradation relative des performances lorsque le taux derreur varie avec diffrents degrs de paralllisme. Le temps de rponse de rfrence est ici celui de FP avec un taux derreurs de 0. Pour obtenir une mesure avec un taux r% derreur, la cardinalit des relations de base et intermdiaires ont t modi par une valeur choisie alatoirement entre [r%,+r%], propageant ainsi lerreur dans lestimation du cot des oprateurs et donc du nombre de processeurs allous. Les mesures ont t effectues avec un taux derreurs raliste entre 0 et 30%. Etant donn le caractre alatoire de ces mesures, nous avons choisi de restreindre le nombre de plans dexcution tests. Par contre, pour chaque plan, trois taux derreur ont t choisis alatoirement. Les mesures montrent que le temps de rponse se dgrade de manire signicative ds que le taux derreur augmente. Avec peu de processeurs (e.g., 8), la dgradation est petite avec un faible taux derreurs mais augmente drastiquement avec le taux derreur. Linexactitude du modle de cot entrane lallocation de processeurs en trop pour certains oprateurs. Linuence de ces processeurs mal allous est dautant plus signicative quil y a peu de processeurs (e.g., 1/8 est pire que 1/64). Ainsi, avec un grand nombre de processeurs, un petit taux derreur modie le processus dallocation des processeurs mais na que peu dinuence sur les performances. Evidemment, les plus mauvaises performances sont obtenues lorsque peu de processeurs sont allous aux oprateurs complexe, les autres processeurs tant allous aux oprateurs plus simples. Cette situation arrive avec un plus ou moins grand taux derreur suivant le degr de paralllisme. Par exemple, avec 5 oprateurs et 8 processeurs, la plus mauvaise allocation est obtenue lorsque seuls 3 processeurs sont mal allous, alors quavec 64 processeurs, il en faut 59 !!. Ceci explique la chute de performance vers les 20% derreurs avec 8 processeurs ainsi que la lente dgradation avec plus de processeurs. Ces mesures conrment les limites de la rpartition de charge statique et motivent le besoin dun mcanisme dynamique. Finalement, la gure 46 montre les speed-up moyens de tous les plans dexcution pour chaque stratgie, avec un taux derreur nul pour FP. De nouveau, SP est
- 92-
Chapitre IV
toujours lgrement meilleur que DP, et FP est toujours le moins bon. Jusqu 32 processeurs, SP et DP obtiennent un speed-up presque linaire. La stratgie DP semble donc bien adapt une architecture hirarchique qui est typiquement compose de noeud-SMP avec moins de 32 processeurs.
5.2.2.
Impact des mauvaises distributions de donnes (data skew).
Dans notre modle, tous les threads ont accs toutes les les dactivations, sources potentielles dinterfrences. Les surcots dus aux interfrences augmentent en cas de mauvaises distributions des activations dans les les pouvant provenir de plusieurs formes de data skew [Walton91]. Le skew de valeur dattribut (AVS) et le skew de placement des tuples (TPS) entranent des variations dans la taille des fragments de relations, menant alors une mauvaise distribution des activations dans les les pipeline. Les mesures suivantes ont pour but dtudier les surcots dus aux interfrences dans notre modle en cas de data skew. Nous avons introduit du skew de redistribution (RS) dans la production des activations trigger et dans tous les oprateurs produisant en pipeline. Toutefois, le skew de redistribution dun oprateur producteur na pas dinuence sur le degr de skew de l'oprateur consommateur. Ainsi, la complexit de la requte est indpendante du degr de skew. Tous les oprateurs ont le mme degr de skew, modlis par une fonction de Zipf [Zipf49] variant entre 0 (distribution uniforme) et 1 (trs fort skew).
Dgradation relative des performances
56 48 40
SP DP FP
DP
1.3
1.2
Speedup
32 24 16 8 1 1 8 16 32 48 64
1.1
0.2
0.4
0.6
0.8
Nb de processeurs
Degr de skew de redistribution (Zipf)
Figure 46 : Speed-up de SP, FP, DP
Figure 47 : Impact du skew sur DP
La gure 47 montre la dgradation des performances de DP en fonction du skew
- 93-
avec 64 processeurs. Le temps de rponse de rfrence est mesur avec une distribution uniforme. Comme le montre la gure 47, limpact du skew sur notre modle dexcution est insigniant. Ceci est d plusieurs dcisions de conception. Premirement, notre modle permet un haut degr de fragmentation4 qui permet de rduire les effets du skew [Kitsuregawa90]. Deuximement, la priorit donne un sous ensemble de les distinctes pour chaque thread (les primaires) permet de rduire les interfrences entre les threads. Finalement, les interfrences sont encore rduites en bufferisant les lectures et critures dactivations. Nous navons pu, dans ces mesures considrer toutes les formes de skew. Les mauvaises distributions de donnes peuvent, par exemple entraner des temps de traitement variables pour le mme type dactivations. Cela arrive en cas de skew de valeur des attributs (AVS), de skew de slectivit (SS) et du skew de produit de jointure (JPS). Les diffrences de temps de traitement des activations entranent aussi la surcharge de les dactivations, nous ramenant alors au cas prcdent.
5.3.
Rpartition globale de la charge
Notre modle permet de minimiser lutilisation de la rpartition globale de la charge (entranant des surcots de communication) et de favoriser la rpartition locale, plus efcace, permettant une rpartition inter- et intra-oprateurs. An d'valuer les gains dune telle stratgie dans une architecture hirarchique, nous lavons compar FP, qui donne de bons rsultats en shared-nothing. Pour nos mesures, nous avons adapt FP de la manire suivante. Comme chaque oprateur est prsent sur tous les noeuds-SMP, la rpartition des processeurs sur les oprateurs est ralise indpendamment sur chaque noeud, de la mme manire que dans la section 5.2.1 An de crer articiellement des mauvaises rpartitions de charge entre les noeuds-SMP, nous avons introduit du data skew comme prcdemment. Nous avons, tout dabord, compar le comportement de FP et DP lors de l'excution dune chane pipeline de 5 oprateurs, chacun ayant un degr de skew de redistribution de 0.8. Le systme hirarchique comporte 4 noeuds-SMP de 8 processeurs chacun. Nous avons mesur la quantit de donnes changes entre les noeuds avec FP et DP. Pour ces
4. Comme dans DBS3, le degr de fragmentation est indpendant du degr de paralllisme, ce qui autorise un haut degr de fragmentation. Par contre les surcots de gestion des les observs dans DBS3 (chapitre prcdent) ne se font pas sentir dans DP car le nombre de les dactivations est indpendant du degr de fragmentation.
- 94-
Chapitre IV
mesures, FP a ncessit l'change de 9 Mo de donnes contre 2.5 Mo pour DP. En effet, avec FP, chaque processeur peut tre inactif, indpendamment les uns des autres. Comme il ny a pas de rpartition de charge dynamique inter-oprateur, un processeur allou un oprateur peut tre inactif alors quun autre, sur le mme noeud, est surcharg. Le processeur inactif entrane alors la mise en route de la rpartition globale de charge pour prendre du travail un processeur dun autre noeud allou au mme oprateur. Ainsi, plusieurs situations de famine peuvent se produire sur le mme noeud-SMP. De plus, il peut y avoir des vols mutuels entre deux noeuds (pour deux oprateurs diffrents). Avec DP, ces problmes sont vits puisque lorsquun processeur est inactif, cest lensemble du noeud qui est en famine. Comme la rpartition de charge se fait au niveau du noeud, et non du processeur, il ne peut y avoir de famines multiples ou mutuelles.
DP FP
1.5 1.4
Relative performance
1.3 1.2 1.1 1 0.9 0.8 0.7 0.6
4x8 4x12 4x16 Configuration (Nb of nodes x Nb of procs/node)
Figure 48 : Performance relative de FP et DP
Comme dans les expriences prcdentes, nous avons aussi effectu des mesures sur 40 plans d'excution (arbres bushy mettant en jeu 12 relations), avec trois congurations et un degr de skew de 0.6. La gure 48 montre les gains de performances de DP sur FP avec 4 noeuds de 8, 12 et respectivement 16 processeurs. Sur lensemble de ces excutions, nous avons observ des gains de performance entre 14 et 39% dus une utilisation moindre de la rpartition globale de charge avec DP ainsi quaux meilleures performances de DP sur chaque noeud-SMP. Les surcots de communications dus la rpartition globale de charge sont entre 2 et 4 fois moindres avec DP. De plus les temps d'inactivits des processeurs, quasiment nuls avec DP sont consquents avec FP. Il faut remarquer que ces mesures ne nous ont pas permis dobserver une relation entre le nombre de processeurs sur chaque noeud et
- 95-
6 Conclusion
le gain de DP sur FP.
Conclusion
Dans ce chapitre, nous avons trait le problme de la rpartition dynamique de la
charge lors de lexcution de requtes multi-jointures sur une architecture hirarchique. Etant donn un plan dexcution parallle, rsultat de loptimisation dune requte, le but de la rpartition de charge dynamique est de minimiser le temps de rponse en vitant l'inactivit des processeurs. Nous avons propos une nouvelle solution qui maximise la rpartition de charge localement, sur chaque noeud-SMP, et rduit autant que possible le besoin dune redistribution de la charge de travail entre les noeuds. Ceci est obtenu en dcomposant le travail en activations autonomes qui reprsentent la plus petite unit de travail squentiel et en permettant nimporte quel thread de traiter nimporte quelle activation localise sur le mme noeud. Il ny a donc pas dassociation statique entre les threads et les oprateurs. Notre modle est plus exible dans la mesure o il permet dexploiter la rpartition de charge intra et inter-oprateur sur chaque noeudSMP. Cela permet de rduire donc son minimum le besoin dune rpartition de charge globale, uniquement invoqu lorsquil ny a plus de travail effectuer localement. De plus, notre modle dexcution simplie loptimisation statique, complexi par le support dune architecture hirarchique. En effet, il nest plus ncessaire de dcider statiquement de lordonnancement des oprateurs, ni de lassociation des processeurs aux oprateurs. Cependant, si une distribution statique des processeurs a t dcide par loptimiseur, notre modle dexcution peut lexploiter et ainsi minimiser encore le surcot de la rpartition dynamique de la charge. Les erreurs du modle de cot, invitables dans une architecture hirarchique ont alors peu dinuence puisquelles sont corriges par le mcanisme dynamique. Nous avons implment un prototype de notre modle an dvaluer ses performances, sur une machine KSR1 avec 72 processeurs. La mmoire virtuellement partage de la KSR1 et le grand nombre de processeurs disponibles ont rendu possible une organisation de type hirarchique. An de mesurer les performances avec plusieurs requtes, de grosses relations et diffrentes congurations (cardinalit, slectivit, distribution, etc..), nous avons simul lexcution des oprateurs atomiques. Nous avons alors ralis plusieurs sries de mesures deux
- 96-
Chapitre IV
niveaux: localement sur un noeud-SMP, puis globalement avec plusieurs noeuds. Dans le cas dun noeud-SMP, nous avons compar notre stratgie de rpartition de charge appele dynamic processing (DP) avec le synchronous pipelining (SP) et xed processing (FP). SP est la meilleure stratgie pour un noeud-SMP mais ne peut tre raisonnablement tendue une architecture distribue. FP est elle conue pour une architecture shared-nothing et fonctionne a fortiori en mmoire partage. FP montre les plus mauvais rsultats dus aux problmes de parties entires qui saggrave lorsque le nombre de processeurs dcrot. Les performances de notre modle sont trs proches de celles de SP entre 8 et 32 processeurs. Enn SP et DP montrent des speed-up presque linaire, mme avec des donnes biaises. An dvaluer les performances de notre stratgie de rpartition de charge globale dans un systme hirarchique, nous lavons compar avec FP, qui donne de bons rsultats en shared-nothing. Notre stratgie surpasse FP dun facteur compris entre 14 et 39%, le surcot de communication, caus par la redistribution de la charge est 2 4 fois plus petits pour DP. Finalement, les temps dinactivit des processeurs sont presque nuls avec DP alors quils sont signicatifs avec FP. Pour rsumer, en mmoire partage, notre modle dexcution obtient des performances presque aussi bonnes quun modle ddi et peut correctement voluer vers une architecture hirarchique.
- 97-
6 Conclusion
- 98-
Chapitre V
V
Excution parallle sur une architecture NUMA

Larchitecture mmoire non uniforme (NUMA) offre les avantages dun modle de programmation de type mmoire partage, sur une architecture parallle extensible. Dans ce chapitre, nous nous intressons au problme de la rpartition de charge lors de lexcution de requtes multi-jointures sur une architecture NUMA. Nous montrons, tout dabord, quun modle dexcution pour ce type darchitecture ne doit pas utiliser la fragmentation des donnes (comme pour les systmes shared-nothing), mais plutt exploiter des stratgies conues pour la mmoire partage comme le pipeline synchrone (SP). Nous montrons alors quune mauvaise distribution des donnes pnalise srieusement SP, et proposons un nouveau modle dexcution qui rpond ce problme. Lide de base est de permettre la matrialisation partielle des rsultats intermdiaires et de les rendre progressivement publiques, de manire ce quils puissent tre traits par nimporte quel processeur. Cette stratgie, appele Progressive Sharing (PS) permet donc dviter linactivit des processeurs. Nous effectuons, sur une machine KSR1 comprenant 72 processeurs, une comparaison des performances de SP et PS sur un ensemble de requtes mettant en jeu de grandes relations. Sans skew, SP et PS montrent de bonnes performances. Cependant, limpact de mauvaises rpartitions des donnes est trs important pour SP et quasiment ngligeable avec PS. Finalement, nous montrons que lexcution concurrente de plusieurs chanes pipeline apporte un gain de performances signicatif avec un grand nombre de processeurs.
Introduction
Les systmes de bases de donnes commerciaux implments sur des
multiprocesseurs mmoire partage, comme Sequent, Sun, Bull's Escala, connaissent un succs croissant1. Cela est d plusieurs raisons [Valduriez93]. Dune part, les SGBD parallles sont essentiellement utiliss pour des applications dcisionnelles, un march qui double chaque anne. Dautre part, la mmoire
1. Les machines mmoire partage reprsentait 95% du march des machines multiprocesseurs en 1995 (01 informatique du 13/01/95)
- 99-
1 Introduction
partage offre un modle de programmation simple qui facilite le portage des SGBD et simplie leur rglage. Enn, larchitecture mmoire partage offre le meilleur rapport performance/prix pour un nombre limit de processeurs [Bhide88]. Les rcents dveloppements de la technologie des multiprocesseurs
(interconnexion haut dbit, technologie de cohrence de cache, etc..) ont rendu faisable les architectures mmoire non uniforme (Non Uniform Memory Access ou NUMA), qui offrent un modle de programmation de type mmoire partage, sur une architecture parallle extensible. Deux classes de machines NUMA ont vu le jour, les CC-NUMA (Cache Coherent NUMA) [Gonzales-Rubio84][Lenoski92] et les architectures COMA (Cache Only Memory Architecture) [Hagersten92][Frank93]. Ces deux architectures utilisent une mmoire physiquement distribue et un systme de cohrence de cache base de rpertoires. A la diffrence de CC-NUMA, larchitecture COMA effectue automatiquement la migration et la copie de donnes dune mmoire une autre. Des exemples rcents darchitecture NUMA sont la NUMA-Q de Sequent et la Convex SPP1200 qui peuvent supporter quelques centaines de processeurs. Nous considrons l'excution de requtes multi-jointures dans une architecture mmoire non uniforme. La paralllisation dune requte peut tre effectue selon deux axes: horizontalement (paralllisme intra-oprateur), en distribuant chaque oprateur sur un ensemble de processeurs, et verticalement (paralllisme interoprateur indpendant ou pipeline) en distribuant tous les oprateurs de la requte sur diffrents processeurs. Lobjectif dune excution parallle est de rduire le temps de rponse en distribuant la charge dune requte sur plusieurs processeurs. Le principal obstacle cet objectif est la mauvaise distribution de la charge, lorsque des processeurs sont surchargs alors que dautres sont inactifs. Les performances dune excution parallle peuvent alors se dgrader fortement puisque le temps de rponse correspond celui du processeur le plus charg. Les solutions proposes pour la rpartition de charge sont gnralement spciques un type de paralllisation et une architecture, shared-nothing [Boral82], [Davison92], [Kitsuregawa90], [Apers92], [Berg92] ou mmoire partage [Hong91], [Bouganim96b]. Sur une architecture shared-nothing o le paralllisme est obtenu grce la fragmentation des donnes, la rpartition de charge est faite statiquement pendant la phase doptimisation ou juste avant lexcution [Rahm93], [Mehta95], [Rahm95], [Garofalakis96]. En mmoire partage, il y a plus de exibilit puisque tous les processeurs ont un accs uniforme la mmoire et aux
- 100-
Chapitre V
disques. Les techniques de rpartition de charge [Murphy91], [Hong92], [Shekita93] peuvent alors tre plus dynamique (i.e., pendant lexcution) puisque la redistribution de la charge peut tre faite faible cot. Une stratgie dexcution trs efcace en mmoire partage est le pipeline synchrone (SP) [Pirahesh90], [Hong92], [Shekita93]. Elle a trois avantages principaux. Premirement, elle ne ncessite que trs peu de synchronisation durant lexcution. Deuximement, elle nentrane pas la matrialisation des rsultats intermdiaires, ce qui rduit la consommation mmoire. Enn, la diffrence des approches destines des architectures distribues, elles ne souffrent pas des problmes de rpartition de charge comme les erreurs du modle de cot, les dlais dans les pipelines et les erreurs de partie entire [Wilshut95]. Comme larchitecture NUMA permet dutiliser un modle de programmation mmoire partage, une solution vidente serait dutiliser SP. Cependant, le fait de considrer une architecture NUMA a une inuence sur la rpartition de charge. Dune part, la mmoire disponible est potentiellement plus grande (si lon suppose de grosses congurations), rendant possible le choix de plan dexcution parallle constitus de longues chanes pipelines. Dautre part, le nombre de processeur est aussi potentiellement plus important. Dans ce chapitre, nous montrons que ces deux facteurs ont une inuence ngative sur la rpartition de charge avec SP en cas de mauvaise distribution de donnes. Dans ce chapitre, nous proposons une nouvelle stratgie dexcution qui rsoud les problmes de SP. Lide de base est de permettre la matrialisation partielle des rsultats intermdiaires et de les rendre progressivement publics, an quils puissent tre traits par nimporte quel processeur inactif. Nous avons appel cette stratgie Progressive Sharing (PS). Elle permet une excellente rpartition de charge, mme avec des donnes biaises. De plus, PS peut excuter concurremment plusieurs chanes pipeline et effectuer un quilibrage de charge globale. An de valider PS et dtudier ses performances, nous avons implment SP et PS et compar leurs performances sur la machine mmoire non uniforme KSR1 muni de 72 processeurs2. Le chapitre est organis comme suit. La section 2 discute de lintrt de modles fragments ou non fragments pour une architecture NUMA. La section 3 prsente
2. Le but de cette tude nest pas de comparer plusieurs architectures NUMA (voir [Stenstrom92], [Morin96]), ni de la comparer larchitecture mmoire partage, mais de proposer une stratgie dexcution efcace pour cette architecture.
- 101-
2 Modle fragment/non fragment
les plans dexcution parallle, entre de notre modle dexcution. La section 4 dtaille la stratgie SP et discute de ses problmes sur une architecture NUMA face de mauvaises distributions de donnes. La section 5 dcrit notre modle dexcution pour larchitecture NUMA. La section 6 dcrit limplmentation sur la machine KSR1 et donne les rsultats de ltude de performances de SP et PS. La section 7 conclut.
Modle fragment/non fragment

En shared-nothing, lutilisation dun modle dexcution non fragment, i.e. o
chaque processeur accde potentiellement lensemble des donnes, est inefcace cause des accs intensifs aux donnes distantes. Le paralllisme est alors obtenu travers la fragmentation des donnes, i.e. les relations sont physiquement fragmentes sur de multiples disques ou en mmoire en utilisant une fonction de fragmentation comme le hachage. Ainsi, chaque processeur accde seulement un sous ensemble des donnes, rduisant donc les interfrences et augmentant la localit de rfrences. Cependant, un modle dexcution fragment a deux inconvnients principaux: (i) surcot de la redistribution des donnes pour des requtes complexes, (ii) rpartition de charge difcile. Un des avantages cl de la mmoire partage sur la mmoire distribue est que les modles dexcution bass sur la fragmentation [Graefe94] ou non [Hong92], [Lu91], [Omiecinski91] peuvent tre utiliss. Lutilisation de techniques non fragmentes facilite la rpartition de charge et nentrane pas de redistribution. Cependant, elle entrane de grands surcots dinterfrences et une localit des rfrences mdiocre. Dans [Shekita93] un modle dexcution fragment est compar analytiquement SP (non fragment), dans un contexte mmoire partage. Il en est conclu que si les effets de cache sont ignors, les deux modles ont un comportement similaire. NUMA autorise aussi lutilisation de lun ou lautre des modles. Cependant, la structure htrogne de la mmoire peut inuer sur le choix dun modle. A notre connaissance, le seul travail initial existant sur lexcution de requtes dans une architecture NUMA, a t fait dans le contexte du prototype DBS3 [Bergsten91]. DBS3 a dabord t implant sur un multiprocesseur mmoire partage mais utilisant un modle dexcution fragment pour des raisons de portabilit vers la mmoire distribue. Les expriences avec DBS3 ont montr des performances comparables sur une architecture mmoire partage et sur la machine KSR1 (COMA) [Dageville94]. Cependant, comme une approche sans fragmentation na pas
- 102-
Chapitre V
t exprimente, nous ne pouvons conclure sur ladquation dun modle fragment pour NUMA. Un autre travail intressant dans ce domaine a t fait dans un contexte distribu avec une mmoire virtuellement partage (Shared Virtual Memory ou SVM) [Shatdal93]. La mmoire virtuellement partage tant implante par logiciel, le cot des accs distants est trs lev. [Shatdal93] indique quun modle dexcution fragment devrait tre utilis pour augmenter la localit des rfrences et viter de saturer les mmoires locales avec les multiples copies des mmes donnes, rsultat des accs distants. Dans le chapitre prcdent, nous avons propos un modle dexcution, bas sur la fragmentation, appel Dynamic Processing (DP), pour une architecture hirarchique. Dans une telle architecture, la rpartition de charge doit tre effectue sur chaque noeud-SMP et entre eux. DP maximise la rpartition de charge locale sur chaque noeud-SMP et minimise le besoin de redistribuer la charge entre les noeuds. La comparaison exprimentale entre DP et une technique classique de rpartition statique de la charge a montr des gains de performances compris entre 14 et 39%. Dans cette tude, nous comparons aussi la performance de DP et SP sur une machine mmoire partage. Dans ce but, nous avons eu simuler la mmoire partage sur le KSR1. Tous les accs ont t fait articiellement dans la mmoire locale, an dviter les effets de NUMA (accs mmoire distants). Les mesures ont montr que, dans un multiprocesseur mmoire partage, les performances de DP sont proches de celle de SP, ce qui conrme lanalyse de [Shekita93]. Comme point de dpart de notre travail dcrit ici, nous avons modi notre implmentation sur lordinateur KSR1 an de prendre en compte les proprits NUMA de la KSR1, en faisant des accs mmoire distants pour lire et crire les tuples. Pour valuer la pertinence dun modle dexcution fragment pour NUMA, nous avons fait des mesures avec la version NUMA de SP et DP. Les mmes mesures que celles du chapitre prcdent ont montr une diffrence de performances de lordre de 35% en faveur de SP. La dgradation de performance de DP est due une redistribution intensive des donnes, ce qui entrane des interfrences entre les processeurs et des surcots dcriture distante des donnes. Pour rsumer, un modle dexcution fragment convient bien aux architectures mmoire partage ou hirarchiques. Cependant, lutilisation dun modle dexcution non fragment comme SP, semble plus appropri pour NUMA.
- 103-
3 Plan dexcution parallle

Le plan dexcution parallle est lentre du modle dexcution parallle. Il est
form dun arbre doprateur et de lordonnancement de ces oprateurs. Plusieurs formes darbres peuvent tre considres: gauches, droits, zigzag [Ziane93] ou bushy. Les arbres bushy sont les plus intressants car ils offrent plus dopportunits pour minimiser la taille des rsultats intermdiaires [Shekita93] et pour exploiter diffrents types de paralllisme [Lanzelotte93]. Aussi, dans ce chapitre, nous nous concentrons sur l'excution darbres bushy. Larbre doprateur provient de la macro-expansion de larbre de jointure [Hasan94]. Les noeuds reprsentent les oprateurs atomiques de l'algbre relationnelle et les arcs reprsentent les ots 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. Pour simplier la discussion, nous considrons ici un arbre doprateur utilisant la jointure par hachage3 [Valduriez84][Schneider89]. Dans ce cas, trois oprateurs sont ncessaires: scan pour lire chaque relation de base, build et probe. L'oprateur de build produit la table de hachage de manire bloquante. Le probe produit, en pipeline, les tuples rsultats. Ainsi; pour une jointure par hachage, il y a toujours un arc bloquant entre le build et le probe. Un arbre d'oprateur peut tre dcompos en un ensemble de chanes pipeline maximum, i.e., avec le plus grand nombre d'oprateurs pipeline, appeles aussi fragments [Shekita93] ou tasks [Hong92]. Pour des raisons de simplicit, nous supposons que chaque chane pipeline peut tre entirement excute en mmoire. Dans le cas contraire, loptimiseur devrait ajouter de nouveaux arcs bloquants entre les oprateurs dune chane pipeline, an de forcer la matrialisation de relations intermdiaires (arbres zigzag [Ziane93]). La gure 49 montre un arbre droit mettant en jeu quatre relations, ainsi que le plan dexcution parallle correspondant. La
3. Nimporte quel algorithme de jointure autorisant une excution pipeline peut tre utilis, eg. jointure par index, boucle imbrique, jointure par hachage pipelin, etc.. Cependant, certains algorithmes peuvent tre inefcaces en NUMA d dintensives lectures ou critures distantes.
- 104-
Chapitre V
lecture des relations R1, R2 et R3 ainsi que la cration des tables de hachage correspondantes H1, H2 et H3 peuvent tre effectues en parallle. Lexcution de la chane de probe ne peut dbiter que lorsque les tables de hachage H1, H2 et H3 ont t construites.
Probe R4 R4 R3 R2 R1 Scan R3 Arbre de jointure Build H4 Scan R4 Build H3 Build R2 Scan R2 Probe R3 Probe R2
arc bloquant arc pipeline chaine pipeline
Scan R1 Arbre doprateur
Figure 49 : Un arbre de jointure et larbre doprateur associ
Le choix dune architecture NUMA a un impact sur les dcisions de paralllisation effectus par loptimiseur d laspect grande mmoire, permis par cette architecture. Avec des requtes multi-jointures, nous pouvons nous attendre ce que les plans produits par loptimiseur soient des arbres bushy avec de longues chanes pipeline car elles permettent dviter la matrialisation des rsultats intermdiaires et permettent le paralllisme intra et inter-oprateur.
Problmes du pipeline synchrone en NUMA.

Dans cette section, nous rappelons la stratgie dexcution par pipeline
synchrone et montrons le problme de cette stratgie en cas de mauvaise distribution des donnes.
4.1.
Le pipeline synchrone
SP savre fournir une excellente rpartition de la charge en mmoire partage [Pirahesh90], [Hong92], [Shekita93]. Chaque processeur est multiplex entre les threads CPU et dI/O et participe tous les oprateurs de la chane pipeline. Les threads dI/O sont utilises pour lire les relations de base dans les buffers. Chaque thread CPU lit les tuples depuis le buffer mmoire et applique successivement chaque oprateur atomique de la chane pipeline en utilisant des appels de procdure. Pour illustrer cette stratgie nous dcrivons ci-dessous lalgorithme de loprateur Probe2
- 105-
4 Problmes du pipeline synchrone en NUMA.
(voir gure 49).

Probe2(tR1:Tuple(R1), HR2: HashTable(R2)) pour chaque tuple tR2 de HR2 joignant avec tR1 si pred(tR1,tR2) alors Probe3([tR1,tR2], HR3) n pour
La procdure Probe2 est appele pour chaque tuple tR1 qui satisfait le prdicat du Scan. Pour chaque tuple produit en confrontant le tuple tR1 avec la table de hachage HR2, la procdure Probe3 est appele, et ainsi de suite jusqu la production du dernier tuple rsultat de la chane pipeline. La gure 50 illustre le traitement dun tuple le long de la chane des probes. Les tuples produits par un tuple t de la relation de base R forment un arbre virtuel. Deux observations peuvent tre faites. Premirement, SP parcourt cet arbre en profondeur dabord (t9 est, par exemple produit avant t21). A chaque instant, les tuples en cours de traitement sont rfrencs dans la pile des appels de procdure. Deuximement, tous les tuples de larbre ayant t pour racine sont produits et traits par le mme thread.
t9 Tuples produits avec t
R4 t1 R3 R2 R1 t21
Figure 50 : Traitement dun tuple de R1
4.2.
Impact du data skew
La mauvaise distribution des donnes (data skew) est frquente et peut entraner une mauvaise distribution de la charge de travail. Les effets du skew sur lexcution parallle dans un contexte distribu sont discuts dans [Walton91]. Cette taxonomie ne sapplique pas directement aux modles dexcution non bass sur la fragmentation des donnes, comme cest le cas pour le parallel synchronous pipeline. Il est, par exemple, vident que le biaisage d la redistribution des donnes naffecte pas SP. Cependant, nous avons pu identier deux autres types de rpartition biaise
- 106-
Chapitre V
affectant SP:
Le
biaisage de haute slectivit apparat avec les oprateurs de slection (sil y
en a), au dbut de la chane pipeline, lorsque le rsultat de la slection se rduit un petit nombre de tuples, infrieur au nombre de threads. Comme chaque tuple, produit par loprateur de slection est entirement trait (le long de la chane pipeline) par un seul thread, cela peut entraner une mauvaise distribution de la charge. Un cas extrme se prsente lorsquun seul tuple est initiallement slectionn. Toute la requte (except loprateur de slection) est alors excute par un seul thread, les autres restant inactifs.
Le
biaisage de jointure apparat avec les oprateurs de jointure, lorsquil y a de
grandes variations dans le nombre de tuples produit pour chaque tuple de la relation externe joint avec la relation interne. Ce type de biaisage est rare lors de jointure sur cl, mais assez frquent lors de non qui-jointures ou de jointures sur des attributs non cls. Ces deux types de biaisage peuvent entraner de grande diffrence dans le temps de traitement de chaque tuple. De plus, la consommation tuple tuple des relations de base peut entraner de grands surcots ds aux interfrences [Hirano91], [Bouganim96d]. Pour viter ces surcots, les threads consomment gnralement les tuples par lot. Dans ce cas, chaque lot est entirement trait par un thread, ce qui empire encore les effets du biaisage des donnes. An dvaluer les effets ngatifs du biaisage des donnes lors de lexcution parallle sur des architectures mmoire partage ou NUMA, nous avons construit un modle analytique simple bas sur les hypothses suivantes. Un seul oprateur de la chane pipeline, au rang r des n oprateurs4, entrane une rpartition biaise des donnes. Un seul tuple, dit tuple biaisant, produit, lui seul, k % du rsulat de cet oprateur. p threads sont allous pour lexcution de la requte. Nous faisons aussi lhypothse simplicatrice indiquant que le cot global de chaque oprateur est le mme, i.e. si T reprsente le temps de rponse total de lexcution de la requte, T/n est le temps dexcution de chaque oprateur. Le thread traitant le tuple biaisant effectuera k % de loprateur biais et de tous les
4. Les oprateurs sont numrots de 1 n suivant leur ordre dans la chane pipeline
- 107-
4 Problmes du pipeline synchrone en NUMA.
oprateurs suivants. Le temps de traitement de ce tuple sera donc de

k ( n r + 1) T --------------------------------------------- . Par exemple, si loprateur biais est le premier, le thread traitant n
le tuple biaisant effectuera k % de la chane pipeline. Le speed-up maximal atteignable peut tre alors aisment calcul:
r min p, ----------------------------------- k ( n r + 1 )-
La gure 50 montre les speed-ups atteignables en fonction de k, et pour diffrents rangs r. Ces courbes montrent que mme un petit (mais raliste) degr de biaisage peut avoir une inuence ngative considrable sur les performances de SP.
64
Speed-up maximal(SP)
48
r=7
32
16
r=3 r=1
0 2 4 6 8 10 12 14 16
Skew scalaire(k %)
Figure 51 : Speed-up maximal thorique
Cette simple analyse nous permet de remarquer que la dgradation du speed-up en prsence de distributions biaises dpend de: (i) le degr de biaisage k, (ii) la position r dans la chane pipeline de loprateur biais et (iii) du nombre de threads p. Le speed-up se dgrade lorsque loprateur biais est plac en dbut de chane pipeline. De plus, le speed-up maximum est limit par un facteur indpendant du nombre de processeurs. La perte potentielle augmente donc avec le nombre de processeurs. Bien que cela napparaisse pas sur notre modle analytique, la longueur de la chane pipeline a aussi un impact sur la rpartition de la charge. Lorsque plusieurs oprateurs sont biaiss, les dgradations peuvent tre, au pire des cas, exponentielle de la longueur de la chane pipeline. Un dernier point concerne limpact du granule de paralllisme (taille des lots de
- 108-
Chapitre V
tuples traits chaque coup) sur la rpartition de charge. Il est vident que les problmes de rpartition de charge sont exacerbs avec un gros granule de paralllisme [Hirano91]. Sur une architecture NUMA, comme le nombre de processeurs est gnralement grand et que les chanes pipelines ont tendance tre plus longues, tous ces problmes sont exacerbs.
Le modle dexcution parallle Progressive Sharing

Dans cette section, nous proposons un modle dexcution parallle pour une
architecture NUMA qui essaye de garder les avantages de SP tout en effectuant une bonne rpartition de la charge mme en cas de distribution biaise des donnes. Comme SP ne matrialise pas les rsultats intermdiaires, il ne peut facilement redistribuer la charge. Lide de base de notre stratgie PS, est dtendre SP avec des matrialisations partielles des rsultats intermdiaires, et de permettre nimporte quel thread de traiter nimporte quel tuple matrialis en utilisant le concept dactivations dni au chapitre prcdent. Une implmentation nave de cette ide aurait pour consquence des surcots prohibitifs. Laccs publique (par tous les processeurs) aux rsultats intermdiaires ncessite des synchronisations, sources dinterfrences. De plus, la matrialisation des tuples entrane des surcots dus aux copies et lutilisation de la mmoire. Une proprit importante de notre modle dexcution est de minimiser ces surcots. Les surcots de synchronisation sont rduits en utilisant deux modes dexcution. Dans le mode normal, lorsquaucun processeur nest inactif, les rsultats matrialiss ne peuvent tre accds que par les processeurs qui les ont produits, vitant ainsi les interfrences entre les processeurs5. Dans le mode dgrad, ds quun processeur est inactif, les rsultats intermdiaires deviennent progressivement publiques an de permettre une redistribution de la charge de travail. De plus, notre implmentation permet dviter les copies de donnes et limite la consommation mmoire. Dans la suite de cette section, nous prsentons les concepts de base de notre modle. Puis, nous prsentons, plus en dtail, PS dans le mode normal et dgrad. Finalement, PS est illustr par un exemple.
5. Bien sur, les interfrences inhrente SP (I/O, gestion des pages, etc...) ne peuvent tre vites.
- 109-
5 Le modle dexcution parallle Progressive Sharing
5.1.
Concepts
Une stratgie simple pour obtenir une bonne rpartition de la charge est dallouer un nombre de threads bien plus grand que le nombre de processeurs, puis de dlguer lordonnancement des threads au systme dexploitation. Cependant cette stratgie provoque de nombreux appels systme lis lordonnancement des threads et introduit des interfrences ainsi que des effets de convoi [Bitton83], [Pirahesh90], [Hong92]. Au lieu de nous appuyer sur le systme dexploitation pour la rpartition de la charge, nous avons choisi dallouer un seul thread par processeur et par requte. Lavantage de cette stratgie dallocation un-thread-par-processeur est de rduire de manire signicative les surcots dinterfrences et de synchronisation. Une activation reprsente un travail lmentaire squentiel. Une activation peut tre de deux types. Une activation de dclenchement ou trigger activation est utilise pour dclencher l'excution dun oprateur feuille, i.e., un scan. Elle est constitue par un doublet (Oprateur, Fragment) rfrenant loprateur de scan ainsi que le fragment de la relation de base lire. Une activation de donne ou data activation est relative aux tuples produits en mode pipeline et est constitue dun triplet (Oprateur, Tuple, Fragment) rfrenant loprateur excuter (build ou probe), le tuple trait et le fragment correspondant. Pour un build, l'excution dune activation de donne revient insrer le tuple dans la table de hachage associe au fragment. Pour un probe, elle consiste effectuer le test du tuple avec la table de hachage associe au fragment. Le traitement dune activation par un oprateur implique la cration dune ou plusieurs activations correspondant aux tuples rsultats, pour loprateur suivant. Ces activations sont stockes dans des buffers dactivation dont la taille est un paramtre de notre modle. A chaque instant un thread possde un buffer dactivation en entre quil consomme, et un buffer dactivation en sortie pour stocker les tuples rsultats. Les buffers dactivation associs un oprateur sont regroups dans des les dactivation. An dviter la recopie dactivations, seules les rfrences vers les buffers sont stockes dans la le. An dunier le modle dexcution, les les sont utilises la fois pour les activations de dclenchement (pour les oprateurs Scan) et pour les activations de donnes (pour les oprateurs Build ou Probe). Chaque oprateur a une le dentre pour recevoir les activations, i.e. les oprandes en pipeline. Nous allouons une le par oprateur et par thread. Si p processeurs
- 110-
Chapitre V
excutent une chane pipeline ayant n oprateurs numrots de 1 n (loprateur n produit le rsultat nal), lensemble des les peut tre reprsent par une matrice Q. Qij (i [1,n], j [1,p]) reprsente la le du thread j associ loprateur i. Une colonne reprsente donc lensemble des les associes un thread, tandis quune ligne reprsente toutes les les associes un oprateur. La taille des buffers et des les impose la limite de consommation mmoire pendant lexcution de la requte. Chaque le est verrouille par un smaphore (mutex) appel verrou de le, pour permettre des lectures et des critures concurrentes. Chaque thread maintien un verrou de le pour chaque le qui lui est associe en dbut dexcution. Nous appelons le prive une le associe un thread. Une le prive devient publique ds quun thread relche son verrou pour la premire fois. Laccs une le prive, i.e. un accs priv, est restreint uniquement au propritaire de la le, et peut donc se faire sans synchronisation. Laccs une le publique, i.e. un accs public, est autoris tous les threads mais ncessite une synchronisation (prise du verrou de le). La gure 52 illustre tous ces concepts sur une conguration initiale de notre modle. Dans cette gure, il y a quatre oprateurs excuts par trois threads. Elle correspond lexcution de la plus grande chaine pipeline de la gure 49. Nous avons donc douze les, chacune tant protge par un verrou. Le thread T1 excute loprateur 3, son buffer dentre contient donc des activations venant de la le Q23, et, il crit les rsultats dans le buffer de sortie, envoy vers la le Q33.
Probe R4
File dactivations
T1 Probe R3
T3
verrou (mutex) Buffer de sortie
Probe R2 T2 Scan R1 T
Thread Buffer dentre
Figure 52 : Conguration initiale du PS
5.2.
Excution en mode normal
Pendant lexcution en mode normal, un thread consomme et produit des activations dans son ensemble de les prives (chaque thread a une le prive pour
- 111-
chaque oprateur de la chane pipeline), sans ncessiter de synchronisation. Le traitement des activations de la chane pipeline se passe comme suit: pour chaque activation (de dclenchement ou de donne) du buffer dentre, le thread excute le code de loprateur rfrenc par lactivation, sur les tuples correspondant. Il produit alors des activations dans le buffer de sortie pour loprateur suivant. Lorsquun buffer de sortie est plein, sa rfrence est insre dans la le de loprateur suivant et un buffer vide est allou. Lorsquun buffer dentre a t entirement trait, il devient le buffer de sortie pour loprateur suivant, qui devient loprateur courant. Ce traitement est rpt jusqu la n de la chane pipeline. Si le buffer dentre de loprateur courant est vide (il ny a plus dactivations traiter), le thread essaie alors den consommer dans la le des oprateurs prcdents. Ainsi, quand un thread excute un oprateur, toutes les les des oprateurs suivants sont ncessairement vides. Autrement dit, les oprateurs en n de chane pipeline sont consomms en priorit par rapport aux oprateurs du dbut. Ce qui minimise la taille des rsultats intermdiaires. Le traitement des activations du premier oprateur (Scan) est lgrement diffrent. Au dbut de lexcution, les activations de trigger sont insres dans les les de loprateur Scan. Ceci est fait de manire maximiser le paralllisme dentres/sorties. Par exemple, si chaque processeur a son propre disque, les activations de dclenchement, insres dans Q1,j doivent entraner des accs au disque j. Donc, lorsque p threads lisent en parallle p activations de dclenchement de loprateur Scan, ils accdent aux p disques en parallle. Les activations de dclenchement sont traites de la faon suivante. Tout dabord, le thread effectue une I/O synchrone pour lire la premire page, et initialise les I/O asynchrones pour les pages suivantes. Aprs avoir lu la premire page, le thread slectionne (et projette) les tuples dans le buffer de sortie. Quand lactivation de dclenchement (i.e,. une page) a t consomme, loprateur suivant dbute son excution qui se droule comme dcrit ci-dessus. Lorsque le thread revient vers loprateur de Scan (pour consommer dautres activations), les I/O asynchrones sont trs probablement termines, et il ny a donc pas dattente. Un problme survient quand le traitement dune activation produit plus de tuples quon ne peut en stocker dans la le de loprateur suivant. Les deux raisons principales de ce problme sont les suivantes : soit lactivation courante produit trop de tuples cause du biaisage des donnes, soit lespace mmoire allou pour lactivation des buffers et les les nest pas sufsant. Dans les deux cas, le thread
- 112-
Chapitre V
suspend son excution courante par un appel de procdure pour traiter le buffer dactivation en sortie qui ne peut pas tre envoy dans la le dactivation pleine. Par consquent, la sauvegarde du contexte est opre efcacement grce un appel de procdure, beaucoup moins coteux quune synchronisation base sur le systme dexploitation (utilisant par exemple des signaux). En rsum, chaque activation est entirement traite et ses rsultats sont matrialiss; ce qui est diffrent de SP o une activation est toujours partiellement consomme. Si nous considrons larbre de tuples produit par une activation de dclenchement (voir gure 50), le parcours se fait partiellement en largeur dabord pour PS, et strictement en profondeur dabord pour SP.
5.3.
Excution en mode dgrad
Lexcution en mode normal continue jusqu ce quun thread devienne inactif, i.e. quand il na plus aucune activation traiter dans ses les prives. Une forme de redistribution de charge est alors ncessaire. Les autres threads rendent publiques une partie de leurs activations qui pourront tre consommes par le thread inactif. Nimporte quel thread peut rendre une le publique en relchant simplement le verrou quil possde depuis le dbut de lexcution. Une fois le verrou relch, les prochains accs la le par nimporte quel thread (y compris le thread initial) doivent tre synchroniss. Pour rduire encore les interfrences en mode dgrad, seul un sous-ensemble des les est rendu public un instant donn. Nous utilisons une heuristique simple6 pour le choix et le nombre de les rendre publiques: (i) toutes les les Qk,j correspondant loprateur k sont rendues publiques simultanment; (ii) les oprateurs sont choisis dans lordre croissant de la chane pipeline (de 1 n). A chaque instant, nous maintenons deux indicateurs globaux: FirstActiveOp et SharingLevel. FirstActiveOp indique le premier oprateur actif de la chane pipeline. Nous avons donc en dbut dexcution : FirstActiveOp=1. SharingLevel indique loprateur de plus haut rang dont les les ont t rendues publiques. Au dbut de lexcution, nous avons : SharingLevel = 0. Ces deux indicateurs peuvent tre mis jour par tous les threads et peuvent uniquement crotre pendant lexcution, i.e. une le publique ne peut redevenir prive. Lexcution de la requte se termine lorsque FirstActiveOp=n + 1. 6. Nous avons essay dautres heuristiques de slection et nous avons obtenu des performances similaires.
- 113-
Lexcution de la requte peut maintenant tre rsume comme suit. Pendant lexcution normale, chaque thread t consomme des activations dans ses les prives Qi,t (i [SharingLevel + 1, n]), sans synchronisation. Quand un thread na plus dactivations dans ses les prives, il tente de consommer des activations dans lensemble des les publiques Qi,j (i [FirstActiveOp, SharingLevel], j [1, p]), en les verrouillant. Lorsque plus aucune activation nest disponible dans les les publiques, SharingLevel est incrment dune unit, entranant le relchement des verrous par tous les thread, autrement dit, rendant publiques les les associes loprateur SharingLevel.
5.4.
Exemple
Nous illustrons maintenant les concepts principaux de notre modle sur lexemple simple dcrit gure 49. Nous considrons la jointure de 4 relations R1, R2, R3 et R4, avec trois processeurs et donc trois threads. Nous nous intressons plus particulirement au mode dgrad avec un thread inactif. Nous supposons que la jointure avec R2 du tuple t, rsultant de la slection de R1, produit un grand nombre de tuples pour loprateur ProbeR3 cause du biaisage de jointure. Ce tuple est trait par le thread T2.
Q4,1
Q4,2
Probe R4 T1 Probe R3
Q4,3
T3
Q3,1
Q2,1
Probe R2
Q2,2
Q2,3
T2
Q3,2
Q3,3
Files prives
Files publiques Files termines
Q1,1
Scan R1
Figure 53 : Exemple simple dune excution avec PS
La gure 53 donne un aperu de lexcution au moment o T2 est encore en train de produire des tuples rsultats de la jointure de t avec R2. T3 vient de terminer le traitement de son buffer dactivation venant de la le Q4,3. Lorsque T3 termine sa dernire activation, il cherche, en vain, de nouvelles activations dans ses les prives Q4,3 et Q3,3. Suite cet chec, il scrute les les publiques Q2,3, Q2,2, et Q2,1 en utilisant
- 114-
Q1,2
Q1,3
Chapitre V
des accs synchroniss. Mais il choue nouveau dans sa recherche dactivations. Il incrmente alors SharingLevel et essaie de consommer dans la le Q3,2 (qui est pleine). Cependant, il reste bloqu par T2 qui possde le verrou. Quand T2 dtecte la mise jour de SharingLevel, il rend publique la le Q3,2 en relchant son verrou. T3 obtient alors le verrou demand sur Q3,2, et consomme ses activations. Cela entrane la production dactivations pour la le Q4,3 qui peuvent donc tre stockes puis consommes par T3 sans verrouillage (car Q4,3 est encore prive). Deux observations peuvent tre faite. Si SharingLevel est rarement test, T3 peut rester bloqu longtemps par le verrou sur la le Q3,2. Il est donc important de tester frquemment SharingLevel. Toutefois, SharingLevel peut devenir un goulot dtranglement, puisquil est accd potentiellement par toutes les threads. En fait, deux raisons empchent cette situation. Premirement, chaque thread accde souvent SharingLevel qui est charg dans le cache local. Deuximement, bien que lcriture de SharingLevel implique linvalidation de son image dans tous les caches, elle se produit seulement n fois (n tant la longueur de la chane pipeline) et a donc un effet ngligeable7. Cet exemple simple montre les bnces de la matrialisation partielle des rsultats intermdiaires et de laccs partiel par tous les threads ces rsultats intermdiaires.
5.5.Excution darbres bushy

Par souci de simplicit, nous avons considr lexcution dune seule chane pipeline. Cependant, notre modle peut facilement se gnraliser. Nous montrons maintenant comment notre modle peut supporter des arbres plus gnraux tels que les arbres bushy. Le meilleur plan parallle produit par un optimiseur nest pas ncessairement purement pipeline (right-deep), mais peut aussi bien tre un arbre bushy compos de longues chanes pipeline. Les avantages et inconvnients de lexcution concurrente de plusieurs chanes pipeline en mmoire partage sont tudis dans [Hong92], [Shekita93]. La conclusion principale est quil ne serait jamais intressant dexcuter plusieurs chanes pipeline concurremment puisque cela augmente la consommation de ressources (mmoire et disques). Dans [Shekita93], lauteur
7. Nous utilisons une variable globale au lieu des signaux systme, mais les deux approches semblent quivalentes.
- 115-
montre, en supposant un speed-up idal, que cette stratgie doit tre utilise seulement dans les deux cas suivants: (i) les performances dune chane pipeline sont limites par les entres/sorties (I/O bound), lautre tant limite par le CPU (CPU bound); (ii)- les deux chanes pipeline accdent des relations qui sont fragmentes sur des ensembles disjoints de disques. Sur une architecture NUMA, cette conclusion doit tre reconsidre car lhypothse de speed-up idal nest plus valide avec un nombre lev de processeurs. En consquence, lexcution de plusieurs chanes pipeline limite par le CPU8 peut tre avantageuse si chaque chane est excute sur un ensemble disjoint de processeurs. Cette stratgie a les avantages suivants. Premirement, comme la localit que de rfrence diminue avec le nombre de processeurs, les accs distants aux donnes sont minimiss. Deuximement, moins dinterfrences surviendront. Ainsi lexcution de chaque chane pipeline avec un nombre restreint de processeurs produira un meilleur speed-up pour chaque chane pipeline. Cependant, nous ne pouvons conclure que le paralllisme indpendant est toujours la meilleure solution. Le choix doit tre pris par loptimiseur en fonction de plusieurs paramtres : le temps de rponse estim, le degr de partitionnement, la mmoire disponible, la longueur des chanes pipelines, etc. Notre modle peut excuter facilement plusieurs chanes pipeline. Lallocation des chanes pipelines aux processeurs est dcide en fonction de leur charge de travail estime. Lexcution normale se droule comme prcdemment. Mais en mode dgrad, SharingLevel est global toutes les chanes pipelines concurrentes. Donc tout processeur peut accder une le publique mme sil travaillait initialement sur une chane pipeline diffrente. En effet, cela est possible car chaque activation est autonome (elle rfrence les donnes et le code excuter). La seule modication ncessaire est la cration dun nombre de le pour chaque thread quivalent la longueur de la chane pipeline la plus longue. Dans ce cas, nous obtenons une rpartition globale de la charge sur lensemble des chanes pipeline.
Etude de performance
Lvaluation des performances dun modle dexcution parallle pour des
8. Loptimisation des tches limits par les I/O ne peut tre effectue dynamiquement car elle dpend essentiellement de stratgie statique de fragmentation et de placement des donnes sur le disque.
- 116-
Chapitre V
requtes multi-jointures est rendue difcile par la ncessit dutiliser un grand ensemble de requtes de test mettant en jeu de grosses relations. Une solution classique est dutiliser une simulation qui facilite la gnration de requtes et des relations, et permet de tester diverses congurations. Cependant, une simulation ne nous permettrait pas de prendre en compte les effets de larchitecture NUMA ainsi que des paramtres importants comme les surcots dinterfrences entre les threads. Dun autre ct, lutilisation dun prototype complet et de jeu de tests rels restreindrait le nombre de requtes testes et rendrait la gnration des donnes difcile. Nous avons donc choisi dimplmenter compltement notre modle dexcution sur un multiprocesseur NUMA et de simuler lexcution des oprateurs. An de prendre en compte les effets de larchitecture NUMA, des tuples sont rellement changs, i.e. lus et crits, mais leur contenu est ignor. Lexcution des requtes ne dpend alors plus du contenu des relations mais de paramtres affects chaque relation (cardinalit, slectivit, distribution, etc...). Dans la suite de cette section nous dcrivons la plate-forme dexprimentation et prsentons les mesures de performances effectues.
6.1.
Nous prsentons maintenant la conguration multiprocesseur utilise pour nos exprimentations et discutons de linuence de NUMA sur lexcution des requtes. Nous expliquons aussi comment nous avons gnr les plans dexcution parallle. La mthodologie suivie pour la prsentation des rsultats est identique celle prsente dans le chapitre IV, section 5.1.3.
6.1.1.
La machine multiprocesseur KSR1
Nous avons implant SP et PS sur la machine KSR1 munie de 72 processeurs. Chaque processeur a une puissance de 40 MIPS et a une mmoire propre de 32 Mo appele cache local. La machine KSR1 implante le concept de NUMA avec une architecture matrielle mmoire virtuelle partage appele Allcache. La dure daccs une donne dpend de la nature de lopration (lecture ou criture) et de lendroit o se trouve la donne (dans le sous-cache du processeur, dans le cache local ou dans le cache distant).
- 117-
32 processeurs x6 ...
32 processeurs
x 36
Cache CPU Disque
Cache CPU Disque
Cache CPU Disque
Cache CPU Disque
Cache CPU Disque
Cache
x1
CPU Disque
Figure 54 : Architecture de la KSR1

Pour mieux comprendre les effets de la mmoire virtuellement partage sur lexcution des requtes, nous avons ralis une exprience qui compare deux oprateurs de base (Build et Probe) implants de deux faons diffrentes : une considre rellement NUMA et lautre simule une architecture purement mmoire partage. Dans limplmentation NUMA, les accs aux donnes sont alatoires parmi tous les caches (locaux ou distants). Dans la simulation de mmoire partage, les accs aux donnes sont tous locaux. Les tuples ont une taille de 208 octets et chaque processeur accde 30 Mo de donnes. Pour loprateur de Build, seules les rfrences aux tuples sont crites (dans la table de hachage globale) ; tandis que pour loprateur Probe, seule une portion (environ 2/3) des tuples est accde (an de tester le prdicat). Dans cette exprience, il ny a ni entres/sorties, ni synchronisation. Les rsultats rsums ci-dessous sont prsents comme le rapport des mesures NUMA sur les mesures simulant la mmoire partage.
16 proc. Oprateur de Build Oprateur de Probe 1.6 1.2 32 proc. 1.8 1.3 64 proc. 2.5 1.6
Aprs analyse de ces rsultats, nous pouvons faire les remarques suivantes:
Les
oprations de lecture, bien quintensives, ont un impact minime sur les
performances, compares aux oprations dcriture. La raison est quune criture doit transmettre un message dinvalidation de cache vers tous les processeurs qui possdent une copie locale de la donne.
Les
oprations distantes ont moins dimpact quattendu (la documentation
technique du KSR prvoit un facteur de 6 entre les accs locaux et distants).
- 118-
Chapitre V
Cela est d au fait que les accs mmoire reprsentent une faible portion du temps dexcution de loprateur. De plus, la prise en compte des accs disque et de la synchronisation rduira encore ce rapport.
Le
surcot relatif augmente avec le nombre de processeurs, en particulier pour
les oprations dcriture. La cause en est le nombre croissant dinvalidations. En rsum, cette exprience illustre lefcacit de NUMA et conrme notre intuition selon laquelle un modle dexcution conu pour une architecture mmoire partage est un bon choix. Comme, sur la KSR1, un seul disque tait disponible, nous avons comme dans les chapitres prcdents, simul les accs aux relations de base (voir chapitre IV, section 5.1.1).
6.1.2.
Plans dexcution parallle
Lentre de notre modle dexcution est un plan dexcution parallle obtenu aprs compilation et optimisation de la requte. Pour gnrer les requtes, nous avons utilis lalgorithme propos par [Shekita93] avec trois types de relations: petite (10K-20K tuples), moyenne (100K-200K tuples) et grande (1M-2M tuples). Tous dabord, nous gnrons alatoirement le graphe de connexion des prdicats. Comme, en pratique, la plupart des requtes multi-jointures ont des prdicats de jointure simple, nous navons considr que des graphes acycliques. La cardinalit de chaque relation mise en jeu dans la requte est alors choisi alatoirement dans les intervalles des petites, moyennes ou grandes relations. Enn, la slectivit de chaque arc entre deux relations du graphe de connexion des prdicats est choisie alatoirement dans lintervalle [0.5 min ( R , S ) R S ,1.5 max ( R , S ) R S ] Le rsultat de la gnration des requtes est un graphe acyclique tiquet avec les cardinalits des relations et la slectivit des arcs. Nous avons produit 20 requtes, portant chacune sur 7 relations. Nous avons alors optimis chaque requte grce loptimiseur de DBS3 [Lanzelotte93], et slectionn le meilleur arbre dexcution en pipeline (right-deep tree). Sans contrainte sur la gnration de la requte, nous aurions obtenu des excutions trs diffrentes et il nous aurait t difcile de tirer des conclusions signicatives. Nous avons donc contraint la gnration des arbres doprateurs de telle sorte que le temps de rponse squentiel soit compris entre 20mn et 35mn. Nous
- 119-
avons ainsi produit vingt plans dexcution parallle ncessitant en moyenne 0.7 Goctet de relation de base et gnrant environ 1.3 Goctet de rsultats intermdiaire. Notons que les excutions avec des relations trop petites (en particulier, les relations internes qui devront tre matrialises) ne nous permettraient pas dapprcier les effets de NUMA.
6.2.
Comparaisons avec SP sans data skew
Nous avons fait cette exprience dans le but dtudier le surcot de PS par rapport SP quand il ny a pas de problme de rpartition des donnes. SP a pu tre facilement implant en modiant PS. La seule modication a t de remplacer les fonctions qui stockent les tuples dans les buffers (et les buffers dans les les) par un appel de procdure vers le prochain oprateur. Donc, SP et PS sont identiques du point de vue de lexcution des activations de trigger et des entres/sorties asynchrones. Utiliser des entres/sorties asynchrones au lieu de multiplexer des processeurs, amliore lgrement les performances, car il y a moins de synchronisation et dappels systme. En ce qui concerne PS, la taille des buffers dactivation est dune page (8Ko) et la le permet de stocker 20 rfrences de buffer. Ainsi, un buffer de taille gale 200 Ko est alloue pour chaque processeur. Par exemple, avec 32 processeurs, nous pouvons matrialiser au maximum 6.4 Mo dactivations. La qualit de la rpartition de charge obtenue dpend de ces valeurs. Elles sont, cependant, relativement faciles calibrer.
56 48 40
SP PS Performance relative (PS/SP)

1.10 1.05 1.00 0.95
Speed-up
32 24 16 8 1 1 8 16 32 48 64
16
32
48
64
Nb de processeurs
Nb de processeurs
Figure 55 : Speed-up de SP et PS (Pas de skew)
Figure 56 : Performance de PS relative SP
La gure 55 montre le speed-up moyen de toutes les excutions pour SP et PS, alors que la gure 56 montre les performances relatives de PS et SP9, cest--dire la
- 120-
Chapitre V
moyenne des rapports du temps de rponse de PS sur celui de SP. Deux observations importantes peuvent tre faite: Premirement, SP et PS montrent un speed-up quasi-linaire. Nous pouvons remarquer que les effets de laccs mmoire non uniforme sont aussi visibles avec un seul processeur. Par exemple, avec un simple processeur excutant la requte toute entire, la mmoire des autres processeurs est utilise au cas o les relations externes (outer relation) ne tiennent pas dans le cache local dun seul processeur. De plus, lorsque davantage de processeurs accdent aux mmes donnes, le surcot caus par NUMA est paralllis, i.e. le surcot des dfauts de cache est partag entre les threads (voir chapitre III, section 5.1.1). Cela explique les trs bon speed-up obtenus. Deuximement, les performances de PS sont trs proches de celles de SP (la diffrence majeure nexcde pas 4%) car la conception de PS minimise les surcots de matrialisation et de partage des tuples. Sans biaisage, lexcution de droule en mode normal pendant presque toute lexcution (le mode dgrad est activ en n dexcution et na pas deffet signicatif). Donc, il ny a ni synchronisation, ni interfrence, mme avec un grand nombre de threads. De plus, SP na pas de localit de rfrence [Smith82] car il passe toujours dun oprateur un autre. Parce que PS utilise des entres et des sorties bufferises, il prsente plus de localit de rfrence que SP.
6.3.
Impact du data skew
Nous tudions ici limpact du biaisage des donnes sur la performance de SP et PS. Nous introduisons du biaisage dans un seul oprateur, au rang r de la chane pipeline. Un tuple de cet oprateur (ou un batch pour le premier oprateur) produit k% de son rsultat. Les autres oprateurs nont pas de biaisage, ainsi la production des tuples rsultats est uniforme. Une telle modlisation du biaisage de donnes est appele scalar skew [Omiecinski91], [Walton91], [DeWitt92a]. Nous choisissons k entre 0 et 6%. Cest un choix raisonnable et optimiste puisque nous considrons que seul un oprateur de la chane pipeline a du biaisage.
9. la mesure du speed-up nest pas sufsante puisqu'elle ne montre pas les performances relatives (voir chapitre II, section 5).
- 121-
56 48 40
Speed-up (SP)
32 24 16 8 1 1 8 16 32 48 64
Speed-up (PS)
k = 6% k = 4% k = 2% k = 6% k = 4%
r=1 r=1 r=1 r=4 r=4
56 48 40 32 24 16 8 1 1
k = 6% k = 4% k = 2% k = 6% k = 4%
r=1 r=1 r=1 r=4 r=4
16
32
48
64
Nb de processeurs
Nb de processeurs
Figure 57 : Speed-up de SP (skew)
Figure 58 : Speed-up de PS (skew)
Les gures 57 et 58 montrent les speed-up obtenus pour SP et PS avec des facteurs de biaisage diffrents. Loprateur biais est plac en position initiale ou mdiane (rang 4) de la chane pipeline. SP se montre grandement sensible au biaisage des donnes. Avec un facteur de biaisage de 4% sur le premier oprateur, le speed-up est seulement de 22, ce qui signie une dgradation des performances de plus de 200% en comparaison avec le cas sans biaisage. Le speed-up thorique (tel que calcul dans la section 4.2) n'est jamais atteint. La cause en est que le tuple biais peut tre consomm tout moment pendant lexcution. Enn, nous remarquons pour SP que lorsque le nombre de processeurs est infrieur dix leffet du biaisage est trs rduit. Ce qui conrme lefcacit de SP pour les petites architectures multiprocesseurs mmoire partage. Limpact du biaisage sur PS est insigniant. En fonction du facteur de biaisage, le mode dgrad commence plus ou moins tard, produisant des interfrences entre les threads. Cependant, ces interfrences son minimises grce au partage progressif de la charge. Par exemple, lorsque les les de loprateur 1 et 2 deviennent publiques, les autres oprateurs (3 7) continuent dtre traites sans synchronisation. La gure 59 montre la variation en fonction du biaisage, du rapport du nombre des accs verrouills aux les, sur ceux non verrouills. Nous pouvons observer que ce taux reste bas (infrieur 10% avec k = 6%) grce notre mcanisme de partage progressif de la charge.
- 122-
Chapitre V
Excutions squentielles / concurrentes
accs privs/accs publiques
1.30 1.25 1.20 1.15 1.10 1.05 1.00 1 8 16 32 48 64
0.20 0.15 0.10 0.05 0.00 0 2 4 6 8 10
Skew scalaire (k %)
Nb de processeurs
Figure 59 : Acces privs / publiques en fonction du skew
Figure 60 : Gain apport par des excutions concurrentes
6.4.
Excution concurrente de plusieurs chanes pipelines
Ainsi que nous lavons expliqu dans la section 5.5, lexcution concurrente de chacune des diffrentes chanes pipeline dont les performances sont limites par le CPU (CPU bound), par un sous-ensemble disjoint de processeurs, semble meilleure dans NUMA car elle rduit les interfrences et les accs distants aux donnes, dgageant de ce fait un meilleur speed-up. Pour ces mesures, nous utilisons un arbre bushy particulier contenant trois chanes pipeline (CPU-bound) pouvant tre excutes concurremment et qui consistent respectivement en 3, 2 et 4 jointures. Nous nous intressons seulement lexcution de ces chanes pipeline en ignorant les autres oprateurs de larbre bushy. Nous avons mesur le temps de rponse des excutions squentielle et concurrente des trois chanes pipeline. Dans le cas de lexcution concurrente, le nombre de processeurs excutant chaque chane pipeline est calcul sur la base dune estimation simple de leur temps de rponse. La gure 60 montre le gain prsent comme tant le rapport du temps de rponse de lexcution squentielle par rapport celui de lexcution concurrente, en fonction du nombre de processeurs. Le gain augmente constamment et devient signicatif (24%) avec un grand nombre de processeurs. Avec laugmentation du nombre de processeurs, le speed-up obtenu par une excution squentielle se dgrade tandis quil samliore pour une excution concurrente. Ces mesures conrment lintrt
- 123-
7 Conclusion
dexcuter concurremment plusieurs chanes pipeline pour de grosses congurations NUMA.
Conclusion
Dans ce chapitre, nous avons trait le problme de lexcution parallle et de la
rpartition
de
charge
de
requtes
multi-jointures
sur
une
architecture
multiprocesseur NUMA. nous avons tout dabord discut de la pertinence des modles dexcution conus pour une architecture mmoire distribue ou mmoire partage. Nous avons montr quun modle dexcution pour NUMA ne doit pas utiliser de fragmentation des donnes (comme le font les systmes mmoire distribue) car le surcot de redistribution des donnes est augment en cas dcriture dans des mmoires distantes. Il doit, au contraire, sefforcer dexploiter lefcacit du modle mmoire partage. Ensuite, nous avons propos dutiliser la stratgie de pipeline synchrone (SP), excellente en mmoire partage. Nous avons montr, en utilisant un modle analytique, que SP ne rsiste pas deux formes de biaisage que nous avons identi et qui sont la consquence de laspect extensible de larchitecture NUMA (beaucoup de mmoire et de processeurs). Nous avons alors propos une nouvelle stratgie dexcution appele Progressive Sharing (PS) qui rsoud ces problmes. Lextension majeure est de permettre la matrialisation partielle des rsultats intermdiaires et de les rendre progressivement publics, an quils puissent tre traits par nimporte quel processeur inactif. Cela permet une excellente rpartition de charge, mme avec des donnes biaises. De plus, PS peut excuter concurremment plusieurs chanes pipeline et effectuer un quilibrage de charge globale. An de valider PS et dtudier ses performances, nous avons men une comparaison des performances au moyen dune implmentation de SP et PS sur la machine KSR1 muni de 72 processeurs, avec plusieurs requtes et des relations de grande taille. Sans biaisage, SP et PS ont tous les deux un speed-up quasi linaire. Cependant, les rpartitions de donnes biaises dgradent fortement les performances de SP alors quelles nont quune inuence quasi-ngligeable sur PS. Par exemple, avec un facteur de biaisage de 4%, la dgradation des performances de SP est de 200% tandis quelle est seulement de 15% avec PS. Finalement, nous montrons que lexcution concurrente de plusieurs chanes pipeline apporte un gain de performances signicatif avec un grand nombre de processeurs.
- 124-
Chapitre V
En rsum, en prsence de mauvaises rpartitions de donnes, PS prsente de meilleures performances que SP en mmoire partage, et peut tre tendu de grosses congurations NUMA. Par consquent, elle doit tre considre comme une stratgie de choix pour la mise en oeuvre de systmes de base de donnes sur les architectures aussi bien mmoire partage que NUMA .
- 125-
7 Conclusion
- 126-
Chapitre VI
VI
Conclusion
Les solutions proposes dans la littrature pour la rpartition de charge sont
gnralement spciques une forme de paralllisme et adaptes des architectures classiques (mmoire partage, disques partags ou compltement distribue). Dans cette thse, nous nous sommes intresss au problme de la rpartition de charge lors de lexcution parallle de requtes sur des architectures multiprocesseurs hybrides (hirarchiques et NUMA). Nous avons propos et mis en oeuvre de nouvelles mthodes, prenant en compte le paralllisme intra-oprateur et inter-oprateur, pour ces architectures. La premire tude, prsente au chapitre III, a t effectue sur DBS3, un SGBD parallle destin une architecture mmoire partage et implment sur une KSR1 munie de 72 processeurs. Nous avons dcrit le modle dexcution de DBS3, et montr comment celui-ci effectue la rpartition de charge intra-oprateur dans un contexte mmoire partage. Le modle dexcution de DBS3 associe une fragmentation statique des donnes (comme dans une architecture distribue) une allocation dynamique des processeurs aux fragments de requtes. La fragmentation statique des donnes permet de rduire les interfrences, et lallocation dynamique des processeurs, de supporter efcacement des charges de travail non uniformment rparties (Data Skew). Dans DBS3, chaque thread peut choisir dynamiquement quelle instance doprateur il va excuter. Combine un haut degr de fragmentation, cette approche permet une bonne rpartition de la charge de travail. Une analyse du modle dexcution de DBS3 a permis de dgager trois paramtres inuant sur les performances obtenues: degr de biaisage, de paralllisme et de fragmentation. Nous avons alors effectu plusieurs mesures sur DBS3 en variant ces trois paramtres. Ces mesures ont montr de bon speed-up, mme en cas de donnes fortement biaises, dans la mesure o un haut degr de fragmentation est employ.
- 127-
Nous avons alors cherch tendre les techniques mises en oeuvre dans DBS3 dans plusieurs directions. Dune part, nous avons pris en compte le paralllisme intra et inter-oprateur. Dautre part, nous nous sommes intresses une architecture hirarchique consistant d'un ensemble de noeuds multiprocesseurs mmoire partage, relis par un rseau rapide. Dans ce contexte, l'quilibrage de charge doit tre effectu deux niveaux, localement entre les processeurs de chaque noeud mmoire partage puis globalement entre les diffrents noeuds. A la diffrence du modle de DBS3, dans notre nouveau modle dexcution, appel DP, chaque thread peut traiter nimporte quel fragment de requte prsent sur son noeudSMP. Ceci est obtenu en dcomposant le travail en activations autonomes qui reprsentent la plus petite unit de travail squentiel, et en permettant nimporte quel thread de traiter nimporte quelle activation localise sur le mme noeud. Il ny a donc pas dassociation statique entre les threads et les oprateurs. Notre modle est donc plus exible dans la mesure o il permet dexploiter la rpartition de charge intra et inter-oprateur sur chaque noeud-SMP, et, rduit donc son minimum le besoin dune rpartition de charge globale, uniquement invoqu lorsquil ny a plus de travail effectuer localement. Des mesures ont t effectues sur un prototype combinant implmentation (pour le modle) et simulation (pour certains aspects de la machine et les oprateurs atomiques). Finalement, nous avons reconsidr lexcution parallle de requtes dans un environnement mmoire partage, mais, cette fois sur une architecture mmoire non-uniforme. A la diffrence de DBS3, nous avons, opt pour un modle dexcution non-fragment [Pirahesh90], [Hong92], [Shekita93] car le surcot de redistribution des donnes, dans le cas de requtes multi-jointures est augment en cas dcriture dans des mmoires distantes1. Nous avons donc cherch exploiter lefcacit du modle mmoire partage en utilisant la stratgie de pipeline synchrone (SP), excellente en mmoire partage. Nous avons montr, en utilisant un modle analytique, que SP ne rsiste pas deux formes de biaisage que nous avons identi et qui sont la consquence de laspect extensible de larchitecture NUMA (beaucoup de mmoire et de processeurs). Nous avons alors propos une nouvelle stratgie dexcution appele Progressive Sharing (PS) qui rpond ces problmes. Lextension majeure est de permettre la matrialisation partielle des rsultats intermdiaires et de les rendre progressivement publics, an quils puissent tre
1. Ces surcots nont pu tre observ dans DBS3 pour deux raisons. Dune part, nous navons pas implment de technique non-fragment et ne pouvons donc les comparer. Dautre part, peu de plan dexcution gnrant dintenses redistributions ont t tests dans le cadre de cette tude.
- 128-
Chapitre VI
Conclusion
traits par nimporte quel processeur inactif. Cela permet une excellente rpartition de charge, mme avec des donnes biaises. De plus, PS peut excuter concurremment plusieurs chanes pipeline et effectuer un quilibrage de charge globale. La validation de PS a t faite, comme pour ltude prcdente, au moyen dune combinaison dimplmentation et de simulation sur la machine KSR1. Sans biaisage, SP et PS prsentent un speed-up quasi-linaire. Cependant, les rpartitions de donnes biaises dgradent fortement les performances de SP alors quelles nont quune inuence limite sur PS. Finalement, nous avons valu le gain de performances obtenu par lexcution concurrente de plusieurs chanes pipeline. Celui-ci sest montr signicatif avec un grand nombre de processeurs. Remarquons que ces tudes ont t effectues dans lordre o elles ont t prsentes. Le travail sur DBS3 a donc t lentre en matire sur les problmes de lexcution parallle. Il a t men sur un prototype complet, rendant ainsi difcile des modications profondes comme lutilisation ou non dun modle dexcution fragment2. A la lumire des autres tudes effectues, nous pourrions maintenant nous demander quels choix nous ferions si nous devions refaire DBS3 sur une architecture mmoire partage3. En fait, nous choisirions probablement la stratgie PS, qui est un modle dexcution non fragment. En effet, nous pensons que les surcots dus aux interfrences entre les processeurs dun modle non fragment sont largement compenss par les surcots de synchronisation entre les processeurs pour la mise en oeuvre du pipeline, auxquels il faut ajouter les surcots de redistribution des donnes et de rpartition de charge intra-oprateur (problme de skew durant les redistributions) et inter-oprateur (stratgie DP). De plus, avec PS, les problmes dinterfrences entre les processeurs peuvent tre largement rduit en mettant en oeuvre du paralllisme inter-oprateur indpendant. En effet, lexcution concurrente de plusieurs chanes pipeline nentrane ni surcot de synchronisation producteur-consommateur, ni interfrences. Finalement, la stratgie PS est beaucoup plus simple implmenter et congurer que DP. Un modle dexcution pour une architecture hirarchique ne doit-il pas, lui aussi, utiliser un modle non-fragment au niveau de chaque noeud-SMP ? Il nous faudrait alors un modle hybride, combinant un modle fragment (entre les noeuds-SMP) et non-fragment. Bien que complexe mettre en oeuvre, ce modle
2. DBS3 et EDBS partagent le mme compilateur de requte. Lutilisation dun modle fragment dans DBS3 tait donc impos pour des raisons de compatibilit avec EDBS. 3. La comparaison dun modle fragment et non fragment a t effectu sur la KSR1 dans la section 2 du chapitre V. Elle montre un gain de 35% pour le modle non fragment.
- 129-
nous semble trs prometteur, car il prote au maximum de la composante mmoire partage de larchitecture hirarchique. A lextrme, dans une architecture mmoire partage, ce modle se comporte comme un modle non fragment. De mme, dans une architecture compltement distribue (un noeud = un processeur), nous obtenons un modle fragment. Cet aspect dindpendance vis- vis de larchitecture nous semble tre trs important car il permettrait, sans modication du modle de paralllisation et dexcution, de porter un SGBD sur nimporte quelle architecture (mmoire partage, distribue, NUMA ou hirarchique). Outre ces travaux dintgrations des stratgies PS et DP, nous pourrions tendre les techniques dveloppes dans cette thse pour proposer une approche plus complte, prenant en compte le paralllisme intra et inter-requte, i.e. ralisant une rpartition de charge globale, mettant en jeu plusieurs requtes. Une telle extension serait trs simple mettre en oeuvre. En effet, les modles dexcution prsents aux chapitres IV et V sont bass sur le concept dactivation autonome. Un thread pourrait donc excuter des activations correspondantes diffrentes requtes. Cependant, il est ncessaire deffectuer une tude approfondie an dlaborer une stratgie de consommation des activations permettant dassurer un traitement gale de chaque requte, une excution indpendante de chaque requte4, et bien sur, une bonne rpartition de charge.
4. Le plantage dune requte ne doit pas entraner larrt de requtes indpendante. Avec le modle actuel (un thread excuterait plusieurs requtes), nous aurions ce comportement.
- 130-
Bibliographie
[ANS86] ANSI Secretariat, Draft International Standard, ISO/TC 97, information processing systems - database language SQL. ISO/DIS 9075, 1986. M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, M. Young, Mach: A New Kernel Foundation for UNIX Development. USENIX Summer Conference, 1986. 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. E. Babb, Implementing a Relational Database by Means of Specialized Hardware. ACM Transactions on Database Systems, 4(1), 1979. M. J. Bach, The Design of the UNIX Operating System. PrenticeHall, Englewood Cliffs, 1986. C. A. van den Berg, M, L, Kersten, Analysis of a Dynamic Query Optimization Technique for Multi-join Queries. International Conference on Information and Knowledge Engineering, 1992. B. Bergsten, M. Couprie, P. Valduriez, Prototyping DBS3, a Shared Memory Parallel System. International Conference on Parallel and Distributed Information Systems, 1991. B. Bergsten, M. Couprie, P. Valduriez, Overview of Parallel Architectures for Databases. Computer Journal, 36(8), 1993. A. Bhide, An analysis of Three Transaction Processing Architectures. International Conference on Very Large Data Bases, 1988. D. Bitton, D. J. DeWitt & C. Turbyll, Benchmarking database systems - A systematic approach. International Conference on Very Large Data Bases, 1983. D. Bitton, C. Orji, C. Turbyl, The AS3AP Benchmark. Database and Transaction Processing System Performance Handbook, J. Gray, San Mateo, 1991.
[Accetta86]
[Apers92]
[Babb79]
[Bach86] [Berg92]
[Bergsten91]
[Bergsten93] [Bhide88]
[Bitton83]
[Bitton91]
- 131-
[Blasgen79] [Boncsz96] [Boral82]
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, D. J. DeWitt, Database Machines: An Idea Whose Time Has Passed? A Critique of the Future of Database Machines. International Workshop on Database Machines, 1983. H. Boral, Parallelism and data management. International Conference on Data and Knowledge Engineering, 1988. H. Boral, W. Alexander, L. Clay, G.Copeland, S. Danforth, M. Franklin, B. Hart, M. Smith, and P. Valduriez, Prototyping Bubba, A Highly Parallel Database System. IEEE Transaction Knowledge and Data Engineering, 2(1), 1990.
[Boral83]
[Boral88a] [Boral90]
[Borla-Salamet91a] P. Borla-Salamet, LERA2 : a language for Extended Relational Algebra. EDS Report, 1991. [Borla-Salamet91b] P. Borla-Salamet, C. Chachaty, B. Dageville, Compiling Control into Database Queries for Parallel Execution Management. International Conference on Parallel and Distributed Information Systems, 1991. [Borla-Salamet93] P. Borla-Salamet, B. Bergsten, L. Bouganim, Architecture of the IDEA Database System (IDBS). IDEA Report IDEA.DD.5B.005.1, 1993. L. Bouganim, B. Dageville: Une approche dynamique pour l'excution parallle de requte dans DBS3. Journes Bases de Donnes Avances, BDA95, 1995. L. Bouganim: Data Placement for Parallel and Distributed Queries. IDEA.DD.24B.002, 1995. L. Bouganim, P. Casadessus, P. Borla-Salamet: The Distributed and Parallel Transactional Kernel: DIPTIK. IDEA.DD.5B.010, 1995. L. Bouganim, D. Florescu, P. Valduriez: Rpartition dynamique de la charge dans un systme de base de donnes parallle hirarchique. Journes Bases de Donnes Avances, BDA96, 1996. L. Bouganim, B. Dageville, P. Valduriez, Adaptative Parallel Query Execution in DBS3. International Conference on EDBT, 1996. L. Bouganim, D. Florescu, P. Valduriez, Dynamic Load Balancing in Hierarchical Parallel Database Systems. International
[Bouganim95a]
[Bouganim95b] [Bouganim95c] [Bouganim96a]
[Bouganim96b]
[Bouganim96c]
- 132-
Conference on Very Large Data Bases, 1996. [Bouganim96d] L. Bouganim, B. Dageville, D. Florescu, Skew Handling in the DBS3 Parallel Database System. International Conference on ACPC, 1996. L. Bouganim, D. Florescu, P. Valduriez: Parallel Query Execution in NUMA Multiprocessors. Soumis la publication. 1996. 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. J. B. Carter, J. K. Bennet, and W. Zwaenepoel. Implementation and Performance of Munin. Symposium on Operating System Principles, 1991. P. Casadessus, P. Borla-Salamet, L. Bouganim, Une Exprience de Conception dun Gestionnaire Transactionnel dans un Environement Parallle. Journes Bases de Donnes Avances, BDA93, 1993. P. Casadessus, B. Dageville, P. Borla-Salamet, Evaluation du SGBD parallle DBS3 sur la machine KSR1. Ingnierie des Systmes dInformation (ISI), 2(4), 1994. P. Casadessus, B. Dageville, L. Bouganim: Performances du SGBD parallle DBS3 sur la machine KSR1. Ingnierie des Systmes dInformation (ISI), 3(1), 1995. S. Ceri, G. Pelagatti, Distributed databases, principles and systems, McGraw-Hill, 1984. C. Chachaty, Paralllisation de Requtes dans un systme de Gestion de Bases de Donnes Relationnel Etendu. Thse de lEcole Nationale Suprieure des Tlcommunications, 1991 C. Chachaty, P. Borla-Salamet, M. Ward, A Compositional Approach for the Design of a Parallel Query Processing Language. International Conference 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. D. R. Cheriton, H. A. Goosen, P. D. Boyle, Paradigm: A Highly Scalable Shared-Memory Multicomputer. IEEE Computer, 24(2), 1991. E. F. Codd, A Relational Model of Data for Large Shared Data
[Bouganim96e] [Brunie95]
[Brunie96]
[Carter91]
[Casadessus93]
[Casadessus94]
[Casadessus95]
[Ceri84] [Chachaty91]
[Chachaty92]
[Chen93]
[Cheriton91]
[Codd70]
- 133-
Banks. Communications of the ACM, 13(6), 1970. [Copeland88] G. Copeland, W. Alexander, E. Boughter, T. Keller, Data Placement in bubba. ACM-SIGMOD International Conference, 1988. B. Dageville, P. Borla-Salamet, C. Chachaty, Compiling Control Into Database Queries For Parallel Execution Management. Journes Bases de Donnes Avances, BDA91, 1991. B. Dageville, P. Casadessus, P. Borla-Salamet, The Impact of the KSR1 AllCache Architecture on the Behavior of the DBS3 Parallel DBMS. International Conference on Parallel Architectures and Language, 1994. C.J. Date. An Introduction to Database Systems. Vol 1, AddisonWesley, 1986. D. D. Davis, Oracles Parallel Punch for OLTP. Datamation, 1992. W. Davison, Parallel Index Building in Informix OnLine 6.0. ACM-SIGMOD International Conference, 1992. D. J. DeWitt, R. H. Gerber, G. Graefe, M. L. Heytens, K. B. Kumar, M. Muralikrishna, GAMMA - A High Performance Dataow Database Machine. International Conference on Very Large Data Bases, 1986. D. J. DeWitt & J. Gray, Parallel database systems: The future of database processing or a passing fad?. SIGMOD RECORD 19, 1990. 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. D.J. DeWitt, J.F. Naughton, D.A. Schneider, S. Seshadri, Practical Skew Handling in Parallel Joins. International Conference on Very Large Data Bases, 1992. D.J. DeWitt, J. Gray, Parallel Database Systems: The Future of High Performance Database Processing. Communications of the ACM, 35(6), 1992. M. Dubois, L. Barroso, Y. S. Chen, K. ner, Scalability Problems in Multiprocessors with Private Caches. International Conference on Parallel Architectures and Language Europe, 1992. EDS Database Group, EDS - Collaborating for High Performance Parallel Relationnal Database. Esprit Conference, 1990. P. Faudemay, P. Valduriez, Design and Analysis of a Direct Filter Using Parallel Comparators. International Workshop on Database Machine, 1985.
[Dageville91]
[Dageville94]
[Date86] [Davis92] [Davison92] [Dewitt86]
[Dewitt90a] [DeWitt90b]
[DeWitt92a]
[DeWitt92b]
[Dubois92]
[EDS90] [Faudemay85]
- 134-
[Fitzjohn94] [Fontenot89]
A. Fitzjohn, EDBS:DBS3 EDS.DD.11l.303, 1994.
Comparaison.
EDS
Report
M. Fontenot, Software Congestion, Mobile Servers, and the Hyperbolic Model. IEEE Transactions on Software Engineering 15, 1989. S. Frank, H. Burkhardt, J. Rothnie, The KSR1: Bridging the Gap Between Shared-Memory and MPPs. Compcon93, 1993. S. Fushimi, M. Kitsuregawa, H. Tanaka, An Overview of the System Software of a Parallel Relational Database Machine GRACE. International Conference on Very Large Data Bases, 1986. S. Gamerman, M. Scholl, Hardware versus Software Data Filtering: The VERSO Experience. International Workshop on Database Machine. G. Gardarin, P. Valduriez, ESQL2 : An Extended SQL with Object and Deductive Capabilities. Databases and Expert Systems Applications, 1990. M. N. Garofalakis, Y. E. Yoannidis, Multi-dimensional Resource Scheduling for Parallel Queries. ACM-SIGMOD International Conference, 1996.
[Frank93] [Fushimi86]
[Gamerman85]
[Gardarin90]
[Garofalakis96]
[Gonzales-Rubio84] R. Gonzales-Rubio, J. Rohmer, D. Terral, The Schuss Filter, a Processor for Non Numerical Data Processing. International Conference on Computer Architecture, 1984. [Goodman88] J. R. Goodman, P. J. Woest, The Wisconsin Multicube: A New Large-Scale Cache-Coherent Multiprocessor. University of Wisconsin-Madison, TR 766, 1988. G. Graefe, Encapsulation of parallelism in the Volcano query processing system. ACM-SIGMOD International Conference, 1990. G. Graefe, S. Thakkar, Tunning a Parallel Database Algorithm on a Shared-memory Multiprocessor. Software - Practice and Experience, 22(7), 1992. G. Graefe, D. L. Davison, Encapsulation of Parallelism and Architecture-Independence in Extensible Database Query Processing. IEEE Transactions on Software Engineering 19. 1993. G. Graefe, Query Evaluation Techniques for Large Databases. ACM Computing Surveys, 25(2), 1993. G. Graefe, Volcano, An Extensible and Parallel Dataow Query Evaluation System. IEEE Trans. on Knowledge and Data Engineering, 6(1), 1994. R. L. Graham, Bounds on Multiprocessing Timing Anomalies.
[Graefe90]
[Graefe92]
[Graefe93a]
[Graefe93b] [Graefe94]
[Graham69]
- 135-
SIAM Journal of Applied Mathematics, V17, 1969. [Hagersten92] [Hasan94] E. Hagersten, E. Landin, S. Haridi, Ddm - a Cache Only Memory Architecture. IEEE Computer, 25(9), 1992. W. Hasan, R. Motwani, Optimization Algorithms for Exploiting the Parallel Communication Tradeoff in Pipelined Parallelism. International Conference on Very Large Data Bases, 1994. Y. Hirano, T. Satoh, A U. Inoue, K. Teranaka, Load Balancing Algorithms for Parallel Database Processing on Shared Memory Multiprocessors. International Conference on Parallel and Distributed Information Systems, 1991. W. Hong, M. Stonebraker, Optimization of Parallel Query Execution Plans in XPRS. International Conference on Parallel and Distributed Information Systems, 1991. W. Hong, Exploiting Inter-Operation Parallelism in XPRS. ACMSIGMOD International Conference, 1992. H. Hsiao, M. S. Chen, P. S. Yu, On Parallel Execution of Multiple Pipelined Hash Joins. ACM-SIGMOD International Conference, 1994. K. A. Hua, C. Lee, An adaptative data placement scheme for parallel database computer systems. International Conference on Parallel and Distributed Information Systems, 1991. K.A. Hua, C. Lee, J.K. Peir, Interconnecting shared-everything systems for efcient parallel query processing. Technical Report RC 17507- IBM Research Center. 1991 IDEA Database Group, IDEA : Intelligent Database Environment for Advanced Applications. ESPRIT III Project EP6333, Technical Annex to the IDEA Contract, Issue 1.1, 1992. M. Kitsuregawa, H. Tanaka, T. Motooka, Application of Hash to Data Base Machine and Its Architecture. in the New Generation Computing Journal, 1(1), 1983. M. Kitsuregawa, Y. Ogawa, Bucket Spreading Parallel Hash: A New, Robust, Parallel Hash Join Method for Data Skew in the Super Database Computer. International Conference on Very Large Data Bases, 1990. M. S. Lakshmi & P. S. Yu, Effect of skew on join performance in parallel architectures. International Symposium on Databases in Parallel and Distributed Systems, 1988. 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
[Hirano91]
[Hong91]
[Hong92] [Hsiao94]
[Hua91a]
[Hua91b]
[IDEA92]
[Kitsuregawa83]
[Kitsuregawa90]
[Lakshmi88]
[Lamport86] [Lanzelotte93]
- 136-
Optimization Search Strategies for Parallel Execution Spaces. International Conference on Very Large Data Bases, 1993. [Lanzelotte94] R. Lanzelotte, P. Valduriez, M. Zait, M. Ziane, IndustrialStrenght Parallel Query Optimization: Issues and Lessons. Information Systems, 19(4), 1994. D. Lenoski, J. Laudon, K. Gharachorloo, W. D. Weber, A. Gupta, J. Henessy, M. Horowitz, M. S. Lam, The Stanford Dash Multiprocessor. IEEE Computer, 25(3), 1992. K. Li and P. Hudak. Memory coherence in shared-virtual memory systems. ACM Transactions on Computer Systems 7(4). 1989. D. J. Lilja, Cache Coherence in Large-Scale Shared-Memory Multiprocessors: Issues and Comparisons. ACM Computing Surveys, 25(3), 1993. M. Livny, S. Khoshaan & H. Boral, Multi-disk management algorithms. ACM SIGMETRICS Conference, 1987. M-L. Lo, M-S. Chen, C. V. Ravishankar, P. S. Yu, On Optimal Processor Allocation to Support Pipelined Hash Joins. ACMSIGMOD International Conference, 1993. M. Lopez, The EDS Database Server. EDS Working Report EDS.D901.B, 1989. T. Lovett, S. S. Thakkar, The Symmetry Multiprocessor System. International Conference on Parallel Processing, 1988. H. Lu, M.-C. Shan, K.-L. Tan, Optimization of Multi-Way Join Queries for Parallel Execution. International Conference on Very Large Data Bases, 1991. C. Lynch, Selectivity Estimation and Query Optimization in Large Databases with Highly Skewed Distributions of Column Values. International Conference on Very Large Data Bases, 1988. M. Metha, D. DeWitt, Managing Intra-operator Parallelism in Parallel Database Systems. International Conference on Very Large Data Bases, 1995. C. Morin, A. Gefaut , M. Bantre, A.M. Kermarrec, COMA: An opportunity for Building Fault-tolerant Scalable Shared Memory Multiprocessors. International Symposium On Computer Architectures, 1996 M. C. Murphy, M-C. Shan, Execution Plan Balancing. IEEE International Conference on Data Engineering, 1991. P. M. Neches, The Ynet: An Interconnect Structure for a Highly Concurrent Data Base Computer System. Symposium on the Frontiers of Massively Parallel Computation, 1988
[Lenoski92]
[Li89] [Lilja93]
[Livny87] [Lo93]
[Lopez89] [Lovett88] [Lu91]
[Lynch88]
[Mehta95]
[Morin96]
[Murphy91] [Neches88]
- 137-
[Omiecinski91]
E. Omiecinski, Performance Analysis of a Load Balancing Hash-Join Algorithm for a Shared-Memory Multiprocessor. International Conference on Very Large Data Bases, 1991. J. Ousterhout, Why Arent Operating Systems Getting Faster as Fast as Hardware?. USENIX Summer Conference, 1990. M. T. Ozsu, P. Valduriez, Principles of Distributed Database Systems. Addison-Wesley, 1991. D. A. Patterson, G. Gibson and R. H. Katz, A Case for Redundant Arrays of Inexpensive Disks (RAID). ACM-SIGMOD International Conference, 1988. H. Pirahesh, C. Mohan, J. Cheng, T. S. Liu, P. Selinger, Parallelism in relational database systems: Architectural issues and design approaches. International Symposium on Databases in Parallel and Distributed Systems, 1990. IEEE POSIX P1003.4a. Threads Extension for Portable Operating Systems. E. Rahm, R. Marek, Analysis of Dynamic Load Balancing Strategies for Parallel Shared-Nothing Database Systems. International Conference on Very Large Data Bases, 1993. E. Rahm, R. Marek, Dynamic Multi-Resource Load Balancing in Parallel Database Systems. International Conference 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 International Conference, 1989. D. Schneider, D. DeWitt, Tradeoffs in processing complex join queries via hashing in multiprocessor database machines. International Conference on Very Large Data Bases, 1990. S. A. Schuster, H. B. Nguyen, E. A. Ozkarahan, K. C. Smith, RAP.2 - An Associative Processor for Databases and Its Applications. IEEE Transactions on Database System, 28(6), 1979. P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A. Lorie, T. G. Price, Access Path Selection in a Relational Database Management System. ACM-SIGMOD International Conference, 1979. A. Shatdal, J. F. Naughton, Using Shared Virtual Memory for Parallel Join Processing. ACM-SIGMOD International Conference, 1993. E. J. Shekita, H. C. Young, Multi-Join Optimization for Symmetric Multiprocessor. International Conference on Very Large Data
[Ousterhout90] [Ozsu91] [Patterson88]
[Pirahesh90]
[Posix] [Rahm93]
[Rahm95]
[Schneider89]
[Schneider90]
[Schuster79]
[Selinger79]
[Shatdal93]
[Shekita93]
- 138-
Bases, 1993. [Singh93] J. P. Singh, J. L. Henessey, A. Gupta, Scaling Parallel Programs for Multiprocessors: Methodology and Examples. IEEE Computer, 26(7) 1993. C. J. Skelton, C. Hammer, M. Lopez, M. J. Reeve, P. Townsend and K.F. Wong, EDS: A Parallel Computer System for Advanced Information Processing. International Conference on Parallel Architectures and Language Europe, 1992. A. J. Smith, Cache Memories. ACM Computing Surveys, 14(3), 1982. J. Srivastava, G. Elsesser, Optimizing Multi-Join Queries in Parallel Relational Databases. International Conference on Parallel and Distributed Information Systems, 1993. P. Stenstrom, T. Joe, A. Gupta, Comparative Performance Evaluation of Cache Coherent NUMA and COMA Architectures. International Symposium on Computer Architecture, 1992. M. Stonebraker, The Case for Shared-Nothing. IEEE Data Engenering Bulletin, 9(1), 1986. M. Stonebraker, R. Katz, D. Patterson & J. Ousterhout, The design of XPRS. International Conference on Very Large Data Bases, 1988. M. Stonebraker, G. Kemnitz, The POSTGRES Next-Generation Database Management System. Communications of the ACM Journal, 34(10), 1991. S. Y. W. Su, Database Computers: Principles, Architectures and Techniques. McGraw-Hill, 1988. Teradata, DBC/1012 Data Base Computer, Concepts and Facilities. 1983. P. Valduriez, G. Gardarin, Join and Semi-join Algorithms for a Multiprocessor Database Machine. ACM Transaction on Database Systems, 9(1), 1984. P. Valduriez, Request Manager Architecture. EDS Working Report EDS.WP.11B.1101, 1989. P. Valduriez, Parallel Database Systems: open problems and new issues. International Journal on Distributed and Parallel Databases, 1(2), 1993. C.B. Walton, A.G. Dale, R.M. Jenevin, A taxonomy and Performance Model of Data Skew Effects in Parallel Joins. International Conference on Very Large Data Bases, 1991. A. N. Wilschut, P. M. G. Apers: Dataow Query Execution in a
[Skelton92]
[Smith82] [Srivastava93]
[Stenstrom92]
[Stonebraker86] [Stonebraker88]
[Stonebraker91]
[Su88] [Teradata83] [Valduriez84]
[Valduriez89] [Valduriez93]
[Walton91]
[Wilshut91]
- 139-
Parallel Main-Memory Environment. International Conference on Parallel and Distributed Information Systems, 1991. [Wilschut92] A. N. Wilschut, J. Flokstra & P. M. G. Apers, Parallelism in a main-memory system: The performance of PRISMA/DB. International Conference on Very Large Data Bases, 23-27, 1992. A. N. Wilshut, Parallel Query Execution in a Main-Memory Database System. Thse de doctorat, 1993. A. N. Wilshut, J. Flokstra, P.G Apers, Parallel Evaluation of multijoin queries. ACM-SIGMOD International Conference, 1995. J. L. Wolf, D. M. Dias, P. S. Yu, An Effective Algorithm for Parallelizing Sort Merge in the Presence of Data Skew. International Symposium on Databases in Parallel and Distributed Systems, 1990. J. L. Wolf, D. M. Dias, P. S. Yu, J. Turek, An Effective Algorithm for Parallelizing Hash Joins in the Presence of Data Skew. IEEE International Conference on Data Engeneering, 1991. 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. K. F. Wong, B. Dageville, Supporting Thousands of Threads Using a Hybrid Stack Sharing Scheme. ACM Symposium on Applied Computing, 1994. H. Zeller, Parallel Query Execution in NonStop SQL. Digest of Papers, CompCon Conference, 1990. M. Ziane, M. Zait, P. Borla-Salamet, Parallel Query Processing With Zig-Zag Trees. VLDB Journal, 2(3), 1993. G. K. Zipf, Human Behavior and the Principle of Least Effort: An Introduction to Human Ecology. Reading, MA, Addison-Wesley, 1949.
[Wilschut93] [Wilshut95] [Wolf90]
[Wolf91]
[Wolf93]
[Wong94]
[Zeller90] [Ziane93] [Zipf49]
- 140-
Rsum
Lutilisation de machines parallles pour les systmes de gestion de bases de donnes constitue une solution aux besoins de performances des nouvelles applications des bases de donnes. An 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. Ce problme a t largement tudi pour des architectures classiques (mmoire partage, disques partags ou compltement distribue). Plusieurs remarques peuvent tre faite sur les solutions proposes pour la rpartition de charge: (i) notre connaissance, aucune tude na cherch rsoudre le problme de la rpartition de charge dans son ensemble, cest dire, au niveau intra-oprateur (problme de mauvaises distributions des donnes) et inter-oprateur (problme dallocation des processeurs aux oprateurs). (ii) les solutions au problme des mauvaises distributions de donnes sont gnralement des solutions dynamiques (i.e. durant lexcution), cherchant redistribuer la charge quitablement. Lallocation des processeurs aux oprateurs est, lui, effectu statiquement ou juste avant lexcution. (iii) enn aucune tude na considr les architectures hybrides comme les architectures hirarchiques et NUMA qui tentent dassocier la exibilit de larchitecture mmoire partage et lextensibilit des architectures distribues. Ce sont ces trois points qui ont motiv notre travail dans le cadre de cette thse. Notre approche est totalement diffrente des tudes existantes. Dune part, les solutions proposes dans cette thse sont ddies des architectures hybrides et cherchent exploiter toutes leurs possibilits. Dautre part, les mcanismes dvelopps sont entirement dynamiques. Enn, nous considrons dune manire intgre les diffrentes formes de paralllisme intrarequtes. Nous proposons et valuons une stratgie dexcution de requtes permettant dobtenir un bon support des mauvaises distributions de donnes sur DBS3, un SGBD parallle conu pour une architecture mmoire partage. Nous tendons alors les concepts de DBS3 dans le but de prendre en compte une architecture hirarchique, consistant d'un ensemble de noeuds multiprocesseurs mmoire partage, relis par un rseau rapide. Un modle dexcution permettant une rpartition dynamique de la charge deux niveaux (locale sur un noeud et globale entre les noeuds) est dvelopp puis valu. Le principal atout de ce modle dexcution est quil permet de maximiser la rpartition de charge locale (peu coteuse) et rduit ainsi le besoin de rpartition de charge globale entranant des surcots de communication. Finalement, nous reconsidrons lexcution parallle de requtes complexes sur une architecture mmoire non uniforme et montrons quun modle dexcution non fragment (i.e. tous les processeurs accdent potentiellement lensemble des donnes) semble plus adapt ce genre darchitecture. Nous identions deux consquences des mauvaises distributions de donnes et proposons un nouveau modle dexcution, adapt cette architecture, permettant de supporter ces problmes. Ces trois modles sont implments sur la machine KSR1 munie de 72 processeurs et ont fait lobjet de mesures de performances intensives. Mots Cls: Bases de donnes, Paralllisme, Equilibrage de charge, Jointure par hachage, Architecture hirarchique, Architecture NUMA, Moteur dexcution

1996 - Equilibrage de Charge Lors de L Execution de Requetes Sur Des Architectures Multiprocesseurs Hybrides

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1996 - Equilibrage de Charge Lors de L Execution de Requetes Sur Des Architectures Multiprocesseurs Hybrides

Uploaded by

Copyright:

Available Formats

THSE

MM. Andr Martin

Claude DELOBEL Examinateurs Philippe PUCHERAL Patrick VALDURIEZ

Anaenza et Tana, mes parents et mes beaux-parents...

Table des matires

Chapitre II : Excution parallle de requtes relationnelles.............................................9

2. Formes de paralllisme. .................................................. 16

3. Oprateur de jointure : algorithme et paralllisation 21

7. Quelques modles dexcution parallle .................... 38

Chapitre III : Excution parallle et rpartition de charge dans DBS3.....................................47

3. Analyse du modle .......................................................... 55 4. Etude de performance ..................................................... 57

Chapitre IV : Excution parallle sur une architecture hirarchique .......................71

3. Le modle dexcution parallle DP ............................ 77

4. Techniques dimplmentation ...................................... 84 5. Etude de performances ................................................... 87

Chapitre V : Excution parallle sur une architecture NUMA .................................99

5. Le modle dexcution parallle Progressive Sharing 109

6. Etude de performance ..................................................... 117

7. Conclusion ........................................................................ 124

Chapitre VI : Conclusion ................................................127

Chapitre VII : Bibliographie ...........................................131

Liste des gures

processeurs, disques et modules mmoire. La diffrence dune architecture

Chapitre II Excution parallle de requtes relationnelles

Requte SQL Compilation

Figure 1 : Architecture Standard dun SGBD Parallle

(mmoire partage, disques partags ou compltement distribue) puis nous

Excution parallle de requtes relationnelles

Architectures mmoire partage ou shared-memory

Figure 2 : Architecture UMA

Architecture distribues ou shared-nothing (SN)

Figure 3 : Architecture shared-nothing

Les partisans de larchitecture shared-nothing [Boral88a] [DeWitt92b] considrent

Excution parallle de requtes relationnelles

Architectures disques partags ou shared disks

Figure 4 : Architecture shared-disks

Architecture mmoire non uniforme ou NUMA

Excution parallle de requtes relationnelles

Disque(s) P1 Mmoire cache

Disque(s) P2 Mmoire cache

Disque(s) Pn Mmoire cache

Gestion des caches

Figure 5 : Architecture COMA

point est lobjet du chapitre IV.

Disque Disque Disque

Disque Disque Disque

Disque Disque Disque

Figure 6 : Architecture Hirarchique

Excution parallle de requtes relationnelles

Modle dexcution fragment

Figure 7 : Mthodes de Fragmentation des Donnes

oprateur Linstance i de loprateur

Figure 8 : Paralllisme Intra-oprateur

Excution parallle de requtes relationnelles

Figure 9 : Paralllisme inter-oprateur indpendant

Figure 10 : Paralllisme inter-oprateur pipeline

Modle dexcution non fragment

Excution parallle de requtes relationnelles

Oprateur de jointure : algorithme et paralllisation

Jointure par hachage mono-processeur

Jointure par hachage sur un modle dexcution fragment

3 Oprateur de jointure : algorithme et paralllisation

Build Scan2 Scan1 R S

Figure 11 : Jointure par hachage de deux relations R et S