70
Bases de données reparties

Bases de données reparties

  • Upload
    nysa

  • View
    111

  • Download
    22

Embed Size (px)

DESCRIPTION

Bases de données reparties. Définition. Base de données reparties? Est une BD stockée sur plusieurs sites(machine +BD locale) connectes par un réseau. Logiquement reliées Physiquement distribuées. Apps. Requêtes. BD logique. Vue logique. Computer 1. Computer 2. Computer 3. - PowerPoint PPT Presentation

Citation preview

Page 1: Bases de données reparties

Bases de données reparties

Page 2: Bases de données reparties

Définition

Base de données reparties? Est une BD stockée sur plusieurs sites(machine

+BD locale) connectes par un réseau. Logiquement reliées Physiquement distribuées

Page 3: Bases de données reparties

Logiquement reliées

Les applications voient les données comme une seule BD indépendamment de son emplacement physique

Emplacement physiqueComputer 1 Computer 2 Computer 3

R1,R2 R4,R5R3

Apps.

BD logique Vue logique

Requêtes

Page 4: Bases de données reparties

Physiquement distribuées

La BD est placée sur différentes machines d’un réseau.

Emplacement physiqueComputer 1 Computer 2 Computer 3

R1,R2 R4,R5R3

Page 5: Bases de données reparties

Problématique

Les pressions pour la distribution : Il devient impératif de décentraliser l’information

(cas des multinationales), Augmentation du volume de l’information (14

fois de 1990 à 2000), Augmentation du volume des transactions (10 fois

dans les 5 prochaines années).

Page 6: Bases de données reparties

Pour améliorer le débit des E/Ss : Partitionnement des données, Accès parallèle aux données, Utiliser plusieurs noeuds (avec un bon coût/

performance), et les faire communiquer par un réseau.

Les BDRs se sont développées, grâce au progrès technologiques réalisés au niveau de l’infrastructure réseau et des postes de travail.

Page 7: Bases de données reparties

Objectifs

1. Transparence pour l’utilisateur2. Autonomie de chaque site3. Absence de site privilégié4. Continuité de service5. Transparence vis à vis de la localisation des données6. Transparence vis à vis de la fragmentation7. Transparence vis à vis de la réplication8. Traitement des requêtes distribuées9. Indépendance vis à vis du matériel10. Indépendance vis à vis du système d’exploitation11. Indépendance vis à vis du réseau12. indépendance vis à vis du SGBD

Page 8: Bases de données reparties

Problèmes à surmonter

1. Coût : la distribution entraîne des coûts supplémentaires en terme de communication, et en gestion des communications (–hardware et software à installer pour gérer les communications et la distribution).

2. Problème de concurrence.

3. Sécurité : la sécurité est un problème plus complexe dans le cas des bases de données réparties que dans le cas des bases de données centralisées.

Page 9: Bases de données reparties

Objectives

Permet aux utilisateurs de partager des données géographiquement reparties.

Besoin de décentralisation des organisations, critères économiques

Avantages Partage des données  Fiabilité, disponibilité des données Accroissement de la vitesse de traitement

Inconvénients Complexité des SGBDs Risque d'erreurs + important Surcoût du traitement du à la communication inter-sites

Page 10: Bases de données reparties

SGBD Reparti

Un SGBD reparti assure la gestion d'une bd repartie Objectifs

Exécution des transactions - locales : accès aux données sur site- globales : accès sur plusieurs sites

Définition : données locales/réparties Cohérence des données Contrôle de concurrence Reprise après panne Optimisation de question Indépendance des applications

- machine- système d'exploitation- protocole réseau- système de gestion de bases de données- localisation des données

Page 11: Bases de données reparties

Conception des BDs reparties

Page 12: Bases de données reparties

Deux approches

Descendante : Top-down (du centralisée au distribuée)

Ascendante Bottom-up ( a partir de SGBDs existants vers des vues intégrées)

Page 13: Bases de données reparties

Architecture d’une BDR

Page 14: Bases de données reparties

La répartition d'une base de donnée intervient dans les trois niveaux de son architecture en plus de la répartition physique des données :

Niveau externe: les vues sont distribuées sur les sites utilisateurs.

Niveau conceptuel: le schéma conceptuel des données est associé, par l'intermédiaire du schéma de répartition (lui même décomposé en un schéma de fragmentation et un schéma d'allocation), aux schémas locaux qui sont réparties sur plusieurs sites, les sites physiques.

Niveau interne: le schéma interne global n'a pas d'existence réelle mais fait place à des schémas internes locaux répartis sur différents sites.

Page 15: Bases de données reparties

Approche descendante

On commence par définir un schéma global de la base de données répartie (description globale et unifiée de toutes les données de la BDR). Puis, on le distribue sur les différents sites en des schémas locaux.

Pour déterminer les schémas locaux, on peut utiliser plusieurs méthodes:

- Stocker une relation sur un seul site

- La réplication

- La fragmentation

- Réplication + fragmentation

Page 16: Bases de données reparties

Réplication

Copie de chaque relation sur plusieurs site. Réplication complète= copie sur tous les sites. Avantages

• Disponibilité des données.

• Augmentation du parallélisme

• Diminution du coût imposé par les transmissions

Inconvénients• Difficulté d’assurer la cohérence des différentes copies.

• Propagation des mises à jour.

Page 17: Bases de données reparties

Fragmentation

Elle consiste à découper les relations en sous-relations appelées fragments. La répartition se fait donc en deux étapes: la fragmentation et l’allocation de

ces fragments aux sites intéressés. Pourquoi fragmenter?

• Généralement les applications utilisent des sous-ensembles de relations.

• Une relation entière peut représenter une unité de distribution très grande

• Utilisation de petits fragments permet de faire tourner plus d’un processus simultanément.

Comment fragmenter?• On distingue trois possibilité de fragmentation:

• Fragmentation Horizontale

• Fragmentation Verticale

• Fragmentation Hybride

Page 18: Bases de données reparties

Fragmentations correctes?

Complitude: R fragmentée en R1 R2 ,…,Rn chaque élément se trouvant dans R doit figurer dans au moins un fragment Ri

Évite les pertes de données pendant la fragmentation

Reconstruction: soit la relation R , F= {R1, R2,., Rn} il est toujours possible de reconstruire R en appliquant des

opérations sur F

Disjonction – fragments de R contient des sous ensembles de R. RiRj= . Garantit l’absence de redondance

Page 19: Bases de données reparties

Fragmentation horizontale

Les fragmentation horizontale concerne les données.

Chaque fragment représente un ensemble de tuples.

Pour fragmenter, on a besoin d’information sur la BD (schéma global,…) et les applications (requêtes utilisées,…).

Les fragments sont définis par des opérations de sélection sur les relations.

Page 20: Bases de données reparties

Exemple

E1 J.Doe Elec. Eng.

E2 M. Smith Syst. Anal.

E3 A. Lee Mech. Eng.

E4 J. Miller Programmer

E5 B. Casey Syst. Anal.

E6 L. Chu Elect. Eng.

E7 R. Davis Mech. Eng.

E8 J. Jones Syst. Anal.

EMP ENO EName TITLE E1 P1 Mngr 12

E2 P1 Anal. 24

E2 P2 Anal. 6

E3 P3 Cons. 10

E3 P4 Eng. 48

E4 P2 Prog. 18

E5 P2 Mngr 24

E6 P4 Mngr 48

ALLOC ENO PNO RESP DUR

Page 21: Bases de données reparties

Exemple

P1 Bioinfo 500000 Lausanne

P2 ELearn. 300000 Rio

P3 Plasma 100000 Geneva

P4 Aircraft 150000 Lausanne

Proj PNO PName Budget Location

Elec. Eng. 40000

Syst. Anal. 34000

Mech. Eng. 27000

Programmer 24000

Sal Title Salary

Page 22: Bases de données reparties

Exemple de fragmentation horizontale

P1 Bioinfo 500000 Lausanne

P2 ELearn. 300000 Rio

Proj

1

PNO PName Budget Location

P3 Plasma 100000 Geneva

P4 Aircraft 150000 Lausanne

Proj

2

PNO PName Budget Location

Relations with BUDGET > 200.000 go into Proj1 and the rest goes into Proj2.Proj1= (budget>200.000) ProjProj2= (budget ≤ 200.000) Proj

Page 23: Bases de données reparties

La reconstruction de la relation est définie par l’union des fragments.

Les requêtes de l’utilisateur incluent des prédicats plus complexes qui sont des combinaison des prédicats simples. Puisqu’on peut toujours transformer une expression booléenne en une forme normale conjonctive, on se base sur les prédicats conjonctives pour fragmenter.

Page 24: Bases de données reparties

Comment?

Comment obtenir des fragments disjoints et assurer la reconstruction ?

Génération automatique Souvent « manuelle » par l ’administrateur. Différentes méthodologies selon le type de

fragmentation.

Page 25: Bases de données reparties

Analyse fragmentation horizontale

Commencer avec les conditions de sélection fréquentes (FAQ)

Extraire des requêtes les conditions de sélections: A < 10, A > 5, Ville = Tunis, Ville = Sfax

On obtient un ensemble : C={c1, c2,...cn} des conditions élémentaires (ce).

Page 26: Bases de données reparties

Fragmentation Horizontal

Construire l’ensemble des conjonctions de ce (cc) suivant :

Simplifier chaque cc ! Supprimer les cc tjr fausses

Page 27: Bases de données reparties

Exemple

A < 10, A > 5, Ville = Tunis, Ville = Sfax A < 10, A > 5, Ville = Tunis, Ville != Sfax A < 10, A > 5, Ville != Tunis, Ville = Sfax A < 10, A > 5, Ville != Tunis, Ville != Sfax A < 10, A <= 5, Ville = Tunis, Ville = Sfax A < 10, A <= 5, Ville = Tunis, Ville != Sfax A < 10, A <= 5, Ville != Tunis, Ville = Sfax A < 10, A <= 5, Ville != Tunis, Ville != Sfax

A >= 10, A > 5, Ville = Tunis, Ville = Sfax A >=10, A > 5, Ville = Tunis, Ville != Sfax A >= 10, A > 5, Ville != Tunis, Ville = Sfax A >= 10, A > 5, Ville != Tunis, Ville !=Sfax A >= 10, A <= 5, Ville = Tunis, Ville =Sfax A >=10, A <= 5, Ville = Tunis, Ville !=Sfax

A >= 10, A <= 5, Ville != Tunis, Ville = Sfax A >= 10, A <= 5, Ville != Tunis, Ville != Sfax

Page 28: Bases de données reparties

Éliminer les inutiles ...

Conditions non satisfiables Connaissance des contraintes d’intégrité, e.g;

ville soit Tunis, soit Sfax A < 10, A > 5, Ville = Tunis, Ville != Sfax A < 10, A > 5, Ville != Tunis, Ville = Sfax A < 10, A <= 5, Ville = Tunis, Ville != Sfax A < 10, A <= 5, Ville != Tunis, Ville = Sfax A >=10, A > 5, Ville = Tunis, Ville != Sfax A >= 10, A > 5, Ville != Tunis, Ville = Sfax.

Page 29: Bases de données reparties

Fragments Finaux

Regrouper les conditions sur un même attribut

5 < A < 10, Ville = Tunis 5 < A < 10, Ville = Sfax A <= 5, Ville = Tunis A <= 5, Ville = Sfax A >=10, Ville = Tunis A >= 10, Ville = Sfax

Page 30: Bases de données reparties

Propriétés de la fragmentation

Complétude : tout n-uplet t vérifie une des ce et nous avons

éliminé seulement les cc impossibles Disjonction :

Supposons t valide deux cc (cc1 et cc2) alors :

et donc t satisfait ci et $ci , contradiction !!

Page 31: Bases de données reparties

Bonne propriétés

Obtenir une partition de l’ensemble de n-uplets telle que : pour tout B de la partition, deux n-uplets de B aient la même probabilité d’être accédés par toute application/requête importante

Page 32: Bases de données reparties

Fragmentation verticale

La fragmentation concerne le schéma. Les fragments sont définis par des opérations de projection. La reconstruction est définie par jointure. La clé doit être répétée dans chaque fragment. Pour appliquer la fragmentation verticale, il existe deux possibilités: Clustering: affecter chaque attribut à un fragment, puis à chaque

étape fusionner certains fragments et s’arrêter lors de la satisfaction de certaines conditions.

Splitting: on part de la relations, puis on décide de la partitionner en des fragments en se basant sur des informations concernant les applications et les attributs.

Page 33: Bases de données reparties

Exemple de fragmentation verticale

P1 500000

P2 300000

P3 1000000

P4 150000

Proj

1

PNO Budget

P1 Bioinfo Lausanne

P2 ELearn. Rio

P3 Plasma Geneva

P4 Aircraft Lausanne

Proj

2

PNO PName Location

Page 34: Bases de données reparties

Matrice d’utilisation

Soit la relation Projet(Pnum, Pnom, Budget, Loc) et soit l’ensemble de requêtes:

q1= budget d’un projet étant donnée son numéro.

q2= nom et budget de tous les projets.

q3= nom des projets d’une ville.

q4= budget total des projets d’une ville La matrice d’utilisation est définie comme suit:

Ut(qi, Aj)=1 si la requête qi utilise l’attribut Aj et Ut(qi, Aj)= 0 sinon.

Page 35: Bases de données reparties

Exemple

A1 A2 A3 A4

q1 1 0 1 0

q2 0 1 1 0

q3 0 1 0 1

q4 0 0 1 1

Page 36: Bases de données reparties

Matrice d’affinité

Refs(qk) pour deux attributs (Ai, Aj) = nombre d’accès effectués par une exécution de qk (sur le site s) aux attributs Ai et Aj.

Accs(qk) est la fréquence d’exécution de qk sur le site s (mesurée pendant une certaine période).

- La matrice d’affinité est définie comme suit:

Aff(Ai,Aj)=k/Ut(qk,Ai)=1 et Ut(qk,Aj)=1site s Refs(qk)*Accs(qK)

Page 37: Bases de données reparties

Exemple

Supposons : Refs( qk ) = 1, quelques soient s et k

Les accès suivants (3 sites): Acc1(q1)=15 Acc2(q1) = 20 Acc3(q1) = 10 Acc1(q2)=5 Acc2(q2) = 0 Acc3(q2) = 0 Acc1(q3)=25 Acc2(q3) = 25 Acc3(q3) = 25 Acc1(q4)= 3 Acc2(q4) = 0 Acc3(q4) = 0

Aff(A1, A3) = K=1 s Accs(qk) = Acc1(q1) +Acc2(q1) +Acc3(q1) = 45

Page 38: Bases de données reparties

Exemple

A1 A2 A3 A4

A1 45 0 45 0

A2 0 80 5 75

A3 45 5 53 3

A4 0 75

3 78

A1 A3 A2 A4

A1 45 45 0 0

A3 45 53 5 3

A2 0 5 80 75

A4 0 3 75 78

Regroupement des attributs ayant une haute affinité

Page 39: Bases de données reparties

Partitionnement

Trouver un point dans la matrice pour créer deux ensembles d’attributs:

AttrHaut(AH) et AttrBas(AB).

- AR(qi)={Aj/Ut(qi, Aj)=1}

- RH={qi/AR(qi)AH}

- RB={qi/AR(qi)AB}

- Autres =Q- {RH RB}

- D’après notre exemple, on obtient:

Q ={q1, q2, q3, q4}

AH={A1, A3}

AB={A2, A4}

RH= {q1}

RB= {q3}

Autres= {q2, q4}

Page 40: Bases de données reparties

Objectives

- Maximiser les accès à un seul fragment.

- Minimiser les accès aux deux fragments.

Total RH= qk RH site s Refs(qk)*Accs(qK)=45.

Total RB=qk RB site s Refs(qk)*Accs(qK)=75.

TotalAutres=qk autres site s Refs(qk)*Accs(qK)=8. Trouver un point dans la matrice pour créer deux ensembles d’attributs AH et AB tels

que : z=(TotalRH*TotalRB)-TotalAutres2 est maximisé. La relation projet est partitionné en deux fragments:

Projet1(Pnum, Budget).

Projet2(Pnum, Pnom, Loc). La duplication de la clé permet de garantir la construction. Si beaucoup d’attributs alors il est peut être nécessaire de trouver plusieurs points

dans la matrice. Utiliser plutôt une approche récursive : partir de deux groups AH et AB et raffiner.

Page 41: Bases de données reparties

Fragmentation Hybride

Fragmentation horizontale suivit de la fragmentation verticale ou vice-versa

R

horizontale

R1 R2

Verticale

R11 R12 R21 R22 R23

Page 42: Bases de données reparties

Allocation

Supposons qu’on dispose d’un ensemble de fragments F={F1, F2, …Fn} et d’un réseau constitué d’un ensemble de sites S={S1, S2, …Sn}.

Une distribution optimale de F sur S est définie en considérant deux mesures: Un coût minimal

La fonction coût est une combinaison d’un ensemble de coûts:

- Coût de stockage de chaque fragment Fi sur un site Sj.

- Coût de modification de Fi sur un site Sj.

- Coût d’interrogation de Fi sur un site Sj.

- Coût de communication. Une meilleure performance

- Minimiser le temps de réponse.

Page 43: Bases de données reparties

Résumé

FRAGMENTATION

ALLOCATION

Relation Globale

Relations locales

Fragments

Page 44: Bases de données reparties

Approche Ascendante (bottom up design)

On dispose de différentes bases de données (les schémas locaux) et on veut les intégrer pour construire un schéma global.

L’intégration des bases de données peut être effectuée en deux étapes: la traduction des schémas et l’intégration des schémas.

Traducteur1 Traducteur2 Traducteur n

Intégrateur

SCG

BD1 BD2 BDn

Page 45: Bases de données reparties

Étape de Traduction

Transformer le schéma local en un autre schéma. Exemple: transformer un schéma en modèle réseau en un schéma en modèle relationnel

Schémas intermédiaires

Pré-intégration

- Identification des éléments reliés (e.g. domaines équivalents) et établissement

des règles de conversion (e.g. 1 inch =2.54 cm). Comparaison

- Identification des conflits de noms (synonymes, homonymes) et des conflits

structurels(clé, dépendances,…). Conformance

- Résolution des conflits de noms (renommage) et des conflits structurels

(changements des clés…) Fusion et Restructuration

- Fusion des schémas intermédiaires et restructuration pour créer un schéma

intégré optimal. .

Page 46: Bases de données reparties

Traitement reparti

Objectifs

-> Minimiser les accès disque

-> Minimiser le temps CPU

-> Minimiser la transmission réseau

-> Exploiter le parallélisme

Page 47: Bases de données reparties

Décomposition de la requête utilisateur: Elle consiste à transformer la requête utilisateur en une

requête de l’algèbre relationnelle. Décomposition: Normalisation, analyse, élimination de

redondance et réécriture.

Normalisation

Transformer la requête en une forme permettant de faciliter son traitement.

On peut distinguer deux formes: forme normale conjonctive et forme normale disjonctive.

Cette transformation utilise les règles d’équivalence suivantes:

Étapes de traitement

Page 48: Bases de données reparties

o p1p2 p2 p1. p1p2 p2 p1. p1 (p2 p3) (p1p2) p3. p1 (p2 p3) (p1 p2) p3. p1 (p2 p3) (p1p2) (p1p3) . p1 (p2 p3) (p1 p2) (p1 p3) . (p1p2 ) p1 p2 (p1 p2 ) p1 p2 ( p) p

Analyse L’analyse de la requête permet d’identifier les requêtes incorrectes qui doivent être

rejetées.

Page 49: Bases de données reparties

Les raisons principales de rejection d’une requête sont : soit la requête est type incorrect soit elle est sémantiquement incorrecte.

Exemple

Soit la requête suivante:

SELECT Enum

FROM Employe

WHERE Enom>200

Cette requête est incorrecte car la condition « >200 » est incompatible avec le type varchar de l’attribut Enom.

Il est possible d’identifier les requêtes sémantiquement incorrectes si ces requêtes ne contiennent pas de disjonction et de négation.

La requête est représentée par un graphe, nommé graphe de requête ou graphe de connexion. Si le graphe obtenu est non connexe alors la requête est sémantiquement incorrecte.

Décomposition de la requête

Page 50: Bases de données reparties

Exemple:

Soit la base de données suivante:

E (Enum, Enom, Titre, Salaire) /* E est la relation employé */

P (Pnum, Pnom, Budget) /* P est la relation projet */

EP(Enum, Pnum, Resp, Dur)

Soit la requête:

SELECT Enom, Resp

FROM E, P, EP

WHERE E.Enum = EP.Enum

and Pnom= « maintenance »

and Dur 36

and Titre =« programmeur »

Décomposition de la requête

Page 51: Bases de données reparties

Cette requête est incorrecte car elle manque une condition de jointure:

P.Pnum = EP.Pnum

E

EP

P

RésultatTitre= « progrmmeur »

E.Enum= EP.Enum

Enom

Resp

Dur 36

Pnom= « maintenance »

Décomposition de la requête

Page 52: Bases de données reparties

Les redondances peuvent être éliminées en simplifiant la requête par les règles suivantes

pp p. pp p. p true p. p false p. p false false. p true true. pp false p p true p1 (p1 p2) p1 p1 (p1 p2) p1

Élimination de la redondance

Page 53: Bases de données reparties

Réécrire la requête en algèbre relationnelle La requête en algèbre relationnelle peut être représentée

par un arbre. Exemple:

Soit la requête:

SELECT Enom

FROM E, P, EP

WHERE E.Enum = EP.Enum

and EP.Pnum= P.Pnum

and Pnom = « maintenance »

and (Dur = 12 OR Dur = 24)

L' arbre de la requête en algèbre relationnelle est:

Réécriture

Page 54: Bases de données reparties

En appliquant les règles de

transformation, on peut obtenir plusieurs arbres équivalents.

Parmi les règles de transformation, on peut citer les règles suivantes:

Soit les relations R, S et T:

- R S S R

- (R S) T R (S T)

- A’(A’’(R)) A’(R) si A’A’’.

- P1(A1)(P2(A2) (R)) P1(A1)P2(A2)(R).

Dur=12 OR Dur=24

Pnom=«maintenace »

pnum

PEP

Enum

E

Enom

Page 55: Bases de données reparties

• Cette étape permet de translater une requête en algèbre relationnelle exprimée par le schéma global de la base de données en une requête exprimée par les schémas locaux (l’ensemble des fragments)

• Les requêtes utilisant des relations fragmentées horizontalement Exemple:

On considère que la relation employé (E) est fragmenté comme suit:

E1= Enum3(E).

E2= 3<Enum<6(E).

E3= Enum>6(E).

La relation est obtenue par l’union E1 E2 E3

Soit la requête:

SELECT *

FROM E

WHERE Enum=5.

Localisation des données

E1

E2

E3

Enum=5

Page 56: Bases de données reparties

Cette requête peut être simplifiée requête réduite.

Les règles de réduction permettent d’identifier les fragments générant des relations vides.

Sélection: on considère une relation R fragmentée horizontalement en R1, R2,…Rn tel que Rj= Pj (R).

Règle 1: Pi (Rj)= si x un tuple de R :(Pi(x)Pj(x))

Pi et Pj sont des prédicats de sélection.

Exemple: on considère la requête:

SELECT * FROM E WHERE Enum=5.

D’après la règle1, si on applique le prédicat de sélection « Enum=5 » pour les fragments E1 et E3 on obtient des relation vides. Donc la requête est réduite comme suit

Localisation des Données

Enum=5

E2

Page 57: Bases de données reparties

Jointure: on peut détecter les jointures inutiles en se basant sur la règle suivante:

Règle 2: Ri Rj= si x un tuple de Rj y un tuple de Ri :(Pi(x)Pj(y))

Ri et Rj sont deux fragments définis respectivement par les prédicats Pi et Pj

Exemple: on considère la requête:

SELECT * FROM E ,EP WHERE E.Enum=EP.Enum

On considère que EP est fragmentée comme suit:

EP1= Enum3(EP)

EP2= Enum>3(EP)

E1 E2E3

Enum

EP1 EP2

E1 EP1 E2

E3 EP2

Enum

EP2

EnumEnum

Requête Générique Requête Réduite

Page 58: Bases de données reparties

On considère que la relation Employé E est fragmentée verticalement comme suit:

E1= Enum, Enom( E )

E2= Enum, Titre( E )

La relation E est reconstruite par une opération de jointure.

E= E1 E2

Les requêtes utilisant des relations fragmentées verticalement peuvent être réduites en éliminant les opérations inutiles. Pour ce faire, on utilise la règle suivante:

Règle3: on pose Ri = A’( R )

D( Ri ) est inutile si l’ensemble des attributs D intersection A’ égale au vide

Les requêtes utilisant des relations fragmentées verticalement

Page 59: Bases de données reparties

Exemple:

Soit la requête:

SELECT Enom

FROM E

E1 E2

Enom

Enum

Requête Générique

E1

Enom

Requête réduite

Page 60: Bases de données reparties

Validation des Transactions réparties

OBJECTIF Garantir que toutes les mises à jour d'une transaction sont

exécutées sur tous les sites ou qu'aucune ne l'est.

EXEMPLE Transfert de la somme X du compte A vers le compte B DEBUT

site 1: A = A - X site 2: B = B + X PANNE --> INCOHERENCE DONNEES

FIN

PROBLEME Le contrôle est réparti : chaque site peut décider de valider ou

d’annuler ...

Page 61: Bases de données reparties

Commit en 2 Phases

Principe Diviser la commande COMMIT en deux phases Phase 1 :

Préparer à écrire les résultats des mises à jour dans la BD Centralisation du contrôle

Phase 2 : Écrire ces résultats dans la BD

Coordinateur : Le composant système d'un site qui applique le protocole

Participant : Le composant système d'un autre site qui participe dans l'exécution

de la transaction

Page 62: Bases de données reparties

Protocole C/S

1. PREPARER Le coordinateur demande aux autres sites s’ils sont prêts à

commettre leurs mises à jour.

2a. SUCCES : COMMETTRE Tous les participants effectuent leur validation sur ordre du client.

2b. ECHEC : ABORT Si un participant n’est pas prêt, le coordinateur demande à tout les

autres sites de défaire la transaction.

REMARQUE Le protocole nécessite la journalisation des mises à jour préparées

et des états des transactions dans un journal local à chaque participant.

Page 63: Bases de données reparties

Cas FavorableSITE COORDINATEUR

SITE PARTICIPANT 2SITE PARTICIPANT 1

PREPARE PREPARE

OK OK

COMMIT COMMIT

ACK ACK

Page 64: Bases de données reparties

Cas Défavorable (1)

PREPARE PREPARE

OK

ACK

KO

ABORT ABORT

ACK

SITE COORDINATEUR

SITE PARTICIPANT 2SITE PARTICIPANT 1

Page 65: Bases de données reparties

Cas Défavorable (2)

PREPARE PREPARE

OK

ACK

OK

COMMIT COMMIT

STATUS

COMMIT

ACK

SITE COORDINATEUR

SITE PARTICIPANT 2SITE PARTICIPANT 1

Page 66: Bases de données reparties

Prepare OK OKCommit

PrepareOK

Commit distribué ou centralisé Validation à deux phases centralisée

Possibilité de diffuser la réponse au PREPARE chaque site peut décider localement dans un réseau sans perte

Page 67: Bases de données reparties

Initial

Wait

Abort Commit

CCommit/Prepare

VoteKO/GAbort VoteOK/GCommit

Initial

Ready

Abort Commit

Prepare/VoteOK

GAbort/Ack GCommit/Ack

COORDINATEUR

PARTICIPANT

Transitions d'Etats

Page 68: Bases de données reparties

Transactions bloquées

Que faire en cas de doute ? Demander l’état aux autres transactions : STATUS

conservation des états nécessaires message supplémentaire

Forcer la transaction locale : ABORT toute transaction annulée peut être ignorée cohérence garantie avec un réseau sans perte de message

Forcer la transaction locale : COMMIT toute transaction commise peut être ignorée non garantie de cohérence avec le coordinateur

Page 69: Bases de données reparties

Initial

Wait

Abort PréCommit

Commit

CCommit/Prepare

VoteKO/GAbort VoteOK/PréCommit

PréOK/GCommit

Initial

Ready

Abort PréCommit

Commit

Prepare/VoteOK

GAbort/AckPréCommit/PréOK

GCommit/Ack

Commit en 3 Phases

Inconvénient du commit à 2 phases en cas de time-out en état

“Prêt”, le participant est bloqué

le commit à 3 phases permet d’éviter les blocages

Messages du commit à 3 phases Prepare, Prepare to Commit, Global-Commit, Global-Abort.

Page 70: Bases de données reparties

Coordinateur global

Coordinateur localPoint de validation(Noeud critique)

Coordinateur local

Protocole arborescent TP

TP est le standard proposé par l’ISO dans le cadre OSI

Protocole arborescent Tout participant peut déclancher

une sous-transaction Un responsable de la validation est

choisi Un coordinateur est responsable

de ses participants pour la phase 1 collecte les PREPARE demande la validation

Le point de validation est responsable de la phase 2

envoie les COMMIT