View
1
Download
0
Category
Preview:
Citation preview
Département de génie logiciel et des TI
LOG660 - Bases de données de haute performance
Évaluation et optimisation de requêtes
Département de génie logiciel et des TI
Question
■ Laquelle de ces requêtes est la plus performante?
© R. Godin, C. Desrosiers - Hiver 2011 2
SELECT SUM(LC.quantite) FROM LigneCommande LC, Produit PWHERE LC.idProduit = P.idProduit AND
P.categorie = ‘imprimante’
Requête 1:
SELECT SUM(LC.quantite) FROM LigneCommande LCWHERE LC.idProduit IN
(SELECT idProduit FROM Produit PWHERE P.categorie = ‘imprimante’)
Requête 2:
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Évaluation des requêtes relationnelles
■ SQL
– QUOI
■ Évaluateur de requêtes du SGBD
– COMMENT
– en fonction du schéma interne
3
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Traitement des requêtes
Décomposition
Requête (ex:SQL)
Schémaconceptuel &
externe
Requête interne
Optimisation
Plan d'exécution
Exécution
Schéma interne &statistiques
BD
Résultats
4
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Requête interne
SELECT titre, descripteurFROM Livre, CatégorieWHERE ISBN = 1-111-1111-1 AND Livre.code = Catégorie.code
Livre{Clé prim aire : ISBN}ISBN : CHAR(13)titre : VARCHAR(50)annéeParution : Dom aineAnnéenom Editeur : VARCHAR(20)code : VARCHAR(10)
<<table>>
Catégorie{Clé primaire : code}code : VARCHAR(10)descripteur : VARCHAR(20)codeParent : VARCHAR(10)
<<ta ble>>
codeParent
Livre Catégorie
s ISBN = 1-111-1111-1
P titre, descripteur
5
Schéma relationnel:
Requête SQL:
Requête interne:
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Coût des opérations physiques
■ La performance d’une requête interne est évaluée en fonction:
■ Dans les systèmes transactionnels: – Le principal soucis est de pouvoir traiter les requêtes le plus
rapidement possible – Les accès disque sont les opérations les plus coûteuses – Donc, la principale métrique de performance est TempsES
6
Métrique Description
TempsES : Temps d’accès (lectures et écritures) à la mémoire secondaire
TempsUCT : Temps de traitement de l’unité centrale (souvent négligeable par rapport au temps d’accès)
TailleMC : Espace requis en mémoire centrale
TailleMS : Espace requis en mémoire secondaire
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Statistiques d’évaluation
Statistique Description NT Nombre de lignes de la table T TailleLigneT La taille d'une ligne de la table T
FBT Facteur de blocage moyen de T (nombre moyen de lignes contenues dans un bloc)
FBMT Facteur de blocage maximal de T
Estimation : !(TailleBloc-TailleDescripteurBloc )/TailleLigneT"
BT Nombre de blocs de la table T
Estimation : #NT / FBT$
CardT (col): Nombre de valeurs distinctes (cardinalité) de la colonne col pour la table T
Ex : CardT(sexe) = 2
MinT (col), MaxT (col) Valeurs minimale et maximale que peut prendre une colonne col
7
■ L’estimation du coût des opérations se base sur des statistiques■ Statistiques d’une table T:
Département de génie logiciel et des TI
■ Statistiques d’une expression de sélection par valeur (col = val) ou par intervalle (col ∈ [val1, val2]) :
■ Le facteur de sélectivité est important car il détermine le nombre de blocs à transférer (TempsES)
© R. Godin, C. Desrosiers - Hiver 2011
Statistiques d’évaluation
Statistique Description
FacteurSélectivitéT (col = val) Pourcentage de lignes pour lesquelles la colonne col contient la valeur val
Estimation : 1/CardT (col)
FacteurSélectivitéT (col ∈ [val1,val2]) Pourcentage de lignes pour lesquelles la colonne col contient une valeur comprise entre val1 et val2
Estimation : (val2- val1)/( MaxT (col)- MinT (col) )
SelT (col = val) Nombre de lignes de T sélectionnées par l'expression de sélection.
Estimation : FacteurSélectivitéT (col) * NT
8
Département de génie logiciel et des TI
■ Statistiques d’un index I (arbre-B+):
■ Autres statistiques:
© R. Godin, C. Desrosiers - Hiver 2011
Statistiques d’évaluation
Statistique Description
TailleEntréeI Taille d'une entrée dans un bloc interne de l'index
Approximation : taille de la clé d'index + taille pointeur de bloc
OrdreI Nombre maximum de fils (pointeurs) pour un bloc interne de l'index I
Estimation : !(TailleBloc-TailleDescripteurBloc)/TailleEntréeI" OrdreMoyenI Nombre moyen de fils (pointeurs) pour un bloc interne de l'index I
HauteurI Nombre de niveaux dans l'arbre de l'index I
Estimation : #logOrdreMoyenI (NT)$
9
Statistique Description THT Taille de l'espace d'adressage pour la fonction de hachage
M Nombre de blocs disponibles en mémoire centrale pour le traitement des opérations
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Maintien des statistiques par le SGBD
■ Dilemme entre la précision des statistiques (menant à une meilleure estimation des coûts) et l’effort (temps, cpu) requis pour les générer
■ Types de mise à jour des statistiques:– Incrémentale
■ À chaque mise à jour de la table ou de l’index
– Mise à jour en différé■ Durant les périodes de faible activité (ex: la nuit)■ Déclenchée par un script
– Estimation par échantillonnage■ Pour les tables très volumineuses (ex: pourcentage des lignes)
10
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Maintien des statistiques par le SGBD
■ Clause ANALYZE (Oracle)– Statistiques complètes:
– Échantillonnage (10 pourcent des lignes):
11
ANALYZE TABLE NomTable COMPUTE STATISTICS
ANALYZE TABLE NomTable ESTIMATE STATISTICSSAMPLE 10 PERCENT
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Opérations à optimiser
1) Sélection de lignes selon une clé – Ex: balayage, index, hashage, etc.
2) Tri des lignes d’une table– Ex: algorithme tri-fusion
3) Jointure de deux tables– Ex: boucles imbriquées, jointure tri-fusion, etc.
12
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011 13
Sélection d’enregistrements
■ Sélection par balayage:– On parcourt la table jusqu'à ce qu'on trouve l'enregistrement désiré– Lire toute la table dans le pire cas: O(N)
■ Sélection par indexage:– On traverse l'index selon la clé de recherche– Complexité: O(log(N))– Permet également la sélection par intervalle
■ Sélection par hachage:– L'adresse du bloc contenant l'enregistrement est obtenu en appliquant
une fonction de hashage sur la clé– Complexité: ~O(1)– Ne permet pas la sélection par intervalle
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Balayage de tables (FULL TABLE SCAN)
■ On lit séquentiellement tous les blocs de la table
■ Facteurs à considérer:– Le nombre de blocs dans la table– Les temps de positionnement de la tête de lecture, dus aux bris de
séquence
■ Temps estimé:– TempsES (BAL) = BT× TempsTrans + NombrePos × TempsPosDébut
Positionnement #1
...
Transfert sans bris de séquence
Positionnement #2
...
Transfert sans bris de séquence
Positionnement #3
...
Transfert sans bris de séquence
14
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Balayage de tables (FULL TABLE SCAN)
■ Situations où il peut être acceptable de balayer une table:– Petites tables:
■ Plus avantageux de lire tous les blocs de la table en mémoire centrale et de faire les opérations (sélection, tri, jointure, etc.) en mémoire centrale
– Tables intermédiaires:■ Ex: table retournée par un SELECT imbriqué■ On ne possède pas d’index ou autres structures d’optimisation
pour ces tables■ Le balayage est souvent la seule option
15
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple : balayage de la table Livre
■ FBLivre= FBMLivre= 20
■ BLivre = éNLivre/ FBLivreù = é1 000 000/ 20ù = 50 000 blocs
■ Meilleur cas (aucun bris de séquence):– TempsES (BALLivre) = 0.5 secs (TempsTrans = 0.1 ms)
■ Pire cas (bris de séquence après chaque lecture de bloc) :– TempsES (BALLivre) = 5.5 secs (TempsTrans + TempsPosDébut = 1.1 ms)
■ Observations:– Le balayage de grandes tables est à éviter si possible
– Le temps de repositionnement peut avoir un impact significatif sur la performance de la requête
NLivre 1 000 000FBMLivre 20
16
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Sélection par égalité dans un index secondaire (INDEX SCAN)
...
...
...
...
.........
Hauteur -1
Feuilles à transférercontenant les références
aux blocs del'organisation primaire
... ...... ... ... Blocs de l'organisationprimaire à transférer...
17
■ Ex: SELECT * FROM Client WHERE id=1052
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Sélection par égalité dans un index secondaire (INDEX SCAN)■ Trois groupes de blocs à lire:
– Blocs internes de l’index (traverse de l’arbre): ■ (HauteurI -1) blocs à lire
– Feuilles de l’index (les références): ■ éSelT (cléIndex = val) /OrdreMoyenIù blocs à lire
– Blocs de l ’organisation primaire (les lignes recherchées)■ SelT (cléIndex = val) blocs à lire
■ Sélection sur une clé unique (ex: clé primaire)– Un seul bloc feuille et un seul bloc de l’organisation primaire, car
une seule ligne (au max.) à récupérer
– Total de (HauteurI +1) blocs à lire
18
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: sélection sur clé non unique (facteur de sélectivité faible)
■ HauteurI = élog66(1 000 000)ù = 4
■ SelLivre (code = val) ≈ NLivre/CardLivre(code) = 250 lignes
■ TempsES (index secondaire) = 284 ms
■ Observations:– La sélection par index secondaire est plus rapide que le balayage
dans ce cas ci (284 ms versus 500 ms)
NLivre 1 000 000 FBMLivre 20 CardLivre(code) 4 000 OrdreMoyenI 66
19
TempsESBloc =TempsTrans + TempsPosDébut
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: sélection sur clé non unique (facteur de sélectivité élevé)
■ HauteurI = élog66(1 000 000)ù = 4
■ SelLivre (code = val) ≈ NLivre/CardLivre(code) = 50 000 lignes
■ TempsES (index secondaire) = 55.84 secs
■ Observations:– La sélection par index secondaire est pire que le balayage (55.8 sec
versus 0.5 sec) !– Comme les lignes se trouvent (potentiellement) dans des blocs
différents, il faut repositionner la tête de lecture pour chaque ligne– Il est préférable de simplement balayer la table dans ce cas
NLivre 1 000 000 FBMLivre 20 CardLivre(code) 20 OrdreMoyenI 66
20
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: sélection sur clé unique (clé primaire ISBN)
■ HauteurI = élog66(1 000 000)ù = 4
■ TempsES (index secondaire) =(HauteurI +1) × TempsESBloc = 5.5 ms
■ TempsES (index primaire) = HauteurI × TempsESBloc = 4.4 ms
■ Observations:– Un index secondaire est comparable à un index primaire dans le
cas d'une clé unique (un seul bloc de plus à lire pour la référence)– L'index secondaire est donc préférable pour les clés uniques
(Oracle en crée un par défaut sur chaque clé primaire)
NLivre 1 000 000 FBMLivre 20 CardLivre (ISBN) 1 000 000 OrdreMoyenI 66
21
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011 22
Index secondaire Balayage
temps (ms)
Balayage vs sélection par index secondaire (N = 1 000 000, FBM =20)
■ Observations:– L’index secondaire est préférable au balayage si la colonne de
sélection possède plus de 200 valeurs différentes (CardT(col) ≥ 200)– Oracle recommande de NE PAS créer d’index si la sélection peut
retourner plus que 15% des lignes (FacteurSélectivitéT(col) ≥ 15%)– Ex: créer un index sur une colonne sexe est une mauvaise idée
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Taille de l'index secondaire
■ Index secondaire sur la colonne code de Livre (clé non unique)
■ Taille de la table Livre:– BLivre = éNLivre/ FBMLivreù = é1 000 000/ 20ù = 50 000 blocs
■ Taille de l’index (estimée par le nombre de blocs feuilles):– BIndexSecondaire = éNLivre / OrdreMoyenI ù = 15 152 blocs
■ Observations:– La taille de l’index en mémoire secondaire correspond à 30% de
la taille de la table indexée !– Il faut donc créer des index UNIQUEMENT lorsque pertinent
NLivre 1 000 000 FBMLivre 20 CardLivre(code) 4 000 OrdreMoyenI 66
23
Département de génie logiciel et des TI
■ Dans les cas où toutes les colonnes souhaitées se trouvent dans la clé de l’index
■ Ex: (index sur la colonne idClient d’une table Transaction)
■ On balaye les blocs feuilles de l’index au lieu de balayer les blocs de la table
■ Comme l’information est plus compacte dans les feuilles de l’index, il y a moins de blocs à lire
Balayage de l’index (FULL INDEX SCAN)
© R. Godin, C. Desrosiers - Hiver 2011 24
SELECT idClient, COUNT(*) as nbTransactionsFROM TransactionGROUP BY idClient
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Sélection par égalité avec hachage(HASH SCAN)■ Stratégie de chaînage en cas de débordement
■ Dans le pire cas, il faut parcourir tous les blocs de l’adresse correspondant à la clé de sélection
■ Nombre moyen de blocs à lire (distribution uniforme des lignes):– éNT / (THT × FBT)ù blocs
...Adresse du
paquet
0
1
2
3
TH-1
25
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: hachage sur ISBN de Livre(HASH cluster Oracle)
■ Cas idéal (sans débordement)– Taux de remplissage des blocs TR = 80%– FBLivre = 80% × FBMLivre = 16
– THLivre = éNLivre/ FBLivreù = 62 500
■ TempsES (hashage) = é1 000 000/(62 500 × 16)ù × 1.1 ms = 1.1 ms
■ TempsES (index secondaire) = (HauteurI + 1)× 1.1 ms = 5.5 ms
■ Observations:– Dans le cas idéal, un seul bloc à lire (versus 5 pour l’index secondaire)– En pratique, la performance est affectée par les débordements si la
taille d’adressage (paramètre TH) est mal choisie
NLivre 1 000 000 FBMLivre 20
26
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Tri d'une table
■ Plusieurs opérations nécessitent de trier une table: – Résultats triés (ORDER BY)– Élimination des doubles (DISTINCT)– Opérations d’agrégation (GROUP BY)– Jointure par tri-fusion
■ Si le nombre de blocs en mémoire centrale (M) est grand– On lit la table et la trie en mémoire centrale
■ Sinon, si M est petit– On doit faire un tri externe de la table (ex: algorithme de tri-
fusion)
27
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Algorithme de tri fusion
■ Étape tri– On trie la table en mémoire centrale par groupes de M blocs– On doit lire et écrire tous les blocs de la table, avec un
repositionnement pour chaque groupe de M blocs– Coût : 2 × ( éBT /Mù × TempsPosDébut + BT × TempsTrans)
15 4 3
Positionnement
Lecture
Créationde 12/3 =4 groupes
9 18 12
Lecture
Positionnement
16 2 5
Lecture
Positionnement
7 14 6
Positionnement
Lecture
3 4 15
Positionnement
Ecriture
9 12 18
Ecriture
Positionnement
2 5 16
Ecriture
Positionnement
6 7 14
Positionnement
Ecriture
28
Département de génie logiciel et des TI
■ Étape fusion– On fusionne récursivement les groupes voisins (triés) jusqu’à
obtenir un seul groupe contenant tous les blocs
– Environ élogM-1(BT /M)ù passes de fusion, chacune demandant un balayage en lecture et écriture de la table
– Coût : BT × (2élogM-1(BT /M)ù - 1) × TempsESBloc
© R. Godin, C. Desrosiers - Hiver 2011
Algorithme de tri fusion
3 4 15 9 12 18 2 5 16 6 7 14
3 4 9 12 15 18 2 5 6 7 14 16
2 3 4 5 6 7 9 12 14 15 16 18
Passe defusion #1
produit 4/2 = 2groupes
Passe defusion #2
produit 2/2 =1groupe
29
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: Tri de la table Livre
■ M = 50
■ TempsES (tri-fusion) = 165 secs
■ Observations:
– Inefficace de trier une grande table lorsqu’on possède peu de mémoire centrale (ex: seulement M=50 blocs)
– Solution alternative: créer un index primaire ou CLUSTER INDEX sur la clé de tri afin que les lignes soient physiquement ordonnées selon cette clé, en mémoire secondaire
NLivre 1 000 000FBMLivre 20BLivre 50 000
30
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Jointure de deux tables (R ⋈q S)
■ Une des opérations ayant le plus d’impact sur la performance des requêtes
■ L’optimisation des jointure est donc cruciale
■ Principales approches de jointure:– Jointure par boucles imbriquées par blocs (BIB)
– Jointure par boucles imbriquées avec index (BII)
– Jointure par tri-fusion (JTF)
– Jointure par hashage (JH)
– Pré-jointure (PJ)
31
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Boucles imbriquées par blocs (NESTED LOOP JOIN)
POUR chaque bloc bR de R POUR chaque bloc bS de S POUR chaque ligne lR de bR POUR chaque ligne lS de bS SI θ sur lR et lS est satisfait Produire la ligne concaténée à partir de lR et lS FINSI FINPOUR FINPOUR FINPOUR
FINPOUR
32
■ TempsES (BIB) = BR × (TempsESBloc + BS×TempsTrans + TempsPosDébut)
■ Variante : Boucles imbriquées multiblocs (BIM)– On lit M blocs de R à la fois (au lieu de 1 bloc)– Réduit le nombre de repositionnements de la tête de lecture
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: BIB sur Livre ⋈ Catégorie
■ R=Livre et S=Catégorie:– TempsES (BIB) = 605 secs
■ R = Catégorie et S = Livre:– TempsES (BIB) = 500 secs
■ S=Catégorie lue une seule fois en mémoire centrale:– TempsES (BIB) = 5.01 secs
■ Observations:– Légèrement avantageux de mettre la plus petite table dans la
boucle externe (500 secs vs 605 secs)– Gain important de performance si la table de la boucle interne
peut être mise en mémoire (aucune relecture)
NLivre 1 000 000FBLivre 20BLivre 50 000
NCatégorie 4 000FBCatégorie 40BCatégorie 100
33
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Boucles imbriquées avec index(NESTED LOOPS with index)
■ Comme BIB, sauf que les lignes la table interne sont obtenues à l’aide d’un index (au lieu d’un balayage):
■ TempsES (BII) = BR × TempsESBloc + NR × TempsES (index secondaire)
■ Exige d’avoir un index sur la colonne de jointure de la table située dans la boucle interne
POUR chaque ligne lR de R POUR chaque ligne lS de S satisfaisant θ (sélection en utilisant un index) Produire la ligne concaténée à partir de lR et lS FINPOUR
FINPOUR
34
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: BII sur Livre ⋈ Catégorie
■ R=Livre et S=Catégorie– TempsES (index secondaire sur Catégorie.code) = 5.5 ms
– TempsES (BII) = BLivre× TempsESBloc + NLivre× TempsES (index sec.) = 92.58 mins
■ R = Catégorie et S = Livre– TempsES (index secondaire sur Livre.code) = 284 ms
– TempsES (BII) = BCatégorie× TempsESBloc + Ncatégorie× TempsES (index sec.) = 18.92 mins
■ Observations:– Sélection par index pas tellement affectée par la taille de la table– Donc mettre la plus grande table dans la boucle interne de la
jointure BII (ex: table Livre dans ce cas)
NLivre 1 000 000FBLivre 20BLivre 50 000
NCatégorie 4 000FBCatégorie 40BCatégorie 100
35
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Contexte avantageux pour BII
■ Lorsqu’une des tables est beaucoup plus petite que l’autre
■ Ex: table produite par la sélection de la table Livre à l’aide d’une clé primaire (une seule ligne)
■ Dans ce cas, BII n’exige qu’une seule sélection par index (table Catégorie dans la boucle interne)
Livre
Catégories ISBN = 1-11-111-1111-1( S é l e c t i o n p a r i n d e x
s e c o n d a i r e s u r I S B N )
P titre, descripteur(Balayage)
(Boucle imbriquéeavec index secondaire
sur code de la tableinterne Catégorie)
36
Département de génie logiciel et des TI
■ On trie les tables R et S, et on les fusionne en faisant un balayagesynchronisé dans les tables triées
■ On joint les groupes de lignes ayant la même valeur pour la clé
■ TempsES (JTF) =TempsES (TRIR) + TempsES (TRIS) + 2 × (BR + BS) × TempsESBloc
© R. Godin, C. Desrosiers - Hiver 2011
Jointure par tri-fusion (SORT MERGE JOIN)
Trier R et S par tri externe et réécrire dans des fichiers temporaires
Lire groupe de lignes GR(cR) de R pour la première valeur cR de clé de jointure Lire groupe de lignes GS(cS) de S pour la première valeur cS de clé de jointure
TANT QUE il reste des lignes de R et S à traiter SI cR = cS
Joindre chaque paire de lignes GR(cR) et GS(cS); Lire les groupes suivants GR(cR) de R et GS(cS) de S;
SINON SI cR < cS Lire le groupe suivant GR(cR) de R;
SINON SI cR > cS Lire le groupe GS(cS) suivant dans S;
FINSI FIN TANT QUE
37
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: JTF sur Livre ⋈ Catégorie
■ M = 50– TempsES (JTF) = TempsES (TRILivre) + TempsES (TRICatégorie) +
2 × (Blivre+BCatégorie) × TempsESBloc = 287.4 secs– TempsES (BIM) = 15 secs (Catégorie dans la boucle externe)
■ Observations:– BIM est plus performante, même si sa complexité moyenne est
pire que celle de JTF– Explication: une des tables est petite (table Catégorie), donc
avantageux pour BIM (ou BII)
NLivre 1 000 000 FBMLivre 20 BLivre 50,000 TempsES(TRILivre) 177 000 ms
NCatégorie 4 000 FBMCatégorie 40 BCatégorie 100 TempsES(TRICatégorie) 134 ms
38
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple 2: 100 fois plus de Catégories
■ M = 50– TempsES (JTF) = 344.4 secs– TempsES (BIM) = 1046.4 secs
■ M = 10– TempsES (JTF) = 618 secs– TempsES (BIM) = 6253.5 secs
■ Observations:– Pour deux grandes tables, JTF est plus performante que BIM,
surtout s’il y a peu d’espace en mémoire centrale (M est petit)
NLivre 1 000 000 FBMLivre 20 BLivre 50,000 TempsES(TRILivre) 177 000 ms
NCatégorie 400 000 FBMCatégorie 40 BCatégorie 10 000 TempsES(TRICatégorie) 35 000 ms
39
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Jointure par hachage (HASH JOIN)■ Étape 1: partition des tables
■ Étape 2: jointure des lignes dans les paquets de même adresse
■ TempsES (JH) =TempsES (BALR) + TempsES (BALS) + 2 × (BR + BS) × TempsESBloc
{Partitionner R par hachage} POUR chaque ligne lR de R
Ajouter lR au paquet Ri , où i = h(clé de lR) Chaîner un nouveau bloc s'il y a débordement
FINPOUR
{Partitionner S par hachage} POUR chaque ligne lS de S
Ajouter lS au paquet Si , où i = h(clé de lS) Chaîner un nouveau bloc s'il y a débordement
FINPOUR
40
POUR chaque paquet Ri
POUR chaque ligne lR de Ri Joindre lR avec les lignes de Si ayant la même valeur pour la clé de jointure FINPOUR FINPOUR
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: JH sur Livre ⋈Catégorie
■ M = 50– TempsES (JH) = 270 secs– TempsES (JTF) = 344.4 secs– TempsES (BIM) = 1046.4 secs (R = Catégorie)
■ Observations:– Sauf si une table est déjà triée, JH est un peu plus rapide que JTF
NLivre 1 000 000 FBLivre 20 BLivre 50 000 TempsES (BALLivre) 5001 ms
NCatégorie 400 000 FBCatégorie 40 BCatégorie 10 000 TempsES (BALCatégorie) 1001 ms
41
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Pré-jointure par une organisation en grappe hétérogène (CLUSTER JOIN)
■ Les deux tables à joindre sont organisées dans une même grappe (cluster) hétérogène, selon la clé de jointure
– Ex: Client et Compte dans une même grappe selon la clé idClient
■ Les tables sont physiquement jointes dans la grappe– Ex: grappe ≈ Client ⋈ Compte (égalité sur idClient)
■ Il suffit de balayer séquentiellement les blocs de la grappe:– TempsES (PJ) = TempsES (BALR) + TempsES (BALs)– Optimal en théorie car un seul balayage des tables à faire, mais la
fragmentation interne peut nuire aux performances
42
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Exemple: PJ sur Livre ⋈ Catégorie
■ On suppose que les tables Livre et Catégorie sont organisées dansune même grappe, selon la clé code
■ TempsES (PJ) = 5 secs■ TempsES (BIM) = 15 secs (R = Catégorie, M = 50)
■ Observations:– PJ est trois fois plus rapide que BIM, même si l’une des tables est
beaucoup plus petite que l’autre– Pas toujours le cas en pratique
NLivre 1 000 000 FBLivre 20 BLivre 50 000 TempsES (BALLivre) 5001 ms
NCatégorie 4 000 FBCatégorie 40 BCatégorie 100 TempsES (BALCatégorie) 11 ms
43
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Comparaison des méthodes de jointure
■ BIB / BIM (NESTED LOOPS JOIN)– Une des deux tables à joindre (ou les deux) est petite et peut être
lue en mémoire centrale
■ BII (NESTED LOOPS INDEX JOIN)– Une des tables est beaucoup plus petite que l’autre et il y a un
index secondaire sur la clé de jointure de la plus grande table– La plus grande table est mise dans la boucle interne, et le coût
de sélection de ses lignes est amorti par l’index
44
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Comparaison des méthodes de jointure
■ JTF (SORT MERGE JOIN)– Pour joindre deux grandes tables– Permet également les jointures sur des conditions d’inégalité– Avantageux lorsqu’une des tables (ou les deux) est déjà triée selon la
clé de jointure (ex: index primaire ou tri d’une opération en amont)
■ JH (HASH JOIN)– Pour joindre deux grandes tables– Permet seulement les jointures sur des conditions d’égalité– Avantageux lorsqu’une des tables (ou les deux) est déjà organisée
dans une grappe homogène (single table hash cluster) selon la clé de jointure
45
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Comparaison des méthodes de jointure
■ PJ (CLUSTER JOIN)
– Optimal en théorie, mais peut parfois nuire à l’exécution: ■ Fragmentation importante de la mémoire secondaire
■ Ralentit le balayage d’une table dans la grappe (car les lignes de la table sont plus distantes les unes des autres)
■ Donc détériore la performance dans la situation ou le balayage est privilégié
46
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Optimisation
■ Chercher le meilleur plan d’exécution ?– Beaucoup trop de possibilités en pratique
■ Solution approchée à coût raisonnable– Générer un nombre limité d’alternatives prometteuses
■ Heuristiques (ex: ordre des sélections, projection, jointures, etc.)
– Choisir la meilleure■ Estimation approximative du coût d’exécution
47
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Plans d'exécutions équivalents
■ Plusieurs arbres algébriques équivalents
Livre Catégorie
s ISBN = 1-111-1111-1
P titre, descripteur
Livre
Catégories ISBN = 1-111-1111-1
P titre, descripteur
48
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Règles d’équivalences d’algèbre relationnelle
■ Eclatement d'une sélection conjonctive (SE)– s e1 ET e2 (T) = s e1 (s e2 (T))
■ Commutativité de la sélection (SC)– s e1 (s e2 (T)) = s e2 (s e1 (T))
■ Elimination des projections en cascades (PE)– p liste1 (p liste2 (T)) = p liste1 (T)
■ Commutativité de la jointure (JC)– T1 ⋈ T2 = T2 ⋈ T1
■ Associativité de la jointure (JA)– T1 ⋈ (T2 ⋈ T3) = (T1 ⋈ T2) ⋈ T3
49
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Règles d’équivalences d’algèbre relationnelle(suite)
■ Commutativité restreinte de la sélection et de la jointure (CSJ)– se (T1 ⋈ T2) = se (T1) ⋈ T2
– Si l'expression de sélection e ne contient que des colonnes de T1
■ Commutativité restreinte de la projection et de la sélection (CPS)– plisteCol (se (T)) = plisteCol (se (p(listeCol È col de e) T))
■ Commutativité restreinte de la projection et de la jointure (CPJ)– plisteCol (T1 ⋈ T2) =
plisteCol (p(listeCol Ç col de T1) (T1) ⋈ p(listeCol Ç col de T2) (T2))
■ etc.
50
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Plusieurs plans d’exécution pour un arbre algébrique
■ Pour chaque opération logique– Plusieurs choix d’opérations physiques
– etc.
Livre Catégorie
s ISBN = 1-111-1111-1
P titre, descripteur
(Jointure partri-fusion)
(Balayage)
(Balayage)
Livre Catégorie
s ISBN = 1-111-1111-1
P titre, descripteur
(Jointure parBIM)
(Balayage)
(Balayage)
Livre Catégorie
s ISBN = 1-111-1111-1
P titre, descripteur
(Jointure parhachage)
(Balayage)
(Balayage)
51
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Mise en oeuvre par matérialisation
Livre
Catégorie
s annéeParution = 2000
P titre, descripteur(Balayage)
(Boucle imbriquée parindex secondaire sur
code de la tableinterne Catégorie)
(Sélection par indexsecondaire surannéeParution)
52
Matérialisation:• On exécute les opérations depuis les
feuilles vers la racine de l’arbre algébrique
• Chaque opération produit une table intermédiaire
Désavantages:• Il faut écrire les tables intermédiaires sur
disque si elles sont volumineuses
• Pas d’index sur les tables intermédiaires, donc les opérations sur ces tables sont coûteuses
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Mise en oeuvre par pipeline
Livre
Catégorie
s annéeParution = 2000
P titre, descripteur (Balayage)
(Boucle imbriquée parindex secondaire sur
code de la tableinterne Catégorie)
(Sélection par indexsecondaire surannéeParution)
53
Pipeline:• Chaque ligne traverse toutes les
opérations sans être écrite dans une table temporaire
Avantage:• Aucune écriture supplémentaire
Désavantage:• Pas adapté à toutes les opérations• Ex (tri): on doit trier toutes les lignes en
même temps
En pratique:• On utilise le pipeline si possible, sinon la
matérialisation
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Heuristiques d'optimisation
■ Élaguer l’espace des solutions– Solutions non applicables
■ Exemples d’heuristiques– Sélections le plus tôt possible– Projections le plus tôt possible– Les jointures plus restrictives en premier– Jointures supportées par index, hachage ou grappe en
premier
54
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Optimisation par coût
■ Minimiser le coût (ex: temps d’exécution)
■ Stratégies– Programmation dynamique– Amélioration itérative– Recuit simulé– Algorithme génétique– etc.
55
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Estimation du coût d'un plan d'exécution
Livre Catégorie
(Jointure par tri-fusionTempsES = 2 873 540 ms)
(BalayageTempsES = 92 314 ms)
s ISBN = 1-111-1111-1
P titre, descripteur
(Ecriture du résultatTempsES = 846 164 ms)
(Ecriture du résultatTempsES = 11 ms)
(BalayageTempsES = 11 ms)
Coût total =3 812 040ms
TempsES(Plan avec pipeline) = TempsES(JTFLivre ⋈ Catégorie) = 287 354 ms
56
1.1
1.1
9231
84 616
287 354
381 204
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Autre exemple
Livre
Catégorie
P titre, descripteur
(Boucle imbriquée parindex secondaire sur
code de la tableinterne Catégorie
TempsES = 44ms)
s ISBN = 1-111-1111-1 (Sélection par indexsecondaire sur ISBNTempsES = 55ms)
(Ecriture du résultatTempsES = 11ms)
(Ecriture du résultatTempsES = 11 ms)
(BalayageTempsES = 11 ms)
Coût total =132ms
TempsES(Plan avec pipeline) =
TempsES(S=IS pour index sur ISBN) +
N s ISBN=1-11-111-1111 (Livre) * TempsES(S=IS sur codede Catégorie)
= 5.5 ms + 3.3 ms = 8.8 ms
57
1.1
1.1
4.4 ms)
1.1 ms)
5.5 ms)
13.2 ms
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Types d’optimisation Oracle■ COST (statistique): minimise le coût estimé
– Besoin de statistiques (ANALYSE)– Plus cher à calculer mais donne de meilleurs plans d’exécution– Mode ALL_ROWS
■ Minimise le temps total■ Ex: on préfère JTF à BIM pour joindre deux grandes tables
– Mode FIRST_ROWS■ Minimise temps de réponse (obtention des premières lignes)■ Ex: on préfère BIM à JTF pour joindre deux grandes tables■ Pour les applications interactives où on n’a pas besoin de voir
simultanément toutes les lignes d’une requête
■ RULE (heuristique)– Utilisé seulement lorsque des statistiques ne sont pas disponibles
58
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Optimisation heuristique
■ Oracle– mode RULE
Rang Chemin d'accès1 Sélection par ROWID2 Sélection d'une ligne par jointure dans une organisation par
index groupant ou hachage hétérogène (CLUSTER)3 Sélection d'une ligne par hachage sur clé candidate
(PRIMARY ou UNIQUE)4 Sélection d'une ligne par clé candidate5 Jointure par une organisation par index groupant ou
hachage hétérogène (CLUSTER)6 Sélection par égalité sur clé de hachage (HASH CLUSTER)7 Sélection par égalité sur clé d'index groupant (CLUSTER)8 Sélection par égalité sur clé composée9 Sélection par égalité sur clé simple d'index secondaire10 Sélection par intervalle borné sur clé indexée11 Sélection par intervalle non borné sur clé indexée12 Tri-fusion13 MAX ou MIN d'une colonne indexée14 ORDER BY sur colonne indexée15 Balayage
59
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Changement du mode pour une session
■ ALTER SESSION SET OPTIMIZER_GOAL =– RULE | ALL_ROWS | FIRST_ROWS | CHOOSE
60
Département de génie logiciel et des TI © R. Godin, C. Desrosiers - Hiver 2011
Indices d'optimisation (hints)
61
■ Suggère au SGBD des optimisations pour une requête
■ Sert en mode de conception ou lorsque l’optimiseur ne choisit pas un plan optimal (ex: mauvaises statistiques)
■ Exemple 1: Forcer l’utilisation du mode d’optimisation RULE
■ Exemple 2: Forcer l’utilisation de l’index secondaire pour les sélections sur la colonne index_sexe de Employé (mauvaise idée)
SELECT /*+ RULE*/ nomFROM ClientWHERE noClient = 10 ;
SELECT /*+ INDEX(EMPLOYÉ INDEX_SEXE)*/ nom, adresseFROM EMPLOYÉ WHERE SEXE = ‘F’
Département de génie logiciel et des TI
Optimisation dans SQL Developper
■ Mode AUTOTRACE
© R. Godin, C. Desrosiers - Hiver 2011 62
Département de génie logiciel et des TI
Optimisation dans SQL Developper
■ Plan d’exécution:
© R. Godin, C. Desrosiers - Hiver 2011 63
OPERATION Nom de l’opération du plan d’exécution (ex : NESTED LOOPS, HASH JOIN)
COST Coût de l’opération estimé par l’optimiseur de requête (~ nombre de blocs en E/S)
LAST_CR_BUFFER_GETS Nombre de blocs lus de la cache pour chaqueopération, lors de la dernière exécution
LAST_ELAPSED_TIME Temps (en microsecondes) passé dans chaqueopération, lors de la dernière exécution
LAST_STARTS Nombre de fois qu’une opération a été faitelors de la dernière exécution
Département de génie logiciel et des TI
Optimisation dans SQL Developper
■ Statistiques d’exécution (liste partielle):
© R. Godin, C. Desrosiers - Hiver 2011 64
consistent gets Nombre de blocs lus en mémoire centrale après accèséventuel au disque
physical reads Nombre de lectures effectives sur le disque (en blocs)
redo size Le nombre d’octets générés pour le journal permettant de refaire l’opération (redo log)
bytes sent Le nombre d’octets envoyés de la BD au client par le réseau.
bytes received Le nombre d’octets envoyés du client à la BD par le réseau
Département de génie logiciel et des TI
Oracle SQL Tuning Advisor
© R. Godin, C. Desrosiers - Hiver 2011 65
Source: Oracle® Database 2 Day + Performance Tuning Guide 11g Release 1 (11.1)
Recommended