Sommaire
1 Introduction . . . . 55 2 Conception physique . . . . 57 3 Quelques exemples de structures d’optimisation . . . . 58
3.1 Les index . . . 58
3.2 Les vues matérialisées . . . 59
3.3 La Fragmentation horizontale . . . 62
4 Synthèse . . . . 64
4.1 Choix structures d’optimisation . . . 65
4.2 Choix de la méthode de sélection . . . 65
4.3 Choix d’algorithme de sélection . . . 66
4.4 Mise en œuvre des solutions d’optimisation . . . 66
5 Vers une conception physique desBDBO . . . 66
1 Introduction
L’optimisation de requêtes est un enjeu important dans le contexte de bases de données. Elle a toujours eu une place importante à travers les différentes générations de bases de données: les bases de données traditionnelles, les bases données XML, les bases de données décisionnelles, les bases de données statistiques et scientifiques, les bases de données sémantiques, et le big data. Puisque les applications de bases de données sont toujours à la recherche de temps de traitement de requêtes plus performant, plusieurs travaux ont été menés pour rendre les optimi-seurs de requêtes plus efficaces. Pour atteindre cet objectif, les optimioptimi-seurs de requêtes ont pris en compte progressivement des paramètres issus des phases du cycle de vie de la conception de base de données (à savoir, la modélisation conceptuelle, la modélisation logique ETL, la modé-lisation physique et le déploiement (Figure 2.1)) et le langage de requêtes utilisé par le SGBD cible.
Figure 2.1 – Problème de conception physique
Deux générations principales d’optimiseurs de requêtes existent : des optimisations dirigées
par certaines phases de cycle de vie (ODCP) et d’autres dirigées par toutes les phases (ODT P).
La première génération des optimiseurs a été basée principalement sur l’étude des propriétés al-gébriques du langage de requêtes défini sur le modèle logique de la base de données à concevoir. Le Rule-based Approach (RBA) est un exemple de ce type d’optimisation. Plus précisément, le
RBA utilise un ensemble de règles intuitives supposé optimiser les requêtes. Nous pouvons citer
par exemple, la règle consistant à descendre les opérations de la sélection et de projection dans un arbre algébrique. Cette règle permet de réduire la taille des relations et des résultats inter-médiaires manipulés. Ce type d’optimisation est simple à implémenter, pour cette raison, elle a été considérée dans l’ensemble des SGBD commerciaux et académiques. La principale limite de cette optimisation est qu’elle ignore les paramètres physiques liés à la base de données et la
plateforme sur laquelle le SGBD est déployé. Les optimisations de typeODT P sont apparues
une optimisation de typeODT P prend en compte des paramètres conceptuels, physiques et de
déploiement. L’approche basée sur des modèles de coût mathématiques, Cost-Based Approach
(CBA) est un exemple de cette génération. Cette approche consiste à d’abord calculer le coût des
différentes stratégies possibles correspondant aux plans d’exécution d’une requête en fonction des caractéristiques des fichiers sur lesquels sont implantées les relations, pour ensuite retenir le plan ayant le coût minimal. Pour illustrer le fonctionnement de cette optimisation, considérons l’exemple suivant:
Exemple 1
Considérons une requête impliquant une opération de jointure entre deux tables relation-nellesR et S stockées sur un disque. Si nous souhaitons calculer le coût de cette jointure en utilisant une implémentation par hachage sachant qu’il existe plusieurs algorithmes pour implémenter une opération de jointure (boucles imbriquées, le tri, etc.), nous aurons besoin des paramètres issus de l’ensemble de phases du cycle de vie:
– la couche conceptuelle: la longueur de chaque attribut de chaque table; – la couche logique: la taille (en termes d’instances) de chaque table;
– la couche physique: le modèle de stockage utilisé pour stocker les tables (row store, column store)
– la couche de déploiement: les caractéristiques de disque comme la taille d’une page disque.
Le coût de cette jointure, dénoté parJHash, est donné par la formule suivante [80]:
JHash = 3× (|R| + |S |) (1)
avec|R|et|S |sont égales respectivement à⌈||R||×LGPS R⌉et⌈||S ||×LGPS S⌉, tels que :
– :LGR etLGS désignent respectivement la taille d’une instance deRet deS (obtenue à partir du dictionnaire de données de la couche conceptuelle) ;
– ||R|| et ||S || représentent respectivement le nombre d’instances de R et S (la couche logique) ;
– PS décrit la taille d’une page disque (la couche de déploiement).
Cet exemple nous montre que l’optimisation de requêtes est sensible à l’ensemble de phases du cycle de vie de conception de bases de données. Si le langage de requêtes, le type de la base de données, le modèle de stockage, ou la plateforme de déploiement changent alors le processus d’optimisation doit être revisité. L’ensemble des optimisations est souvent traité dans la phase physique du cycle de vie. Les bases de données autres que orientées objet ne prennent qu’un seul paramètre de la phase conceptuelle, à savoir le dictionnaire de données. Rappelons que le modèle conceptuel exprime à la fois les besoins applicatifs et la connaissance du domaine sous une forme intelligible pour un utilisateur ultérieur. Malheureusement, c’est le modèle lo-gique qui est exploité; et celui-ci, résultant de la normalisation (dans le cas de bases de données relationnelles) et de l’adaptation au système support, est en général très différent du modèle conceptuel. Dans les bases de données orientées objets, les optimiseurs prennent en compte
les caractéristiques du modèle objet dans l’optimisation: les expressions de chemins, les grou-pages d’objets, les parcours de pointeurs, les index de chemins, et aussi les méthodes utilisateur [81]. La présence du modèle d’ontologie au sein d’un SGBD doit être prise en compte pour la conception physique. La Figure 2.2 illustre bien les phases de cycle de vie prises en compte par les deux types de bases de données: traditionnelles et sémantiques.
Phase Conceptuelle Besoins Phase Logique Phase de déploiement Phase Physique A B C D A1 B1 C1 D1 A2 B1 C2 D2 A3 B2 C1 D3
Base de Données Traditionnelle
Base de Données Sémantique
Figure 2.2 – Problème de conception physique dans les phases de cycle de vie
A partir de cette discussion, deux constats importants émergent: (i) la présence de l’ontolo-gie dans une base de données sémantique peut être exploitée pour offrir des optimisations et (ii) tout changement au niveau des phases du cycle de vie entraine automatiquement une nouvelle visite de la conception physique.
Dans ce chapitre, nous détaillons le processus de la conception physique à la fois dans le contexte des bases de données traditionnelles et sémantiques. Nous y exposons la probléma-tique, des exemples de structures d’optimisation ainsi que notre démarche de résolution dans le
cas desBDBO.