Parallel database management system.
M. Bamha et M. Exbrayat, LIFO
Doctorant: P. Courtois Univ Orléans.
Metin Osman, stagiaire ingénieur (Belford) quelques mois au LIFO.  

Object: développer un prototype de bibliothèque pour 
SGBD parallèle extensible et l'étendre à l'exécution 
dans un contexte GRID.

Etape 1.
Algo de jointure parallèle testé sur un exemple particulier. 
Essais sur les paramètres de la performance de cet algo qui 
règle le cas le plus difficile d'équilibrage et d'extensibilité 
du traitement des requêtes.  Parseur pour intégration d'un 
fichier index de la base (ce fichier décrit les tables de la 
base et leur répartition). Exécution d'une requête complexe 
comme une séquence d'opérations parallèles. Le plan d'exécution 
est découpé en plusieurs jointures parallèles, chacune est 
individuellement optimale mais pas d'optimisation globale sur 
toute la requête complexe. Hypothèse de base: toutes les 
tables sont réparties de manière équilibrée sur tous les 
processeurs. 

Etape 2.
Etendre le parseur à traiter le cas où les relations sont 
réparties de manière quelconque. Cette répartition est 
décrite par une syntaxe spécifique: noms des tables sur 
les processeurs, liste des tables etc. Utilisation du 
parallélisme pipelinage: les données peuvent passer d'une 
opération parallèle à la suivante avant que la première  
soit complétée. Cela offre une flexibilité dans l'allocation 
des ressources: dans le cas d'un allocation de processeurs où 
une opération relationnelle n'utilise pas tous les proc (c'est 
le cas en général si on veut optimiser le temps) on peut 
rentabiliser le temps des autres processeurs en les allouant 
à une autre opération relationnelle. Cela est facilité par le 
pipelinage car on donne ainsi plus de degrés de liberté à 
l'allocation, il peut éliminer certains délais d'attente, des 
termes additifs dans le temps d'exécution. Problème technique 
difficile: adapter osfa-join (algorithme extensible et 
parfaitement équilibré) au pipelinage. Le pipelinage évite 
en outre de saturer la mémoire vive ou d'avoir à stocker sur 
disque les résultats intermédiaires. Gain de l'ordre de 20% 
sur des requêtes de 3 ou 4 jointures. Technique clé: pipelinage 
des histogrammes des relations intermédiaires. 

Prototype permettant les exécutions pipelinées des requêtes. 
Possibilité de participation à l'ACI-Propac 2004-2007 F.Loulergue. 

Développement d'une bibliothèque de requêtes SGBD avec C+MPI 
au niveau d'une machine parallèle et le parseur de requête 
mentionné ci-dessus. Extension avec Globus pour meta-computing. 
Dans ce cas, découpage de la requête entre sites, table globale 
des tables et de leur découpage. Communications par grid-ftp, 
une composante Globus permettant de transférer des données entre 
les sites. Pas de duplication de données, que du découpage. 
Ecrit en Java et Globus et C, MPI. La partie globus n'est pas 
parfaitement nécéssaire et l'interface globus est trop lourde 
pour être absolument nécéssaire. On pourrait refaire notre 
bibli avec TCP/IP et produire une interface avec Caml. Les 
éléments d'une interface Caml pour une grappe de PC sont déjà 
écrits. Il suffirait d'y ajouter une partie distribution des 
tables pour obtenir une interface Caml complète. Ce prototype 
fonctionne en MySQL mais une interface ODBC est déjà prête. 

Poursuite encore 2 ans pour la thèse de P. Courtois. 
---