1 Évaluation des Requêtes: Survol Chapitre 12. 2 Objectifs Catalogue Préliminaires: Techniques de base pour traiter des requêtes Chemin daccès Correspondance.

Présentation au sujet: "1 Évaluation des Requêtes: Survol Chapitre 12. 2 Objectifs Catalogue Préliminaires: Techniques de base pour traiter des requêtes Chemin daccès Correspondance."— Transcription de la présentation:

1 1 Évaluation des Requêtes: Survol Chapitre 12

2 2 Objectifs Catalogue Préliminaires: Techniques de base pour traiter des requêtes Chemin daccès Correspondance dindexes Sommaire des algorithmes de traitement des requêtes Sélection Projection Join Introduction à loptimisation des requêtes Plans dévaluation Plans alternatifs

3 3 Évaluation des Requêtes: Survol Évaluation dune requête SQL: Analysée syntaxiquement, ensuite transformée en plan dévaluation. Plan dévaluation: Arbre dopérations de lalgèbre relationnelle avec un choix dalgorithme pour chaque opération. Deux problématiques importantes dans loptimisation: Énumération des plans alternatifs pour une requête Estimation des coûts de ces plans et choix de celui estimé être le moins cher On doit se montrer pragmatique: Idéalement: Trouver le meilleur plan. Pratiquement: Éviter les pires plans! Approche utilisé: Système R.

4 4 Quelques Techniques Communes Les algorithmes pour lévaluation des opérateurs relationnels utilisent largement trois idées simples: Indexes: Utilisation des conditions des clauses WHERE pour puiser de petits ensembles de tuples (sélections, joins) Itération: Scannage de tous les tuples dune relation (même sil y a un indexe). Parfois, le scannage est fait sur des entrées des données de lindexe plutôt que sur la relation elle-même Partition: Division dune instance de relation en un ensemble de relations plus petites de manière à appliquer une opération coûteuse sur ces petites relations plutôt que sur la relation originale.

5 5 Statistiques et Catalogues Lévaluateur a besoin dinfo sur les relations ainsi que les indexes impliquées. Les Catalogues contiennent: pour chaque relation: # tuples (NTuples) et # pages (NPages) pour chaque index: # valeurs de clés distinctes (NKeys) et # pages (NPages) pour chaque index à arbre: Hauteur de lIndex (Height), plus petites / plus grande valeurs de clé (Low/High) Catalogues rafraîchis périodiquement. Doù lon vivra avec de légères inconsistances ! Dautres types dinfos détaillées (p.ex., histogrammes des valeurs dans certains champs) sont aussi stockées. Histogramme: structure donnant une approximation de la distribution des valeurs des données

6 6 Chemins dAccès et Correspondance dIndex Un chemin daccès est une méthode pour puiser les tuples: Utilisation du Scannage du fichier, ou dun index qui correspond à (match) une sélection (WHERE) de la requête. Un index à arbre correspond à une conjonction de termes qui mentionnent seulement des attributs dun préfixe de la clé de recherche. P.ex., lindex à arbre sur correspond à la sélection a=5 AND b=3 et à a=5 AND b>6, mais pas à b=3. Un index à hachage correspond à une conjonction de termes qui a un terme de la forme attribut = valeur pour chaque attribut de la clé de recherche de lindex. P.ex., lindex à hachage sur correspond à a=5 AND b=3 AND c=5 ; mais pas à b=3, ni à a=5 AND b=3, ni à a>5 AND b=3 AND c=5.

7 7 Algorithmes dOpérations Relationnelles Quelles sont les algorithmes dévaluation des principaux opérateurs de lalgèbre relationnelle ? Supposez une distribution uniforme des valeurs d attributs (Cette supposition est naïve, mais simplifie la discussion !!) Détails au Chapitre 14 Illustration des coûts estimés Exemple: Sailors( sid :integer, sname : string, rating : integer, age : real) Reserves( sid : integer, bid : integer, day : date, rname : string) Supposez: Reserves: tuples de 40 bytes; #tuples/pg = 100; #pgs = 1000 Sailors: tuples de 50 bytes; #tuples/pg = 80; #pgs = 500

8 8 Sélection Si aucun indexe nexiste, faire un scan. Sinon, trouver le chemin daccès le plus sélectif, puiser les tuples en lutilisant et appliquer tout terme de sélection restant qui ne correspond à aucun index choisi: Chemin daccès le plus sélectif : Index ou scannage de fichier qui requiert le plus petit nombre dentrées et sorties (I/Os) de pages possible. Facteur de sélection : Fraction de tuples qui satisfont un terme conjoint. Tout terme qui correspond à un index utilisé réduit le nombre de tuples puisés ; tout autre terme dans la sélection est utilisé pour discriminer certains tuples puisés sans affecter le nombre de tuples/pages puisés. P.ex.: day pourrait être utilisé; dans ce cas, cest day<8/9/94 qui doit alors être vérifié. SELECT * FROM Reserves R WHERE day<8/9/94 AND bid=5 AND sid=3

9 9 Utilisation dun Index pour des Sélections Le coût dépend du # de tuples qualifiés et du groupement de lindex. Coût total = coût pour trouver lentrée des données qualifiées (typiquement négligeable), plus le coût de puiser les enregistrements (non négligeable si lindex nest pas groupé). Dans lexemple ci bas, environ 10% de tuples sont qualifiés (100 pages, 10000 tuples). Avec un index groupé, le coût peut être de lordre de 100 I/Os; avec un index non groupé, il peut aller jusquà 10000 I/Os! SELECT * FROM Reserves R WHERE R.rname < C%

10 10 Projection Simplement effacer les attributs autres que sid et bid. La partie coûteuse est leffacement des duplicatas. Les systèmes SQL néliminent pas les duplicatas à moins de le spécifier explicitement avec le mot clé DISTINCT. Deux alternatives pour traiter DISTINCT: Élimination par triage: Trier Reserves par et éliminer les duplicatas. (Optimisation possible: éliminer des colonnes en passant pendant le triage) Élimination par hachage: Hacher sur pour créer des partitions. Charger ces partitions en mémoire principale, chacune à la fois, construire une structure de hachage en mémoire et éliminer les duplicatas. Si un index existe sur R.sid et R.bid à la fois, le triage peut même se faire sur les entrées dindexes ! SELECT DISTINCT R.sid, R.bid FROM Reserves R SELECT R.sid, R.bid FROM Reserves R

11 11 Join: Index Nested Loops « Jointure à boucles imbriquées avec index». Sil y a un index sur la colonne de la condition de join dune des relations (p.ex. S), faire de cette relation la relation interne (inner) et exploiter lindex. Pour chaque tuple de Reserves, le coût de la vérification de lindex sur Sailors (index probing) est denviron 1.2 pour le hachage et 2-4 pour les arbres B+. Le coût de trouver le tuple correspondant de Sailors dépend ensuite du groupement de lindex. foreach tuple r in R do foreach tuple s in S where r i == s j do add to result

12 12 Exemples de Index Nested Loops Hachage (Alt. 2) de sid de Sailors (rel. interne): Scannage de Reserves: 1000 I/Os de pages, 100*1000 tuples. Pour chaque tuple de Reserves: 1.2 I/Os pour obtenir lentrée dindex, plus 1 I/O pour obtenir le tuple correspondant de Sailors. Total: 220,000 I/Os (=100,000 * (1+1.2)). Hachage (Alt. 2) de sid de Reserves (rel. interne): Scannage de Sailors: 500 I/Os de pages, 80*500 tuples. Pour chaque tuple de Sailors: 1.2 I/Os pour trouver la page de lindex contenant lentrée des données, plus le coût de puiser les tuples correspondants de Reserves. Supposez 2.5 réservations par navigateur (100,000 / 40,000); le coût pour les puiser est de 1 ou 2.5 I/Os dépendant du fait que lindex est regroupé ou pas.

13 13 Join: Sort-Merge (R S) « Jointure à tri-fusion ». Trier R et S selon leur colonne de join, ensuite les scanner afin de faire une fusion (suivant la colonne de join.), enfin sortir les tuples du résultat. Avancer le scannage de R jusquà ce que le tuple courant de R >= tuple courant de S, ensuite avancer le scannage de S jusquà ce que le tuple courant de S >= tuple courrant de R; répéter cela jusquà ce que le tuple courrant de R = tuple courrant de S. A ce moment, tous les tuples de R avec la même valeur que le groupe courant de S correspondent ; sortir tous ces tuples qui correspondent. Continuer le scannage de R et S. R est scanné une fois; chaque groupe de S est scanné une fois pour chaque tuple correspondant de R. i=j

14 14 Exemple de « Sort-Merge Join » coût: M log M + N log N + (M+N) Le coût du scannage (M+N) pourrait devenir M*N Avec 35, 100 ou 300 pages tampon, Reserves et Sailors peuvent toutes les deux être triées en 2 passages; coût total du join: 7500.

15 15 Aspects Importants de lOptimisateur du Système R Espaces des plans: Trop large, doit être élagué. Considère seulement les left-deep plans. Ceux-ci permettent du pipelining des résultats dune opération dans une autre sans laide dun stockage temporaire. Évite le produit Cartésien. Estimation des coûts: Approximation au mieux. Statistiques maintenues dans les catalogues et utilisées pour estimer les coûts des opérations et la taille des résultats. Considère la combinaison des coûts CPU et I/O. Impact: Couramment utilisé; marche bien pour < 10 joins.

16 16 Estimation et Facteur de Réduction Considérez un bloc de requête: Maximum # tuples du résultat = produit des cardinalités des relations dans la clause FROM. Un facteur de réduction (FR) est associé avec chaque terme. Cardinalité du résultat = Max # tuples * produit de tous les FRs. Supposition implicite: tous les termes sont indépendants! FR( col=value) = 1/NKeys(I), avec lindex I sur col FR( col1=col2) = 1/ MAX (NKeys(I1), NKeys(I2)) FR( col>value) = (High(I)-value)/(High(I)-Low(I)) SELECT A_1, A_2, …, A_n FROM R_1, R_2, …, R_m WHERE terme_1 AND... AND terme_k

17 17 Exemple coût: 500+500*1000 I/Os On rate beaucoup de choses à faire ici: les sélections pourraient être faites plutôt, aucun indexe nest utilisé, etc. But de loptimisation: Trouver des plans plus efficients qui donnent la même réponse que le plan original. SELECT S.sname FROM Reserves R, Sailors S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5 Reserves Sailors sid=sid bid=100 rating > 5 sname Reserves Sailors sid=sid bid=100 rating > 5 sname (Simple Nested Loops) (On-the-fly) Arbre de lA.R.: Plan:

18 18 Plan Alternatif 1 (Aucun Index) Différence principale: sélections le plutôt que possible. Avec 5 pages tampon, on a le coût suivant: Scannage de Reserves (1000) + écriture de temp T1 (10 pages, si on a 100 bateaux et une distribution uniforme). Scannage de Sailors (500) + écriture de temp T2 (250 pages, si on a 10 niveaux (ratings)). Triage de T1 (2*2*10), triage de T2 (2*3*250), et enfin merge (10+250) Total: 3560 I/Os de pages. Un join BNL donnerait un coût de 10+4*250; coût total = 2770. Avec des projections le plutôt que possible, T1 ayant seulement sid et T2 seulement sid et sname on aurait: T1 tient en 3 pages; le coût de BNL descend en dessous de 250 pages; total < 2000. Reserves Sailors sid=sid bid=100 sname (On-the-fly) rating > 5 (Scan; Sauver temp T1) (Scan; Sauver temp T2) (Sort-Merge Join)

19 19 Plan Alternatif 2 (Avec Indexes) Avec un index groupé sur bid de Reserves, on a 100,000/100 = 1000 tuples sur 1000/100 = 10 pages. Reserves Sailors sid=sid bid=100 sname (On-the-fly) rating > 5 (Index à hachage, aucune écriture du résultat temporaire) (Index Nested Loops, pipelining ) (On-the-fly)

20 20 Résumé Il existe plusieurs algorithmes alternatif dévaluation des opérateurs relationnel. Une requête est évaluée en la convertissant en un arbre dopérateurs et en évaluant les opérateurs de larbre en question. Deux parties majeures de loptimisation des requêtes: Considère un ensemble de plans alternatifs. Doit élaguer lespace de recherche des plans; typiquement seuls les left- deep plans seulement sont considérés. Estime les coûts de chacun des plans considérés. Doit estimer la taille des résultats et le coût pour chaque nœud du plan. Problématiques clé : Statistiques, indexes, implémentation des opérateurs.