View
4
Download
0
Category
Preview:
Citation preview
BASES DE DONNÉES RÉPARTIES
nicolas.lumineau@univ-lyon1.fr
CM3
Master 1
MIF24
MIF24
EVALUATION DE REQUÊTES RÉPARTIES
Evaluation de requêtes réparties
Plan d’exécution réparti
Modèles de coût
Algorithmes de décomposition de requêtes
Transactions réparties
Garantir un accès concurrent à des données réparties
2
EVALUATION DE REQUÊTES
RÉPARTIES
MIF24
EXEMPLE
Soient les relations : Client(nclient, nom, ville)
et Cde(ncde, #nclient, produit, qte)
Schéma de fragmentation
Site 1 : Client1 = ville = Lyon(Client)
Site 2 : Client2 = ville != Lyon(Client)
Site 3 : Cde1 = Cde Client1
Site 4 : Cde2 = Cde Client2
nclient
nclient
MIF24
QUESTION
Quels sont les clients qui ont passé des commandes
comprenant plus de 10 articles? On précisera les
commandes concernées.
Hypothèses:
Les données sont réparties dans différentes BD
Les données sont accessibles via le réseau
Les requêtes sont formulées en fonction d’un schéma global
5
SELECT *
FROM Client JOIN Cde ON Client.nclient = Cde.nclient
WHERE Cde.qte > 10;
MIF24
EVALUATION DE REQUÊTES RÉPARTIES
Requête sur schéma global
Fragmentation de la requête Schéma global
Optimisation globaleStatistiques sur
les fragments
Sous-requête(s) portant sur fragments
Plan d’exécution réparti optimal
Localisation des données Schéma d’allocation
Optimisation locale
Espaces de recherche des
plans d’exécution répartis
Schéma local
Requêtes locales optimisées
Sur site local
Via le dictionnaire
global
MIF24
PLAN
Fragmentation de requêtes
Plan d’exécution réparti
Evaluation du plan d’exécution réparti Définition d’un modèle de coût
Calcul du coût d’un plan
Optimisation Recherche du plan d’exécution optimal (réduisant le coût)
Focus sur les jointures inter-sites
NB: pour chaque point, un rappel est fait sur l’approche centralisée
7
MIF24
FRAGMENTATION DES REQUÊTES
Construction du plan d’exécution global
Mettre la requête sous forme d’un arbre algébrique
feuille = relation
nœud = opération relationnelle
Expression du plan en fonction des fragments
Remplacer chaque feuille par un programme de
reconstruction de la relation globale
Transformation du plan
Appliquer des techniques de réduction pour éliminer
des opérations inutiles
MIF24
EXEMPLE
Soient les relations : Client(nclient, nom, ville)
et Cde(ncde, #nclient, produit, qte)
Schéma de fragmentation
Site 1 : Client1 = ville = Lyon(Client)
Site 2 : Client2 = ville != Lyon(Client)
Site 3 : Cde1 = Cde Client1
Site 4 : Cde2 = Cde Client2
nclient
nclient
MIF24
FRAGMENTATION D’UNE REQUÊTE
Exemple
SELECT nom FROM Client;
Schémas de fragmentation
Client1 = ville = ‘Lyon’(Client)
Client2 = ville != ‘Lyon’(Client)
nom
Client
nom
Client2Client1
U
MIF24
RÉDUCTION DE LA FRAGMENTATION HORIZONTALE
Règle : éliminer l’accès aux fragments inutiles
Exemple
SELECT nom FROM Client WHERE ville = ‘Paris’;
Schémas de fragmentation
Client1 = ville = ‘Lyon’(Client)
Client2 = ville != ‘Lyon’(Client)
nom
Client
Client2Client1
U
ville=‘Paris’ville=‘Paris’
nom
Client2Client1
U
nom
ville=‘Paris’ville=‘Paris’ Client2
nom
ville=‘Paris’
MIF24
RÉDUCTION DE FRAGMENTATION VERTICALE
Règle: éliminer les accès aux relations de base qui n’ont pas d’attributs utiles pour le résultat final
ExempleSELECT nclient FROM Cde;
Schéma de fragmentationCde1 = ncde, nclient(Cde)
Cde2 = ncde, produit, qté(Cde)
Cde2Cde1
nclient
ncdeCde
nclient
Cde1
nclient
MIF24
RÉDUCTION POUR LA FRAGMENTATION HORIZONTALE
DÉRIVÉE (1)
Règle : distribuer les jointures par rapport aux unions et appliquer les réductions pour la fragmentation horizontale
Exemple
SELECT *
FROM Client, Cde
WHERE Client.nclient = Cde.nclient AND Ville = ‘Paris’;
Schémas de fragmentation
Client1 = ville = Lyon(Client)
Client2 = ville != Lyon(Client)
Cde1 = Cde Client1
Cde2 = Cde Client2
nclient
nclient
MIF24
RÉDUCTION POUR LA FRAGMENTATION HORIZONTALE DÉRIVÉE
(2) SELECT * FROM Client, Cde WHERE Client.nclient = Cde.nclient AND Ville = ‘Paris’
Client
Cde
nclient
U
ville=‘Paris’
Client1
Cde1
nclient
ville=‘Paris’
Cde2 U
Client2
U
Cde1
nclient
ville=‘Paris’
Cde2 Client2
Requête
canonique
1er
réduction
Distribution
U
nclient
ville=‘Paris’Cde2
Client2
nclient
ville=‘Paris’Cde1
Client2
nclient
ville=‘Paris’Cde2
Client2
Réduction
MIF24
PLAN D’EXÉCUTION
Définition
En centralisé, c’est l’enchainement des opérateurs
algébriques pour le calcul d’une requête
En réparti, c’est l’enchainement des opérateurs
algébriques et des échanges de données intersites
pour le calcul d’une requête
15
MIF24
EXEMPLE DE PLAN D’EXÉCUTION EN
CENTRALISÉ
Exemple de requête globale :
SELECT nom
FROM Client, Cde
WHERE Client.nclient = Cde.nclient AND qte > 10 ;
En centralisé, deux plans d’exécution possibles seraient :
nclient
qte > 10
Client
nom
Cde
nclient
qte > 10Client
nclient,nom
nom
nclient
Cde
Algébriquement
optimal
MIF24
RAPPEL : OPTIMISATION ALGÉBRIQUE
Optimisation basée sur les règles Principe:
Faire les opérateurs les moins coûteux (projection, sélection) en premier, de manière à réduire la taille des données d’entrée pour les opérateurs les plus coûteux (jointure)
Méthodologie :
Descendre les sélections, puis les projections au maximum grâce aux règles de transformation
Optimisation basée sur le coût
Principe: Exploiter au mieux les index définis sur les tables
Méthodologie :
Retarder l’application des opérateurs qui ‘cassent’ les index
MIF24
EXEMPLE D’UN PLAN D’EXÉCUTION RÉPARTI
Schéma de fragmentation
Site 1 : Client1 = ville = Lyon(Client)
Site 2 : Client2 = ville != Lyon(Client)
Site 3 : Cde1 = Cde Client1
Site 4 : Cde2 = Cde Client2
Site 5 : Résultat
nclient
nclient
MIF24
EXEMPLE D’UN PLAN D’EXÉCUTION
Un plan d’exécution possible
Transfert de Client1 du Site 1 vers le Site 5
Transfert de Client2 du Site 2 vers le Site 5
Transfert de Cde1 du Site 3 vers le Site 5
Transfert de Cde2 du Site 4 vers le Site 5
Sur site 5: Union de Client1 et Client2 : on obtient T1
Sur site 5: Union de Cde1 et Cde2 : on obtient T2
Sur site 5: Sélection sur T2 des n-uplets dont la valeur de qté > 10 : on obtient T3
Sur site 5: Jointure entre T1 et T3 : on obtient le résultat
Cde1
Client1
nclient
qté > 10
Client2
Cde2Site 1
Site 2 Site 3Site 4
Site 5
MIF24
AUTRE EXEMPLE DE PLAN D’EXECUTION
C1 = nclient,nom (qté > 10 (Cde1)) C2 = nclient,nom ( qté > 10 (Cde2))Site 3
Site 4
C3 = nom(C1 Client1) C4 = nom(C2 Client2)nclient
nclient
C3 C4
Site 1
Site 5
Site 2
◼ Scénario
Sur site 3 : Sélection des commande de Cde1 de quantité > 10 : on obtient C1
Sur site 4 : Sélection des commande de Cde2 de quantité > 10 : on obtient C2
Transfert de C1 du Site 3 vers le Site 1
Transfert de C2 du Site 4 vers le Site 2
Sur site 1: Jointure de C1 avec Client 1: on obtient C3
Sur site 2: Jointure de C2 avec Client 2 : on obtient C4
Transfert de C3 du Site 1 vers le Site 5
Transfert de C4 du Site 2 vers le Site 5
Sur site 5: Union de C3 avec C4 : on obtient le résultat
MIF24
COMPARATIF DU COÛT DES SOLUTIONS
Supposons Taille(Cde1) = taille(Cde2) = 10 000 n-uplets
Taille(Client1) = Taille(Client2) = 2 000 n-uplets
Coût de transfert de 1 n-uplets = 1
Sélectivité (qté > 10) = 1%
Solution 1 Transfert de Cde1 + Cde2 = 20 000 n-uplets
Transfert de Client1 + Client2 = 4 000 n-uplets
Solution 2 Transfert de C1 + C2 = 200 n-uplets
Transfert de C3 + C4 = 200 n-uplets
24 000 n-uplets
400 n-uplets
MIF24
EVALUATION D’UN PLAN D’EXÉCUTION
(EN CENTRALISÉ)
Modèle de coût (en centralisé)
Fonction de coût : donne une estimation du coût d’un plan d’exécution basé sur les entrée/sortie disque (I/O) et la vitesse du processeur (CPU)
Coût total = coût I/O + coût CPU
On peut négliger le coût CPU << coût I/O
Parcours de l’espace de recherche
Recherche non-exhaustive d’une bonne solution avec des statistiques : stratégies
Problèmes liés à la taille de l’espace de recherche
22
MIF24
ESPACE DE RECHERCHE (EN CENTRALISÉ)
Caractérisé par les plans “équivalents” pour une même requête
qui donnent le même résultat
qui sont générées en appliquant des règles de transformation
Le coût de chaque plan est en général différent
L'ordre des jointures est important
MIF24
Commutativité des opérations binaires
R S S R
R S S R
R S S R
Associativité des opérations binaires
( R S ) T R (S T)
( R S ) T R (S T )
Idempotence des opérations unaires
A’(A’’(R)) A’(R) avec A' A"
p1(A1)(p2(A2)(R)) p1(A1) p2(A2)(R)
RAPPEL : RÈGLES DE TRANSFORMATION
MIF24
Distributivité de la sélection avec les opérations binaires
p(A)(R S) (p(A) (R)) S
p(Ai)(R (Aj,Bk) S) (p(Ai)
(R)) (Aj,Bk) S
p(Ai)(R T) p(Ai)
(R) p(Ai) (T)
où Ai appartient à R et T
Distributivité de la projection avec les opérations binaires
C(R S) A’(R) B’(S)
C(R (Aj,Bk) S) A’(R) (Aj,Bk) B’(S)
C(R S) C (R) C (S)
où R[A] et S[B]; C = A' B' où A' A, B' B, Aj A', Bk B'
RAPPEL: RÈGLES DE TRANSFORMATION
STRATÉGIE DE RECHERCHE (EN CENTRALISÉ)
Déterministe :
part des relations de base et construit les plans en
ajoutant une relation à chaque étape
programmation dynamique: largeur-d'abord
excellent jusqu'à 5-6 relations
Aléatoire :
recherche de l'optimalité autour d'un point de départ
aléatoire
réduit le temps d'optimisation (au profit du temps
d'exécution)
meilleur avec > 5-6 relations
recuit simulé
amélioration itérative
Déterministe
Aléatoire
R2R1
R3
R4
R2R1 R2R1
R3
R2R1
R3
R3R1
R2
STRATÉGIE DE RECHERCHE (EN CENTRALISÉ)
MIF24
EVALUATION D’UN PLAN D’EXÉCUTION EN
RÉPARTI
Modèle de coût réparti Fonction de coût : doit, en plus des entrées/sorties,
considérer le coût induit par les messages échangés (MSG) et le transferts de données (TrD).
Coût total = coût I/O + coût CPU + coût MSG + coût TrD
On peut négliger le coût CPU << coût I/O et MSG << coût TrD
Le ratio coût I/O et coût TrD dépend du type de réseau considéré (LAN ou WAN)
Parcours de l’espace de recherche
Recherche non-exhaustive d’une bonne solution avec des statistiques sur les sources de données
Problèmes liés à la taille de l’espace de recherche
28
MIF24
STATISTIQUES SUR LES RELATIONS
Soit R(A1,…,An) une relation fragmentée en R1,…, Rk fragments
Statistiques sur la relation R: cardinalité : card(R) largeur : n (nombre d’attributs) bornes du domaine de définition des attributs : min(Ai) et max(Ai);
i=1..n nombre de valeurs distinctes de chaque attribut: card(Ai(R)); i=1..n taille du domaine de définition de chaque attribut: dom(Ai) ; i=1..n distribution des valeurs (histogramme) : distrib(Ai); i=1..n
Statistiques sur les fragments Rj: cardinalité : card(Rj) nombre de valeurs distinctes de chaque attribut: card(Ai(Rj)); i=1..n
MIF24
STATISTIQUES SUR LES OPÉRATEURS :
FACTEUR DE SÉLECTIVITÉ
Facteur de sélectivité des opérateurs: La proportion de tuples résultant de l’exécution d’une opération
Remarque: On suppose que les attributs sont indépendants et que les valeurs des attributs
sont uniformément distribuées
Pour la sélection F (R) : Soit SF est une estimation de la sélectivité du prédicat:
SF(A = valeur) = card(∏A(R))
1
S F(A > valeur) = max(A) – min(A)
max(A) – valeur
S F(A < valeur) = max(A) – min(A)
valeur – min(A)
MIF24
STATISTIQUES SUR LES OPÉRATEURS
FACTEUR DE SÉLECTIVITÉ
MIF24
STATISTIQUES SUR LES OPÉRATEURS :
FACTEUR DE SÉLECTIVITÉ
A
A
ASF = 1
MIF24
ESTIMATION DE LA TAILLE DES RÉSULTATS
INTERMÉDIAIRES
Sélectioncard(F (R)) = SF (F) card(R)
Projection
Si A est la clé, alors card(A(R)) = card(R)
sinon card(A(R)) card(R)
Produit cartésien
card(R S) = card(R) card(S)
Union
max{card(R), card(S)} card(R S) card(R) + card(S)
Différence
0 card(R–S) card(R)
33
MIF24
ESTIMATION DE LA TAILLE DES RÉSULTATS
INTERMÉDIAIRES
Jointurecard(R S) card(R) × card(S)
cas particulier: A est clé de R et B est clé étrangère de S :
card(R A=B S) = card(S)
plus généralement
card(R S) = SF × card(R) × card(S)
Semi-Jointurecard(R S) = SF × card(R)
34
AA
EXEMPLE
35
nclient
qte > 10
Client
nclient,nom
Cde
Q:
OPTIMISATION DE REQUÊTES
En centralisé,
L’élément clé de l’optimisation concerne le traitement des jointures L’ordre d’exécution des jointures
L’algorithme utilisé pour effectuer la jointure
Jointure par boucle imbriquée (avec ou sans index)
Jointure par tri-fusion
Jointure par hachage
En réparti,
Le traitement des jointures est crucial Impacte la quantité d’information transitant par le réseau.
36
MIF24
TECHNIQUES D’EXÉCUTION DISTRIBUÉE
Transmission de blocs de tuples (Row blocking)
Réduction du surcoût du aux entêtes des protocoles
réseaux (TCP/IP, UDP….)
Optimisation de la diffusion des tuples
Tenir compte des coûts de transferts pour une même
information nécessaire sur plusieurs sites
37
MIF24
TECHNIQUES D’EXÉCUTION DISTRIBUÉE
Multithreading
Parallélisation de certains opérateurs
Problème de communication synchronisée inter-thread
Réduire les transferts en cas de jointures inter-site
38
MIF24
A PROPOS DES JOINTURES INTERSITES
Jointures intersites
C’est une jointure interrogeant des données distribuées sur
différents sites
➔ Coût de transfert des données dans la résolution des requêtes
Approches
Par jointures parallèles
Boucles imbriquées
Par ordonnancement des jointures
Algorithme INGRES
Par remplacement des jointures par des semi-jointures
Algorithme basé sur les semi-jointures
39
MIF24
JOINTURE ENTRE DEUX SITES
Principe élémentaire
Toujours transférer la relation la plus petite
Site 1: RequêteSELECT nom, titre
FROM Employé E, Statut S
WHERE E.tnum = S.tnum;
Site 2 : Employé(enum, nom, adr, #tnum) =>100 000 tuples de 1 Ko
Site 3 : Statut(tnum, titre) => 10 tuples de 0,5 Ko
Plan d’exécution P : Transfert de Statut du site 3 vers le site 2
T1 Exécution de la jointure entre Employé et Statut sur le site 2
T2 Projection sur nom et titre appliquée à T1
Transfert de T2 du site 2 vers le site 1
40
MIF24
JOINTURE ENTRE DEUX SITES
Coût du plan d’exécution P En supposant que
Chaque attribut est de taille 0,25 Ko
Qu’il n’y a pas d’homonymes parmi les employés
le coût de transfert est définit comme suit :Tr( X, site1, site2) = card(X) * taille(X)
Tr( X, site2, site3) = 2 * card(X) * taille(X)
Tr( X, site1, site3) = 3 * card(X) * taille(X)
Tr( X, S, W) = Tr( X, W, S)
Coût du plan d’exécution P
1) Tr(Statut, Site3, Site2) = 2 * 10 * 0,5 = 10
2) Card(T1)=Card(Employé)=100 000 car tnum clé étrangère dans Employé
3) Card(T2)= Card(T1)=100 000 car par d’homonymes parmi les employé Taille(T2) = 0,5 car 2 attributs
4) Tr(T2, site2, site1) = 100 000 * 0,5 = 50 000
➔ Le plan d’exécution coûte 50 000 + 10 = 50 010 50Mo
NB: transférer les attributs enum et adr de Employé sur le site 3 aurait coûté environ 150 Mo (voire 300 Mo si transfert direct d’Employé)
41
1) Transfert de Statut du site 3 vers le site 2
2) T1 Exécution de la jointure entre Employé et Statut sur le site 2
3) T2 Projection sur nom et titre appliquée à T1
4) Transfert de T2 du site 2 vers le site 1
MIF24
JOINTURE ENTRE TROIS SITES
Contexte Site 1: Requête
SELECT e.nom, p.intitule
FROM Employé E, Travaux T, Projet P
WHERE E.enum = T.enum AND T.pnum = P.pnum;
Site 2 : Employé(enum, nom, adr, statut) =>1 000 tuples de 1 Ko
Site 3 : Projet(pnum, intitule, durée, budget) => 100 tuples de 1 Ko
Site 4 : Travaux(pnum, enum) => 1 000 tuples de 0,5 Ko
(NB: un projet par employé et 10 employés par projet)
Constat
Plusieurs plans sont possibles
42
MIF24
PLANS D’EXÉCUTION RÉPARTIS POSSIBLES
Plan1 Transfert d’Employé du site 2 vers el site 3
Transfert de Projet du site 4 vers le site 3
T1 Exécution de la jointure de Projet avec Travaux sur le site 3
T2 Exécution de la jointure de T1 avec Employé sur le site 3
T3 Projection sur nom et intitule appliquée à T2
Transfert de T3 sur le site 1
Plan2 Transfert de Projet du site 4 vers le site 3
T1 Exécution de la jointure de Projet avec Travaux sur le site 3
Transfert de 𝑒𝑛𝑢𝑚, 𝑖𝑛𝑡𝑖𝑡𝑢𝑙𝑒( T1 ) sur le site 2
T2 Exécution de la jointure de T1 avec Employé sur le site 2
T3 Projection sur les attribut nom et intitule appliquée à T2
Transfert de T3 sur le site 1
Plan 3 Transfert de Employé du site 2 vers le site 3
T1 Exécution de la jointure de Employé avec Travaux sur le site 3
Transfert de T1 sur le site 4
T2 Exécution de la jointure de T1 avec Projet sur le site 4
T3 Projection sur les attribut nom et intitule appliquée à T2
Transfert de T3 sur le site 1
Autres plans …
43
Besoins:
Connaitre la
taille de
Employé,
Travaux,
Projet
et des
différents Ti
calculés !
MIF24
CALCUL DU COÛT
Coût du plan d’exécution Plan2 En supposant que
Chaque attribut est de taille 0,25 Ko
Qu’il n’y a pas d’homonymes parmi les employés
Hypothèse simplificatrice : site1 = site 4
le coût de transfert est définit comme suit :Tr( X, site1, site2) = card(X) * taille(X)
Tr( X, site2, site3) = 2 * card(X) * taille(X)
Tr( X, site1, site3) = 3 * card(X) * taille(X)
Tr( X, S, W) = Tr( X, W, S)
Coût du plan d’exécution P
1) Tr(Projet, Site1, Site3) = 3 * 100 * 1 = 300
2) Card(T1)=Card(Employé)=1 000 car 1 projet par employé
3) Tr(𝑒𝑛𝑢𝑚, 𝑖𝑛𝑡𝑖𝑡𝑢𝑙𝑒(T1), Site3, Site2) = 2 * 1 000 * 0,5 = 1 000
4) Card(T2)= Card(T1)=1 000 car jointure sur clé étrangère
5) Card(T3) = Card(T2)=1 000 car pas de doublons
6) Tr(T3, site2, site1) = 1 000 * 0,5 = 500
➔ Le plan d’exécution coûte 300 + 1 000 + 500 = 1 800
44
1. Transfert de Projet du site 4 vers le site 3
2. T1 Exécution de la jointure de Projet avec Travaux sur le site 3
3. Transfert de 𝑒𝑛𝑢𝑚, 𝑖𝑛𝑡𝑖𝑡𝑢𝑙𝑒( T1 ) sur le site 2
4. T2 Exécution de la jointure de T1 avec Employé sur le site 2
5. T3 Projection sur les attribut nom et intitule appliquée à T2
6. Transfert de T3 sur le site 1
MIF24
JOINTURES PARALLÈLES
Objectif:
Eviter de rassembler l’ensemble des fragments horizontaux sur un même
nœud.
Principe de la jointure parallèle par boucles imbriquées:
Soit R fragmenté horizontalement sur Site S1 et Site S2: R = R1 R2
Soit T fragmenté horizontalement sur Site S3 et Site S4: T = T3 T4
Si R est une relation plus petite (en nombre de tuples) que T
Alors Transférer R1 sur S3 et S4
Transférer R2 sur S3 et S4.
Faire l’union de R1 et de R2 sur S3 puis faire la jointure avec T3
Faire l’union de R1 et de R2 sur S4 puis faire la jointure avec T4
45
MIF24
JOINTURES PARALLÈLES
Objectif:
Eviter de rassembler l’ensemble des fragments horizontaux sur un même
nœud.
Principe de la jointure parallèle par boucles imbriquées:
Soit R fragmenté horizontalement sur Site S1 et Site S2: R = R1 R2
Soit T fragmenté horizontalement sur Site S3 et Site S4: T = T3 T4
Si R est une relation plus petite (en nombre de tuples) que T
Alors Transférer R1 sur S3 et S4
Transférer R2 sur S3 et S4.
Faire l’union de R1 et de R2 sur S3 puis faire la jointure avec T3
Faire l’union de R1 et de R2 sur S4 puis faire la jointure avec T4
46
R1 R2
R1 R1R2 R2T3 T4U U
MIF24
JOINTURES INTER-SITES: RÉDUCTION DES
DONNÉES TRANSFÉRÉES
Algorithme des semi-jointures
Intérêt:
réduire la quantité d’information transférée pour exécuter
une jointure quand peu de n-uplets participent à la jointure
Constat:
Soient R(A, B, C, D) sur Site 1 et S(A, D, E, F) sur Site2
On a:
R S ( R A(S) ) S R (S A(R) )
Principe:
On suppose que card(A(S)) < card(A(R))
Pour effectuer la jointure de R avec S :
Transfert de A(S) du site 2 vers le site 1
Calcul de T1 R A(S)
Transfert de T1 du site 1 vers le site 2
Calcul de T2 T1 S47
A A A AA
A
A
MIF24
JOINTURE ENTRE TROIS SITES
Coût du plan d’exécution
En supposant que
Chaque attribut est de taille 0,25 Ko
Hypothèses :
Card(R) = 10 000
Card(S) = 1 000
Card(A(S)) = 10
SF A = 20 %
le coût de transfert est définit comme suit :
Tr( X, site1, site2) = card(X) * taille(X)
Tr( X, S, W) = Tr( X, W, S)
Coût du plan d’exécution P
1) Tr(A(S) , Site2, Site1) = 10 * 0,25 = 2,5
2) Card(T1)= SF A * card( R) = 0,2 * 10 000 = 2000
3) Tr(T1, Site1, Site2) = 2 000 * 1 = 2 000
➔ Le plan d’exécution coûte 2 000 + 2,5 = 2 002,5
48
Le transfert de la
projection sur S et la
semi-jointure évite
ensuite le transfert de
8 000 n-uplets inutiles
de R
MIF24
COMMENT ÇA SE PASSE AVEC ORACLE
Site 1: Employé + Requête
Employé(enum, nom, adr, #tnum)
SELECT E.nom, S.titre
FROM Employé E JOIN Statut@Lien S
ON E.tnum = S.tnum
WHERE S.tittre != ‘directeur’;
Site 3 : Statut(tnum, titre)
49
MIF24
COMMENT ÇA SE PASSE AVEC ORACLE
La requête est réécrite pour construire une sous-requête
regroupant les tables distantes co-localisées sur une même base.
SELECT E.nom, S.titre
FROM Employé E JOIN Statut@Lien S
ON E.tnum = S.tnum
WHERE S.tittre != ‘directeur’;
SELECT E.nom, S.titre
FROM (SELECT tnum, titre
FROM Statut@Lien
WHERE titre != ‘directeur’) S,
Employé E
WHERE E.tnum = S.tnum;50
MIF24
QUID DU PLAN D’EXÉCUTION ?
Exemple de requête :
Plan d’exécution associé :
51
MIF24
QUID DU PLAN D’EXÉCUTION ?
Exemple de requête :
Plan d’exécution associé :
52
MIF24
REMARQUE
Importance de la décomposition et la réécriture
de requêtes comportant des jointures inter-sites
Différents algorithmes existent:
INGRES distribué
R* distribué
Hill-Climbing
SDD-1
53
MIF24
JOINTURES INTER-SITES:
ALGORITHME INGRES DISTRIBUÉ Principe:
Décomposer récursivement une requête en sous-requêtes irréductibles Qi Une requête est dite irréductible si elle est mono-relation ou s’il n’est pas possible
de séparer les relations qui la compose
Le résultat de la requête Qi est utilisée en entrée de la requête Qi+1
Pour chaque requête irréductible multi-relation, faire une substitution de n-uplets La substitution de n-uplets consiste à créer autant de requêtes qu’il y a de
valeurs possibles pour l’attribut de jointure
Contraintes: algorithme applicable si l’étape de substitution de n-uplets ne génère
pas trop de sous-requêtes.
Algorithme applicable uniquement sur des fragments horizontaux
Exemple: Soit une requête Q portant sur 2 relations R(A,B,C,D) et S(A,D,E,F)
Q: SELECT R.B
FROM R,S
WHERE R.A=S.A AND S.D>2 54
MIF24
JOINTURES INTER-SITES:
ALGORITHME INGRES
Décomposition de la requête Q
On considère la sous-requête Q1SELECT S.A FROM S WHERE S.D>2;
Le résultat de Q1 est nommé T1
La requête Q’ suivante est alors équivalente à Q :Q’: SELECT R.B
FROM R,T1
WHERE R.A=T1.A;
Application de la substitution de n-uplets, en supposant que T1.A {1,2,3}
➔ la requête Q’ est décomposée en 3 sous- requêtesQ’1: SELECT R.B Q’2: SELECT R.B Q’3: SELECT R.B
FROM R FROM R FROM R
WHERE R.A=1; WHERE R.A=2; WHERE R.A=3;
55
Q: SELECT R.B
FROM R,S
WHERE R.A=S.A AND S.D>2
Sous-requête
mono-relation
Sous-requête
irréductible
multi-relation
MIF24
VERS UN TRAITEMENT MASSIVEMENT
PARALLÈLE DES REQUÊTES
Emergence des technologies basée sur MapReduce
pour l’analyse de données par le traitement de
requêtes SQL :
Spark SQL (Shark), BigSQL, Hive, HadoopDB …
56
Contexte différent
Recommended