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
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
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
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
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).
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.
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
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.
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
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
Conception des BDs 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)
Architecture d’une BDR
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.
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
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.
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
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
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.
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
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
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
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.
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.
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).
Fragmentation Horizontal
Construire l’ensemble des conjonctions de ce (cc) suivant :
Simplifier chaque cc ! Supprimer les cc tjr fausses
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
É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.
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
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 !!
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
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.
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
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.
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
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)
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
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é
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}
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.
Fragmentation Hybride
Fragmentation horizontale suivit de la fragmentation verticale ou vice-versa
R
horizontale
R1 R2
Verticale
R11 R12 R21 R22 R23
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.
Résumé
FRAGMENTATION
ALLOCATION
Relation Globale
Relations locales
Fragments
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
É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. .
Traitement reparti
Objectifs
-> Minimiser les accès disque
-> Minimiser le temps CPU
-> Minimiser la transmission réseau
-> Exploiter le parallélisme
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
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.
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
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
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
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
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
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
• 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
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
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
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
Exemple:
Soit la requête:
SELECT Enom
FROM E
E1 E2
Enom
Enum
Requête Générique
E1
Enom
Requête réduite
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 ...
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
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.
Cas FavorableSITE COORDINATEUR
SITE PARTICIPANT 2SITE PARTICIPANT 1
PREPARE PREPARE
OK OK
COMMIT COMMIT
ACK ACK
Cas Défavorable (1)
PREPARE PREPARE
OK
ACK
KO
ABORT ABORT
ACK
SITE COORDINATEUR
SITE PARTICIPANT 2SITE PARTICIPANT 1
Cas Défavorable (2)
PREPARE PREPARE
OK
ACK
OK
COMMIT COMMIT
STATUS
COMMIT
ACK
SITE COORDINATEUR
SITE PARTICIPANT 2SITE PARTICIPANT 1
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
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
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
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.
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