56
BASES DE DONNÉES RÉPARTIES [email protected] CM3 Master 1 MIF24

Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

  • Upload
    others

  • View
    4

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

BASES DE DONNÉES RÉPARTIES

[email protected]

CM3

Master 1

MIF24

Page 2: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 3: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

EVALUATION DE REQUÊTES

RÉPARTIES

Page 4: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 5: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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;

Page 6: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 7: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 8: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 9: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 10: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 11: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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’

Page 12: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 13: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 14: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 15: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 16: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 17: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 18: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 19: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 20: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 21: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 22: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 23: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 24: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 25: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 26: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 27: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

Déterministe

Aléatoire

R2R1

R3

R4

R2R1 R2R1

R3

R2R1

R3

R3R1

R2

STRATÉGIE DE RECHERCHE (EN CENTRALISÉ)

Page 28: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 29: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 30: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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)

Page 31: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

MIF24

STATISTIQUES SUR LES OPÉRATEURS

FACTEUR DE SÉLECTIVITÉ

Page 32: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

MIF24

STATISTIQUES SUR LES OPÉRATEURS :

FACTEUR DE SÉLECTIVITÉ

A

A

ASF = 1

Page 33: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 34: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 35: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

EXEMPLE

35

nclient

qte > 10

Client

nclient,nom

Cde

Q:

Page 36: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 37: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 38: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 39: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 40: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 41: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 42: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 43: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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 !

Page 44: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 45: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 46: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 47: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 48: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 49: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 50: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 51: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

MIF24

QUID DU PLAN D’EXÉCUTION ?

Exemple de requête :

Plan d’exécution associé :

51

Page 52: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

MIF24

QUID DU PLAN D’EXÉCUTION ?

Exemple de requête :

Plan d’exécution associé :

52

Page 53: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 54: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 55: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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

Page 56: Master 1 BASES DE DONNÉES RÉPARTIES nicolas.lumineau@univ

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