Vous êtes sur la page 1sur 46

30/08/2018

Plan du cours
Organisation sur les disques
Indexation et hachage
Optimisation des requêtes SQL

1
30/08/2018

Stockage et Gestion des données


RAM, mémoire vive, primaire, ou principale, données
« volatiles », accès rapide (micro seconde)
Disque dur, mémoire secondaire, données « persistantes », accès
lent (qqs milli seconde)
Disque dur SSD (solid state drive), accès rapide, données
« persistantes », fiabilité ? prix ?
Organisation physique des données
façon dont les données sont structurées en mémoire
secondaire
Méthode d'organisation des données
structure de données particulière utilisée pour organiser les
données en mémoire secondaire

Système de gestion de fichiers


Le domaine du SGF (Système de Gestion de Fichiers,
« file system ») fait partie du système d’exploitation
Séquence de bits
Ecriture / Lecture de fichiers

Stockage et accès à de gros volumes de données


Différents modèles selon l’OS
Problème de fiabilité
Accès lent
=> division en bloc de données (4~8ko)

2
30/08/2018

Caractéristiques d’un disque dur

lecture

RAM Traitement
ou
Blocs interface
Disque dur

Fichiers

=> RAM : algorithme LRU (Least Recently Used)


5

Caractéristiques d’un disque dur

Tête de
Plateau lecture/écriture
Secteur
Piste

Cylindre

3
30/08/2018

Capacité d’un disque dur


capacitéDisque = nbSurfaces × nbCylindres × nbSecteursParPiste ×
tailleSecteur
Paramètre Valeur
Nombre de surfaces (nbSurfaces) 200
Nombre de pistes par surface (nbCylindres) 10000
Nombre de secteurs par piste (nbSecteursParPiste) 500
Nombre d'octets de données par secteur (tailleSecteur) 512

= 200 surfaces × 10000 cylindres × 500 secteurs par piste × 512 octets

= 512,000,000 kilo Octets ≅ 500 GigaOctets (Go)

Transfert d’un secteur


Secteur
unité d'adressage et de transfert minimal
Adresse physique de secteur
numéro de surface (noSurface), numéro de cylindre
(noCylindre), numéro de secteur dans la piste
(noSecteur)
Adresse relative de secteur (noSecteurRelatif)
dans l'intervalle [0..n-1]
Tampon (buffer ) = zone de transit

4
30/08/2018

Temps d’accès (wiki)

Pour lire le secteur (en vert) situé sur une piste interne à l’opposé de la tête
de lecture (en rouge), il faut déplacer la tête vers l’intérieur (TSeek),
attendre que le bloc arrive sous la tête (TLatence) puis lire la totalité du bloc
(TTransmission). Il est possible d’optimiser le temps d’accès en prenant en
compte la vitesse de rotation pendant que la tête se déplace
9

Coûts d’Entrée/Sortie
Temps de transfert (E/S) de n octets
TempsESDisque(n) = TempsPosDébut + TempsTrans (n)
TempsPosDébut = TempsDépBras + TempsRotation
Tseek : 0.4-9 ms (moyenne = 3,4 ms)
TempsRotation : 15000 tr/min => 4ms pour un tour
TempsTrans(n) = n / TauxTrans
TauxTrans = 100Mo/s
ex: TempsTrans(2K) = 2K / 100M/sec = 0.02ms
ex: TempsESDisque(2K) = 7ms + 0.02ms = 7.02ms
TempsESDisque(2M) = 7ms + 20ms = 27ms
Minimiser le nombre d'entrées/sorties en mémoire
secondaire
10

5
30/08/2018

Impact de la continuité physique


Ex: transfert de 2000 secteurs de 512 octets (1M)
Secteurs consécutifs
TempsESDisque(1M) = 7ms + 10ms = 17ms
Secteurs dispersés aléatoirement
TempsESDisque(un secteur) = 7ms + 0.005ms = 7.005ms
Total = 2000 × 7.005 = 14 secondes
Effet de grappe (clustering)
regrouper physiquement pour accéder rapidement aux
informations voulues

11

Critères de comparaison
Temps d'accès aux données par rapport à différentes
méthodes d'accès
sériel, sélection, ...
Délai d'insertion et de suppression
Occupation mémoire

12

6
30/08/2018

Organisation des données


Allocation en vrac à la création du fichier

ajusté
Mieux

Fichier A Fichier B Fichier C Fichier D

Croissance de la taille du fichier ???


Fragmentation externe

13

Organisation des données


Granule d'allocation d'espace (segment, cluster, extent)
unité d'allocation d'espace
ensemble de blocs consécutifs
Fragmentation du fichier (file fragmentation)

D A B A C B B B C D B

Défragmentation

D D A A B B B B B C C

14

7
30/08/2018

Plan du cours
Organisation sur les disques
Indexation et hachage
Optimisation des requêtes SQL

15

Indexation et hachage
Sélection basée sur une clé d'accès
recherche associative
Séquentiel ou sériel
lire tout le fichier en pire cas
O(N)
Indexation
O(log(N))
sélection par intervalle
Hachage
~O(1)

16

8
30/08/2018

Indexation : les bases


Recherche de l'âge de l’étudiant Bussière ?
Solution 1 : parcours séquentiel

N°Etudiant nomEtudiant Age


10025423 Clavette 23
12031548 Gauthier 22
Bloc 1
12457852 Sauriol 25
37849562 Veronneau 23
45781245 Bussière 25
Bloc 2 Coût : lecture de 5 valeurs
75642358 Fecteau 24 chargement de 2 blocs
76845896 Lajeunesse 26
Bloc 3 85236547 Therriault 24
92564875 Alexandre 23

17

Indexation : les bases


Recherche de l'âge de l’étudiant Bussière ?
Solution 2 : tri du tableau, recherche dichotomique
(diviser pour conquérir)
N°Etudiant nomEtudiant Age
92564875 Alexandre 23
45781245 Bussière 25 Trouvé, coût : 3 lectures, 2 blocs
Bloc 1
10025423 Clavette 23 Clavette > Bussière
75642358 Fecteau 24
12031548 Gauthier 22 Gauthier > Bussière
Bloc 2
76845896 Lajeunesse 26
12457852 Sauriol 25 Problème ! On ne peut pas trier la
Bloc 3 85236547 Therriault 24 table selon tous ses attributs
37849562 Veronneau 23
18

9
30/08/2018

Indexation : les bases


Recherche de l'âge de l’étudiant Bussière ?
Solution 3 : index par attributs importants
nomEtudiant bloc N°Etudiant nomEtudiant Age
Alexandre 3 10025423 Clavette 23
Bussière 2 12031548 Gauthier 22
Bloc 1
Clavette 1 12457852 Sauriol 25
Fecteau 2 37849562 Veronneau 23
Gauthier 1 45781245 Bussière 25
Bloc 2
Lajeunesse 3 75642358 Fecteau 24
Sauriol 1 76845896 Lajeunesse 26
Therriault 3 Bloc 3 85236547 Therriault 24
Veronneau 2 92564875 Alexandre 23
Coût : 5 lectures dans l’index, 1 bloc, 2 lectures dans le tableau, 1 bloc
Remarque : coût quasi similaire à la table triée, mais avantageux pour plus de données
19

Indexation : les bases


Recherche de l'âge de l’étudiant Bussière ?
Solution 3 : index par attributs importants
nomEtudiant bloc N°Etudiant nomEtudiant Age
Alexandre 3 10025423 Clavette 23
Bussière 2 12031548 Gauthier 22
Bloc 1
Clavette 1 12457852 Sauriol 25
Fecteau 2 37849562 Veronneau 23
Gauthier 1 45781245 Bussière 25
Bloc 2
Lajeunesse 3 75642358 Fecteau 24
Sauriol 1 76845896 Lajeunesse 26
Therriault 3 Bloc 3 85236547 Therriault 24
Veronneau 2 92564875 Alexandre 23

Clé de l’index Adresse de l’enregistrement Table Etudiant 20

10
30/08/2018

Indexation : les bases


Index trop volumineux ?
Une solution : l’index hiérarchique
nomEtudiant bloc nomEtudiant bloc
A 1 Alban 3
B 10 Alexandre 2
Bloc 1
… … … …
F 53 Favre 2
G 70 Bloc 53 Fecteau 1
… … … …
S 93 Sauriol 1
T 122 Bloc 93 Suria 3
… … … …

Index plus petit, donc plus rapide


21

Hachage
Hachage ou adressage dispersé (hashing)
Fonction h(clé de hachage) => l'adresse d'un paquet
Habituellement paquet = bloc
Pas d ’index à traverser : O(1) en meilleur cas
Sélection par égalité (pas intervalle)

22

11
30/08/2018

Hachage statique

Plus de place ? Dans la zone


de débordement

23

Hachage statique
Problème de débordement dû aux collisions
Zone de débordement nécessaire
Pire cas vs. meilleur cas
Pas de cout de mise à jour de l’indexation
Répartition uniforme des clés dépendant de la
fonction de hachage et des données à indexer

24

12
30/08/2018

Hachage dynamique
Principe : doublement de l’espace d’adressage en cas de
saturation

Plus assez de place ???


=> Doublement de l’espace d’adressage

25

Hachage dynamique (2)


Solution : modification de la fonction de hachage de
manière intelligente si possible.

9 T. Hanks
0
54 B. Bardot
90 Fernandel
6 60 Bourvil
h(10) = 10 MOD 9 = 1 51 P. Fresnai
10 T. Cruise
1
100 S. LeBihan
109 J. Balasko
4 121 Anémone
130 I. Adjani
7 133 S. Bonnaire

26

13
30/08/2018

Hachage dynamique
Autre exemple : utilisation des bits pour indexer
dynamiquement

16 00100 00 0 16 00 16
2 4
15 00011 1 1
4 10 2
7 00001 1 1
01
2 00000 10 1 7
15 11 7
4 00001 00 15

27

Indexation : les bases


Index hiérarchique vers l’arbre B+

nomEtudiant bloc nomEtudiant bloc


A 1 Alban 3
B 10 Alexandre 2
Bloc 1
… … … …
F 53 Favre 2
G 70 Bloc 53 Fecteau 1
… … … …
S 93 Sauriol 1
T 122 Bloc 93 Suria 3
… … … …

27 lignes
! 7 milliards
de lignes 28

14
30/08/2018

Arbre B+: L’Index le plus Usuel


Insertion/effacement avec coût log F N; Garde la hauteur
balancée. (F = ‘’fanout’’, N = # feuilles)
Taux d’occupation minimum de 50%(sauf pour la racine).
Chaque nœud contient d <= m <= 2d entrées. Le
paramètre d est appelé l’ordre de l’arbre.
Supporte efficacement les recherches de plages de valeurs et
les recherches d’égalités.

Entrées de l’index
(orientent la recherche)

Entrées de données
("Sequence set")

Arbre B+ : exemple

La recherche commence à la racine et les comparaisons


des clés l’orientent vers une page (similaire à la
méthode ISAM).
Recherche de la clé d’index 35

Racine 10 20

6 12 23 35

3* 4* 6* 9* 10* 11* 12* 13* 20*22* 23* 31* 35*

15
30/08/2018

Arbre B+ en Pratique
Ordre typique: 100. Remplissage typique: 67%.
Sortance (‘’fanout’’) moyenne = 133
Capacités typiques:
Hauteur 4: 1334 = 312,900,700 enreg.’s
Hauteur 3: 1333 = 2,352,637 enreg.’s
Les niveaux supérieurs de l’arbre peuvent souvent tenir
en mémoire principale (‘’buffer pool’’):
Niveau 1 = 1 page = 8 Kbytes
Niveau 2 = 133 pages = 1 Mbyte
Niveau 3 = 17,689 pages = 133 MBytes

Exemple d’Arbre B+
Algorithme d’insertion
Arbre B+ d’ordre 2 => entre 2 et 4 valeurs par nœuds et
feuilles
Racine

14 19 24 33

2* 3* 5* 7* 14* 16* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

* Signifie que la clé contient la valeur de l’adresse de l’enregistrement

16
30/08/2018

Insertion d’une Entrée de Données


Trouver la feuille appropriée L.
Mettre l’entrée de données dans L.
Si L a assez d’espace, fin!
Sinon, on doit partager L (en L et un nouveau nœud L2)
Redistribuer les entrées de manière égale, copier la clé du milieu vers
le haut.
Insérer l’entrée d’index pointant vers L2 dans le parent de L.
Ceci peut arriver de manière récursive
Pour partager nœud d’index, redistribuer les entrées de manière
égale, mais pousser la clé du milieu vers le haut. (Contrastez
ceci avec le partage des feuilles !!)
Les partages font croître l’arbre; le partage de la racine
augmente sa hauteur.
Croissance de l’arbre: devient plus large ou d’ un niveau plus élevé à
la racine.

Exemple d’Arbre B+
Insertion de 8*
Étape 1 : Trouver la feuille appropriée L.

Racine

19 24 33

2* 3* 5* 7* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

8*

17
30/08/2018

Exemple d’Arbre B+
Insertion de 8*
Étape 2 : Mettre l’entrée de données dans L.
Si L a assez d’espace, fin!
Sinon, on doit partager L (en L et un nouveau nœud L2)
Redistribuer les entrées de manière égale, copier la clé du milieu vers
le haut.

Clé du milieu à copier vers le haut

2* 3* 5* 7* 2* 3* 5* 7* 8*

8*

2* 3* 5* 7* 8*

Exemple d’Arbre B+
Insertion de 8*
Étape 3 : Insérer l’entrée d’index pointant vers L2 dans le
parent de L.
Racine

19
5 24 33

2* 3* 5* 7* 8* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

18
30/08/2018

Exemple d’Arbre B+
Insertion de 14*
Trouver la feuille appropriée L.
Mettre l’entrée de données dans L.
Si L a assez d’espace, fin!
Racine

5 19 24 33

2* 3* 5* 7* 8* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

14*

Exemple d’Arbre B+
Insertion de 16*
Algorithme récursive
Pour partager nœud d’index, redistribuer les entrées de manière
égale, mais pousser la clé du milieu vers le haut. (Contrastez
ceci avec le partage des feuilles !!)

Racine

5 19 24 33

2* 3* 5* 7* 8* 14* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

16*

19
30/08/2018

Insertion de 16*

Racine
19

5 8 24 33

2* 3* 5* 7* 8* 14* 16* 19* 20* 22* 24* 27* 29* 33* 34* 38* 39*

Insertion de 8* dans l’exemple


Veuillez noter la Entrée à insérer dans le nœud parent.
(Notez que 5 est copié vers le haut et
5
différence entre continue d’apparaître dans la feuille.)

copier vers le haut


et pousser vers le 2* 3* 5* 7*

haut. (Pourquoi
fait-on cette
différence????)
Entrée à insérer dans le nœud parent.
19 (19 est poussé vers le haut et
n’apparaît qu’une fois dans l’index.

5 8 24 30

20
30/08/2018

Effacement d’une Entrée de Donnée


Commencer à la racine, trouver la feuille L à laquelle
l’entrée appartient.
Enlever l’entrée.
Si L est au moins à moitié vide, fin!
Sinon L a seulement d-1 entrées,
Essayer de redistribuer, empruntant des voisins .
Sinon, fusionner L et un voisin.
Si une fusion a lieu, on doit effacer l’entrée (d’indexe)
pointant (vers L ou le cousin) à partir du parent de L.
La fusion peut se répercuter jusqu’à la racine,
décroissant ainsi la hauteur de l’arbre.

Suppression

Racine

19

5 8 27 33

2* 3* 5* 7* 8* 14* 22* 24* 27* 29* 33* 34* 38* 39*

Effacer 16* et 19* est facile.


Effacer 20* est fait via une redistribution. Noter
comment la clé du milieu est copiée vers le haut
après la redistribution.

21
30/08/2018

... Et Ensuite Après l’Effacement de 24*


On doit fusionner.
A droite, on fait un 33
`échange’ d’entrée
d’index.
39*
Ci bas, on `tire une 22* 27* 29* 33* 34* 38*

entrée vers le bas’.

Racine
5 8 19 33

2* 3* 5* 7* 8* 14* 22* 27* 29* 33* 34* 38* 39*

Chargement en Vrac d’un Arbre B+


Si l’on a une large collection d’enreg.’s et que l’on veut créer un
indexe à arbre B+ avec une clé donnée, le faire enregistrement
par enregistrement est très inefficace.
Solution: ‘’Bulk Loading’’ (chargement en vrac).
Initialisation:
Trier toutes les entrées de données et les diviser en page;
créer une page racine vide; et
insérer un pointeur de la racine vers la 1ère page des données.

Racine Pages d’entrées de données triées;


non encore mises dans l’arbre B+

3* 4* 6* 9* 10* 11* 12* 13* 20* 22* 23* 31* 35* 36* 38* 41* 44*

22
30/08/2018

Chargement en Vrac (Suite)


Les entrées d’index Racine 10 20
pour les feuilles sont
toujours créées dans
Pages de données
la page d’index la plus 6 12 23 35
à mettre sur l’arbre
à droite située juste
au dessus du niveau
des feuilles. Si cette 3* 4* 6* 9* 10* 11* 12* 13* 20*22* 23* 31* 35*36* 38*41* 44*

dernière est pleine,


elle est partagée. (Ce Racine 20

processus peut se
répéter récursivement 10 35

6 12 23 38

3* 4* 6* 9* 10* 11* 12* 13* 20*22* 23* 31* 35*36* 38*41* 44*

Arbre B+
Arbre-B+ (B-arbre, B-tree)
forme d ’index hiérarchique
Équilibré (redistribution)
O(ln(N)) en pire cas
Ré-organisation dynamique
division/fusion des blocs
taux d ’occupation minimum de 50%

46

23
30/08/2018

Plan du cours
Organisation sur les disques
Indexation et hachage
Optimisation des requêtes SQL

47

Optimisation
Les langages de requêtes de haut niveau comme
SQL sont déclaratifs. L'utilisateur:
indique ce qu'il veut obtenir.
n'indique pas comment l'obtenir.
Donc le système doit faire le reste:
Déterminer le (ou les) chemin(s) d'accès aux données,
les stratégies d'évaluation de la requête
Choisir la meilleure. Ou une des meilleures …

48

24
30/08/2018

Architecture de type SGBD


SYNTAXE
ANALYSEUR SEMANTIQUE
SCHEMA

VUES
CONTROLE INTEGRITE
AUTORISATIONS

ORDONNANCEMENT
META-BASE OPTIMISEUR ELABORATION
D'UN PLAN

EXECUTABLE EXECUTION
METHODES D'ACCES

Étapes de l’optimisation
(1) Obtention d’une représentation canonique
(2) Réécriture = transformation par :
simplification
ordonnancement des opérations élémentaires
(3) Planning = construction des plans d'exécution
candidats
choix des algorithmes pour chaque opérateur,
calcul du coût de chaque plan,
choix du meilleur plan.
Etapes 1 et 2 : indépendantes des données
Etape 3 : dépendante des données

25
30/08/2018

Exemple d’arbre
Base de données de buveurs de bières
Bière(n°Bière, nomBière, année, dégré, origine)
Boire(n°Bière, n°SS, date, quantité)
Buveur(n°SS, nomBuveur, ville)
N°Bière nomBière année degré origine

1 ChimayBleue 1862 9 Belgique


2 Kwak 1791 6.5 Belgique
3 Moulins d’Ascq 1999 8%N°Bière
FranceN°SS Date quantité
2 1800386247514 10/02/2011 1.5
1 2860486145754 15/05/2011 0.75
N°SS nomBuv ville 2 2860486145754 16/05/2011 0.99
1800386247514 Duff Lille
2860486145754 Lemon Poitiers

Arbres Relationnels
RESTRICTION PROJECTION TRI

Bière.Origine = « Belgique » Bière.nom, Bière.Origine Bière.degré

Bière
JOINTURE Bière
DIFFERENCE Bière

Bière. Nb = Boire. Nb
— AGREGAT
Bière Boire
B1 B2

PRODUIT CARTESIEN UNION


COUNT(*),AVG(DEGRE)

Bière.Origine
U
Bière Boire B2
B1
Bière

26
30/08/2018

Exemple d’arbre
RESULTAT
Quel buveur lillois a bu de la B.NOM
Chimay en 2011 ?
Coût d'exécution: A.date > 01-01-2011
10 millions de buveurs dont 1 m à
Lille C.nom = « Chimay »
20 millions de Boire dont 100000
de Chimay et 1000 en 2011
1000 bières A.N° = C.N°

Bière C
10 m + 10m * 1m + 10 m * 1000 B.N° = A.N°
+ 10 m + 100000 + 1000
de l'ordre de 10 ^ 13 B.ville = « Lille » Boire A

comparaisons de tuples !!!


Buveur B

Restructuration algébrique
Problème :
suivant l'ordre des opérateurs algébriques dans un
arbre, le coût d'exécution est diffèrent

Pourquoi?
1. le coût des opérateurs varient en fonction du volume
des données traitées
i.e., plus le nombre de tuple des relations traitées est
petit, plus les coûts cpu et d'E/S sont minimisés
2. certains opérateurs diminuent le volume des données
e.g., restriction et projection

27
30/08/2018

Règles de Restructuration
(1) Commutativité des jointures
(2) Associativité des jointures
(3) Groupabilité des restrictions
(4) Semi-commutativité des projections et restrictions
(5) Semi-commutativité des restrictions et jointures
(6) Semi-distributivité des projections / jointures
(7) Distributivité des restrictions / unions ou
différences
(8) Distributivité des projections / unions

Règle 1 : Commutativité des Jointures

R S S R

R |><| S S |><| R

28
30/08/2018

Associativité des jointures


Il existe N!/2 arbre de jointure de N relations.
Parmi les jointures, certaines sont des produits cartésiens.

T R

R S S T
(R |><| S) |><| T R |><| (S |><| T)

Groupage des Restrictions

Ai = a

Ai = a
et
Aj = b

Aj = b

29
30/08/2018

Groupage des Restrictions


Exemple
SELECT * FROM BIERE B
WHERE ((B.DEGRE = 12) OR (B.ORIGINE = ‘Belgique') OR
(V.ORIGINE = ‘Irlande'))
AND NOT ((B.ORIGINE = ‘Belgique') OR (V.ORIGINE =
‘Irlande'));
Propriété logique: ((P|Q|R).^(Q|R)),(P .^(Q|R))
Expression simplifiée de la requête
SELECT * FROM BIERE B WHERE ((B.DEGRE = 12)
AND NOT ((B.ORIGINE = ‘Belgique') OR
(V.ORIGINE = ‘Irlande'));
59

Semi-commutativité des Projections


Il est possible de descendre les projections, mais les
attributs utilisés dans la suite doivent être conservés !!!

A1, … Ap
A1, … Ap

Ai = a
Ai = a

Ai,
A1,… Ap

30
30/08/2018

Heuristique d'Optimisation
Appliquer d'abord les opérations réductrices
(restrictions et projections) en les groupant sur chaque
relation.
1. Dégrouper les restrictions (Règle 3')
2. Descendre les restrictions (Règles 4, 5 et 7)
3. Grouper les restrictions aux feuilles (Règle 3)
4. Descendre les projections (Règles 4, 6 et 8)

L'ordre des unions, différences et jointures reste


inchangé !!!

Exemple d’arbre RESULTAT


Quel buveur lillois a bu de la B.NOM
Chimay en 2011 ?
Coût d'exécution: A.date > 01-01-2011
10 millions de buveurs dont 1 m à
Lille
C.nom = « Chimay »
20 millions de Boire (200000 en
2011) dont 100000 de Chimay et
1000 Chimay en 2011
1000 bières dans C A.N° = C.N°

Bière C
10 m + 20m * 1m + 20 m * 1000 B.N° = A.N°
+ 20 m + 100000 + 1000
de l'ordre de 20 ^ 13 B.ville = « Lille » Boire A
comparaisons de tuples !!!
Buveur B

31
30/08/2018

Exemple d'Arbre Optimisé


Résultat
Coût d'exécution :
B.nomBuveur 10 millions de buveurs
dont 1 m à Lille
20 millions de Boire
A.N°Bière C.N°Bière (200000 en 2011) dont
=
100000 de Chimay et
1000 Chimay en 2011
B.nom, A.n°Bière 1000 bières dans C

B.N°B = A.N°B C.N°Bière


10 m + 20m +
200000*1m +
B.N°B, B.nom A.N°B, A.N°Bière
1m + …
C.nom = "Chimay"
B.ville = « Lille »
A.DATE > 01-01-2011 de l'ordre de 20 ^10
comparaisons de tuples
B Bière C !
Buveur B
Boire A

Exemple d'Arbre Optimisé


Résultat

Coût d'exécution :
B.nomBuveur 10 millions de buveurs
dont 1 m à Lille
20 millions de Boire
C.N°Bière = A.N°Bière (200000 en 2011) dont
100000 de Chimay et
1000 Chimay en 2011
B.nom, C.n°Bière
1000 bières dans C
B.N°B C.N°B
C.N°Bière A.N°B, A.N°Bière

Coût ?
B.N°B, B.nom C.N°Bière
A.DATE > 01-01-2011

B.ville = « Lille » A
Boire A
C.nom = « Chimay »
B B
Buveur
CBière C

32
30/08/2018

Ordonnancement des Jointures


HEURISTIQUES :
Choix des relations de taille minimum
Jointures pré-calculés en premier (indexes)
Semi-jointures plus réductrices

ORDONNANCEMENT DES AGREGATS


Permutations difficiles
Profiter des tris des jointures, dédoublement, etc..
Gains importants pour MIN et MAX

Choix du meilleur plan dans Oracle


Arbre Schéma interne
d'opérations

Plans d'exécution
Bibliothèque de
Générateur de
Plans transformations

Stratégie de Heuristiques
Recherche
de choix

Modèle de coût
Plan d'exécution
Optimal

33
30/08/2018

Optimisation : à éviter
Les algorithmes de tri ! Très couteux
pour les algorithmes de jointure (sort/merge)
l'élimination des doublons (clause DISTINCT)
pour les opérations de regroupement (GROUP BY)
... et bien sûr pour les ORDER BY

Réfléchir à la mise en place d’un index sur l’attribut à


trier

67

Optimisation : important
Analyser les requêtes effectuées dans votre base de
données
Enregistrement des fichiers de journalisation
Calcul de statistiques

Solutions
Réfléchir à la mise en place d’un index sur l’attribut à
trier
Réfléchir à la restructuration du stockage des données
Création de vues selon l’application : limiter les
requêtes

68

34
30/08/2018

Optimisation : outils sous Oracle


Analyser le plan d’indexation choisi pour les
requêtes effectuées dans votre base de données
L’outil EXPLAIN donne le plan d’exécution d’une requête. La
description comprend :
Le chemin d’accès utilisé.
Les opérations physiques (tri, fusion, intersection, ...)
L’ordre des opérations.
Il est représentable par un arbre.

69

L’outil EXPLAIN d’Oracle


Syntaxe :SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]}
[EXP[LAIN]] [STAT[ISTICS]]
OFF : Désactive le suivi d’exécution automatique des instructions
SQL.
ON : Active le suivi d’exécution automatique des instructions SQL.
TRACEONLY : active le suivi d’exécution automatique des
instructions SQL et supprime la sortie des instructions.
EXPLAIN : Affiche les plan d’exécutions mais pas les statistiques.
STATISTICS : Affiche les statistiques mais pas les plans d’exécution.
Si les deux dernières options sont omises, les statistiques et les plans
d’exécution sont affichés par défaut.
On peut connaître le temps précis d’une requête (temps exprimé
en centième de seconde) par la commande :
SQL> set timing on ;

70

35
30/08/2018

Exemple
EXPLAIN PLAN FOR
SELECT e.employee_id, j.job_title, e.salary,
d.department_name
FROM employees e, jobs j, departments d
WHERE e.employee_id < 103
AND e.job_id = j.job_id
AND e.department_id = d.department_id;

71

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3713 consistent gets
11 physical reads
0 redo size
11677 bytes sent via SQL*Net to client
591 bytes received via SQL*Net from client
10 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
135 rows processed
72

36
30/08/2018

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

* Predicate Information (identified by operation id):


---------------------------------------------------
3 - filter("E"."EMPLOYEE_ID"<103)
5 - access("E"."JOB_ID"="J"."JOB_ID")
7 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")

73

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Les opérations :
mode d’accès à la base de données
- via un index (INDEX UNIQUE SCAN)
- via un accès par table d’index (TABLE ACCESS BY INDEX ROWID)
- via une lecture séquentiel (TABLE ACCESS FULL)
- via une double boucle for (NESTED LOOPS)
74

37
30/08/2018

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Les tables affectées


Le nombre de lignes retournées
Le nombre de bytes retournées
Le cout CPU et le pourcentage

75

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX RO | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Recherche dans un index (B-tree par exemple) et renvoie les identifiants des tables respectant les
critères de jointure de la requête
7 => 6
5 => 4
Accès instantané grâce à l’indexation

76

38
30/08/2018

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Recherche dans une table à partir des index renvoyés par 5 et 7


Renvoie la ligne entière de chaque id aux étapes 1 et 2

77

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Accès complet à la table afin de renvoyer les lignes répondant aux critères de sélection de la
requête
Renvoie à l’étape 2

78

39
30/08/2018

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Double boucle permettant les jointures entre 2 tables

79

Exemple
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |Cost (%CPU)|
----------------------------------------------------------------------------------- -------------------------------------------------
|0| SELECT STATEMENT | |3 | 189 | 10 (10) |
|1| NESTED LOOPS | |3 | 189 | 10 (10) |
|2| NESTED LOOPS | |3 | 141 | 7 (15) |
| *3 | TABLE ACCESS FULL | EMPLOYEES |3 | 60 | 4 (25) |
|4| TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513 | 2 (50) |
| *5 | INDEX UNIQUE SCAN | JOB_ID_PK |1 | | |
|6| TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50) |
| *7 | INDEX UNIQUE SCAN | DEPT_ID_PK |1 | | |
-------------------------------------------------------------------------------------------------------------------------------------

Sélection des informations à afficher

80

40
30/08/2018

Exemple
Statistics
----------------------------------------------------------
0 recursive calls \\ nombre d’appels récursifs du système ou de l’utilisateur
nécessaire si besoin : triggers, mise en cache, libération
mémoire, point de sauvegarde, etc.
0 db block gets \\ nombre de blocks à lire en cours de modification (appel à la
version courante du block)
3713 consistent gets \\ nombre de blocks à lire d’une version stable ou antérieure de la
base de données (appel à « undo » si nécessaire)
11 physical reads \\ nombre de block lus sur le disque
0 redo size \\ taille des informations redo générées (0 sur un select)
11677 bytes sent via SQL*Net to client
591 bytes received via SQL*Net from client
10 SQL*Net roundtrips to/from client
\\ envoie et réception de bytes et nombre de messages echangés entre le client et serveur
0 sorts (memory)
0 sorts (disk)
\\ utilisation des fonctions de tri en mémoire vive ou sur le disque
135 rows processed \\ lignes lues pour l’opération

81

Stratégies de jointure
nested loop join :
la table à droite de la jointure est confrontée à chaque tuple de la
table à gauche. Si la table à droite est indexée sur l’attribut qui sert
pour la jointure, cette approche peut donner des résultats corrects
(elle peut autrement s’avérer coûteuse)

hash join
la table à droite de la jointure fait l’objet d’une table de hachage, le
ou les attributs impliqués dans la condition de jointure font office
de clé pour la table de hachage. La table à gauche est alors examinée
et la jointure s’effectue alors via la table de hachage

merge sort join


chaque table est triée sur les attributs impliqués dans la condition
de jointure. Une fois le tri réalisé, l’opération de jointure peut alors
être effectuée. Dans cette stratégie, c’est l’opération de tri qui s’avère
alors la plus coûteuse.
82

41
30/08/2018

L’outil TK-PROF

SELECT * FROM emp, dept


WHERE emp.deptno = dept.deptno;

call count cpu (s) elapsed disk query current rows


--------------------------------------------------------------------------------------
Parse 11 0.08 0.18 0 0 0 0
Execute 11 0.23 0.66 0 3 6 0
Fetch 35 6.70 6.83 100 12326 2 824
---------------------------------------------------------------------------------------
total 57 7.01 7.67 100 12329 8 826

Misses in library cache during parse: 0

83

TKPROF

PARSE
Traduit l'instruction SQL en un plan d'exécution, y compris
les vérifications des droits d’accès et l'existence de tables, de
colonnes, et d'autres objets référencés.
EXECUTE
Exécution effective de la déclaration faite par Oracle. Pour des
instructions INSERT, UPDATE et DELETE, modification des
données. Pour les commandes SELECT, identification des
lignes sélectionnées.
FETCH
Récupère les lignes retournées par une requête, uniquement
pour les instructions SELECT.

84

42
30/08/2018

Optimisation : outils sous Oracle


Analyser le coût des opérations réalisées
Avec l’utilitaire TKPROF, on obtient :
Le coût CPU
Le nombre d’entrées/sorties physiques
Le nombre d’entrées/sorties en mémoire
Le nombre de tris
etc

85

Résumé : Comment optimiser ?


traduire une requête exprimée avec un langage
déclaratif en une suite d'opérations (typiquement
opérateurs de l'algèbre relationnelle).
En fonction (i) des coûts de chaque opération (ii) des
caractéristiques de la base, (iii) des algorithmes utilisés,
estimer la meilleure stratégie.
On obtient le plan d'exécution de la requête.
L'exécuter.

86

43
30/08/2018

Résumé : Paramètres de l’optimisation


L'optimisation s'appuie sur des :
règles de ré-écriture des expressions de l'algèbre.
connaissances sur l'organisation physique de la base
(index, hachage, …)
statistiques sur la base (taille des relations par exemple).

Un modèle de coût permet de classer les


différentes stratégies envisagées.

87

Conclusion
Problème essentiel des SGBD

Nécessité d’un modèle de coût

Approches par compilation dans un langage d’accès


(opérateurs avec annotations)

Stratégies de choix aléatoires

44
30/08/2018

Optimisation : exercice
Cinéma(idCinéma, Adresse, Gérant)
Salle (idCinéma, NoSalle, Capacité)

avec les hypothèses suivantes :


Il y a 300 n-uplets dans CINEMA, occupant 30 pages.
Il y a 1200 n-uplets dans SALLE, occupant 120 pages.

89

Optimisation : exercice
Adresse des cinémas ayant des salles de plus de 150
places
On suppose que 5% des cinémas ont cette capacité
En SQL, cette requête s'exprime de la manière
suivante :
SELECT Adresse FROM CINEMA, SALLE WHERE
capacité >150 AND CINEMA.cinéma =
Salle.cinéma

90

45
30/08/2018

Jointure d’abord
Calculer le cout de cette requête et proposer une
optimisation

Cout :
Adresse
Jointure : 30 * 120 =
3600 tuples
Capacité > 150
Sélection à rajouter

Salles Cinéma 91

Sélection d’abord
Cout :

Adresse Sélection : 120 * 5% = 6 tuples


Lectures : 120 + 6

Jointure : 30 * 6 = 180 tuples


Lectures : 180

cinéma = cinéma Total = 306 tuples

Capacité > 150 Cinéma

Salles

92

46