Opérateurs relationnels Architecture en couche d’un SGBD

Interface
1. Gestion de la mémoire
Analyseur sémantique
2. Algorithmes de sélection
Optimiseur

3. Algorithmes de jointure Evaluateur de plan d’exécution

Opérateurs relationnels
4. Autres opérateurs
Méthodes d’accès aux données

Gestion de Gestion de Gestion des

Mémoire Verrous Journaux

Système d’exploitation
1 2

Gestion de la mémoire par l’OS ou le SGBD ? Comment répartir la mémoire ?

• L’OS considère toutes les pages comme équivalentes

Query 2
– Application d’heuristiques de swap (ex: LRU)
– Pas de connexion avec le verrouillage/journalisation BD

Op. 2 Op. 3
• Le SGBD a une connaissance du contenu des pages et de leur

Query 1
utilisation
– Permet d’optimiser les accès aux pages

Disponible

Nécessaire
Problème complexe …

Op. 1
• prefetching,
• heuristiques associées aux opérateurs (patterns d’accès connus) … et important
– Permet de ne pas swapper des pages déjà existantes dans la BD Entre les Entre les Dans un
– Ecritures disques faites en accord avec la gestion de transactions requêtes opérateurs opérateur
(journalisation)

3 4
 Adapter les opérateurs à la mémoire ! Les opérateurs
• Le choix de la bonne implémentation d’un opérateur • Sélection (σ), sélection d’un sous ensemble des tuples d’une table
– Par Scan, par index
relationnel (select, project, join, union, etc.) dépend
• Projection (π), sélection d’un sous ensemble d’attributs d’une table
– de la requête et de sa sélectivité – Par Scan, par index, par tri ou hachage (si élimination des doublons)
– des caractéristiques des inputs (tables en entrée) • Jointure (∞), combinaison de deux tables sur critère
– Par boucles imbriquées
– de ses paramètres (prédicat de jointure, de sélection, etc.) – Par index
– des structures d’indexation existantes – Par tri
– Par hachage
– et de la quantité de mémoire disponible
• Autres opérateurs
– Groupement, agrégats
– Différence (-), Union (∪), Intersection (∩)
• Quels sont les différents choix ? Objet de ce cours
• Chaque opérateur prend en entrée une ou deux tables et renvoie une table
• Comment choisir ? Problématique d’optimisation possibilité de composer les opérateurs pour former des plans (arbres)
d’exécution de requêtes
(cours suivant)

5 6

Sélection σ: par Scan Sélection σ : utilisation d’un index

• Quand utiliser l’index ?
• Algorithme Select (R, Q) : – Si la sélectivité est forte (S très petit)
For each page p de R do { – car coût(I/O aléatoire) >> coût(I/O séquentielle)
Read (p); • Ex. SQL> SELECT * Comparer les coûts d’accès:
> FROM Medicament 1) Sans index;
2) Avec index plaçant sur Nom;
For each tuple t de p > WHERE Nom = ‘N%';
3) Avec index non plaçant sur Nom
{ if Check (t, Q) then result = result ∪ t ;} ;
– Médicaments = 100.000 tuples stockés dans 1000 pages contiguës;
} – Noms uniformément distribués; I/O = 10ms + nbpages x 0,2ms
• La solution la plus simple et la meilleure quand la – Il y a 5 % de médicaments commençant par un N (=‘N%’)
sélectivité est très faible (ex: chaque page contient au • NB : optimisation des accès aux données par index non plaçant
moins un tuple qualifié) – Trouver dans l’index les Rid qualifiés
– Trier les Rid qualifiés
– Result  = S* R , avec 0 ≤ S ≤ 1
– Accéder les tuples sur disque dans l’ordre des Rid
– ATTENTION: Sélectivité faible = S élevé et vice-versa (pour ne pas accéder 2 fois la même page…)

7 8
 Sélection σ : utilisation de plusieurs index Projection
• Identification des index les plus sélectifs • Habituellement intégrée à la production du résultat du dernier
opérateur du plan ( coût nul)
• Intersection et union de listes de Rid de ces index
• L’opération coûteuse est l’élimination des doublons
– Accès aux tuples dont les identifiants sont retenus
– SQL n’élimine pas les doublons
– Vérification du reste du critère sur les tuples résultat (sauf si la clause DISTINCT est spécifiée dans la requête)
– Exemple :
SQL> SELECT DISTINCT V.id, V.doc
• (SPEC=‘Dentiste’ OR SPEC=‘Stomatologie’) AND (ADRESSE = > FROM Visite V ;
‘Versailles’) AND (AGE>30)
• L = (S1 ∪ S2) ∩ A1 • Algorithme
• Accéder aux tuples de L et vérifier le critère AGE – Basé sur du tri ou du hachage
• Les index bitmap permettent de combiner
efficacement des critères peu sélectifs • Remarques sur l’approche tri
– Le résultat final est de fait trié
– C’est l’implantation standard choisie par les éditeurs de SGBD

9 10

Coût du Tri Coût du Tri : exemple en 2 phases

• Comment trier une table qui ne tient pas en mémoire ? • A chaque passe : lecture et écriture du fichier complet
– Problème récurrent en base de données Fichier à trier
– Solution = algorithme de tri-fusion – Soit 2 N I/Os 3,4 6,2 9,4 8,7 5,6 3,1 2
Passe 0
• La table est triée par morceaux (monotonies) 3,4 2,6 4,9 7,8 5,6 1,3 2
• Les monotonies sont fusionnées entre elles Passe 1

2,3 4,7 1,3

• Nombre de passes = 1+ logM-1 N / M  (N = Nb de pages à trier, 4,6 8,9 5,6 2
M = Nb de pages mémoire) Passe 2
2,3
4,4 1,2
• Coût I/O = 2N x (nombre de passes)
6,7 3,5
– Lecture et écriture (complète) des pages de la table à chaque passe
8,9 6
Passe 3
• Ex. 5 pages en RAM, pour trier 108 pages
– Passe 0: 108 / 5 = 22 monotonies triées de 5 pages chacune • Fichier de N pages 1,2
Fichier trié
(sauf la dernière qui contient 3 pages)
– Passe 1: 22 / 4 = 6 monotonies triées de 20 pages chacune (resp. 8 pages)
– Nb de passes = log2 N  + 1 2,3
3,4
– Passe 2: 2 monotonies triées de 80 pages (et 28 pages) – I/Os = 2 N ( log2 N  + 1 ) 4,5
– Passe 3: fichier trié de 108 pages 6,6
– Coût total = 2*108*4 = 864 I/O 7,8
9
11 12
 Nombre de passes du Tri Fusion Jointure
• L’opérateur le plus étudié en BD car le plus coûteux
• Variations de l’algorithme de jointure
– Par boucle
• Jointure par boucles imbriquées ((Block-) Nested Loop Join)
– Par index
• Jointure par index (Index Join)
– Par tri
• Jointure par tri fusion (Sort Merge Join)
– Par hachage
• Jointure par hachage (Hash Join)
• Jointure par hachage de Grace (Grace Hash Join)
• Jointure par hachage hybride (Hybrid Hash Join)
• NB : ces d’algorithmes peuvent êtres adaptés à
d’autres opérateurs binaires (intersection, différence,
13
etc.) 14

Comparaison des algorithmes de jointure Jointure Brute-Force : Nested Loop

• On veut joindre les tables DOCteur et VISite
• Egalement appelée jointure par Produit Cartésien
DOC id Nom spécialité …… VIS
1 5 Pédiatre ……
id
1
docid
3
date
……
prix
……
……
…… • Algorithme Join(DOC, VIS, Q)
2 2 Radiologue …… 2 2 …… …… ……
3 1 Pneumologue …… 3 2 …… …… …… For each page p de DOC
… … … …… 4 3 …… …… ……
5 1 …… …… …… For each page q de VIS
6 1 …… …… ……

• Coût = Nombre d’I/O 7 3 …… …… …… For each tuple tp de p

… … …… …… ……

- on ne distingue pas I/O séquentielles et aléatoires For each tuple tq de q

- on ne compte pas le coût d’écriture du résultat final (identique pour tous) if Check (tp, tq, Q) then result = result ∪ (tp||tq) ;
• Paramètres
– |DOC| = Nombre de pages occupées par DOC • Coût I/O = |DOC| + |DOC| * |VIS|
– ||DOC|| = Nombre de tuples dans DOC
– |DOC| << |VIS| • Fonctionne quel que soit Q et quel que soit M ≥ 3
– M = Nombre de pages mémoire disponibles
• Très sous-optimal dès que M > 3
(NB : quelques approximations pour simplifier les formules) 15 16
 Jointure : Block Nested Loop Jointure par index
• Algorithme • Hypothèses
– DOC = table externe (outer relation) de la jointure
• Choisir la table la plus petite comme table externe – Un index sur l’attribut de jointure de VIS (ou de DOC)
• Chargement par bloc de M-2 pages
– VIS = table interne (inner relation) de la jointure – L’index a n niveaux et tient sur p pages
• Chargement par bloc d’une page en RAM
• Principe (équi-jointure)
DOC – Choisir comme table interne celle qui a un index sur l’attribut
RAM
Page D

de jointure (ex. VIS) et utiliser l’index

Page 2

Page 1

IN M-2
DOC ∞ VIS

IN 2

IN 1
…

Page K

Page 2

Page 1
OUT M
VIS
…

…
FOR EACH tuple tD IN DOC
Page V

Page 2

Page 1

IN M-1

Accède index(VIS.DocId, tD.join_key) L= {tV }

…

∀tV∈L Ajoute tDtV au résultat

END FOR

• Coût en I/O = |DOC| + |DOC|/(M -2) × |VIS| – Coût = |DOC| + ||DOC|| × (n+1) si M=4
• Les idées simples sont parfois les meilleures – Coût = |DOC| + p + |VIS| si M = |VIS| + p
– NB1: algo optimal si la table externe tient en mémoire !
– NB2: en plus, ne génère que des I/O séquentielles – Par rapport à Block Nested Loop ?
17 18

Jointure par Tri Fusion : Sort-Merge Join Jointure par hachage (Hash Join)
• Principe de l’algorithme : (équi-jointure DOC.id = VIS.docid)
• Principe de l’algorithme : (équi-jointure DOC.id = VIS.docid)
– Phase de construction (Build)
– Trier DOC (resp. VIS) sur DOC.id (resp. VIS.docid) • Charger DOC, hacher en RAM en n paquets, avec n le plus grand possible compatible
VIS
– fusionner DOC et VIS 1 id docid date ……
avec M
– Produire les tuples résultat 4 3
5 1 …… ……
h=1
6 1 …… …… DOC h=2
DOC 3 2 …… ……

Page D

Page 2

Page 1
4 3

…
1 id Nom spécialité …… 2 2 …… …… IN 1 h M-2 pages
Etc. …
1 5 Pédiatre …… 4 3 …… ……
4 2

4 2
2 2 Radiologue …… 1 3 …… …… RAM h = ||DOC||
3 1 Pneumologue …… 7 3 …… ……
Etc.
… … … …… … … …… ……
– Phase de test (Probe)
• Parcourir VIS, pour chaque tuple tester la table de hachage et produire les résultats
1 5 Pédiatre …… 5 1 …… ……
DOC
5 1 5 Pédiatre …… 6 1 …… …… VIS IN 2 DOC ∞ VIS

Page D+V
IN 3

OUT M

Page 2

Page 1
2 2 Radiologue …… 3 2 …… ……
• Coût du Sort-Merge Join
Page V

Page 2

Page 1
…

…
…
5 2 2 Radiologue …… 2 2 …… ……
IN 1 h
…
– Tri des deux tables
IN M-1
• 2×|DOC|×(1 + log M-1 |DOC|/M) // ou 0 si DOC déjà triée RAM

• 2×|VIS|×(1 + log M-1 |VIS|/M) // ou 0 si VIS déjà triée • Coût

– Fusion – Identique à la jointure (Block-) Nested Loop en terme d’I/O !
• |DOC| + |VIS| – Optimise le coût CPU de la jointure
19 20
 Jointure par hachage (Grace Hash Join) Jointure par hachage Hybride (Hybrid Hash Join)
• Principe de l’algorithme : (équi-jointure DOC.id = VIS.docid) • L’approche Hybrid Hash Join est optimiste
– Phase de construction (Build) : Hacher DOC et VIS sur disque avec la même fonction h
• Hachage en n partitions, avec n ≤ M-1 – On espère que la plus petite table (DOC) tient en mémoire
IN 2 Page 1 Page 2 – Build :
Page D

Page 1
Page 2
DOC IN 3 Page 3 Page 4 Page 5
• On hache cette table en n paquets comme dans l’algorithme Hash join
…
IN 1
h …
RAM IN M Page … Page D
VIS
• Si cette table tient en RAM, build optimal
IN 2
Page 1 Page 2 Page 3
• Sinon, sélectionner des partitions qui vont déborder sur disque
Page V

Page 2

Page 1
IN 3
…

IN 1
h … Page … Page V
RAM IN M

• Coût I/O du Build = 2 × (|DOC| + |VIS|) DOC h

h=n
– Phase de test (Probe) : Joindre DOC et VIS par partition Page 1 h=1
IN 2
h=2
IN … IN … IN …
Page 2
• Les tuples de la partition i de DOC joignent uniquement avec la partition i de VIS IN 1 IN 3
……
IN
… …
• Joindre les partitions de même numéro par Hash join Page D
… IN … …
IN … IN M
RAM
IN 2
Page 1 Page 2 h’ IN 3
Page 3 Page 4 Page 5

DOC ∞ VIS
…
IN M-1
Page … Page D
… IN 2 IN …

Page D+V
h’

Page 2

Page 1
IN 3

…
Page 1 Page 2 Page 3 IN 1 OUT …
… IN …
Page … Page V RAM IN …

• Coût I/O du Probe = |DOC| + |VIS|

– Diviser pour régner: une grosse jointure remplacée par n petites
21 22

Jointure par hachage (Hybrid Hash Join) Coût de la jointure (Hybrid Hash Join)
– Probe1 • Coût I/O
• Appliquer la même fonction de hachage h aux tuples de VIS – Hypothèse M = |DOC|/k // optimal avec k=1
• Si h(tV) correspond à une partition de DOC en mémoire, produire les – Build : |DOC| + |DOC|(k-1)/k
résultats
– Probe1 : |VIS| + |VIS|(k-1)/k
• Sinon, écrire la partition correspondante de VIS sur disque (i.e., Build
– Probe2 : |DOC|(k-1)/k + |VIS|(k-1)/k
partiel)
DOC VIS – Total = (|DOC|+|VIS|) x (1 + 2 (k-1)/k) I/O
IN 2

IN 3
IN … IN … IN …
• Avec k = 1,5 (i.e., 2/3 de DOC tient en RAM) 1,66 × (|DOC|+|VIS|) I/O
IN……

2,8 × (|DOC|+|VIS|) I/O

… …
… IN … IN …
DOC ∞ VIS • Avec k = 10 (i.e., 10% de DOC tient en RAM)
IN …
Page 1

VIS Page 2
h
Page 1
Page 2
h=1 h=2
IN …
h=n

IN …
… • Comme quoi certaines solutions compliquées sont parfois aussi
…
IN 1
……
IN
…
OUT Page … très bonnes …
Page V IN M
RAM

– Probe 2 • Technique implantée dans la plupart des SGBD commerciaux

– Oracle, MS SQL Server, IBM DB2, …
• Joindre (si besoin) les partitions disque de DOC et de VIS comme
dans l’algorithme Grace Hash Join 23 24
 Autres opérateurs CONCLUSION
• Groupements et agrégats
– Les tuples peuvent être groupés par tri ou hachage • Pour chaque opérateur de l’algèbre, plusieurs
– Optimisation: calculer l’agrégat en même temps que le groupement implémentations possibles
• évite une seconde passe et réduit le nb d’I/O du groupement en maintenant
en RAM le calcul intermédiaire plutôt que de la liste des tuples membres • Pas d'algorithme systématiquement meilleur !
– Le bon choix dépend de :
• Union (∪), intersection (∩) et différence () • La taille des tables opérandes
• La quantité de RAM affectée à l’opérateur
– Adaptation des algorithmes de jointure (exemples) • L’organisation des tables (indexées, hachées)
• R∩S • la sélectivité de la condition de jointure (PS: 90% des jointures sont
– Évaluer la condition de jointure sur tous les attributs clé et projeter sur des équi-jointures sur clé)
les attributs d’une seule des deux tables
• RS
• Nécessité d'un modèle de coût précis et d’un
– Évaluer la condition de jointure sur tous les attributs clé optimiseur de requêtes
– Retirer de R tous les tuples qui joignent et produire le résultat – Mais encore faut-il que l’administrateur BD ait produit les
• R∪S conditions d’un bon choix !
– Calculer (R  S) + S, où + est une simple concaténation
25 26

Evaluation de requêtes

Interface

Analyseur sémantique
Mise en œuvre dans les
Optimiseur
SGBDR Evaluateur de plan d’exécution

Opérateurs relationnels

Méthodes d’accès aux données

Gestion de Gestion de Gestion des

Mémoire Verrous Journaux

Système d’exploitation
27 28
 Exécution d’une requête Exécution matérialisée
• Combinaison d’opérateurs physiques • Evaluation complète d’un opérateur à la fois
– Ex. Implantation physique de la jointure
π – Chaque opérateur prend en entrée une table
(ou deux pour les opérateurs binaires) π
• Deux opérateurs
– Build : construction de la table de hachage – Et produit une table en sortie
Probe
– Probe : test avec la table de hachage
• Résultats de chaque opérateur matérialisé Probe

• Les opérateurs physique s’interfacent σ Build – Sur disque dans des relations temporaires
σ Age > 32 Build
• Représentation sous forme d’arbre d’opérateurs
Scan Scan
• Ex. Scan Scan
DOC VIS – Accéder VIS et construire la table de hachage
DOC VIS
– Accéder DOC et sélectionner (ici age>32)
• 2 alternatives d’exécution d’un arbre d’opérateurs
Ecrire le résultat sur disque
– Avec matérialisation
– Lire les DOC sélectionnés et tester avec la table de hachage
• construction du résultat complet des opérateurs dont l’entrée est matérialisée
Ecrire les résultats de la jointure sur disque
• Du bas : les opérateurs dont les entrées sont les relations de base déjà matérialisées
– Lire le résultat de la jointure et effecteur les projection
• Vers la racine : les opérateurs dont les fils ont déjà matérialisé leur résultat
• L’exécution matérialisée est toujours applicable mais coûteuse
– En pipeline
– Ecritures intermédiaires ajoute l’écriture du résultat aux coûts précédents
• Chaque opérateur renvoie directement ses résultats à son parent (sans matérialiser)
• Eviter d’écrire les résultats (autant que possible) Exécution pipeline…
29 30

Exécution pipeline (1) Exécution pipeline (2)

• Plusieurs opérateurs fonctionnent ‘simultanément’ • Toutes les opérateurs ne peuvent former une chaîne pipeline…
– Sans écrire de résultat intermédiaire (se passe directement les tuples
résultats) • Dépend de la nature de l’opérateur (build vs. sélection)
– Ils forment alors une chaîne pipeline π • Dépend de son implémentation physique
– Certains algorithmes sont bloquants
• Ex. Dans l’arbre précédent Probe – i.e., ne peuvent produire des résultats dès qu’ils reçoivent des tuples en entrée
– Accéder VIS et construire la table de hachage – Ex. Jointure par tri fusion, jointure par hachage (Hybrid Hash Join)
– Accéder DOC et sélectionner (age > 32) σAge > 32 Build
Passer chaque tuple résultat au probe • Il faut créer des versions (‘presque’) pipeline des algorithmes bloquants
Scan Scan – i.e., capable de générer des résultats quand des tuples sont fournis en entrée
DOC VIS – Ex. algorithme de jointure pipeline: variante pipeline du Hybrid Hash Join
(détail après…)
– Lire les DOC sélectionnés et tester avec la table de hachage
Passer chaque tuple résultat à la projection DOC
Table de
hachage
– Lire le résultat de la jointure et effectuer les projections DOC
Table de
hachage
Test

• Efficacité du pipeline VIS Test

Table de
VIS
– Moins de résultat temporaire moins d’I/Os Bloquant
hachage

– Les opérateurs produisent des tuples dès qu’ils en consomment Pipeline

• MAIS : pas toujours possible…
31 • Types d’exécution pipeline : orientée production ou consommation 32
 Modèles d’exécution pipeline Implantation sous forme d’itérateur

• Modèle orienté consommation (pull ou lazy)

– Un opérateur demande à son fils le tuple suivant quand il en a besoin
– Entre les appels, chaque opérateur maintient son ‘contexte’
• Nécessaire pour savoir quel tuple renvoyer ensuite
– Ex. le modèle itérateur… (voir la suite)
• Modèle orienté production (push ou eager)
– Un opérateur produit des tuples et les envoie aussitôt à son parent
– Des buffers sont maintenus entre les opérateurs
• Les enfants placent des tuples dans le buffer
• Le parent retire des tuples du buffer
– Si le buffer est plein, les enfants attendent
• le parent doit consommer des tuples pour libérer de l’espace
• Le modèle iterateur
– Interface uniforme et générale pour tous les operateurs
physiques
– Chaque opérateur est décomposé en trois méthodes
• Open() alloue la mémoire, effectue l’initialisation
• Next() renvoie un tuple résultat (ou ‘end of file’ eof)
• Close() libère la mémoire et rend la main
• Flot de données (tuples) : itérateurs feuilles racine
• Flot de controle : itérateur racine feuilles

33 34

Ex. d’itérateur : le Hash Join Execution d’un arbre d’itérateurs (1)

probe project project.open(){
build
R h(R.a) R hash table output R S
probe2.open{
build scan buffer build2.open() { // hash table de T
scanT.open();
scan S S probe2 t = scanT.next()
h(S.b) probe while (! eof) {
R Memory t = scanT.next();
build2 insert t in table }
• probe.open() { • buildR.open() { scanT.close();
buildR.open(); scanR.open(); probe1 }
scanS.open() } t = scanR.next() probe1.open() {
scanT
while (t != eof) { T build1.open() {
• probe.next() { // hash table de R
t = scanS.next() put t in table; build1
scanS ...}
probe the hash table with t; t = scanR.next() }
S scanS.open();
return one result tuple } scanR.close() }
}
• probe.close() { • buildR.close() { scanR }
buildR.close() de-allocate hash table } R
scanS.close() }
35 36
 Execution d’un arbre d’itérateurs (2) Execution d’un arbre d’itérateurs (3)
project.next(){ • Relation producteur-consommateur project
project
probe2.next { – Des données sont matérialisées
probe1.next() { – Des données passent en pipeline probe2
s = scanS.next(); build2
probe1
probe2 test table de R avec s; • Les chaines pipeline sont délimitées
return tuple rs; – Opérateurs bloquants scan build1 scan
} – Ex. build, mat, sort, ... S T
build2 test table de T avec rs; scan chaineT
Constrainte d’ordonnancement chaineS R
return tuple rst;
probe1 (ordonancement partiel des chaines pipelines)
} chaineR
scanT rstp=projection(rst);
T • NB : L’implantation des opérateurs physiques détermine complètement
build1 return rstp;
l’ordre d’execution du plan (l’ordonancement)
scanS }
S
scanR • Pb : allouer la mémoire aux opérateurs qui s’exécutent en même temps
R – Ex. ChaineS = scanS 10%, probe1 45%, probe2 45%, project 10%

37 38

Optimisation de Requêtes Architecture en couche d’un SGBD

1. Introduction Interface

2. Simplification de requêtes Analyseur sémantique

3. Restructuration algébrique
Optimiseur
4. Choix du meilleur plan
Evaluateur de plan d’exécution
5. Conclusion
Opérateurs relationnels

Méthodes d’accès aux données

Gestion de Gestion de Gestion des

Mémoire Verrous Journaux

Système d’exploitation
39 40
 Optimiser : pour quoi faire ? Optimisation : exemple
• Une question Select Patients.Nom, Patients.Prénom
• Plusieurs expressions From
Where
Patients, Visites
Patients.Id-P = Visites.Id-P π
π
équivalentes en SQL and Patients.Ville = ’Paris’
• Plusieurs expressions and Visites.Date = ’15 juin’

équivalentes en algèbre

σ
• Plusieurs algorithmes
équivalents
π π
Coût

σ σ
Ex:
5 tables 1620 plans possibles
Plans sémantiquement équivalents
10 tables 17 milliards de plans…
Variation de performance de plusieurs ordres de magnitude Patients Visites Patients Visites
41 42

Optimisation : exemple Qui optimise ?

π Jointure • Dans la théorie …

– Nested Loop Join ? – 2 requêtes SQL équivalentes (i.e., donnant le même résultat) doivent,
après optimisation, produire le même plan d’exécution (i.e., le meilleur) !
– Index Join ?
– Seuls les concepteurs de SGBD (noyau) devraient avoir besoin de
– Hash Join ?
comprendre l’optimisation pour développer un bon optimiseur de
– Sort Merge Join ? requêtes

π π Sélection
• Mais dans la pratique
– Les algorithmes ont leurs limites (2 requêtes équivalentes peuvent ne

σ σ
– FTS (Full Table Scan) ?
– Index Scan (B+tree) ?
– Index Scan (Bitmap) ?
Patients Visites
43
pas être identifiées comme telles)
– Le bon choix dépend souvent des données (distribution, taille,
sélectivité), dont la connaissance est approximative
– Enfin, seuls les plans d’exécution rendus possibles par le schéma
physique de la BD sont évalués
le DBA joue donc un rôle majeur
44
 Optimisation basée sur les coûts Difficultés de l’optimisation basée coût
• Rule-Based Optimizer (ex: RBO d’Oracle) • Espace de recherche très grand (plans candidats)
– Basé exclusivement sur des heuristiques (plus maintenu depuis 2006) – n algorithmes par opérateur
• Cost-Based Optimizer (ex: CBO d’Oracle) – p ordonnancement pour les opérations binaires
– modèle de coût + statistiques sur les données • 1620 ordres possibles pour joindre 5 tables, et 17 milliards pour 10
– Plus précis mais plus complexe tables !
• Modèle de coût (choix du plan)
Graphe d'opérations Schéma interne
– Difficulté pour estimer le coût de chaque opérateur
Plans d'exécution – Difficulté encore plus importantes pour estimer la taille des résultats
(espace de recherche)
intermédiaires (permettant de calculer l’opérateur suivant)
Bibliothèque de
Générateur de – Propagation exponentielle des erreurs (dans l’arbre d’exécution) !
transformations
Plans
Statégie de
• Modèle de coût basé sur des hypothèses d’uniformité de
Heuristiques
Recherche
de choix
distribution et/ou sur des statistiques
Modèle de coût – RunStat(<Table>, <attribut>) : construction et stockage d’un histogramme

Plan d'exécution
Optimal 45 46

Conclusion
• L’optimisation de requêtes est une tâche cruciale du SGBD
– Fort impact sur les performances du système
– Mécanisme puissant mais complexe à maîtriser
Mise en œuvre
• Le SGBD ne peut pas tout dans les systèmes NoSQL
– Sans bon DBA, pas de bonne optimisation possible
et application au Big Data
• De plus en plus d’aide à l’administration
– Outils d’audit des performances, ‘explainer’ de plans d’exécution,
outils de recommandation de schéma physique (fragmentation de
tables, index, vues concrètes, statistiques …)
• Automatic SQL Tuning dans Oracle 10
• Database Tuning Advisor dans SQL Server 2005
– Longue route vers un futur SGBD auto-administrable

47 48
 HDFS – distributed, fault tolerant file system
MapReduce – framework for writing/executing distributed, fault
tolerant algorithms Giant File
{node2, node2, node 4}
node4,
{node1, node3, 3}
5}
110010101001
Hive & Pig – SQL-like declarative languages 010100101010

Sqoop – package for moving data between HDFS and relational

011001010100 (based on “replication
101010010101 HDFS
DB systems 001100101010 factor”) (3 by default)
010101001010 Client
100110010101
+ Others… 001010100101 Name node tells client where to store each
BI ETL block of the file
RDBMS
Reporting Tools
Client transfers block directly NameNode BackupNode

Avro (Serialization)
Hive & Pig to assigned data nodes
Zookeeper

Sqoop and so on…

Map/
Reduce
DataNode DataNode DataNode DataNode DataNode
HBase
HDFS

49 50
Source: Big Data: What’s the Big Deal, Dewitt et al

Programming framework (library and runtime) for <keyi, valuei> Mapper

<keyA, valuea>
<keyB, valueb>
analyzing data sets stored in HDFS <keyC, valuec>
…
MapReduce jobs are composed of two functions: DataNode <keyA, list(valuea, valueb, valuec, …)>

Reducer

map() reduce()
combine & reduce
<keyi, valuei> Mapper
<keyA, valuea>
<keyB, valueb>
sub-divide & <keyC, valuec>
cardinality … Sort
conquer <keyB, list(valuea, valueb, valuec, …)>
DataNode and
group Reducer Output
by
User only writes the Map and Reduce functions <keyA, valuea> key
<keyi, valuei> Mapper <keyB, valueb>
<keyC, valuec>
MR framework provides all the “glue” and coordinates …
DataNode <keyC, list(valuea, valueb, valuec, …)>
the execution of the Map and Reduce jobs on the
cluster. Reducer
<keyA, valuea>
Fault tolerant <keyi, valuei> Mapper <keyB, valueb>
Scalable <keyC, valuec>
…
51 52
 Reducer

Get sum sales grouped by zipCode

53705 $65 53705 $65
(custId, zipCode, amount) 54235 $75 54235 $75 53705 $30 Sort 53705 $30 SUM 53705 $110
4 54235 $75 54235 $22 54235 $22 53705 $15 53705 $15
DataNode3

Mapper
Blocks
7 10025 $60
of the 10025 $60 10025 $60
Sales 4 54235 $75
2 53705 $30 10025 $95 10025 $95
file in 5 7 53705
10025 $65
$60 Reducer
1 02115 $15 44313 $55 44313 $55
HDFS
0 54235 $22
3 10025 $95 44313 $10 10025 $60
Group 53705 $65
8 44313 $55 Mapper By
53705 $65
10025 $95
44313 $25

Shuffle
5 53705 $65 One output 10025 $155
DataNode2

10025 $60 Sort 44313 $10

0 54235 $22 bucket per SUM
44313 $90
reduce task 10025 $95 44313 $25
5 53705 $15 2 53705 $30
53705 $30 44313 $55 44313 $55
6 44313 $10 1 02115 $15 53705 $30
53705 $15
53705 $15
Reduce
Mapper
Group tasks Reducer
By 02115 $15

Mapper
3 10025 $95 5 53705 $15 02115 $15
DataNode1

02115 $15 54235 $75 02115 $15

8 44313 $55 6 44313 6 $10
44313 $25 02115 $15
44313 $10 54235 $22 02115 $15 02115 $30
9 02115 $15
6 44313 $25 Sort SUM
44313 $10 54235 $97
44313 $25 02115 $15 54235 $75
9 02115 $15 Map tasks
44313 $25
02115 $15 54235 $22
53

Dataset A Dataset B Different join keys

Reducers perform the

Reducer 1 Reducer 2 Reducer N actual join

Mise en œuvre
Shuffling and Sorting
Shuffling and sorting over
the network
dans les SGBD embarqués
- Each mapper produces the
join key and the record pairs

Mapper Mapper Mapper Mapper - Each mapper processes

1 2 3 M+N one block (split)

HDFS stores data blocks

(Replicas are not shown)

55 56
 How to deal with large tables
under the RAM constraints?
SKT (SubTree Key Table)
• Classical join algorithms need a large RAM Prescription (Pre)
Hypothèse = schéma de BD
– HashJoin, SortMergeJoin … PreID
Quantity arborescent
• Join indices could be a solution but consecutive joins incur random Frequency
WhenWritten
access or an expensive sort MedID
VisID A chaque table (noeud de
l’arbre) est associée une SKT
Medicine (Med) Visit (Vis) -A chaque tuple t de la table
Sorted on R1.id JI MedID VisID correspond un tuple de SKT
Sorted on R2.id Name Date
Effect Purpose -- Le tuple de SKT contient les
JI Type DocID
Sorted on R1.id
PatID
identifiants des tuples des
σ(R1) R2 R3 tables filles qui joignent avec t

Table Doctor (Doc) Patient (Pat)

• A fully indexed model is required to allow efficient execution of multi- DocID PatID
La SKT précompile toutes les
join queries with selections on a “large” database while satisfying the SubTree Key Table Name Name jointures des tables ancêtres
Speciality Age
RAM constraint Zip BodyMassIndex vers les tables descendantes
Country Country

57 58

Climbing index Plan d’exécution (100% indexé)

SELECT Med.Name, Pre.Quantity, Vis.Date
– Chaque clé de l’index contient une sous-liste d’IDs par
FROM Medicine Med, Prescription Pre, Visit
table ancêtre jusqu’à la table racine Vis
WHERE Vis.Date > 11/2006
– Précompile les sélections et les jointures des tables AND Vis.Purpose = “Sclerosis”
descendantes vers les tables ancêtres AND Med.Type = “Antibiotic”
AND Med.MedID = Pre.MedID
AND Vis.VisID = Pre.VisID;
Index Index Index
Prescription
on Doctors.name on Visits.purpose on Prescriptions.Qty PreIDH
QuantityH
FrequencyH
WhenWrittenH
MedIDH
VisIDH

Pid Pid
Medicine Visit
Pid
MedIDH VisIDH
NameH DateH
EffecHt PurposeH
TypeH DocIDH
Vid PatIDH

Vid
Doctor Patient
DocIDH PatIDH
Did NameH NameH
SpecialityH AgeH
ZipH BMIH
CountryH CountryH

59 60