Anda di halaman 1dari 11

Optimisation des bases de données

par Anne DOUCET


Professeur, université Pierre-et-Marie-Curie (Paris-6)
Laboratoire d’informatique de Paris-6
et Hubert NAACKE
Maître de conférences, université Pierre-et-Marie-Curie (Paris-6)
Laboratoire d’informatique de Paris-6

1. Architectures des SGBD ........................................................................ H 3 702 - 2


1.1 Architecture client/serveur .......................................................................... — 2
1.2 Bases de données parallèles ...................................................................... — 2
1.3 Bases de données réparties........................................................................ — 3
1.4 Entrepôts de données ................................................................................. — 3
2. Modèle de données.................................................................................. — 3
2.1 Modèle relationnel....................................................................................... — 3
2.2 Modèles objet et objet-relationnel ............................................................. — 4
2.3 Modèle multidimensionnel......................................................................... — 4
2.4 Modèle semi-structuré XML ....................................................................... — 4
2.5 Modèle de données et optimisation .......................................................... — 5
3. Stockage des données............................................................................ — 5
4. Méthodes d’accès .................................................................................... — 5
4.1 Définition d’un critère de recherche ........................................................... — 5
4.2 Accès par identifiant.................................................................................... — 5
4.3 Parcours séquentiel ..................................................................................... — 6
4.4 Accès à des données triées......................................................................... — 6
4.5 Accès par index............................................................................................ — 6
4.6 Usage adéquat des méthodes d’accès ...................................................... — 8
5. Requêtes SQL ............................................................................................ — 8
5.1 Réécriture algébrique .................................................................................. — 8
5.2 Optimisation de requêtes basée sur le coût.............................................. — 8
5.3 Exécution du plan ........................................................................................ — 9
5.4 Optimisation des requêtes non SQL .......................................................... — 9
6. Transactions .............................................................................................. — 9
6.1 Contrôle de concurrence............................................................................. — 9
6.2 Performance du contrôle de concurrence ................................................. — 9
6.3 Performances des applications transactionnelles .................................... — 10
7. Conclusion ................................................................................................. — 11
Pour en savoir plus ........................................................................................... Doc. H 3 702

n système de gestion de bases de données (SGBD) s’évalue par ses


U performances et sa facilité d’usage. L’optimisation dans les SGBD, qui a
pour objectif de fournir aux utilisateurs un système optimal en termes de coût
et d’usage, est un aspect crucial des bases de données. Elle se situe à tous les
niveaux : lors de la conception de l’application, où le choix de l’architecture du
système, du modèle de données, des techniques de stockage et des méthodes
d’accès aux données jouent un rôle important tant sur le plan de l’usage que
sur celui de l’efficacité, et lors de l’utilisation où le temps de réponse aux
requêtes et le nombre de transactions par seconde représentent les critères
majeurs de performances.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 1
OPTIMISATION DES BASES DE DONNÉES ___________________________________________________________________________________________________

Pour évaluer les performances d’un système, il est nécessaire de définir des
métriques. Celles-ci s’appuient sur différents critères, en fonction du type
d’optimisation. Il peut s’agir par exemple du temps de réponse ou de l’expres-
sivité du langage pour les requêtes, de l’espace disque occupé et du temps de
parcours des données d’une relation pour le choix d’une technique de stoc-
kage, de la disponibilité des ressources ou de l’extensibilité du système
lorsqu’il s’agit d’une architecture.
Ce dossier est destiné aux lecteurs ayant une connaissance générale des
fonctionnalités des bases de données (modèle relationnel, SQL, transactions et
contrôle de concurrence). La lecture préalable des dossiers « Bases de don-
nées. Introduction » [H 3 800], « Bases de données relationnelles » [H 2 038] et
« Langages de bases de données : SQL et les évolutions vers l’objet » [H 3 128]
est recommandée.

1. Architectures des SGBD applications centralisées, gérant un volume de données relative-


ment peu important, de l’ordre de quelques gigaoctets. Centraliser
la gestion des données se révèle particulièrement intéressant pour
L’architecture d’un SGBD [H 2 918] définit sa structure, c’est-à-dire améliorer l’efficacité des accès disque et des requêtes, puisque l’on
l’organisation de ses différents composants. Il existe plusieurs archi- dispose sur le serveur de l’ensemble des informations nécessaires
tectures pour les SGBD, correspondant à des besoins différents. Le à l’optimisation de requêtes (statistiques, méthodes d’accès, etc.).
choix d’une architecture pour un SGBD peut avoir une influence Pour faire face à l’accroissement du volume des données à
forte sur l’exploitation du système, à savoir les temps de réponse, le traiter et du nombre simultané d’utilisateurs, plusieurs variantes de
débit des transactions, la disponibilité des données ou la fiabilité de l’architecture client/serveur ont été développées. Il est ainsi
la base en cas de panne. Il peut également avoir un impact sur la possible d’avoir plusieurs serveurs et de répartir les fonctionnalités
durée de vie du système, c’est-à-dire sur son évolution à long terme. du SGBD entre le client et les serveurs pour améliorer le débit des
L’optimisation consiste ici à adapter l’architecture du système aux transactions.
besoins des applications. Il s’agit d’obtenir les meilleures perfor- Bien que l’architecture client/serveur reste la mieux adaptée dans la
mances d’accès aux données, de faciliter l’usage du système aux plupart des cas, elle trouve ses limites avec l’accroissement du
utilisateurs et de répondre aux évolutions naturelles des besoins, volume des bases de données et la nécessité de gérer des ressources
des données, des usages et du matériel. Les critères principaux à stockées sur des sites distants. Les bases de données parallèles (§
prendre en compte sont donc le temps de réponse (nombre d’accès 1.2), les bases de données réparties (§ 1.3) et les entrepôts de
disque, coûts de communication), la disponibilité des données données (§ 1.4) sont des architectures offrant des solutions intéres-
(fréquence des défauts d’accès au serveur contenant les données), santes à ces problèmes.
la facilité de maintenance du système et son extensibilité.
Les différentes architectures des SGBD sont les suivantes :
— architecture client/serveur (§ 1.1) ; 1.2 Bases de données parallèles
— base de données parallèle (§ 1.2) ;
— base de données réparties (§ 1.3) ; Développées au début des années 1990, les bases de données
— entrepôt de données (§ 1.4). parallèles [H 2 068] ont pour objectif d’exploiter le parallélisme pour
la gestion des données, afin d’obtenir de bonnes performances, tout
en conservant une bonne disponibilité des données. Le principe est
1.1 Architecture client/serveur d’utiliser simultanément la puissance de plusieurs processeurs pour
exécuter les programmes des applications, en implémentant le
L’architecture client/serveur [H 2 728] est l’architecture opéra- SGBD sur plusieurs machines parallèles. Les architectures parallèles
tionnelle des SGBD la plus classique. Le serveur contient des res- diffèrent par le fait de partager ou non la mémoire et le disque de
sources (données et programmes), qu’il met à disposition des chaque machine.
clients, et les clients gèrent les aspects applicatifs. Clients et Dans l’architecture à mémoire partagée, chaque processeur a accès
serveurs communiquent via le réseau. Le client pose une requête à l’ensemble des mémoires et des disques des autres machines, via
au serveur, qui l’exécute, et renvoie la réponse. le réseau. Cette architecture est simple et permet d’équilibrer la
Ce type d’architecture présente de nombreux avantages, parmi charge. Toutefois, l’obligation de relier tous les processeurs à toutes
lesquels on peut citer la fiabilité et la robustesse des accès les mémoires coûte cher, la puissance globale de l’ensemble des pro-
sécurisés, la réutilisation de procédures, et la centralisation de cesseurs induit des conflits d’accès à la mémoire qui dégradent les
l’administration et de la gestion des données. Ce dernier point se performances et représente un frein à l’extensibilité de cette architec-
révèle particulièrement intéressant pour améliorer l’efficacité des ture, qui est limitée à une vingtaine de machines environ. Enfin, la
accès disque et des requêtes, puisque l’on dispose sur le serveur disponibilité des données n’est pas garantie en cas de défaillance de
de l’ensemble des informations nécessaires à l’optimisation (statis- mémoire.
tiques, méthodes d’accès, etc.). Dans l’architecture à disque partagés, seuls les disques sont par-
Dans sa forme la plus simple (plusieurs clients, un seul serveur), tagés. Les processeurs ont un accès exclusif à leur mémoire, ce qui
cette architecture est proche des architectures centralisées utilisées résout plusieurs inconvénients de l’architecture précédente : la solu-
pour les premiers SGBD, où les données et les applications se tion est plus économique (car elle limite les interconnexions),
trouvent sur une unique machine, et convient parfaitement aux l’architecture peut s’étendre à une centaine de processeurs (les

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


H 3 702 − 2 est strictement interdite. − © Editions T.I.
__________________________________________________________________________________________________ OPTIMISATION DES BASES DE DONNÉES

conflits d’accès aux données sur les disques peuvent être réduits L’optimisation d’une base de données répartie consiste, au
avec une mémoire cache suffisante) et les défauts de mémoire sont niveau de la conception, à répartir les données en fonction des
peu pénalisants puisqu’iIs n’affectent pas l’ensemble des machines. besoins de chaque site, et à définir des répliques en trouvant le
Ces avantages sont cependant contrebalancés par une plus forte meilleur compromis entre surcharge et efficacité. Une bonne répar-
complexité du système et par des baisses de performance pouvant tition s’évalue en fonction du rapport entre le nombre d’accès
provenir de l’utilisation de protocoles de verrouillage répartis et du distants (ad) et le nombre d’accès locaux ( a  ) réalisés sur chaque
maintien de la cohérence des copies, qui génèrent de nombreux site. Plus le rapport a d /a  est faible, meilleure est la répartition.
messages.
Répliquer une donnée est toujours efficace lorsque l’on accède à
Dans l’architecture sans partage, ni les mémoires, ni les disques la donnée en lecture. Le surcoût provient des mises à jour, qu’il
ne sont partagés. Cela permet de réduire les coûts, d’offrir une faut propager sur toutes les répliques de la donnée modifiée. Si n 
bonne disponibilité des données (par réplication des données) et est le nombre de lectures d’un donnée et n e le nombre d’écritures,
de mettre en parallèle des milliers de machines. Cependant, elle est la réplication de cette donnée est intéressante lorsque n  /n e > 1 .
plus complexe que les systèmes à mémoire partagée et l’équili- Lors de l’exploitation de la base, il est possible d’optimiser les
brage de charge est difficile à mettre en œuvre. Enfin, l’ajout d’une performances en répartissant les traitements sur les serveurs en
nouvelle machine implique de réorganiser la base de données. Plu- fonction de leur charge respective [2].
sieurs constructeurs de SGBD fournissent des outils d’aide à la
réorganisation de la base. Oracle RAC [1] en est un bon exemple.
L’architecture hiérarchique est une combinaison des architec- 1.4 Entrepôts de données
tures sans partage et des architectures à mémoire partagée. Le
principe est de construire une machine parallèle sans partage, dont Les entrepôts de données [H 3 870] ont été conçus pour les appli-
les nœuds sont des machines parallèles à mémoire partagée. Une cations d’aide à la décision, qui ont besoin d’accéder à l’ensemble
telle architecture permet d’allier l’extensibilité offerte par l’architec- des informations de l’entreprise sous un format adapté à la prise
ture sans partage à la souplesse et aux bonnes performances de de décision. Les décideurs ont en effet besoin de statistiques et
l’architecture à mémoire partagée. d’historiques sur les données de production, de regrouper des
Le choix d’une architecture dépend en premier lieu du volume informations, de combiner et comparer des données provenant de
des données à gérer et du nombre de processeurs. Pour une différentes bases de données de l’entreprise. Les données utiles à
configuration d’une dizaine de processeurs, l’architecture à mémoire l’aide à la décision sont nettoyées, transformées, calculées, regrou-
partagée est optimale. Lorsque le nombre de processeurs croît, la pées, organisées, avant d’être stockées dans l’entrepôt, qui est une
recherche du meilleur compromis entre performances, disponibilité base de données indépendante des sources de production.
des données et extensibilité dépend essentiellement des caractéris- Dans les entrepôts de données, deux aspects sont particuliè-
tiques de l’application. Cependant, il est important de noter que rement adaptés aux applications de l’aide à la décision. D’une part,
l’architecture sans partage est la plus utilisée, en raison de son fai- les données sont présentées aux analystes sous un format corres-
ble coût et de sa facilité d’extension à de nouvelles machines, pas pondant à leurs besoins, et de nombreux calculs (moyennes,
forcément homogènes. sommes, statistiques, tendances, etc.) sont déjà effectués. D’autre
part, puisque les analystes accèdent aux données en lecture seule-
ment, les attentes consécutives à la gestion de transactions sont
évitées. Les mises à jour des données s’effectuent périodiquement
1.3 Bases de données réparties par répercussion des mises à jour des sources, en profitant des
périodes de faible charge du système.
Les bases de données réparties [H 3 850] prennent en compte la
nécessité des entreprises à gérer des informations disséminées sur Les entrepôts de données peuvent gérer des bases de données
plusieurs sites. Dans un SGBD réparti, la base de données est très volumineuses (de l’ordre de plusieurs téraoctets) et sont conçus
perçue comme une base unique par l’utilisateur, mais les données pour supporter des augmentations importantes et rapides du
et les traitements sont répartis sur plusieurs serveurs, reliés par un volume de données. Par exemple, il est possible, pour avoir de
réseau. Les serveurs, qui correspondent généralement aux dif- meilleures performances, de créer des sous-ensembles de l’entrepôt
férents sites de l’entreprise, comportent chacun un SGBD qui gère (appelés datamarts) dédiés à un domaine d’application. Toutefois, la
les données locales et participe aux transactions globales. Les création de datamarts complique la gestion et la maintenance glo-
données peuvent être répliquées sur plusieurs sites pour assurer bale de l’entrepôt.
une meilleure disponibilité des données. Le contrôle de la base
reste centralisé, afin de garantir la cohérence de la base.
L’intérêt de la répartition est multiple. Cette architecture s’adapte
à la configuration des entreprises, en permettant à chaque site de
2. Modèle de données
l’entreprise de gérer localement ses propres données, tout en
conservant une gestion globale de la base. Une répartition adé- Dans une base de données, les données sont décrites à l’aide d’un
quate des données permet de réduire les transferts, diminuant modèle de données, qui propose une structure pour représenter les
ainsi le coût d’accès aux données. La réplication assure une bonne données, et un langage permettant de manipuler les données ainsi
résistance aux pannes et augmente la disponibilité des données. décrites. L’objectif d’un modèle de données est de permettre de
La présence de plusieurs serveurs permet d’équilibrer la charge du représenter les données du monde réel le plus simplement et le plus
système en répartissant les traitements sur les différents serveurs. fidèlement possible. Les différents modèles de données diffèrent
Enfin, cette architecture est facilement extensible, puisqu’il est essentiellement par leur adéquation aux besoins des applications.
possible d’ajouter un nouveau serveur au système sans créer de
perturbation majeure.
Les architectures réparties induisent naturellement un surcoût 2.1 Modèle relationnel
par rapport aux architectures centralisées. L’administration de la
base et le développement des applications sont plus complexes, la Le modèle relationnel est de loin le modèle le plus répandu. Créé
gestion des transactions et la présence de répliques (qui doivent au début des années 1970 pour les applications de gestion, il doit
rester cohérentes) nécessitent des échanges de messages entre les son succès à sa simplicité et à l’aspect déclaratif du langage de
différents serveurs. manipulation associé.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 3
OPTIMISATION DES BASES DE DONNÉES ___________________________________________________________________________________________________

Dans le modèle relationnel, les données sont représentées sous


forme de relations (des tables), composées d’attributs (les colonnes)
Ventes
et de nuplets (les lignes). Chaque nuplet décrit une donnée de façon
unique. Une relation représente un ensemble de données ayant la
34 25 27
même structure.
Les cinq opérateurs (sélection, projection, produit cartésien,
27
union, différence) de l’algèbre relationnelle permettent de relier les 25 18 21
données des relations et de les interroger. Ils constituent la base du
langage SQL (Structured Query Language) [H 3 128] devenu le 21
langage standard des SGBD relationnels (SGBDR) [H 2 038]. 33
Roller 25 18 21
En représentant les données dans des tables, le modèle relation-
nel a permis de rapprocher la structure informatique des données
de celle qui est utilisée dans les applications de gestion. Le pas- 5
2
sage à l’informatique des applications de gestion en a été grande- Produits VTT 13 15 5
ment facilité. L’utilisation d’un langage de requêtes déclaratif, qui Auvergne
permet d’interroger la base en décrivant le résultat qu’on veut
20
obtenir plutôt que la procédure nécessaire pour l’obtenir, a Régions
contribué à la popularité de ce modèle. 5 8 20
Surf Bretagne

Paul Léa Luc


2.2 Modèles objet et objet-relationnel
Vendeurs
Bien adapté aux applications de gestion, le modèle relationnel
trouve ses limites lorsque l’on sort de ce cadre où les données sont
de type simple. En effet, la structure de relation se révèle inadaptée Figure 1 – Cube de ventes de produits par vendeur et par région
pour modéliser les objets complexes, composés d’autres objets. Il
est difficile par exemple de représenter en relationnel une voiture
composée d’un moteur, de quatre roues et d’une carrosserie, Le modèle multidimensionnel, souvent appelé cube multidimen-
chacun de ces objets étant lui-même composé d’autres objets. sionnel, a été défini pour répondre aux besoins de l’analyse en
Le modèle objet s’appuie sur les concepts des langages à objets ligne et est essentiellement utilisé dans les entrepôts de données.
(objet, classe, héritage) pour modéliser les entités du monde réel. Il permet de visualiser les données dans plusieurs dimensions, de
Les entités sont représentées par des objets regroupés en classes. définir et ajouter des dimensions facilement, et de manipuler les
Un schéma de base de données objet est un ensemble de classes données efficacement.
organisées en hiérarchie. Une base de données multidimensionnelle est un hypercube dont
Un des points forts du modèle objet est sa puissance de modé- les axes sont les dimensions de l’analyse (par exemple, produit,
lisation. Les objets sont construits à l’aide de constructeurs région, vendeur, période), et les cellules contiennent des mesures cal-
(ensemble, nuplet, liste, tableau) qui s’appliquent à des objets ato- culées à l’aide de formules. La figure 1 représente un cube indiquant
miques (caractères, chaînes, entier, réel, booléen...) ou complexes, la somme des ventes de chaque produit par vendeur et par région.
indépendamment de leur type. Chaque objet a un identificateur Un ensemble d’opérateurs s’appliquant à un ou plusieurs cubes
d’objet (oid), géré par le système, qui l’identifie de manière unique. permet de visualiser les informations sous d’autres dimensions,
Il est ainsi possible de partager des objets et de faire des réfé- d’extraire des sous-ensembles d’un cube, de changer le niveau de
rences mutuelles. La notion d’objet complexe avec identificateur granularité (visualiser par exemple les données selon la hiérarchie
d’objet permet de représenter aisément les entités structurées jour ; mois ; année), de fusionner des cubes. Des extensions de SQL
et/ou composites des domaines tels que la CAO, la PAO, la bureau- pour l’OLAP (par exemple MDX de SQLServer [3] et la clause Model
tique ou la gestion de données multimédias, spatio-temporelles. d’Oracle [4]) permettent de définir des cubes et de les interroger.
Le modèle objet relationnel [H 3 270] résulte d’une intégration
des principaux concepts objets au relationnel, préservant ainsi la
compatibilité entre ces deux modèles. Le langage de requêtes asso- 2.4 Modèle semi-structuré XML
cié SQL3, standard de l’ISO (ISO/CEI 9075), est une extension de
SQL2. Les SGBD objet-relationnels représentent actuellement un La prise en compte des données du Web par les SGBD est un des
bon compromis pour gérer les applications manipulant des entités grands défis actuels des bases de données. En effet, toutes les
complexes, en alliant les bonnes performances des SGBD relation- techniques de gestion des données dans les SGBD s’appuient sur
nels à la puissance de modélisation des SGBD objets. l’existence d’un modèle de données, et plus particulièrement d’une
structure de données. Or, les données du Web qui sont très hété-
rogènes et fortement évolutives ne peuvent être modélisées par les
modèles de données existants, trop rigides et qui ne permettent
2.3 Modèle multidimensionnel pas de gérer aisément l’évolution des données du Web.
Les besoins de l’analyse en ligne (OLAP : on line analytical Les modèles de données semi-structurés ont été développés
processing) sont différents de ceux de l’OLTP (on line transaction dans les années 1990 pour répondre à ces besoins. Génériques et
processing). Les décideurs ont besoin de données agrégées à extensibles, ils permettent de modéliser toutes les informations
différents niveaux de granularité, historisées et dont la structure sous un format unique, et s’adaptent aux évolutions.
peut évoluer. Ils désirent aussi accéder aux données selon leur XML (eXtensible Markup Language) [H 3 500] est un standard
centre d’intérêt (produits, clients, vendeurs). En d’autres termes, ils développé par le World Wide Web Consortium (W3C) pour
doivent pouvoir appréhender, visualiser et manipuler les données l’échange et la représentation de données. Il permet de représenter
selon les dimensions qui leur sont naturelles. Il est rapidement les documents sous forme d’éléments balisés imbriqués. Un
apparu que le modèle relationnel, qui donne une vue aplatie de élément, délimité par des balises (étiquettes) définies par l’utili-
structures naturellement multidimensionnelles, n’est pas adapté à sateur, peut être vide, contenir du texte, ou tout autre élément. Un
l’OLAP. document complet est un arbre d’éléments imbriqués.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


H 3 702 − 4 est strictement interdite. − © Editions T.I.
__________________________________________________________________________________________________ OPTIMISATION DES BASES DE DONNÉES

La représentation par balises offre une grande souplesse de modé- zones de plusieurs pages, et donc de blocs contigus, qui serviront
lisation. Elle permet de modéliser des données ayant des structures par la suite à stocker les données qui sont lues ensemble. Cette
irrégulières, partielles, comme les modèles semi-structurés. fonctionnalité est essentielle pour organiser les données selon une
De nombreux standards ont été développés autour d’XML structure particulière (arbre ou table de hachage, § 4). Cependant, la
[H 7 404] pour définir les structures des documents (DTD et suppression des données libère des blocs quelconques, ce qui
XShema), pour naviguer dans les documents (XPath), les interroger provoque des « trous » dans l’espace de stockage. Le recyclage des
(XQuery), les présenter (XSLT [H 7 160]) . L’ensemble de ces stan- espaces libérés permet de réduire l’espace total qu’occupe la base
dards permet désormais de gérer de véritables bases de données de données sur le disque, mais peut éloigner des blocs qui sont lus
XML, ouvrant ainsi les données du Web au monde des bases de ensemble. Une réorganisation des données a posteriori améliore
données [H 3 502]. Les données XML pouvant être stockées dans généralement le placement des données sur le disque.
des relations, le modèle de données XML est désormais souvent dis- Lorsque plusieurs applications consultent simultanément la base
ponible dans les SGBD relationnels. Il peut ainsi servir de modèle de données, l’accès au disque peut être congestionné. L’augmenta-
d’échange entre bases de données sans entraîner de modifications tion du temps de réponse d’une requête est proportionnelle au
des structures de stockage, par exemple en échangeant les données nombre de requêtes simultanées, dans le cas défavorable où les
par l’intermédiaire de services Web. requêtes effectuent principalement des accès au disque plutôt que
des traitements en mémoire. Dans cette situation, il est conseillé de
répartir les accès sur plusieurs disques afin d’offrir à chaque appli-
2.5 Modèle de données et optimisation cation un débit en lecture plus élevé. Les SGBD commerciaux dis-
posent d’outils semi-automatiques pour diagnostiquer la congestion
Le choix du modèle de données a essentiellement des répercus- des accès au disque et répartir les données sur un groupe de
sions sur l’usage d’une application, en aidant l’utilisateur à mieux disques (voir Automatic Storage Management – ASM-d’Oracle 10g).
appréhender ses données. Modéliser et visualiser les données d’une
application telles qu’elles sont perçues dans la réalité simplifie leur
utilisation et leur manipulation et permet d’en tirer un plus grand
profit. 4. Méthodes d’accès
Quel que soit le modèle de données utilisé, les données sont
stockées dans des fichiers. Les techniques de stockage et les Une base de données possède un schéma qui définit les ensem-
méthodes d’accès présentées dans la suite sont donc applicables bles d’objets contenus dans la base. En particulier, le schéma d’une
à tous les modèles présentés. En revanche, chaque modèle de base de données relationnelle définit des relations qui sont des
données a un langage de requêtes associé, qui peut nécessiter des ensembles de nuplets. La consultation de la base demande l’accès
optimisations spécifiques. à un ou plusieurs nuplets. On appelle « méthode d’accès » les
divers moyens pour retrouver des données stockées dans la
base [5]. Les méthodes d’accès forment la couche élémentaire pour
lire la base, elles sont utilisées par le moteur de requêtes SQL (§ 5).
3. Stockage des données
Les données sont stockées durablement dans une mémoire de
4.1 Définition d’un critère de recherche
masse, généralement un disque dur (voir Périphériques de stoc-
Dans un SGBD relationnel, une requête SQL [H 3 128] se traduit
kage magnétique et optique [H 1 258]). Les données sont rangées
par un accès aux nuplets. Un critère de recherche précise quelle doit
sur des pistes circulaires concentriques découpées en plusieurs
être la valeur d’un attribut pour les nuplets retrouvés, en indiquant
secteurs. Un bloc est formé de plusieurs secteurs contigus de la
une valeur ou une plage de valeurs possibles. Un critère correspond
même piste et correspond à la quantité élémentaire d’information
à la clause WHERE d’une requête SQL. Il s’exprime sous la forme
pouvant être lue ou écrite en une seule opération. La taille d’un
d’une composition logique de prédicats simples. Les trois opéra-
bloc, généralement 4 ko, est fixée lors du formatage du disque et
teurs de composition sont le « et », le « ou » et le « non » logiques.
est indépendante des spécificités de la base de données.
Un prédicat simple est constitué de trois termes : un nom d’attribut
Le temps d’accès à un bloc quelconque dépend de la durée de suivi d’un opérateur de comparaison (inférieur, égal, supérieur),
déplacement radial de la tête de lecture vers la piste, de la rotation suivi d’une valeur (par exemple, durée < 6). L’opérateur LIKE permet
du disque jusqu’à ce que le premier secteur à lire soit placé sous de tester la correspondance entre un attribut textuel et un motif
la tête et du temps de lecture des secteurs. Les performances d’un décrivant la partie commune d’un ensemble de mots (par exemple,
disque dur se mesurent avec deux valeurs : la latence correspond prénom LIKE ‘an%’ est vrai pour tous les abonnés dont le prénom
au temps moyen de déplacement de la tête de lecture vers une commence par an tels que anémone ou anatole, mais pas jean).
page quelconque, et le débit correspond au nombre de blocs
Lorsque le critère de recherche est suffisamment précis, seule-
consécutifs pouvant être lus en une unité de temps.
ment un ou quelques nuplets sont retrouvés. Dans ce cas, le critère
Pour accéder rapidement à des données stockées sur plusieurs est qualifié de sélectif. La sélectivité d’un critère est le rapport entre
blocs, il est important que ces blocs soient proches entre eux. le nombre de nuplets qui satisfont le critère et le nombre total de
L’accès à des blocs consécutifs est rapide car la tête est déjà bien nuplets concernés. Par exemple, si parmi les 1 000 nuplets de la
positionnée en fin de chaque bloc pour lire le bloc suivant. Le gain relation Modules (présentée dans [H 3 128], § 2) seulement 50 ont
obtenu peut être d’un facteur 10 par rapport à la lecture de blocs une durée supérieure à 6 mois, alors la sélectivité du critère
dispersés aléatoirement sur le disque. Module.durée > 6 vaut 5 %.
Le module de gestion de l’espace disque manipule des données
organisées en pages. Une page correspond généralement à un seul
bloc de disque afin d’accéder à une page en une seule opération. 4.2 Accès par identifiant
Le rôle du gestionnaire consiste à trouver un espace libre sur le
disque pour stocker une nouvelle page, et à libérer l’espace occupé La première méthode d’accès, appelée accès par identifiant,
par une page supprimée. Il est important, pour accélérer l’accès, consiste à retrouver une donnée pour laquelle on connaît la locali-
que les pages lues fréquemment ensemble soient stockées dans sation dans la base, notamment son numéro de page, son rang
des blocs consécutifs. Or, les données sont rarement insérées dans dans la page et son emplacement précis sur le disque. Dans ce cas,
l’ordre des accès ultérieurs. Ainsi, le gestionnaire peut réserver des l’accès est directement traité par le gestionnaire de la mémoire

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 5
OPTIMISATION DES BASES DE DONNÉES ___________________________________________________________________________________________________

vive qui vérifie la présence en mémoire de la page en question. Si par matière). Les requêtes fortement sélectives retrouvant un seul
la page n’est pas déjà en mémoire, le gestionnaire du disque lit la nuplet (par exemple, retrouver un étudiant à partir de son numéro)
page résidant sur le disque. La donnée est finalement extraite de ne sont pas prises en compte pour choisir la clé de tri. En effet,
la page. l’accès au résultat de ce type de requête entraîne la lecture d’une
L’efficacité de l’accès dépend de la nature des informations iden- seule page, que les données soient triées ou non.
tifiant la donnée. On distingue deux types d’identifiants. L’identi-
fiant dit physique est formé des coordonnées de la page sur disque 4.4.2 Impact du tri sur la mise à jour de la base
et du rang de la donnée dans la page. Il permet un accès rapide à
la donnée en une seule opération de lecture sur le disque. Mais il Le tri des données sur disque doit tenir compte des mises à jour
doit être modifié lorsque la donnée est déplacée vers une autre de la base de données. Initialement, il faut prévoir un espace
partie du disque (un autre disque ou une autre base), ce qui peut suffisant pour insérer de nouveaux nuplets à côté des nuplets
ralentir les opérations de réorganisation des pages sur le disque. répondant au même critère. Toutefois, si l’espace prévu initiale-
L’identifiant dit logique est un numéro unique attribué à chaque ment pour un groupe de nuplets, est plein, il n’est pas possible
nouvelle donnée. Il est indépendant de l’emplacement réel de la d’ajouter un nouveau nuplet juxtaposé aux autres. Cette situation
donnée dans la base. Par conséquent, une structure auxiliaire doit s’appelle un débordement. Il faut alors allouer un espace supplé-
être maintenue dans la base pour associer l’identifiant logique mentaire non contigu au premier, au détriment de l’objectif de
avec la localisation de la donnée. Ainsi, la réorganisation des don- proximité. Une autre solution consiste à réorganiser entièrement la
nées sur le disque et le déplacement de la base sont plus rapides base de données afin d’agrandir l’espace insuffisant, mais cela
car seule la structure auxiliaire doit être ajustée sans modification peut nécessiter le déplacement de la majeure partie des données,
des identifiants logiques. Cependant, l’accès à une donnée néces- par un effet de dominos, ce qui nuit à la disponibilité du système.
site de lire la structure auxiliaire avant de lire la donnée, ce qui Une telle solution est envisageable occasionnellement pendant
peut ralentir fortement l’accès. Par exemple, s’il faut 3 lectures une opération de maintenance, hors période d’utilisation.
pour traverser la structure auxiliaire, l’accès est 4 fois plus lent. Ainsi, deux objectifs s’opposent : d’une part, prévoir initialement
Toutefois, le ralentissement est moindre lorsque la structure auxi- suffisamment d’espace libre afin de limiter les débordements et la
liaire peut être chargée en mémoire. réorganisation complète des données, d’autre part limiter la taille
L’accès par identifiant demande de connaître au préalable la totale de la base de données. La taille de l’espace libre initial est le
localisation de la donnée recherchée. Or, la plupart des résultat d’un compromis entre ces deux objectifs ; sa valeur sera
consultations ne précisent pas l’identifiant de la donnée mais les d’autant plus satisfaisante que la fréquence des mises à jour est
critères que doit satisfaire la donnée. Cela nécessite d’autres connue avec précision. Dans le cas particulier où les données sont
méthodes d’accès plus évoluées qui retrouvent directement les triées selon la date d’insertion des nuplets dans la base, l’ajout de
données souhaitées ou au moins leur identifiant afin de procéder données ne pose aucun problème de débordement.
ensuite à un accès direct (voir l’accès par index secondaire, § 4.5). Après avoir trié les données sur disque, l’accès à un groupe précis
s’effectue rapidement grâce aux index.

4.3 Parcours séquentiel


4.5 Accès par index
Pour obtenir le résultat d’une requête, il est possible de parcourir
séquentiellement l’ensemble des nuplets de la relation en ques- Un index permet une recherche multicritères rapide dans la base
tion, puis de filtrer ceux qui satisfont le critère de la requête. Cette de données. Il offre un accès direct aux nuplets possédant des
méthode est appelée « parcours séquentiel » d’une relation. Sa valeurs communes, et seulement ceux-ci, sans lire inutilement
performance dépend de la proximité des pages contenant les aucun autre nuplet. La partie commune peut être constituée de plu-
nuplets sur le disque et de la sélectivité du critère. Le parcours sieurs attributs (par exemple, tous les modules de matière
séquentiel est approprié lorsque le critère est peu sélectif (sélecti- « informatique » et dont la durée est 6 mois).
vité entre 30 % et 100 %) car le résultat de la requête contient une
grande portion des nuplets.
4.5.1 Propriété et structure d’un index
L’index est une structure auxiliaire faisant référence à des nuplets
4.4 Accès à des données triées mais sans les contenir entièrement : il fournit une liste de numéros
de nuplets, à partir d’une valeur d’attribut donnée. Cet attribut est
Une autre méthode consiste à organiser les données de façon appelé clé de l’index. La structure d’un index est conçue pour loca-
adéquate pour retrouver rapidement le résultat d’une requête sans liser très rapidement les données pertinentes. Par exemple, il est
lire tous les nuplets de la relation concernée par la requête. Les possible de retrouver un étudiant précis, parmi une collection de
nuplets qui satisfont un même critère doivent être proches sur plusieurs millions d’étudiants, en lisant moins de trois pages.
disque afin de lire des pages contiguës. L’objectif principal du tri Un index dont la clé est identique à celle du tri des données sur
est d’améliorer la proximité des nuplets satisfaisant le même disque, est qualifié de plaçant car il retrouve des nuplets « placés »
critère. au même endroit sur le disque ; les autres index sont dits non
plaçants ou secondaires. Afin d’améliorer la recherche des nuplets
d’une relation selon différents critères, il peut exister plusieurs
4.4.1 Choix de la clé de tri index par relation, mais un seul est plaçant. Un index plaçant
Les nuplets peuvent être triés selon une clé composée d’un ou apporte plus d’efficacité car les nuplets à retrouver sont regroupés
plusieurs attributs. Le choix de la clé de tri dépend des applications sur le disque. Ce n’est pas le cas avec un index non plaçant pour
interrogeant la base de données et en particulier de leurs requêtes. lequel les nuplets à retrouver sont dispersés sur un plus grand
Un recensement des requêtes les plus fréquentes permet de choisir nombre de pages (dans le pire des cas, un seul nuplet pertinent par
une clé de tri pour chaque relation (par exemple, les modules sont page).
triés par matière). Lorsqu’une requête interroge au moins deux La structure élémentaire composant un index est un couple,
relations, les relations en question peuvent être triées ensemble appelé entrée, qui associe une clé (c’est-à-dire la valeur d’un ou
selon leurs attributs communs (par exemple, les spécialités sont plusieurs attributs) avec les identifiants de nuplets correspondants.
triées par matière). Cela facilite les opérations de jointure entre Par exemple, une entrée de l’index des matières associe chaque
relations (par exemple, trier ensemble les modules et les spécialités matière avec la liste des modules de la matière.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


H 3 702 − 6 est strictement interdite. − © Editions T.I.
__________________________________________________________________________________________________ OPTIMISATION DES BASES DE DONNÉES

Tableau 1 – Usage des méthodes d’accès selon les requêtes


Type de requête Méthode d’accès préconisée
4 7 9
Requête avec un seul prédicat Table de hachage ou arbre
Index d’égalité équilibré
Requête avec un seul prédicat Arbre équilibré
d’inégalité numérique (ex.
1 2 4 5 7 8 9 10 Modules.durée < 3) ou
un seul prédicat précisant le
préfixe d’une chaîne de
caractères (ex. Module.Libellé
like ‘Info%’)
Données
Requête multicritères dont les Matrice binaire si le domaine
attributs ont un domaine est des attributs est petit (une
Les modules durant 10 semaines
discret centaine de valeurs).
Requête multicritères lorsque le Index composé de plusieurs
Figure 2 – Exemple d’arbre équilibré domaine des attributs est infini arbres équilibrés imbriqués
(ex. les nombre réels)
Requête ciblée dont la réponse Index non plaçant
Afin de retrouver rapidement une entrée, étant donné une contient un seul nuplet
certaine clé, il existe principalement trois façons d’organiser les
entrées : en arbre, en table ou en matrice [6]. Requête avec tri (order by X ) ou Index plaçant si la clé de l’index
de regroupement (group by X ) contient les attributs de tri ou
regroupement (X ).
4.5.2 Arbre équilibré Requête de jointure naturelle Index plaçant
entre deux relations
La plupart des SGBD dispose d’index en arbre équilibré ou arbre
B (B tree pour balanced tree). De nombreuses variantes de l’arbre
équilibré existent pour indexer efficacement divers types de données
(par exemple, l’arbre R pour les données multidimensionnelles). l’entrée recherchée. Dans une table de hachage, les entrées ne sont
pas triées selon la valeur d’un attribut ; elles sont organisées en
L’ensemble des entrées est scindé en sous-listes, de la taille
compartiments (buckets), chacun de la taille d’une page. La fonction
d’une page, qui forment les feuilles de l’arbre. Le problème se
de hachage transforme une valeur de l’attribut indexé en une valeur
réduit alors à retrouver rapidement une feuille à partir d’une valeur
entière (inférieure ou égale au nombre de compartiments) repré-
de clé. Pour cela la liste des couples [clé de la première entrée de
sentant un indice de compartiment. De plus, un vecteur appelé
la feuille, numéro de la feuille] est construite ; elle est plus petite
répertoire, associe l’indice d’un compartiment avec son identifiant
que la liste précédente mais contient suffisamment d’information
(c’est-à-dire l’information de localisation du compartiment).
pour retrouver un numéro de feuille, quelle que soit la clé. Cette
liste est également scindée en sous-listes, de la taille d’une page, Pour plus d’efficacité, les techniques de hachage linéaire ou
qui forment un niveau intermédiaire au-dessus des feuilles. Puis, le dynamique minimisent le nombre de compartiments tout en assu-
procédé est réitéré, ainsi de suite, jusqu’à obtenir une liste, tenant rant que toutes les entrées tiennent dans l’index. Ces techniques
sur une seule page, qui forme la racine de l’arbre. L’arbre est dit nécessitent l’ajustement dynamique de la taille du répertoire et
équilibré car la distance de la racine à une feuille quelconque est donc de la fonction de hachage.
constante. La figure 2 illustre l’exemple d’un arbre pour indexer les
nuplets de la relation Modules selon les valeurs de l’attribut durée
(pour plus de clarté la taille des sous-listes a été volontairement 4.5.4 Matrice binaire
réduite à 2 ou 3 entrées).
Une matrice binaire (bitmap index) permet de dénombrer ou de
Dans le cas d’un index plaçant (les données sont triées sur le retrouver rapidement des nuplets, spécialement lorsque le critère
disque selon la clé de l’index), l’ensemble des entrées peut être de recherche porte sur des attributs dont le domaine est de petite
réduit à une seule entrée par page de données. L’index ainsi taille (quelques centaines de valeurs distinctes).
compacté est qualifié de non dense car il ne contient pas toutes les
La matrice est un tableau à deux dimensions. Les colonnes corres-
entrées. Pour retrouver une entrée non incluse dans l’index, il suffit
pondent aux valeurs des attributs de la clé de l’index. Par exemple,
d’accéder à la page contenant la plus grande entrée inférieure à
l’index sur l’attribut durée de la relation Spécialité contiendra 4
l’entrée recherchée. En revanche, un index non plaçant est obliga-
colonnes nommées « durée=1 », « durée=3 », « durée=6 » et
toirement dense car deux entrées ayant des valeurs de clé
« durée=9 » si les valeurs possibles pour la durée d’un module sont
consécutives ne correspondent pas à des données stockées au
seulement 1, 3, 6 et 9 mois. Une ligne de la matrice correspond à un
même endroit.
nuplet, une case de cette ligne vaut 1 lorsque sa colonne est égale
En pratique, l’accès par un arbre équilibré s’avère très rapide car à la valeur de l’attribut indexé. Par exemple, un module durant 3
la hauteur de l’arbre est généralement inférieure à 4. En effet, un mois correspond à la ligne [0, 1, 0, 0] où le 1 correspond à la colonne
nœud de l’arbre peut contenir de nombreuses valeurs de clés « durée=3 ». Une colonne supplémentaire contient généralement
(environ 100 valeurs pour un nœud de 8 ko). Cela permet d’indexer l’identifiant du nuplet (sauf si le rang suffit pour identifier un nuplet).
plusieurs millions de nuplets avec un arbre ayant un seul niveau Ce type d’index offre l’avantage d’être très compact, du fait de son
intermédiaire entre la racine et les feuilles. Ainsi, il suffit de lire 3 contenu binaire. Par exemple, un index avec 256 colonnes et pour un
nœuds pour retrouver une feuille depuis la racine. (0) million de nuplets tient dans un espace de 1 Mo.
Ce type d’index présente tout son intérêt lorsque la clé de l’index
4.5.3 Table de hachage est composée de plusieurs attributs. Dans ce cas, une recherche
multicritères (c’est-à-dire à plusieurs prédicats reliés par les
Une table de hachage permet de retrouver directement une entrée mots-clés and ou or ) est évaluée très rapidement par des opéra-
au moyen d’une fonction de hachage qui donne la localisation de tions logiques élémentaires entre les colonnes de la matrice.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 7
OPTIMISATION DES BASES DE DONNÉES ___________________________________________________________________________________________________

4.6 Usage adéquat des méthodes d’accès


Base Arbre algébrique
Pour obtenir de bonnes performances, il est important de choisir
judicieusement des méthodes d’accès en adéquation avec les trai- Professeur (Mat, Grade)
Modules (Sigle, Libellé, Durée, Mat) projection :
tements (requêtes et mise à jour) produits par l’application. Nous Libellé
récapitulons dans le tableau 1 les méthodes les plus appropriées Requête :
en fonction de la nature des requêtes.
SELECT Libellé
De plus, lors de la création des index, il faut prendre en compte jointure :
FROM Professeur p, Modules m
la pénalité subie par les opérations de mise à jour des données. En p. Mat = m. Mat
effet, la création de trop nombreux index ralentit fortement les WHERE Grade = ’A’
mises à jour car elles doivent maintenir l’index. Finalement, des AND Durée = 3
AND p. Mat = m. Mat sélection : sélection :
outils d’aide à l’optimisation des index analysent l’historique des Grade = ’A’ Durée = 3
requêtes traitées par le SGBD et énoncent des recommandations
pour l’administrateur de la base de données : création, suppres-
sion, réorganisation d’un index (voir par exemple SQLAccess Professeur Modules
Advisor d’Oracle ou Database Engine Tuning Advisor – alias lndex
Tuning Wizard – de SQL Server).
Figure 3 – Arbre algébrique d’une requête

Chaque opérateur possède des opérandes qui sont soit une rela-
5. Requêtes SQL tion de la base de données, soit un autre opérateur. La requête
devient un arbre d’opérateurs dont les feuilles sont les fichiers où
sont stockées les relations. L’opérateur racine représente le dernier
Une requête SQL correspond à une série d’opérations sur la base.
traitement à effectuer afin d’obtenir le résultat de la requête. Par
Le moteur de requêtes (query engine) reçoit une requête provenant
exemple, la figure 3 montre une requête SQL et son arbre algé-
de l’application. Cette requête est déclarative, c’est-à-dire qu’elle ne
brique associé. Dans cet exemple, on fait d’abord la sélection des
dit pas quelles opérations effectuer ni dans quel ordre. Elle est tout
professeurs de grade A et celle des modules durant 3 mois. Puis on
d’abord transformée en un programme impératif qui sera ensuite
fait la jointure entre les deux relations résultantes, telle que la
exécuté pour calculer le résultat de la requête. Le programme
matière enseignée par le professeur corresponde à la matière du
correspondant à la requête est appelé plan d’exécution. Plusieurs
module, c’est-à-dire que chaque module est relié à son professeur.
étapes sont nécessaires pour obtenir un plan d’exécution.
Finalement, on projette sur l’attribut libellé pour n’afficher que le
Dans un premier temps, la syntaxe de la requête SQL est véri- libellé des modules.
fiée. La requête doit être conforme à la grammaire du langage
Les expressions algébriques sont à leur tour restructurées grâce
SQL. Les noms des relations mentionnés dans la clause FROM doi-
à des règles d’équivalence fondées sur les propriétés de l’algèbre
vent correspondre à une relation de la base de données. Les noms
relationnelle telles que la commutativité, l’associativité ou la distri-
d’attributs se trouvant dans les autres clauses (SELECT, WHERE,
butivité entre opérateurs. Par exemple, une union de deux relations
ORDER BY et GROUP BY) doivent correspondre à un attribut d’une
suivie d’une sélection équivaut à deux sélections suivies d’une
relation, sans ambiguité. La concordance des types est vérifiée
union. Les expressions algébriques équivalentes sont potentielle-
pour chaque prédicat, par exemple, prix < 9,5 n’est pas correct si
ment très nombreuses, mais seules quelques-unes pourront s’éva-
l’attribut prix est un nombre entier.
luer rapidement. Il s’agit de repérer celles qui aboutiront à un
Les noms de vues apparaissant dans la clause FROM sont rem- traitement efficace de la requête. Pour cela, les règles sont appli-
placés par leur définition en SQL. Plusieurs substitutions de vues quées dans un ordre pertinent traduisant des méthodes heuristi-
s’enchaînent en cascade lorsqu’une vue est définie en fonction ques. Une heuristique souvent utilisée repose sur l’hypothèse que
d’une autre vue, pour aboutir finalement à une requête SQL com- plus les données que traite un opérateur sont petites, plus l’exécu-
posée de plusieurs imbrications de clauses. Par exemple, la clause tion sera rapide. Or, un moyen de réduire la taille des données est
SELECT de la requête suivante contient une autre clause SELECT : de les filtrer à travers des sélections et des projections. En consé-
quence, afin de traiter en premier les opérations les plus réductrices,
select Libellé les sélections et projections sont rapprochées des feuilles de l’arbre
from Module d’opérateurs. L’usage exclusif de méthodes heuristiques a montré
where durée = (select max(durée) ses limites lorsque les requêtes sont complexes et accèdent à plu-
from Module) sieurs relations. Par exemple, pour une requête contenant une join-
ture, il n’est pas toujours judicieux de traiter une sélection en
priorité si cela empêche l’usage d’un index pour la jointure.
Puis la requête SQL est simplifiée de manière à obtenir une
requête SQL constituée de plusieurs expressions simples qui sont
des blocs formés d’une seule clause SELECT et FROM. Les blocs 5.2 Optimisation de requêtes basée
indépendants des autres sont repérés car ils pourront être évalués sur le coût
séparément. En revanche, deux blocs corrélés seront traités
itérativement ; le bloc englobant détermine les valeurs nécessaires Dans la plupart des SGBD, l’estimation du coût relatif pour traiter
pour évaluer le bloc imbriqué. une expression permet de ne retenir que les expressions présu-
Nota : une vue (view ) est une relation « virtuelle » définie par un nom et une requête mées comme les moins coûteuses. On appelle cette méthode l’opti-
SQL. misation de requêtes basée sur le coût. Le modèle de coût doit être
suffisamment précis pour prendre en compte la complexité de
chaque algorithme utilisé pour traiter un opérateur. Par exemple,
5.1 Réécriture algébrique une jointure par boucles imbriquées a un coût différent d’une join-
La requête est ensuite transformée en une expression algébrique ture par tri et fusion, les sélections par index ou par lecture séquen-
constituée d’opérateurs (par exemple, les opérateurs de sélection, tielle n’ont pas le même coût. Ainsi, pour chaque opérateur de
projection, jointure, union, tri ou regroupement). l’arbre, un algorithme de coût minimal est choisi. L’arbre est alors
Nota : les opérateurs ne sont pas seulement ceux de l’algèbre relationnelle définis dans appelé plan d’exécution car toutes les informations nécessaires au
Bases de données relationnelles [H 2 038] (§ 3). traitement de la requête sont réunies [7].

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


H 3 702 − 8 est strictement interdite. − © Editions T.I.
__________________________________________________________________________________________________ OPTIMISATION DES BASES DE DONNÉES

5.2.1 Directives d’optimisation et extensibilité ralentissement ou un empêchement de valider. Par la suite, nous
présentons les mécanismes qui contrôlent les accès concurrents à
L’optimiseur de requêtes est un module logiciel éprouvé et très la base de données et leur impact sur les performances.
efficace. Dans la majorité des cas, le plan d’exécution déterminé
par l’optimiseur a des performances satisfaisantes, mais parfois ce
plan n’est pas optimal à cause de certaines particularités des 6.1 Contrôle de concurrence
données. L’utilisateur averti peut alors influencer la décision prise
par l’optimiseur, en complétant sa requête SQL avec des directives
Dans un contexte multiutilisateurs, le SGBD doit contrôler les
d’optimisation. Il peut indiquer par exemple quels sont les index à
accès concurrents aux données afin de préserver la cohérence de
utiliser en priorité, dans quel ordre effectuer les accès à la base ou
la base : il garantit qu’aucune transaction ne vienne corrompre la
quels algorithmes de jointure utiliser.
base. On distingue principalement deux techniques de contrôle de
Le langage SQL permet à un utilisateur de définir ses propres concurrence : d’une part le verrouillage en deux phases et d’autre
fonctions et de les utiliser dans une requête. Lorsque la requête part le verrouillage couplé avec de l’estampillage.
SQL contient les appels de fonctions définies par l’utilisateur, l’opti-
miseur a besoin de connaître le coût de telles fonctions afin d’esti-
mer le coût total de la requête. C’est pourquoi certains SGBD 6.1.1 Verrouillage en deux phases
proposent aux utilisateurs de spécifier conjointement le coût de
leurs fonctions, ce qui améliore l’optimisation qui est alors quali- Deux types de verrous sont utilisés pendant le traitement des
fiée d’extensible. instructions SQL. Une requête demande un verrou partagé pour
chaque nuplet à lire. Une mise à jour demande un verrou exclusif
pour chaque nuplet à modifier. Une transaction conserve tous les
verrous obtenus jusqu’à ce qu’elle se termine, afin d’empêcher
5.3 Exécution du plan qu’une autre transaction lise ou écrase les modifications de la tran-
saction qui n’est pas encore validée.
L’ultime étape de l’évaluation de requêtes consiste à traiter le
plan d’exécution pour fournir le résultat de la requête à l’utilisateur.
L’accès aux nuplets se fait soit en parcourant séquentiellement les 6.1.2 Verrouillage avec estampillage
relations, soit au moyen d’index. Puis les nuplets transitent à tra-
vers les opérateurs du plan d’exécution pour être filtrés, composés Seule une mise à jour demande un verrou exclusif avant chaque
et triés jusqu’à obtenir le résultat final. écriture d’un nuplet. Une requête ne demande aucun verrou. Une
transaction conserve ses verrous exclusifs jusqu’a ce qu’elle se ter-
Lorsqu’une application pose fréquemment la même requête, le mine. Chaque transaction est estampillée avec la date de début de
plan d’exécution prêt à l’emploi peut être conservé dans le SGDB son exécution. Chaque nuplet est estampillé avec la date de la vali-
pour être réutilisé directement par la suite. Or, le contexte d’exécu- dation la plus récente. La transaction ne lit que des données dont
tion peut varier fortement entre deux instants, par exemple, un l’estampille est inférieure à la sienne. Si une donnée a une estam-
plan efficace à un instant peut ne plus l’être une heure après si la pille supérieure (elle a été modifiée et validée après le début de la
quantité de mémoire disponible a fortement baissé à cause de transaction), le système reconstruit la valeur antérieure à l’aide du
l’arrivée de nombreux utilisateurs. Certains SGBD produisent un journal (rollback segment). Le SGBD autorise une écriture lorsque
plan d’exécution capable de s’adapter au contexte courant. L’opti- le verrou exclusif est obtenu et si l’estampille de la donnée est infé-
misation devient dynamique pendant l’exécution, ce qui s’avère rieure à celle de la transaction. Sinon, il refuse l’écriture.
intéressant dans un contexte très instable où les ressources dispo-
nibles (mémoire et processeur) sont imprévisibles. Cette technique garantit qu’une lecture est cohérente par rapport
aux données validées avant le début de la transaction. Elle est aussi
appelée isolation par cliché (snapshot isolation) car la base de
données semble s’être figée au commencement de la transaction.
5.4 Optimisation des requêtes non SQL
Certains SGBD peuvent gérer des données non relationnelles, par
exemple des données XML. Ils fournissent le langage de requêtes 6.2 Performance du contrôle
XQuery dédié aux données XML, et différent de SQL. Une solution de concurrence
répandue pour traiter des requêtes XQuery consiste à traduire la
requête XQuery en SQL afin de bénéficier de l’optimisateur SQL. Les deux techniques décrites ci-avant offrent aux transactions
Une autre solution est d’optimiser directement la requête XQuery en une image parfaitement cohérente de la base. Cependant, le ver-
s’appuyant sur l’algèbre XQuery plus riche que l’algèbre relation- rouillage en deux phases offre des performances moindres car les
nelle. Cela permet de minimiser le coût des opérations spécifiques situations d’attente sont plus fréquentes. En effet, les verrous par-
à XQuery telles que la navigation en profondeur dans un arbre d’élé- tagés, que détient une requête, bloquent toute transaction voulant
ments XML. modifier les données lues par cette requête. De même, une tran-
saction en cours d’exécution empêche toute requête de lire les
données que la transaction modifie.
La deuxième technique évite qu’une lecture bloque (ou soit
6. Transactions bloquée par) une écriture. Toutefois, en tolérant de manière opti-
miste plus de lectures, il peut se produire la situation suivante :
Une transaction est un programme applicatif constitué d’une une transaction veut modifier une donnée qui vient d’être modifiée
suite d’instructions SQL (modification et interrogation de la base entre temps par une autre transaction qui est déjà validée. Cette
de données). Elle se termine par une validation (commit ) ou un situation n’étant pas conforme avec l’isolation des transactions, le
abandon (rollback ). Le SGBD est un logiciel multiutilisateurs qui SGBD empêche la transaction d’aboutir. Cette situation s’appelle
permet l’exécution simultanée de plusieurs transactions pour amé- un refus d’exécution non sérialisable.
liorer la disponibilité de la base de données. De plus, il offre à Lorsque plusieurs transactions sont en attente, une situation
chaque transaction un environnement d’exécution qui semble être d’interblocage (deadlock) peut se produire. L’exemple de la figure 4
isolé des autres transactions. L’optimisation des transactions a montre deux transactions T1 et T2 qui modifient chacune un nuplet
pour objectif de détecter et résoudre les effets indésirables qu’une distinct. Puis chaque transaction tente de modifier le nuplet modi-
transaction peut produire sur d’autres transactions, notamment un fié par l’autre transaction, par conséquent chaque transaction

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 9
OPTIMISATION DES BASES DE DONNÉES ___________________________________________________________________________________________________

Base : Modules (Sigle, Durée, Mat)

Transactions : Verrous

T1 : UPDATE Modules SET durée = 3 V1 M1 3 français


WHERE sigle = 'M1'
M2 ... physique

T2 : UPDATE Modules SET durée = 4


WHERE sigle = 'M2 ' V1 M1 3 français

V2 M2 4 physique
T1 : UPDATE Modules SET durée = 4
WHERE sigle = 'M2 '

V1 M1 3 français
T2 : UPDATE Modules SET durée = 3
V2 M2 4 physique attente
WHERE sigle = 'M1 '

temps
V1 M1 3 français interblocage

V2 M2 4 physique attente
Figure 4 – Interblocage entre deux
transactions

attend l’autre pendant un temps infini. Cette attente mutuelle est 6.2.3 Agir sur l’application
détectée par le SGBD : il demande à une des deux transactions de
ne pas traiter l’instruction à l’origine de l’interblocage. En général, Un moyen simple d’éviter les blocages entre deux transactions
un interblocage peut être causé par plus de deux transactions (T1 est de les séparer temporellement. Il est parfois possible de
attend T2 qui attend... Tn qui attend T1). repousser certaines transactions pour les traiter ultérieurement
lorsque le SGBD est plus disponible [8].
6.2.1 Compromis cohérence/performance Aucun interblocage ne peut se produire si toutes les transactions
s’accordent pour accéder aux nuplets communs dans le même
Un SGBD permet d’évaluer l’impact du contrôle de concurrence ordre, ou si chaque transaction commence par « réserver » tous les
sur les performances. Les informations disponibles sont la liste des verrous dont elle a besoin. Cette solution, lorsqu’elle n’est pas trop
transactions en attente d’un verrou, réciproquement la liste des contraignante, peut être mise en œuvre si l’on sait dès le début de
transactions actives à l’origine d’une attente, la durée des attentes, la transaction quels sont les nuplets à manipuler.
le nombre de refus d’exécution non sérialisable, le nombre d’inter-
blocages détectés. Des mesures sont effectuées pendant que le Plus une transaction est courte, plus les risques de blocage sont
SGBD est en pleine activité, afin d’identifier les principales transac- réduits. Il est parfois possible de diviser une transaction en plu-
tions à l’origine de la plupart des blocages. sieurs transactions indépendantes, tout en préservant la cohérence
de la base et de l’application. C’est le cas notamment lorsque le
Il est possible d’agir à deux niveaux pour réduire les blocages :
développeur d’application a écrit une transaction longue par faci-
au niveau du SGBD, l’algorithme de contrôle de concurrence est
lité et non par nécessité.
modifié, au niveau de l’application les transactions sont modifiées.

6.2.2 Agir sur le SGBD


6.3 Performances des applications
Les protocoles de contrôle de concurrence peuvent être modifiés transactionnelles
dans le but d’augmenter le nombre de transactions validant. En
contrepartie, les transactions ne sont plus complètements isolées
des autres transactions concurrentes. Les applications transactionnelles exigent un fort débit transac-
tionnel. L’aptitude du SGBD à traiter un nombre élevé de transac-
■ Verrouillage en deux phases : en relâchant prématurément les tions par minute est souvent le critère prépondérant pour choisir
verrous partagés, les requêtes bloquent moins de transactions. Cela un SGBD parmi l’offre logicielle existante. Pour mieux comparer
diminue également le nombre d’interblocages et le nombre d’aban- des performances des divers SGBD, un organisme indépendant a
dons liés à leur résolution. défini un banc de test (benchmark ) appelé TPC-C [9]. Le benchmark
spécifie de manière très précise la nature des données, la charge
■ Verrouillage avec estampillage : en autorisant une transaction à transactionnelle soumise par les applications et le cadre pour
modifier des données validées plus récemment que la date de début mesurer les performances obtenues et le prix de revient de la solu-
de la transaction, moins de transactions sont annulées. tion. Les résultats du benchmark sont rendus publiques après cer-
Le degré d’isolation étant relâché, l’application peut être tification par un comité d’experts afin de garantir leur crédibilité.
confrontée à certaines situations d’incohérence telles que des lec- Par exemple, en 2006, le SGBD IBM DB2 est capable de traiter 4
tures non répétables. Le SGBD autorisant ces situations, elles millions de transactions par minute, tout en assurant que 90 % des
doivent être prises en considération au niveau de l’application. transactions durent moins de 5 s. Le coût total de la solution mise

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


H 3 702 − 10 est strictement interdite. − © Editions T.I.
__________________________________________________________________________________________________ OPTIMISATION DES BASES DE DONNÉES

en œuvre étant estimé à 12 millions de dollars, cela permet d’esti- afin de définir les méthodes d’accès les mieux adaptées. S’il est
mer le prix de revient d’une solution dont le débit moindre est difficile de modifier l’architecture ou de changer de modèle de
adapté aux exigences d’une application particulière. données lorsque l’application est en place, il est possible de définir
de nouvelles méthodes d’accès ou de les modifier en fonction des
évolutions de l’application.
Les SGBD fournissent des optimiseurs de requêtes très perfor-
7. Conclusion mants. Ce sont des logiciels éprouvés, ayant nécessité d’importants
moyens de développement (50 hommes.an environ pour dévelop-
per un optimiseur). Il est donc difficile d’améliorer les performances
L’optimisation d’une base de données commence dès sa de l’optimiseur en fonction de l’application. Toutefois, l’utilisateur
conception et dure tout au long du cycle de vie de l’application. Il peut, dans certains cas, orienter les décisions de l’optimiseur.
convient dans un premier temps de bien choisir l’architecture du
système, qui doit refléter le contexte et les besoins de l’application. Lors de l’utilisation de l’application, il est possible d’améliorer
Le choix du modèle de données a des impacts importants sur la les performances en agissant sur les transactions et sur le contrôle
précision de la représentation des informations du monde réel, et de concurrence. Contrairement aux autres aspects de l’optimisa-
surtout sur l’évolutivité de l’application. Enfin, il est important de tion, il faut ici avoir une vision globale de toutes les applications
déterminer les requêtes les plus fréquentes et les plus coûteuses, qui modifient la base de données.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie


est strictement interdite. − © Editions T.I. H 3 702 − 11