Flora - Un Optimiseur pour Bases de Donn ees a Objets1

Flora - Un Optimiseur
pour Bases de
1
Donnees a Objets
Daniela Florescu { Jean-Robert Gruser { Hubert
Naacke { Zhao-Hui Tang { Mikal Ziane
* Projet Rodin, INRIA-Rocquencourt. Bp 105, 78153 Le Chesnay Cedex
France
** Laboratoire CNRS-Prism, Universit
e de Versailles St-Quentin. 45, Avenue
des Etats-Unis 78035 Versailles Cedex France
*** Universit
e de Paris V, IUT - D
epartement Informatique. 143, Avenue de
Versailles 75016 Paris France
resume. Dans cet article nous presentons le systeme Flora, un environnement pour
l'optimisation de requ^etes a objets. S'appuyant sur une algebre tres generale qui supporte le modele ODMG et sur une architecture modulaire qui allie extensibilite et
ecacite, il est capable de tirer partie d'une riche palette de connaissances semantiques. Contrairement a la plupart des optimiseurs pour SGBDO, le systeme Flora
s'appuie sur un modele de co^ut. Ce modele de co^ut a ete partiellement valide et nous
resumons en n d'article les principaux resultats de cette validation.
abstract. In this article, we present the Flora system, a plateform for the optimization of object-oriented database queries. Based on a very general algebra which
supports the ODMG model, Flora can take advantage of sophisticated semantic knowledge. Contrary to most OODBMS's optimizers, the Flora system relies on a cost
model whose partial evaluation is also presented here.
mots-cles : base de donnees, requ^ete, objet, OQL, optimisation, modele de co^ut,
reecriture semantique.
key words : database, query, object, OQL, optimization, cost model, validation,
semantic rewriting.
1
Ce travail a ete partiellement nance par le projet ESPRIT IDEA.
1
1 Introduction
La declarativite et surtout la simplicite du systeme relationnel en ont fait un
cadre ideal pour l'optimisation de requ^etes. Les modeles a objets ne sont pas
aussi declaratifs mais surtout beaucoup plus complexes ce qui rend la realisation
d'un optimiseur nettement plus complexe. De nombreux SGBDO (Systeme
de Gestion de Bases de Donnees a Objets) n'ont d'ailleurs pas de veritable
optimiseur, ou bien celui-ci ne s'appuie que tres rarement sur un modele de
co^ut.
Dans le cadre du projet ESPRIT IDEA, nous avons concu, realise et partiellement valide un environnement pour l'optimisation de requ^etes a objets:
le systeme Flora. Vu la diversite des modeles a objets, nous avons deni une
algebre tres generale qui supporte notamment le modele ODMG. Cette algebre
est decrite formellement et en detail dans Flo96]. Nous en presentons ici une
version tres synthetique et informelle (section 2).
Lors de la conception de l'optimiseur Flora, deux objectifs principaux se sont
naturellement imposes. D'abord, il est essentiel d'obtenir des plans d'execution
ecaces avec des temps d'optimisation raisonnables. Ensuite, le contexte objet, fortement evolutif, suggere que l'optimiseur soit extensible, an de pouvoir
s'adapter aux evolutions des langages de requ^etes et des techniques d'evaluation.
Nous avons donc deni une architecture modulaire basee sur un petit ensemble
de concepts generaux mis en oeuvre de facon uniforme (section 3).
Un des points forts de notre optimiseur est sa capacite a utiliser un ensemble
particulierement riche de connaissances semantiques. Ces connaissances sont
exprimees dans un langage declaratif qui permet de les enrichir tres facilement
(section 4).
Contrairement a la plupart des optimiseurs pour SGBDO, le notre s'appuie
sur un modele de co^ut (section 5). Cette approche, bien que plus complexe
que celle basee sur des heuristiques, permet d'obtenir des plans d'execution de
meilleure qualite. Pour cela il faut neanmoins que le modele de co^ut soit able,
c'est pourquoi nous avons fait porter une partie de nos eorts sur la validation
de ce modele (section 6).
1.1 Contexte
Le systeme Flora est un environnement pour l'optimisation de requ^etes objet.
Il comporte essentiellement un compilateur qui traduit une requ^ete objet en un
programme imperatif ecace, exprime dans le langage d'interface du SGBDO
cible.
L'optimiseur Flora n'est pas concu pour un SGBD particulier. Cependant,
nous supposons que le SGBD cible fait partie de la famille \langage de programmation de base de donnees". Ce type de SGBD objet etend des langages
de programmation objet, comme C++ ou Smalltalk, avec des fonctionnalites
bases de donnees (persistance, transactions, requ^etes, etc.). Ils orent aussi un
langage de requ^etes declaratif, qui s'execute dans le m^eme environnement que
l'application, en partageant le systeme de types et l'espace de travail du langage
de programmation. Cette architecture fournit un seul environnement pour les
2
donnees les objets de la base apparaissent alors de facon transparente comme
des objets du langage de programmation. Des exemples de tels systemes sont
O2 et ObjectStore, que nous avons utilise pour valider notre optimiseur.
L'architecture du prototype Flora est decrite gure 1. Ses composants principaux sont la metabase, le compilateur et l'explainer. La m
etabase est la partie du compilateur qui permet de gerer les informations decrivant les donnees
stockees dans la base, informations qui sont necessaires pour la compilation
des programmes et l'optimisation de requ^etes. La metabase contient plusieurs
types d'informations: (i) les informations relatives au schema objet, c.-a-d. la
denition des classes, des types et fonctions utilisateurs, et la denition des
variables nommees (ii) les informations concernant les contraintes d'integrite
(iii) les denitions des vues (materialisees ou virtuelles) (iv) les statistiques correspondant aux donnees et (v) les decisions concernant le placement physique
des donnees, ainsi que la denition des methodes d'acces disponibles.
Le modele de donnees est celui du standard ODMG RGGC93]. C'est celui
de la plupart des prototypes et produits SGBDO recents qui cherchent a deployer completement l'approche objet.
Le compilateur accepte en entree deux langages: Flora et OQL. Complet
et simple, le langage OQL manipule des objets complexes sans privilegier la
construction ensembliste, ni la clause select-from-where. Une requ^ete dans ce
langage est syntaxiquement construite par l'application recursive d'operateurs,
de methodes ou de fonctions, en partant de constantes et de variables.
Le langage Flora FGN+ 95] a ete concu (en parallele a OQL) pour la manipulation et l'interrogation des donnees objet. Flora est un langage imperatif
fortement type, base sur le modele objet du standard ODMG. Il supporte naturellement les calculs sur les collections, notamment les requ^etes declaratives,
comme le langage propose dans Bla94]. Ainsi, les requ^etes declaratives et le
code imperatif se combinent dans le m^eme programme, s'appuyant sur le m^eme
systeme de types. La conception du langage Flora nous a permis de developper
tres t^ot un optimiseur de requ^etes objet qui a pu ^etre facilement adapte au
langage OQL.
Les composants majeurs du compilateur sont les suivants: (i) l'analyseur
syntaxique et semantique, (ii) l'optimiseur de requ^etes, (iii) le generateur de
code. Pendant la compilation, le programme ecrit en Flora (sa partie imperative, aussi bien que sa partie declarative) est traduit par l'analyseur syntaxique
dans la representation interne. Ensuite, le vericateur de type teste la correction du programme, en utilisant les informations du schema stockees dans la
metabase. Lors de la verication syntaxique, les expressions select-from-where
(SFW)1 sont detectees et envoyees a l'optimiseur.
Pour chaque requ^ete, l'optimiseur examine un ensemble de plans d'execution
et choisit le plan d'execution le plus ecace parmi ceux examines. Le m^eme
optimiseur peut ^etre utilise pour la compilation de ces deux langages (Flora et
OQL) car (i) les deux langages s'appuient sur le m^eme modele de donnees et sur
1 M^
eme si syntaxiquement, les autre types d'expression correspondent aussi a des requ^etes
OQL, elles ne sont pas interessantes du point de vue de l'optimisation.
3
Schema
Requete
Contraintes d’integrite
Vues
Catalog
Compilateur
Analyseur
utilise
Metabase
Schema
Contraintes d’Integrite
Definitions de Vues
Optimiseur
Statistiques
Placement
Generateur de code
Program imperatif
Figure 1: L'architecture du compilateur Flora.
le m^eme systeme de types et (ii) les requ^etes OQL correspondent parfaitement a
la partie declarative du langage Flora. L'algebre objet proposee a la section 2 et
qui constitue la base formelle de notre travail d'optimisation, peut representer
aussi bien les requ^etes OQL que la partie declarative du langage Flora.
Dans Flora, l'optimisation des requ^etes est statique, c.-a-d. precede leur
execution. Ainsi, chaque requ^ete est optimisee une seule fois quel que soit le
nombre d'execution de cette requ^ete.
Le plan d'execution produit par l'optimiseur pour une requ^ete donnee remplace la requ^ete correspondante dans le programme initial. Le g
en
erateur de
code traduit ensuite la representation interne du plan d'execution dans un programme du langage imperatif admis par le SGBDO cible. Dans le prototype
actuel, le code genere par l'optimiseur est exprime dans le langage O2 C/O2Api
pour ^etre execute par le SGBD O2 . Ce langage utilise le m^eme systeme de
types que les langages d'entree (OQL ou Flora) et possede les primitive de
base pour exprimer les plans d'execution produits par l'optimiseur (c.-a-d. les
primitives d'iteration sur les collections et les primitives utilisant les methodes
d'acces telles que les index).
Finalement, l'explainer permet, gr^ace a son interface graphique, de piloter
la compilation et l'optimisation de requ^etes, l'execution des plans produits, la
visualisation graphique des informations gerees par la metabase, des requ^etes et
des plans d'evaluation examines par l'optimiseur, le parametrage de l'activite
4
de l'optimiseur et l'execution des programmes generes par le SGBDO cible.
1.2 Criteres de qualite de l'optimiseur
KMP93] propose un certain nombre de criteres de qualite qui peuvent ^etre
resumes comme suit:
extensibilit
e et adaptabilit
e: l'architecture de l'optimiseur doit pouvoir ^etre
adaptee facilement a de nouvelles methodes d'acces, de nouvelles transformations, etc., au fur et a mesure que celles-ci sont supportees par le systeme
am
elioration progressive: l'optimiseur doit pouvoir ^etre ameliore au fur et
a mesure de l'experience accumulee apres l'optimisation d'un certain nombre
de requ^etes. A l'extr^eme, nous pouvons imaginer un optimiseur qui s'adapte
lui-m^eme en fonction du retour (feed-back) qu'il peut obtenir apres l'execution
des requ^etes
pr
evision de la qualit
e: le compromis entre le temps consacre a l'optimisation
et la qualite du meilleur plan d'execution produit doit ^etre considere. En eet,
la qualite du plan d'execution doit ^etre mesuree en fonction du temps necessaire a l'optimiseur pour le produire
d
egradation douce: ce critere est lie au precedent. En reduisant le temps
d'optimisation, la qualite du meilleur plan d'execution produit doit se degrader
doucement tout en restant raisonnable
evaluation anticip
ee des alternatives : les performances de l'optimiseur dependent fortement du nombre d'alternatives examinees. Typiquement, des heuristiques sont utilisees pour restreindre l'espace de recherche examine. Une strategie
egalement ecace consiste a retarder l'examen des alternatives potentiellement
moins interessantes. Pour cela, il faut pouvoir estimer tres t^ot la qualite du
meilleur plan d'execution courant.
Durant la conception de l'optimiseur Flora nous avons toujours eu comme
objectif de satisfaire ces criteres de qualite.
2 Algebre objet
Un plan d'execution pour une requ^ete peut ^etre represente par un terme d'une
certaine algebre. Les entites manipulees ainsi que les transformations qui constituent la base du processus d'optimisation dierent selon l'algebre supportee
par l'optimiseur. Le choix de l'algebre determine la puissance du modele de
donnees, la puissance du langage de requ^etes supporte ainsi que la complexite
et les performances de l'optimiseur.
Deux criteres essentiels ont guide le choix de notre algebre objet. D'abord,
elle doit supporter le standard ODMG, ce qui revient a avoir un systeme de
types aussi general que le modele objet ODMG et un ensemble d'operateurs
capable de supporter le langage de requ^etes objet OQL. Ensuite, l'ensemble
des operateurs de l'algebre doit faciliter le processus d'optimisation.
Les SGBDO representent les objets conceptuels en utilisant des identiants
d'objets (OIDs). Conceptuellement, un objet est un couple (OID valeur). Les
objets de m^eme nature sont regroupes en classes. L'ensemble des types de
5
notre algebre est deni en appliquant recursivement quatre constructeurs de
type: set, list, bag et tuple, a partir de l'ensemble des classes de la base de
donnees et de l'ensemble des types atomiques predenis (ex. string, integer).
2.1 Les operateurs de l'algebre
Contrairement a l'algebre relationnelle, dont les operateurs ne manipulent que
des relations (c.-a-d. ensembles de tuples), une algebre objet doit manipuler
uniformement des donnees de n'importe quel type (entier, objets, ensemble
d'entiers, listes de listes, etc.). Ainsi, notre algebre objet doit avoir des operateurs manipulant des collections et des operateurs manipulant les donnees simples, comme par exemple, les operateurs arithmetiques, les operateurs booleen,
etc. Les operateurs manipulant des collections sont similaires aux operateurs
de l'algebre relationnelle (c.-a-d. union, dierence, selection, projection, etc.).
L'algebre utilisee est une algebre typee. Chaque operateur a une signature
qui decrit le type des donnees auxquelles il peut ^etre applique et chaque terme
de l'algebre a un type associe. Elle manipule uniformement des operateurs du
premier ordre (c.-a-d. dont les arguments sont des donnees) comme les operateurs arithmetiques, l'union ou la dierence, et des operateurs du second ordre
(c.-a-d. dont les arguments peuvent ^etre des fonctions) comme les quanticateurs, l'operateur de groupement et les operateurs de selection, projection et
jointure.
Trois algebres dierentes sont considerees dans le processus d'optimisation:
l'algebre initiale, dont les termes constituent une representation directe des
requ^etes OQL, l'algebre logique contenant un ensemble d'operateurs logiques
elementaires (c.-a-d. pour lesquels il existe un algorithme les implantant) et
l'algebre physique contenant l'ensemble des algorithmes implantes dans les couches
basses du systeme. Classiquement, les optimiseurs considerent seulement deux
niveaux d'abstraction (c.-a-d. l'algebre logique et l'algebre physique), mais,
pour certaines techniques d'optimisation(ex. l'optimisation semantique ou l'utilisation
des vues materialisees), l'introduction d'un niveau supplementaire est necessaire.
De nombreux operateurs sont communs entres ces trois niveaux. Par exemple, les operateurs arithmetiques ne sont pas modies lors du processus
d'optimisation. Par contre, l'operateur de selection-projection-jointure n-aire
(SPJ) deni dans l'algebre initiale est transforme dans l'algebre logique en
operateurs unaires ou binaires.
2.2 Les Operateurs SPJ
Le choix des operateurs SPJ a ete guide par les motivations suivantes: (i)
l'algebre doit contenir des operateurs susamment riches pour couvrir le langage OQL et (ii) elle ne doit pas contenir d'operateurs redondants.
L'algebre initiale. Ce niveau d'algebre contient un seul operateur n-aire,
collect, qui generalise les operateurs SPJ, avec toutes leurs variantes connues
6
dans l'algebre relationnelle (jointure externe, semi-jointure, etc.) ou dans les
algebres objet (ex. jointure dependante). Cet operateur construit une collection
resultat a partir de n collections (non necessairement independantes), d'une
fonction de selection n-aire et d'une fonction de projection n-aire. Il est deni
par deux variantes: collect , correspondant a la decision exprimee en OQL
\les duplicats sont gardes et l'ordre n'est pas preserve dans le resultat", et
collect , correspondant a la decision \les duplicats et l'ordre sont preserves
dans le resultat".
L'algebre logique. Dans l'algebre logique, les operateurs n-aires collect et
collect se decomposent chacun en deux operateurs: un operateur unaire de
selection-projection et un operateur binaire de selection-projection-jointure.
L'algebre physique. A chaque operateur unaire ou binaire de l'algebre
initiale correspond un certain nombre d'algorithmes physique l'implantant.
L'operateur select se transforme en deux algorithmes scan et indexscan.
L'operateur join se transforme dans l'algebre physique en cinq algorithmes
dont hashjoin, indexjoin et nestedjoin.
bag
list
list
bag
bag
bag
Nous pouvons faire deux remarques concernant les algebres objet que nous
considerons. Premierement, les operateurs SPJ (c.-a-d. l'operateur n-aire collect
de l'algebre initiale, ainsi que les operateurs unaires ou binaires select et join de
l'algebre logique) sont presentes avec deux variantes (bag et list), selon le type
des collections arguments et le type de la collection resultat. En eet, le code
genere (c.-a-d. le modele d'execution) pour toutes ces variantes est identique.
Par exemple, les deux variantes de l'operateur collect s'executent par n boucles
imbriquees. Cependant, certaines transformations utilisees pas l'optimiseur ne
s'appliquent que sur une certaine variante de ces operateurs. Deuxiemement,
l'operateur binaire de jointure de notre algebre ne verie aucune propriete
algebrique telle que la commutativite ou l'associativite. En eet, comme il
generalise la jointure dependante et la jointure sur les listes, cet operateur
n'est pas commutatif. De plus, il prend en entree non seulement deux collections mais aussi deux fonctions representant le predicat a tester et la projection
a appliquer. Il ne peut donc pas verier la propriete d'associativite. Ceci a une
consequence importante sur l'algorithme d'ordonnancement d'operations que
nous pouvons utiliser. En eet, ces algorithmes, developpes dans le cadre de
l'algebre relationnelle, exploitent les proprietes algebriques de ces operateurs.
3 Architecture
L'architecture de l'optimiseur Flora a ete concue pour atteindre un bon compromis entre ecacite et extensibilite, c.-a-d. en preservant les avantages des
optimiseurs bases sur des regles, sans penaliser ni le temps d'optimisation, ni
la qualite du plan d'execution produit. Pour ^etre extensible, l'optimiseur Flora
est base sur un ensemble de transformations elementaires. Cependant, an
d'eviter les surco^uts inherents aux optimiseurs bases sur des regles (en particulier le pattern-matching), les transformations algebriques predenies (communes a toutes les applications) ne sont pas decrites dans un langage declaratif
7
mais codees directement dans l'optimiseur. Pour simplier le probleme du
contr^ole de l'application des regles dans le contexte objet ou le nombre de
transformations est tres grand, nous avons opte pour une architecture modulaire, comme celle proposee dans MZD93] . D'autre part, le choix du meilleur
plan d'execution est eectue en fonction d'un modele de co^ut.
Un autre objectif important a ete de construire une bonne plateforme pour
experimenter les elements principaux d'un optimiseur: les transformations, les
heuristiques, les strategies de recherche et les fonctions de co^ut. Pour ce faire,
nous avons construit un module d'explication graphique, appele explainer, qui
permet d'etudier et de demontrer le comportement de l'optimiseur.
3.1 Espaces de recherche
L'activite principale de l'optimiseur est d'explorer l'espace de recherche, c.-a-d.
l'ensemble des plans d'execution equivalents a la requ^ete initiale.
Une requ^ete est representee dans l'optimiseur par un terme algebrique.
Graphiquement, un terme peut ^etre represente par un arbre, dont les feuilles
representent des donnees et les nuds internes representent des operateurs (qui
peuvent ^etre des operateurs predenis de l'algebre ou des operateurs denis par
l'application).
La representation interne est susamment generale pour pouvoir coder aussi
bien les requ^etes initiales, que les plans d'execution physiques. Une requ^ete
initiale est representee par un terme de l'algebre initiale et un plan d'execution
par un terme de l'algebre physique.
Pendant l'optimisation, l'optimiseur maintient en permanence trois espaces
de recherche: l'espace de recherche initial, l'espace de recherche logique et
l'espace de recherche physique. Chaque espace de recherche contient la liste
(sans double) des termes de son l'algebre respective (initiale, logique ou physique),
equivalents au terme correspondant a la requ^ete a optimiser.
L'optimisation debute par l'introduction du terme correspondant a l'espace
de recherche initial. A la n de l'optimisation, le terme de co^ut minimal de
l'espace de recherche physique constitue le resultat de l'optimisation.
An de satisfaire le critere de qualite \evaluation anticipee des alternatives"
que nous nous sommes xe, l'optimiseur associe a chaque terme, independamment du niveau d'algebre, une estimation de co^ut d'evaluation potentiel. Par
exemple, pour les termes de l'algebre initiale, la fonction du co^ut est proportionnelle a la quantite des donnees impliquees dans la requ^ete2 . Pour les
termes de l'algebre logique, qui contient deja l'ordonnancement d'operations,
une estimation du co^ut d'evaluation plus ne est possible, en supposant que
l'algorithme physique le plus co^uteux est utilise pour chaque operateur logique
(nestedLoop pour l'operateur join, et scan pour l'operateur select, etc.). Finalement, pour les termes de l'algebre physique, une estimation de co^ut plus
complexe est eectuee.
2 Le but n'est pas d'obtenir une estimation ne du temps r
eel d'execution. Ce qui nous
interesse ici est le ratio des co^uts d'evaluation des termes de chaque espace de recherche.
8
Les fonctions de co^ut utilisees dans l'optimiseur Flora sont developpees dans
Gru96]. Les plans d'execution incomplets3, potentiellement co^uteux sont examines par l'optimiseur le plus tard possible.Dans chaque espace de recherche,
les termes sont tries en permanence selon leur fonction de co^ut. Lorsqu'un nouveau terme est produit, il est insere dans son espace de recherche en fonction
du co^ut estime.
3.2 Architecture modulaire
En concevant l'optimiseur Flora, nous nous sommes eorce de preserver les
avantages de l'approche par regles sans sourir de ses inconvenients. Ainsi,
l'optimiseur est base sur une bibliotheque de transformations elementaires,
logiquement formulees comme des couples de termes equivalents, avec variables libres. Du point de vue de l'implementation, une transformation est un
objet qui peut ^etre active par l'envoi d'un terme de l'algebre et qui produit un
ensemble de termes equivalents.
Les transformations peuvent ^etre classees en fonction des connaissances
qu'elles utilisent. Les transformations pr
ed
enies n'utilisent que les proprietes
algebriques des operateurs predenis de l'algebre (ex. la commutativite de
l'operateur union avec l'operateur select). Ces transformations sont communes
a toutes les applications. Pour augmenter leur ecacite, ces transformations ne
sont pas ecrites dans un langage declaratif (ce qui impliquerait l'utilisation d'un
algorithme de pattern-matching), mais implantees directement dans l'optimiseur.
Un autre type de transformations concerne les transformations s
emantiques
utilisant les connaissances speciques a une certaine application (ex. la reecriture basee sur les liens inverses ou la reecriture en utilisant des vues materialisees), decrites en utilisant des assertions. Lors de la compilation d'une assertion, une nouvelle transformation semantique est ajoutee a la bibliotheque des
transformations elementaires.
Pour eviter le contr^ole complexe de l'application des transformations elementaires, celles-ci sont regroupees dans des modules, comme dans l'optimiseur
Epoch MZD93]. Les transformations utilisant le m^eme type de connaissances
sont donc regroupees dans le m^eme module. Par exemple, les principaux
modules de l'optimiseur Flora sont la simplication, la reecriture semantique,
l'ordonnancement d'operations, la reecriture algebrique et l'optimisationphysique.
Chaque module a un but particulier et une strategie locale qui determine la
facon dont le module atteint son but. De facon similaire aux transformations,
les modules sont des objets que l'on peut activer en leur envoyant des termes.
Un module active produit un ensemble de termes equivalents, en appliquant
sa propre strategie. Pour atteindre son but, un module peut faire appel a des
transformations et/ou a d'autres modules.
Les modules sont regroupes dans une hierarchie. Un module parent peut
activer des modules ls, en leur envoyant des termes (en utilisant la m^eme
3 On appelle incomplet un plan d'ex
ecution qui ne contient pas encore toutes les decisions
d'evaluation.
9
interface que pour les transformations). Un module ls produit un ensemble de
termes equivalents, selon sa strategie locale, et les retourne au module parent.
Un module parent peut appeler un module ls, mais ne contr^ole en aucun cas
la strategie locale de ce dernier.
Cette architecture modulaire permet un grand degre d'extensibilite. Tout
d'abord, l'ensemble des transformations elementaires peut ^etre etendu facilement. L'ajout d'une nouvelle transformation dans l'optimiseur necessite seulement son codage et son integration dans le module qui lui correspond. Ainsi, cet
ajout se fait sans impact sur le code de l'optimiseur. De plus, la strategie locale
de chaque module peut ^etre changee localement, sans impact sur les autres modules. Par exemple, on peut changer la strategie du module d'ordonnancement
d'operations ou on peut inhiber l'optimisation semantique, sans changer le reste
de l'optimiseur.
Il y a cependant des restrictions sur l'ordre d'application des transformations
et/ou des modules, car ils ne peuvent pas ^etre combines de facon arbitraire.
Certains modules supposent que d'autres modules ou transformations ont ete
deja invoques (c.-a-d. l'ordonnancement d'operations doit ^etre eectue apres
l'optimisation semantique, les predicats doivent ^etre mis sous la forme normale
avant d'eliminer les quanticateurs, etc.).
3.3 Principaux modules
Les principaux modules utilises par l'optimiseur Flora sont la simplication, la
r
e
ecriture s
emantique, l'ordonnancement d'op
erations, la r
e
ecriture alg
ebrique
et l'optimisation physique. Dans cette section nous presentons leur buts, leurs
strategies ainsi que les transformations appliquees par chacun de ces modules.
Le but du module de simplication est de transformer le terme SFW (SelectFrom-Where) initial (terme de l'algebre initiale) dans un terme equivalent
(toujours un terme de l'algebre initiale), a la fois plus simple et plus facile
a optimiser. Ceci est realise en appliquant les transformations suivantes: (i)
elimination des variables locales (ii) elimination des vues virtuelles (iii) desimbrication des requ^etes imbriquees dans la clause from (iv) desimbrication des
requ^etes imbriquees dans la clause where (v) mise sous forme normale des
predicats (vi) ajout de la clause distinct (si possible) (vii) elimination des
quanticateurs existentiels (si possible). Contrairement aux transformations
appliquees dans les autres modules, elles ne creent pas de choix mais transforment directement le terme original.
Le but de la r
e
ecriture s
emantique est d'examiner, a partir d'une requ^ete
OQL originale (c.-a-d. un terme de l'algebre initiale), un ensemble de requ^ete
OQL equivalentes (c.-a-d. termes de l'algebre initiale) potentiellement moins
co^uteuses a evaluer. Ceci est realise en appliquant des transformations qui
utilisent les connaissances semantiques (c.-a-d. contraintes d'integrite) et/ou
les connaissances concernant les vues materialisees.
Deux observations peuvent ^etre faites concernant ce module. Premierement,
les transformations appliquees ici creent des choix, c.-a-d. par l'application de
ces transformations, le terme original n'est en aucun cas modie. Un nouveau
10
Simplification
Reecriture source a source
Algebre Intiale
cout croissant
Ordonancement d’Operations
Reecriture Algebrique
Algebre Logique
Controle
Global
cout croissant
Optimisation Physique
Algebre Physique
cout croissant
Figure 2: Les espaces de recherche.
terme produit par une telle transformation est insere a son tour dans la liste
qui forme l'espace de recherche initial, s'il n'existe pas deja. Deuxiemement, la
strategie de ce module consiste a appliquer des transformations semantiques,
en boucle, jusqu'a la n de l'optimisation, contrairement au module de simplication, qui ne s'execute que lorsqu'un autre module l'appelle explicitement.
Le module d'ordonnancement d'op
erations construit, a partir d'un terme de
l'espace de recherche initial, un ensemble de termes de l'algebre logique. Ceuxci sont inseres dans l'espace de recherche logique, en fonction de leur co^ut. De
facon similaire au module precedent, le module d'ordonnancement d'operations
s'execute dans une boucle, sans interruption jusqu'a la n de l'optimisation. Il
examine ainsi les termes de l'algebre initiale (c.-a-d. les elements de l'espace de
recherche) dans l'ordre croissant de co^uts, les plans incomplets potentiellement
co^uteux etant examines apres les plans de co^uts potentiellement reduits.
Le module de r
e
ecriture alg
ebrique applique aux termes de l'espace de
recherche logique un ensemble de transformations correspondant aux proprietes
des operateurs de l'algebre logique. Il produit ainsi d'autre termes, qui sont
11
inseres dans le m^eme espace, selon leurs co^uts respectifs.
La dierence avec la reecriture algebrique eectuee dans les optimiseur relationnels, reside principalement dans l'absence des transformations habituelles,
provenant de l'associativite et de la commutativite de l'operateur join et de la
commutativite de l'operateur join avec l'operateur select, car ces deux operateurs ne verient plus ces proprietes algebriques. Par consequent, la complexite
de la reecriture algebrique est bien reduite.
Finalement, a chaque terme de l'algebre logique correspond un ensemble de
termes de l'algebre physique, construit par le module d'optimisation physique.
La t^ache principale de ce module est de detecter, en fonction des structures
d'acces disponibles, les algorithmes physiques qui peuvent executer chaque
operateur logique. Les nouveaux termes produits sont inseres, en fonction de
leur co^ut dans l'espace de recherche physique.
Une image globale de l'activite de l'optimiseur est donnee gure 2.
3.4 Contr^ole de l'optimiseur
Classiquement, un optimiseur procede en un certain nombre d'etapes (c.-a-d.
reecriture, ordonnancement de jointures, optimisation physique), executees
sequentiellement. Determiner un contr^ole xe c.-a-d. un ordre exact pour
l'application des transformations et/ou des modules, adapte pour toutes les
requ^etes, est une t^ache d'une grande complexite. De plus, trouver un tel ordre
semble impossible si l'on desire que l'optimiseur produise un plan d'execution
ecace dans un temps optimal quelle que soit la requ^ete.
Dans notre optimiseur, nous avons mis en oeuvre la solution suivante. Les
modules de reecriture semantique, d'ordonnancement d'operations, de reecriture algebrique et d'optimisation physique s'executent de facon concurrente.
Chaque module est execute par un processus leger (\thread") dierent, ce qui
permet leur execution simultanee, sans synchronisation globale rigide.
Un avantage considerable de cette approche est le fait que l'optimiseur possede, a tout moment4, au moins un plan d'execution. A chaque instant du
processus d'optimisation, le meilleur plan est toujours le premier terme de
l'algebre physique. Il est evident que le co^ut estime pour le meilleur plan
d'execution diminue avec le temps d'optimisation. Ainsi, l'optimisation peut
^etre interrompue a tout moment, ce qui satisfait le critere de qualite \degradation douce'.
L'activite de l'optimiseur est supervisee par un contr^oleur global qui peut
interrompre l'executions des modules lorsque l'une des conditions suivantes est
veriee: (i) le temps d'optimisation depasse le budget maximal admis, (ii)
la taille de l'espace de recherche initial examine depasse la limite superieure
admise, (iii) la taille de l'espace de recherche logique examine depasse la limite superieure admise, (iv) la taille de l'espace de recherche physique examine depasse la limite superieure admise, (v) le meilleur plan d'execution produit est satisfaisant, (vi) le rapport entre le temps d'optimisation et le temps
4
Au moins apres la production du premier plan d'execution.
12
d'execution estime pour le meilleur plan d'execution depasse la limite maximale
admise.
4 Optimisation semantique
Dans les bases de donnees relationnelles, l'optimisation semantique a pour objectif de tirer prot des connaissances sur des entites du monde reel, et donc
des proprietes des donnees stockees dans la base, an de trouver, pour une
requ^ete donnee, des alternatives de calcul ecaces. L'information semantique
est typiquement decrite par un ensemble de contraintes d'integrite.
Avec un modele de donnees objet, les donnees sont principalement structurees en classes, qui peuvent capturer directement les associations et le code
applicatif. Les donnees sont representees dans la base comme des objets et
les associations sont implementees par des liens directs (via les identiants
d'objets) qui permettent un acces navigationnel rapide entre les dierents objets. En speciant pour une certaine classe un lien mono ou multi-value vers
une autre classe, les requ^etes peuvent suivre ce lien an d'atteindre les objets recherches. Dans ce cas, les alternatives de calcul pour une telle requ^ete
ne sont plus construites en utilisant les proprietes algebriques des operations,
mais, principalement, en utilisant la semantique des liens qui relient les nuds
dans le graphe d'objets.
Certaines contraintes semantiques sont representees naturellement et maintenues sans surco^ut dans les SGBDO en etant directement exprimees dans le
schema. Les contraintes de ce type sont appelees les contraintes s
emantiques
implicites. Des exemples typiques de contraintes d'integrite implicites sont la
relation de sous-typage et la relation referentielle (c.-a-d. les liens directs entre les classes), qui representent deux notions inherentes au modele objet. Les
contraintes qui sont explicitement speciees par les utilisateurs sont appelees
contraintes s
emantiques explicites. Le but de cette section est d'examiner ce
deuxieme type de contraintes qui, dans un certain sens, generalise les contraintes implicites. Nos contraintes semantiques explicites sont typiquement
des predicats decrivant des proprietes veriees par les donnees de la base.
Nous avons identie plusieurs categories de connaissances semantiques. Une
premiere categorie concerne les assertions d'equivalence qui permettent de declarer les eventuelles redondances de donnees dans la base. Un seconde categorie concerne les assertions de valeur nulle des expressions elles permettent d'appliquer des transformations classiques (\type-based rewriting") qui
font la correspondance entre les jointures fonctionnelles et les jointures explicites avec les extensions de classes. Une troisieme categorie concerne les cles
(c.-a-d. identiants uniques) des diverses collections, en generalisant la notion
de cle telle qu'elle est denie dans la norme ODMG. Finalement, les assertions
d'inclusion ou les assertion d'appartenance generalisent les informations que
l'on peut obtenir en exploitant la denition des classes (ex. relation d'heritage,
l'appartenance d'une instance d'une classe a l'extension de la classe respective, etc.) pour des donnees qui ne sont pas forcement des objets et pour des
collections qui ne sont pas forcement des extensions de classes.
13
4.1 Les assertions d'equivalence
L'elimination de la redondance des donnees n'est pas un objectif de la conception d'un schema de base de donnees objet. La connaissance concernant
la redondance de donnees peut ^etre utile pour l'optimisation, car elle permet
d'examiner plusieurs manieres d'obtenir les m^emes donnees demandees par une
requ^ete, avec des co^uts potentiellement dierents.
Les redondances eventuelles d'un schema objet sont speciees a l'optimiseur
a l'aide d' assertions d'equivalence que nous denissons comme suit. Une assertion d'
equivalence est une formule logique du premier ordre de la forme
suivante:
forall
< variable declaration >] ]
t1
t2
ou une declaration de variable peut avoir l'une des formes suivantes:
<var name> of type <type expression>
<var name> in <col>
(1)
(2)
ou t1 et t2 sont des termes du m^eme type et chaque terme col utilise dans
une declaration de variable est un terme de type set, bag ou list. Les termes
utilises dans les declarations de variables, ainsi que t1 et t2 peuvent utiliser
les variables nommees du schema, ainsi que les variables quantiees declarees
auparavant. Les expressions de type utilisees dans la declaration des variables
peuvent ^etre des expressions de type generales avec des variables.
Dans le processus d'optimisation, les assertions d'equivalence sont utilisees
comme des regles de reecriture. Une assertion d'equivalence arme que deux
termes t1 et t2 sont evalues a la m^eme valeur pour toute substitution correcte
des variables quantiees. Etant donne un terme initial t a optimiser, elle permet
de remplacer toute occurence de t1 dans t par t2 (ou les occurences de t2 par
t1), produisant ainsi des termes equivalents a t.
La correction de la reecriture(c.-a-d. le fait qu'un terme t derive de t en
utilisant l'assertion A est equivalent a t) est assuree seulement si l'assertion
A est valide. Dans toutes les instances de bases de donnees du schema S ou
l'assertion A est valide, nous garantissons que les deux termes t et t sont
evalues a la m^eme valeur.
0
0
4.2 Autres assertions
A la dierence de SQL, le langage OQL est un langage type et la connaissance
concernant les types peut ^etre exploitee lors de l'optimisation de requ^etes. La
connaissance concernant le type d'une sous-expression d'une certaine expression
SFW peut ^etre exploitee pour transformer la jointure implicite5 produite par
5 Navigation d'une classe d'objets a
une autre classe d'objets via un calcul de fonction. Ce
type de jointure est appelee aussi navigation ou jointure fonctionnelle.
14
cette sous-expression dans une jointure explicite6 utilisant les extensions des
classes. Les deux types de jointures representent des alternatives d'execution
pour une m^eme requ^ete logique et l'optimiseur doit choisir la meilleure en
fonction du co^ut estime de ces alternatives.
Pour appliquer la transformation d'une jointure implicite en jointure explicite l'information concernant les types n'est pas susante. Des informations
semantiques supplementaires sont necessaires pour la raison suivante: les assertions de non nullite garantissent que certains termes ne sont jamais evalues a la valeur nil (dans le cas mono-value) ou n'incluent jamais la valeur nil
(dans le cas multi-value) 7 . Cette information est utilisee dans la transformation de la jointure implicite en jointure explicite et vice-versa.
En utilisant ce type d'assertion, on peut denir des liens inverses simples,
des liens inverses generalises (obtenus comme combinaison d'autres liens), des
fonctions materialisees, des vues materialisees, des fonctions inverses, etc.
Le modele de donnees objet, base sur les classes, les extensions de classes
et l'heritage, permet d'inferer deux types d'informations semantiques particulieres: (i) l'inclusion de l'extension d'une sous-classe dans l'extension d'une
super-classe (c.-a-d. tout objet de la sous-classe est egalement instance de la
super-classe) (ii) l'inclusion de toute collection d'objets de type c (qui ne contient pas la valeur nil) dans l'extension de la classe c. Ces deux types de connaissances, intrinseques au modele de donnees objet et deduites a partir de la
denition du schema, peuvent ^etre exploitees lors de l'optimisation de requ^etes
an d'examiner d'autres alternatives d'execution pour une requ^ete donnee.
Les assertions d'inclusion generalisent les contraintes speciques au modele de donnees objets. Une assertion d'inclusion arme que la valeur d'un terme
multi-value t1 est incluse dans la valeur d'un autre terme multi-value t2 .
De facon similaire aux assertions d'inclusion, les assertions d'appartenance
arment que la valeur d'un terme mono-value t1 est un element de la collection resultat d'un autre terme multi-value t2. En utilisant cette connaissance, il
est possible de remplacer dans l'expression d'un terme la jointure fonctionnelle
denie par t1 par une jointure explicite impliquant la collection t2.
Ce type de reecriture generalise la reecriture basee sur les types (CD92,
JWKL90]). Avec la reecriture basee sur les types, l'assertion d'appartenance
utilisee est celle inherente au modele objet: la valeur d'un terme t de type
c (c etant une classe) appartient a l'extension de la classe c8 . Les assertions
d'equivalence denies ici generalisent ce genre d'information an de couvrir
d'autres cas: la connaissance sur l'appartenance du resultat de l'evaluation
d'un terme a une collection complexe.
6 Jointure classique impliquant les extensions de classes, dont le pr
edicat teste la fonction
faisant la correspondance entre les objets.
7 Ce type d'assertion g
eneralise la clause
du langage SQL.
8 Ceci a condition de ne pas evaluer a la valeur nil.
not null
15
A : UNIVERSITE
A : UNIVERSITE
1
A : UNIVERSITE
1
10
5
1
B :ETUDIANT
B : ETUDIANT
a. Placement par defaut
b. Placement simple
D : ETUDIANT
8
10
A : UNIVERSITE
1
1 C : PROFESSEUR
1
C : PROFESSEUR
1
10
1
1
c. Placement conjonctif
d. Placement disjonctif
Figure 3: Les dierentes possibilites de regroupement
5 Le module d'optimisation physique
Ce module transforme un terme logique en un plan d'execution dont il doit
de plus estimer le co^ut. Le plan d'execution qui sera nalement choisi par
l'optimiseur sera alors eventuellement compile par le systeme cible dans un
langage de plus bas niveau. Les trois principales composantes du principe
d'optimisation physique sont le modele d'execution, le modele de placement et
le modele de co^ut.
5.1 Un modele general de regroupement des donnees
Le modele de placement doit permettre a l'optimiseur d'evaluer de facon adequate
le co^ut d'acces aux objets. Le modele propose se veut tres general permettant
ainsi d'englober de nombreuses politiques de placement. Pour cela nous avons
adopte un regroupement d'objet base sur la generalisation des arbres de placement.
5.1.1 d
enition
Nous generalisons les arbres de placement en denissant les proprietes suivantes: (i) les noeuds des graphes sont des collections d'objets persistants, (ii)
les arcs sont labellises par des predicats d'association si necessaire, (iii) une
priorite est attribuee a chaque arc, (iv) un arc qui pointe sur son noeud de
depart indique un placement par defaut.
La gure 3 montre quatre dierentes possibilites de regroupement.
Le regroupement par defaut : Tous les objets de la collection sont regroupes
physiquement dans des pages disque contigues. Si un objet ne correspond a
aucun predicat de placement, c'est le placement adopte par defaut. Ainsi sa
priorite est toujours egale a 1. Dans la gure 3.a, la collection Universit
e a un
placement par defaut.
Le regroupement simple : C'est le regroupement classique de deux collections avec un predicat de jointure. Dans la gure 3.b, les objets de la collection
Etudiant sont regroupes avec les objets correspondants de la collection Universit
e avec un priorite egale a 10. Tous les objets de la collection Universit
e ne
pointant pas sur des objets de la collection Etudiant sont regroupes ensemble.
Tous les objets de la collection Etudiant dont l'objet de la collection Universit
e
n'est pas connu sont aussi regroupes ensemble.
16
Le regroupement conjonctif : La gure 3.c montre un exemple de placement
ou les objets de la collection Etudiant et les objets de la collection Professeur
sont regroupes avec les objets de la collection Universit
e qui leur est associee.
Cette strategie de placement permet de regrouper plusieurs collections avec une
m^eme collection.
Le regroupement disjonctif : Dans la gure 3.d, chaque objet Professeur
peut ^etre stocke soit avec son Universit
e, soit avec ses Etudiant. Comme ce
modele n'accepte pas la duplication, chaque objet Professeur est place suivant
la !eche ayant la plus grande priorite.
La composition de ces dierents types de placement conduit a l'elaboration
d'un arbre de placement complet. Dans notre modele un graphe de placement
donne le regroupement des objets ainsi que la partition des dierents types de
regroupements. Par exemple, l'arbre de la gure 3.c donne six regroupements.
Pour le placement par defaut, nous avons trois regroupements : les objets de la
collection Etudiant seuls (Cl
), les objets de la collection Professeur seuls
(Cl
) et les objets de la collection Universit
e seuls (Cl
). Puis
nous avons deux regroupements avec deux collections : Cl
et
Cl
. Enn, le regroupement qui stocke les trois collections
: Cl
(
)
Un des principaux but du modele de co^ut est de donner le nombre d'EntreesSorties (ES) realisees pour une requ^ete donnee. Pour cela le modele de placement doit stocker des statistiques pour chaque type d'objet dans chacun des
regroupements.
Etudiant
P rof esseur
U niversite
U niversite!E tudiant
U niversite!P rof esseur
U niversite! Etudiant P rof esseur
5.1.2 La fonction Yao'
Le modele d'execution decrit des algorithmes capables d'acceder a des objets
selectionnes dans un regroupement et non pas a tous les objets du regroupement. Ce sont des algorithmes utilisant des index ou des expressions de chemin.
Le probleme est le suivant : soit n objets stockes sur m pages, si je selectionne seulement k objets, combien d'ES vais-je realiser ? Dans les systemes
relationnels, la formule utilisee est la formule de Yao Yao77]:
Y ;i+1
yao(n m k) = m 1 ; nd
n ; i + 1 ] where d = 1 - 1/m
=1
k
i
Elle est basee sur la repartition uniforme des objets dans les pages disque.
Mais cette hypothese n'est plus acceptable car notre modele est fragmente.
Le principe de la fonction Yao' est de repartir la fonction Yao sur chacun des
regroupements utilises dans la requ^ete :
X
yao0 (C k) = yao(jjC jj jC j k )
p
C li
i
=1
C li
i
jjC jj est la cardinalite et jC j le nombre de pages des objets de la collection C dans le regroupement Cl . Soit k le nombre d'objets selectionnes pour
Cli
C li
i
i
17
chaque regroupement, nous pouvons facilement calculer k en repartissant proportionnellement la selection sur chaque regroupement : k = (jjC jj =jjC jj) k
Le principe de fonctionnement du modele de placement est detaille dans
GGT95].
i
i
C li
5.2 Modele d'execution
Dans cette section nous nous concentrons, sur l'execution des expressions de
chemins qui sont utilisees de facon intensive dans les requ^etes a objets. Dans
un premier temps, nous avons derive le concept des expressions de chemin pour
denir le concept plus general d'expression de chemin ltree. Ce nouveau type
d'expression de chemin nous a permis d'exprimer des requ^etes complexes en
utilisant le formalisme usuel des expressions de chemin des SGBDOO GGT96].
La plupart du temps les optimiseurs de requ^etes objet envisagent uniquement deux methodes d'execution des expressions de chemin. Dans cet article
nous avons adapte ces methodes aux expressions de chemin ltrees et nous
avons deni une nouvelle methode basee sur les jointures de pointeurs (\pointer
based join"). La diversite de ce modele d'execution ameliore considerablement
les performances d'optimisation des expressions de chemin.
5.2.1 Les di
erentes m
ethodes d'
evaluation
E valuation en profondeur d'abord (DFF). L'operateur DFF est un opera-
teur n-aire evaluant les expressions de chemin en profondeur d'abord. Il utilise
l'evaluation na$ve par traversee de pointeur. Pour chaque objet de la collection
racine l'expression de chemin est traversee jusqu'au bout de facon recursive.
Un tel algorithme est assimilable a l'evaluation en pipeline d'une serie de jointure dependante.
E valuation avec des jointures de pointeurs (BFF). L'algorithme BFF est
issue des jointures basees sur les pointeurs SC90, KGM91]. L'idee principale
est d'assimiler une traversee de pointeur a une jointure entre OID. En fait la
jointure est entierement stockee dans les objets gr^ace aux pointeurs. Comme
le DFF il sut de parcourir uniquement les objets pointes. A chaque pas du
BFF, l'algorithme balaie une collection et cree une table de correspondance
assimilable a une jointure d'indice Val87]. Lors de la creation, les OID pointes
sont tries pour respecter l'ordre physique de placement9. Ensuite l'acces aux
objet de la collection suivante dans l'expression de chemin se fait en balayant
directement la table. A chaque pas, le BFF renvoie la table de correspondance
modiee en remplacant les pointeurs de la collection precedente, par les pointeurs tries de la collection suivante a balayer.
E valuation avec des jointures classiques (RJ). L'expression de chemin
peut ^etre evaluee inversement, en partant de la derniere collection, gr^ace a des
9
Uniquement possible si les OID sont physiques, sinon le trie ne sert a rien
18
jointures classiques. Le predicat de jointure est une comparaison de valeur
d'OID. Les algorithmes de jointures employes sont le sortmergejoin (SRJ) ou
le hashjoin (HRJ). L'algorithme doit utiliser les extensions de classe correspondant a chaque type de l'expression de chemin. Classiquement l'arbre de jointure
peut ^etre en pipeline ou materialise.
5.3 Co^ut des algorithmes
La construction du modele de co^ut physique decoule directement des deux
premiers modeles. Sa problematique est la suivante : etant donnee un plan
d'execution physique et des informationsde placement, quel est le co^ut d'execution
correspondant? Generalement le modele de co^ut est separe en deux : le co^ut
des algorithmes et le co^ut des plans d'execution. Le modele associe a chaque
algorithme une fonction de co^ut locale dont les parametres d'entree sont donnes
par la forme du plan d'execution. Le co^ut du plan d'execution est estime en
calculant de proche en proche (selon l'ordre d'execution deni par le plan) le
co^ut des algorithmes jusqu'a obtenir le co^ut d'execution global.
5.3.1 Statistiques
Le modele de co^ut utilise des statistiques sur les composants de la base pour
estimer un plan d'execution donne. Les statistiques incluent la cardinalite des
collections d'objets de la base, la taille de ces objets, le nombre de valeurs
distinctes pour chaque attribut, ainsi que des informations sur les index et le
regroupement des objets. Nous maintenons aussi des parametres systeme et
des formules de calcul du co^ut.
Les statistiques sur les collections d'objets sont les suivantes :
Parametres Description
P
jjC jj
jC j
S
D
fan 1 2
D1 2
C
a C
C
C
C
C
Sel(Predicat)
b
Bl(I)
S
p
m
IO
CPU
Predicat de la requ^ete
cardinalite de la collection C
Nbr. de pages de la collection C
taille moyenne d'un objet de la collection C
Nbr. de valeurs distinctes de l'attribut \a" de la collection C
Nbr. moyen de references d'un objet C1 vers les objets C2
Nbr. distinct de references d'un objet C1 vers les objets C2
selectivite d'un predicat
fanout de l'index en arbre binaire
Nbr. de niveaux de l'index en arbre binaire I
taille d'une page
memoire disponible en Nbr. de page)
co^ut d'une ES pour charger une page en memoire
unite de temps CPU
Table 1: Statistiques du modele de co^ut
19
5.3.2 Les op
erateurs de bas niveaux
Le modele d'execution utilise des operateurs de bas niveaux representant chacun un co^ut unitaire. En decomposant chaque algorithme en operateur de bas
niveaux nous evaluons aisement leurs fonctions de co^ut.
D'une maniere generale, le processus d'evaluation d'un algorithme est le
suivant : l'algorithme doit comparer des valeurs d'objet et renvoyer un resultat, pour cela il faut d'abord charger en memoire les objets (si les objets sont
deja en memoire, il ne fait rien), puis comparer les valeurs en memoire enn
construire le resultat en memoire. Les operateurs sont les suivants :
L'operateur de chargement des objets en memoire : Fetch(OID) ! State.
Cet operateur prend en entree l'OID de l'objet, et charge l'etat de l'objet s'il
n'est pas deja present en memoire. Le co^ut d'un telle operation est egal a une
ES en lecture ou a 0 si l'objet est deja en memoire.
L'operateur permettant de retrouver la valeur d'un attribut dans un tuple
objet (cette operation est eectuee en memoire uniquement) : Dot(State) !
value. Son co^ut est generalement neglige.
L'operateur de comparaison de deux valeurs en memoire :
Comp(valeur1 valeur2 oprateur) ! boolen. Son co^ut est du temps CPU pur.
5.4 Co^ut de creation des resultats temporaires
Pendant l'execution d'une requ^ete, le systeme a besoin de generer des resultats
temporaires. La taille du resultat depend du predicat applique sur la collection
d'entree, du nombre d'attributs projetes (Nb ) et de la taille moyenne de la
projection (S ). Le co^ut de creation du resultat temporaire se decompose
en:
proj
proj
CPU out(PC proj ) = Sel(P ) jjC jj CPU et IO out(PC proj ) = jjoutjj (1)
b
Sp
Sproj
c
5.5 Co^ut pour evaluer un predicat
Nous faisons l'hypothese que les pages a lire pendant le calcul sont deja en
memoire. Deux cas doivent ^etre consideres:
le predicat n'a pas d'expression de chemin.
le predicat comporte une expression de chemin,
5.5.1 Pr
edicat sans expression de chemin
Pour evaluer le predicat, il faut d'abord acceder a l'attribut de l'objet en invoquant l'operateur Dot, puis comparer les deux valeurs atomiques. L'objet
etant en memoire, il n'y a pas d'ES. Ce qui donne:
20
IO Pred(P ) = 0 et CPU Pred(P ) = jjC jj CPU
(2)
5.5.2 Pr
edicat avec expression de chemin
Le modele d'execution evalue les expressions de chemin par un algorithme de
recherche en profondeur d'abord. Au niveau physique les plans n'ont plus
d'expression de chemin. Pour chaque objet de la collection d'entree, l'algorithme
doit trouver l'attribut correspondant. Soit l'expression de chemin ltree suivante : (x 2 C1 x:c2(P2 ):::c (P ):attr) ou c reference un objet de C et S est la
selectivite du predicat P .
Le nombre de references distinctes impliquees dans la lecture de la collection
C est Ref tel que: Ref = (1 ; Prob ) jjC jj. P rob etant la probabilite pour
qu'un objet de i soit implique dans le traitement telle que:
;1 ) avec Ref1 = jjC1jj.
Prob = (1 ; 1 )( ;1 ;1
Nous etudions ici le cas ou la taille memoire est plus grande que le nombre
de pages necessaires au traitement du predicat. Le cas contraire est etudie en
detail dans GGT96]. Chaque page a lire est donc chargee une et une seule fois
en memoire. La formule de Yao' donne l'approximation du nombre de pages a
charger.
X 0 si C ;1 est regroupe avec C
n
n
i
i
i
i
i
i
i
i
Refi
i
Si
f anCi
i
i
Ci
jjCi jj
n
IO Pred(P ) =
i
i
=2
i
(3)
i
Y ao0 (C Ref )
i
Pour l'ensemble des objets rencontres pendant la traversee de chemin, le
co^ut CPU d'acces aux attributs et de comparaison de leur valeur est:
XY
CPU Pred(P ) = jjC 1jj CPU (
fan ;1 S ;1 )
(4)
n
i
Cj
Cj
j
=2 j =2
i
5.5.3 Les algorithmes issus de l'algebre relationnelle
Ce sont les algorithmes classiques des bases de donnees relationnelles. Pour
evaluer le temps de reponse d'une jointure (resp. d'un scan), nous multiplions
le nombre d'ES estime par le temps unitaire d'une ES. Puis, nous ajoutons le
temps CPU.
Le detail de ces formules de co^ut et du principe de calcul des co^uts des plans
d'execution peut ^etre trouve dans Gru96].
6 Validation du modele de co^ut
La validation de notre modele de co^ut est faite sur le SGBD client/serveur
O2 BCD89]. La conguration est mono-utilisateur. Le serveur et le client
O2 s'executent sur une m^eme machine Sun Sparc LX. Le co^ut d'une ES est la
21
A
A
A
4500
3500
C
A
A
B
C
B
AC
A
4500
AB
B
2000
C ABC
Figure 4: Exemple d'une base de donnee
12
Clustered
Not Clustered
10
Response Time (s)
Theoretical
Clustered
8
Theoretical Not
Clustered
6
4
2
0
0
2000
4000
6000
8000
10000
12000
14000
16000
Cardinality of A
Figure 5: E valuation des expressions de chemin
somme du temps de lecture d'une page de 4Ko dans la memoire du serveur, et
du temps de transfert de cette page dans la memoire du client. Nous mesurons
un temps moyen de 25ms pour le co^ut d'une ES.
Les requ^etes sont executees sur deux bases equivalentes dont les strategies
de placement dierent. La premiere a le placement decrit dans la gure 4, la
deuxieme a un placement par defaut pour chaque collection. Nous creons un
index sur l'attribut \indexId" de chaque collection. Les liens entre A, B et C
sont aleatoires. Un attribut non indexe \name" est un identiant unique pour
chaque objet. Pendant l'experimentation, chaque requ^ete est executee dix fois
dans les m^emes conditions, puis la moyenne des dix temps de reponse sert de
resultat.
Validation de la strategie de placement Dans la premiere experience,
nous executons sur les deux bases une requ^ete qui lit toute la collection A. Et
pour chaque element de A la requ^ete evalue une expression de chemin traversant
B et C.
select x from x in A where x.b.c.name ! = \" 22
60
Response Time (s)
50
40
30
Yao
20
Yao'
Theoretical Yao
10
Theoretical Yao'
0
0
20
40
60
80
100
Selectivity (%)
Figure 6: Validation de la formule de Yao
Cette experience doit valider l'in!uence du placement sur le co^ut d'execution
de la requ^ete et la precision de notre modele de co^ut. Nous faisons varier la
cardinalite et nous mesurons le temps de reponse (cf. Figure 5). Le resultat montre que la technique de placement par regroupement des objets relies,
ameliore les performances de la requ^ete. Nous mesurons un rapport de 6 entre
les deux strategies de placement. De plus, le rapport estime avec les formules de
co^ut a sensiblement la m^eme valeur, ce qui valide la precision de notre modele.
Validation de la formule de Yao Cette experience doit valider la formule
de Yao. La requ^ete est executee sur les deux bases de la gure 4.
select x from x in A where x.IndexId >= N% La requ^ete lit la collection A a l'aide d'un index sur IndexId. L'index permet
de ne lire que les objets satisfaisant le predicat de selection. Cette experience
valide la formule de Yao' et de Yao, respectivement avec la premiere et la
deuxieme base.
La taille d'un objet etant de 300 octets, nous avons 12 objets par page. La
taille de la memoire disponible n'in!uence par la mesure (elle est superieure
aux besoins de la requ^ete). Nous faisons varier la selectivite (cf. gure 6). Nous
mesurons un rapport entre les courbes mesurees qui est identique au rapport
entre les courbes estimees.
Validation du co^ut des expressions de chemin: Cette experience doit
montrer l'in!uence de la memoire sur une traversee de chemin. La requ^ete
executee est celle de la premiere experience. Nous mesurons le temps de reponse
en fonction de la taille de la memoire disponible pour executer la requ^ete. La
memoire du systeme UNIX est videe avant chaque requ^ete. La gure 7 montre
que l'execution sur la base avec placement est insensible aux variations de
memoire. En eet, seule la page courante de chaque collection est memorisee
(lecture en !ot continu).
Dans le cas du placement par defaut (objets regroupes en 3 collections),
23
80
Not Clustered
Break Point = 1941 Kbytes
70
Approximation
Clustered
Response Time (s)
60
50
40
30
20
10
0
200
1200
2200
3200
4200
5200
6200
7200
Buffer Size (KBytes)
Figure 7: Co^ut de la traversee de chemin
nous avons: Ref1 = 14500, Ref2 = 3965 et Ref3 = 1202. Donc IO Pred =
Y ao (C2 Ref2) + Y ao (C3 Ref3) = 485:26. Le point d'arr^et vaut 485:26 S ' 1941KBytes. Ce point d'arr^et est determine avec precision par notre
modele de co^ut. Il represente la limite inferieure de la memoire en dessous de
laquelle le nombre des ES deteriore le temps d'execution. Ce point d'arr^et est
le critere utilise par l'optimiseur pour choisir entre la navigation de pointeur et
les jointures binaires.
0
0
p
Comparaison des algorithmes DFF, BFF and RJ La prochaine experi-
ence compare trois algorithmes de traversee de chemin dierents. La longueur
du chemin est de 4. L'expression de chemin contient un predicat sur la premiere collection (variable) et sur la derniere collection (xe a 10%). La gure
8 montre que le chacun des algorithmes est meilleur que les autres dans une
plage de memoire particuliere. En realite, selon la taille memoire, le meilleur
plan d'execution devrait ^etre un melange des dierents algorithmes. Par exemple, DFF pour les trois premieres collections et BFF pour les deux suivantes.
Pour reduire l'espace de recherche, l'optimiseur devrait avoir une heuristique
qui propose ce melange d'algorithmes GGT96].
7 Travaux connexes
La plupart des produits SGBDO comme ObjectStore et GemStone font peu
d'optimisation, et se bornent a exploiter les chemins d'acces existants sans faire
de transformation algebrique. Les principales exceptions sont Orion JWKL90],
Epoq SZ90], GOM KMP93], O2 VDD+ 90] et Volcano GM93].
7.0.4 Orion
Orion JWKL90] fut le premier SGBDO a introduire des techniques d'optimisation
de requ^etes. Le langage de requ^etes, base sur Lisp, est simple. L'optimiseur
24
3500
DFF
3000
BFF
HRJ
Response Time (s)
2500
2000
1500
1000
500
0
0
5000
10000
15000
20000
25000
30000
35000
40000
Memory Size (KBytes)
Figure 8: Comparaison de DFF, BFF et RJ
d'Orion manipule la requ^ete par des transformations tres simples appliquees
dans un ordre pre-deni. Ces transformations permettent de decomposer les
expressions de chemin en jointures et de realiser l'ordonnancement de jointures,
avec dierents chemins d'acces speciques pour les parcours avant ou arrieres
correspondant aux sous-expressions de chemins. Le modele de co^ut s'appuie
sur celui des systemes relationnels, et prend en compte les acces disques pour
evaluer le co^ut des operateurs.
7.0.5 Epoch
Epoch SZ90] est un modele d'architecture pour construire des optimiseurs de
requ^etes objet. L'architecture d'un optimiseur Epoq comporte un ensemble de
modules concurrents. Chaque module est capable d'optimiser des expressions
de requ^ete selon une certaine strategie. Les modules sont organises selon une
hierarchie, et chaque module parent contr^ole ses modules enfants.
Cette architecture permet de contr^oler globalement l'optimisation de requ^etes. Un but a atteindre est aecte a chaque module ce but caracterise la
requ^ete pouvant ^etre renvoyee par ce module. Etant donne une requ^ete et un
but a atteindre pour cette requ^ete, le module indique au module parent s'il a
reussi a atteindre ce but.
Cette architecture modulaire permet de concevoir divers types d'optimiseurs
extensibles qui integrent diverses techniques d'optimisation objet.
7.0.6 GOM
Le systeme GOM KMP93] preconise l'application de l'architecture tableau
noir issue de l'intelligence articielle, pour l'optimisation de requ^etes objet.
L'objectif est que l'optimiseur puisse ^etre extensible, specialisable, et reglable.
Le langage de requ^etes s'inspire du langage Excess VD91] et l'algebre com25
porte des operateurs particuliers pour manipuler des collections d'identiants
d'objets.
L'architecture d'optimiseur qui est proposee est organisee sous la forme
d'une echelle de regions sur un tableau noir. Entre chaque paire successive
de regions, une source de connaissances manipule une requ^ete pour la faire
avancer d'une region vers la region immediatement plus haute (sur l'echelle).
Le traitement d'une source de connaissances peut aussi acceder n'importe quelle
information sur le tableau noir. Tous les elements d'une region ont une information de co^ut associee pour assister les sources de connaissance dans leur t^ache.
Ce concept de region correspond assez bien aux modules specialises d'Epoch.
7.0.7 O2
Le SGBD O2 VDD+ 90] supporte le langage de requ^etes OQL. Son optimiseur
applique les transformations algebriques suivantes: factorisation des expressions communes, utilisation des liens inverses pour produire de nouvelles expressions de chemin, et decomposition des expressions de chemins en jointures
explicites en utilisant les extensions de classes.
La generation du plan d'execution utilise des heuristiques qui exploitent
l'existence d'index et le regroupement physique des donnees sur disque. Elle
n'utilise pas de modele de co^ut. Le modele d'execution est assez simple puisqu'il
ne supporte que le balayage d'une collection et la jointure de deux collections
par boucles imbriquees, avec ou sans index.
7.0.8 Volcano
Volcano GM93] est un generateur d'optimiseurs de requ^etes, qui a servi de
base notamment aux optimiseurs Cascades Gra91] et OpenOODB BMG93].
Il est issu directement du generateur d'optimiseur EXODUS GD87].
Volcano est un systeme extensible avec lequel il est possible de programmer
ses propres modules de regles de transformation. Volcano supporte une algebre
logique et une algebre physique, qui capture le modele d'execution. An de
pouvoir etendre ces algebres, le concept de propri
et
es associees aux operateurs
algebriques est propose. Ce sont des informations denies par l'utilisateur
et traitees par Volcano comme des donnees de type abstrait. Les proprietes
de l'algebre logique permettent de denir des regles d'equivalence entre les
operateurs.
Le systeme ne comporte pas de langage de requ^etes, ni de modele de donnees. L'utilisateur doit programmer le module de traduction des requ^etes dans
l'algebre logique de Volcano.
7.1 Conclusion
Dans cet article nous avons presente de facon tres synthetique Flora, un environnement pour l'optimisation de requ^etes a objets. S'appuyant sur une
algebre tres generale, il dispose d'une architecture modulaire qui lui permet
de preserver l'extensibilite des systemes a base de regles sans compromis sur
26
l'ecacite. Un des points forts de Flora est sa capacite a utiliser une riche
panoplie de connaissances semantiques qui peuvent ^etre exprimees de facon
declarative. Le modele de placement de Flora peut exprimer des politiques
tres variees et permet a l'optimiseur d'exploiter cette connaissance pour trouver un moyen ecace d'acceder aux donnees.
Bien qu'il soit plus complexe de s'appuyer sur un modele de co^ut, cette
approche permet d'obtenir des plans d'execution de grande qualite pour autant
que ce modele ait ete valide. Cette t^ache est d'une complexite considerable
aussi, nous l'avons eectuee sur une partie critique du modele d'execution a
savoir les expressions de chemin.
Une partie du systeme Flora est en cours d'adaptation au sein du projet
Rodin pour permettre l'optimisation de requ^etes sur un reseau tres etendu
comme l'internet.
References
BCD89] F. Bancilhon, S. Cluet, and C. Delobel. A query language for the O2
object-oriented database system. In R. Hull, R. Morrison, and D.
Stemple, editor, Proc. 2nd Intl. Workshop on Database Programming Languages, page 122, Gleneden Beach, Oregon, June 1989.
Morgan Kaufmann.
Bla94] J.A. Blakeley. OQL++]: Extending the C++ language with an
object query capability. In Modern Database Management - ObjectOriented and Multidatabase Technologies, ACM Press/AddisonWesley, 1994.
BMG93] J.A. Blakeley, W. McKenna, and G. Graefe. Experiences building
the open OODB query optimizer. In Proc. ACM SIGMOD International Conference on Management of Data, Washington, DC, May
1993.
CD92] S. Cluet and C. Delobel. A general framework for the optimization
of object-oriented queries. In Proc. ACM SIGMOD International
Conference on Management of Data, San Diego, California, June
1992.
FGN+95] D. Florescu, J-R. Gruser, M. Novak, P. Valduriez, and M. Ziane.
Design and implementation of Flora, a language for object algebra.
Information Science, 87(1-3), 1995.
Flo96] Daniela Florescu. Espace de recherche pour l'optimisation de requ^etes objet. PhD thesis, Universite de Versailles St Quentin, 1996.
GD87] G. Graefe and D. DeWitt. The EXODUS optimizer generator. In
Proc. ACM SIGMOD International Conference on Management of
Data, San Francisco, USA, May 1987.
27
GGT95] G. Gardarin, J.R. Gruser, and Z.H. Tang. A cost model for clustered
object-oriented databases. In Proc. Int'l. Conf. on Very Large Data
Bases, Zurich, Switzerland, September 1995.
GGT96] G. Gardarin, J.R. Gruser, and Z.H. Tang. Cost-based selection of
path expression processing in object-oriented databases. In Proc.
Int'l. Conf. on Very Large Data Bases, Bombay, India, September
1996.
GM93] G. Graefe and W.J. McKenna. The Volcano optimizer generator:
Extensibility and ecient search. In Proc. Int. Conf. on Data Engineering, Vienna, Austria, April 1993.
Gra91] G. Graefe. The Cascades framework for query optimization. Data
Engineering Bulletin, 18(2):58{62, September 1991.
Gru96] J.R. Gruser. Modeles de co^ut pour l'optimisation de requ^etes objet.
PhD thesis, Universit Pierre et Marie Curie - Paris VI, 1996.
JWKL90] B.P. Jenq, D. Woelk, W. Kim, and W.-L. Lee. Query processing in
distributed ORION. In Proc. EDBT, Venice, Italy, 1990.
KGM91] T. Keller, G. Graefe, and D. Maier. Ecient assembly of complex
objects. In ACM-SIGMOD International Conference on Management of Data, pages 148{157, Denver, Colorado, May 1991.
KMP93] A. Kemper, G. Moerkotte, and K. Peithner. A blackbord architecture for query optimization in object bases. In Proc. Int. on Very
Large Data Bases, Dublin, Ireland, August 1993.
MZD93] G. Mitchell, S. Zdonick, and U. Dayal. Control of an extensible
query optimizer: A planning-based appoach. In Proc. Int. Conf. on
Very Large Data Bases, Dublin, Ireland, August 1993.
RGGC93] ed. R. G. G. Cattel. The Object Database Standard: ODMG-93.
Morgan Haufmann Publishers, San Mateo, Ca., 1993.
SC90] E.J. Shekita and M.J. Carey. A performance evaluation of pointerbased joins. In ACM-SIGMOD International Conference on Management of Data, Atlantic City, New Jersey, May 1990.
SZ90]
G.M. Shaw and S.B. Zdonick. A query algebra for object-oriented
databases. In Proc. Int. Conf. on Data Engineering, Los Angeles,
California, February 1990.
Val87] P. Valduriez. Join indices. ACM Trans. on Database Sys., 12(2):218,
June 1987.
VD91] S. Vandemberg and D. DeWitt. Algebraic query processing in EXTRA/EXCESS. Data Engineering Bulletin, 14(2):48{52, June 1991.
28
VDD+90] F. Velez, V. Darnis, D. Dewitt, P. Futtersack, G. Harrus, D. Maier,
and M. Raoux. Implementing the o2 object manager: Some lessons.
In Fourth Int'l Workshop on Persistent Object Systems, September
1990.
Yao77] S. B. Yao. Approximating the number of accesses in database organizations. Comm. of the ACM, 20(4):260, April 1977.
Daniela Florescu est chercheur au laboratoire
d'ATT (Murray Hill, New Jersey) depuis novembre 1996. Auparavant, elle etait doctorante au sein
du projet Rodin a l'INRIA (Rocquencourt). Elle a
soutenu sa these de doctorat a l'universit
e de Paris
VI en septembre 1996, sur l'optimisation de requ^etes dans les bases de donn
ees objet.
Jean Robert Gruser pr
epare une these de doc-
torat de l'universit
e Pierre et Marie Curie (Paris
VI), au sein du projet Rodin a l'INRIA. Son travail porte sur l'optimisation physique de requ^etes
a objets. Il etudie principalement les modeles de
placement, les modeles d'ex
ecution et les modeles
de co^ut.
29
Hubert Naacke pr
epare une these de doctorat de
l'universit
e de Versailles St-Quentin (UVSQ), au
sein du projet Rodin a l'INRIA. Son travail porte
sur l'optimisation physique de requ^etes a objets.
Il etudie principalement les modeles d'ex
ecution
et les modeles de co^ut dans les bases de donn
ees
h
et
erogenes.
Zhao-Hui Tang a soutenu sa these de doctorat
a l'Universit
e de Versailles en octobre 1996. Dr.
Tang eectue un post-doc au laboratoire Prism
travaillant sur l'ex
ecution des requ^etes a objet.Il
s'int
eresse principalement a l'ex
ecution des expressions de chemin et aux architectures multi-bases
sur Internet.
Mikal Ziane est Ma^tre de Conf
erences a
l'Universit
e Ren
e Descartes (Paris V) depuis 1992.
Il a eectu
e sa these d'Universit
e au sein du projet Rodin de l'INRIA sur l'optimisation de requ^etes
pour bases de donn
ees paralleles. Son travail porte
a pr
esent sur les systemes d'aide a la programmation a base de connaissances.
30