Base de Données

Bases de donnees reparties Universite de Lorraine, FST/MIAE, Dept.
MIAE, Dept. Informatique & ESIAL 1/136 Bases de donnees reparties Universite de Lorraine, FST/MIAE, Dept. Informatique & ESIAL 2/136
Bases de donnees reparties
Nacer.Boudjlida@loria.fr
http://www.loria.fr/ nacer Chapitre I : Introduction
Universite de Lorraine, FST/MIAE, ESIAL
Septembre 2012
Support de cours. Des complements importants seront donnes en cours.
c Nacer.Boudjlida@loria.fr c Nacer.Boudjlida@loria.fr
Bases de donnees reparties Universite de Lorraine, FST/MIAE, Dept. Informatique & ESIAL 3/136 Bases de donnees reparties Universite de Lorraine, FST/MIAE, Dept. Informatique & ESIAL 4/136
Bases de donnees distribuees : Definitions Bases de donnees distribuees : Definitions (fin)
Integration des technologies bases de donnees (BDD) et reseau Base de donnees distribuee (DDB) :
Integration des donnees dune entreprise sans centralisation Collection de BDD logiquement reliees et physiquement
distribuees sur un reseau
Distribution naturelle :
SGBD Distribue :
Agence mere et ses filiales
Systeme logiciel de gestion rendant les applications insensibles
Unite centrale et sous-systeme dentrees/sorties, etc.
a la distribution des donnees (TRANSPARENCE)
Denition orientee bases de donnees :
Base de donnees distribuee NEST PAS :
Systeme de traitement distribue = (1) Unites dexecution de
Fichiers independants sur des sites differents,
programmes, (2) autonomes, eventuellement (3) heterogenes,
(4) relies par un reseau de communication et (4) cooperant a la Base centralisee accessible via le reseau
realisation de taches.
QUOI distribuer ? Problemes lies a la distribution
Donnees Conception des bases distribuees :
Traitements Partitionnement des donnees (FRAGMENTATION,

LOCALISATION)
Fonctions du systeme
DUPLICATION totale/partielle
Controle et coordination des taches Administrateur global, local
Dictionnaire(s)
Extension avec des informations sur les sites, la fragmentation, la
duplication et la localisation des donnees
Centralise ou distribue ?
Copie simple ou multiple ?
Problemes lies a la distribution (suite) Problemes lies a la distribution (suite)
Traitement des requetes : Acces concurrents

Objectif : Optimiser en exploitant le parallelisme Controle reparti des acces concurrents prenant en compte la
Probleme NP-complexe : Approches heuristiques duplication
Facteurs : Techniques : verrouillage, estampillage

Localisation/Duplication des donnees Traitement du deadlock distribue ?
Cout des communications
Disponibilite locale dinformations suffisantes
Strategies : Sous-requetes, jointures paralleles, semi-jointure, etc.
Problemes lies a la distribution (suite) Problemes lies a la distribution (fin)
Securite et reprise en cas dincident Heterogeneite

Nouveaux types dincidents : perte de messages, panne dune Materiels/Logiciels
liaison, etc. Modeles de donnees et Langages de manipulation
Preservation des bases des sites operationnels en cas de panne dun Introduite aussi dans les systemes MULTI-BASEs : regroupement
site de BDD centralisees autonomes
Condentialite sur un reseau Mecanimes de traduction (donnees, programmes)
Systemes hotes :
Quelles solutions (homogenes) pour supporter les applications
distribuees et celle non distribuees (TRANSPARENCE) ?
Bases de donnees reparties : Contenu
Chapitre II. Typologie des SGBD distribues (p. 12)

Chapitre III. Distribution de donnees (p. 23)
Chapitre IV. Traitement des requetes (p. 33)

Chapitre V. Contraintes dintegrite et Confidentialite (p. 52) Chapitre II : Typologie des SGBD distribues
Chapitre VI. Transactions et Acces concurrents (p. 55)
Chapitre VII. Securite de fonctionnement (p. 95)
Chapitre VIII. Architecture des SGBD distribues (p. 105)

Chapitre IX. Conclusion (p. 131)
Bibliographie (p. 134)
Caracteristiques dun SGBD distribue Caracteristiques dun SGBD distribue
1. Transparence du reseau 3. Transparence de la fragmentation dans le traitement des requetes

Nommage des objets Requete sur UNE relation (utilisateur)
Localisation des objets Decomposee en sous-requetes (systeme)
Services (Exemple : cp f1,f2; rcp site:f1, site:f2) Sous-requetes evaluees sur les fragments (systeme)
Union des reponses (systeme)
2. Transparence de la duplication : Points de vue
Utilisateur : Duplication ? Connais pas ! 4. Transparence des langages dans le cas de DDB heterogenes
Systeme : implications en recherche, en mise a jour, en gestion des
acces concurrents
Criteres de classification Typologie (1/3)
1. AUTONOMIE Distribution
SGBD Homognes
Concerne la distribution du controle 5 Distribus
Mesure le degre dindependance

Fonction de :
SGBD Fdrs
Volume des echanges inter-sites Htrognes Systme
Mono-sites Multi-bases
Capacites dexecution independamment des autres sites 2 3
1
2. DISTRIBUTION : (ou pas) des donnees Autonomie
3. HETEROGENEITE
Hardware, protocoles reseaux SGBD Htrognes
4 Intgrs
Modeles de donnees : puissances dexpression
Htrognit
Langages : paradigmes, dialecte(s)
Typologie (2/3) Typologie (3/3)
Distribution Distribution
5 6 7 5 6 7
Homogne Multi-Bases
Fdr Homognes
Distribu Distribues
Fdr Multi-bases
Distribu Htrogne
Distribu Htrogne Distribu
8 Htrogne 8 12
11
2 3 2 3
1 1
Autonomie Autonomie
Fdr Htrogne Multi-bases

Mono-site Htrognes
4 4
9 10 9 10
Htrognit Htrognit
Architecture de reference ANSI/SPARC (1/2) Architecture de reference (2/2)
Administrateur Entreprise
Administrateur
Administrateur dapplication
Base Globale Processeur de Schma
Conceptuel Global
Processeur de
Schmas Externes
Dictionnaire
Global
Gestion de Donnes Locales
Gestion de Donnes Locales
Administrateur Processeur de Schma

Base Locale Conceptuel Local
Processeur de Dictionnaire
Schmas Internes Local
Composants fonctionnels dun SGBD distribue Composants fonctionnels dun SGBD distribue
1. Processeur de donnees 2. Processeur dapplications

PROCESSEUR dAPPLICATIONS
UTILISATEUR
USER INTERFACE
PROCESSEUR LOCAL SCHEMA CONCEPTUEL
de REQUETES LOCAL
SCHEMA EXTERNE
CONTRAINTES
SCHEMA CONCEPTUEL
SOUS-SYSTEME LOCAL JOURNAL GLOBAL
de REPRISE
OPTIMISATION
GLOBALE
SCHEMA INTERNE DICTIONNAIRE GLOBAL

MECANISME dEXECUTION LOCAL
CONTROLE EXECUTION
REPARTIE
BASES
de
DONNEES
PROCESSEUR de DONNEES
III.1- Fragmentation et duplication de donnees
DUPLICATION TOTALE :
(+) Disponibilite des donnees
(+) Parallelisme en lecture
(+) Moindre flux sur le reseau
Chapitre III : Distribution de donnees (-) Cout des mises a jour
FRAGMENTATION :
Decoupage dune relation R en fragments
Fragmentation Horizontale : Reconstruction par UNION
Fragmentation Verticale : Reconstruction par JOINTURE
Fragmentation horizontale Fragmentation verticale
Peut etre definie par une selection Forme la plus simple : Decomposition de R
Fragments disjoints ou non (Duplication partielle) Identifiant (cle) dans chaque fragment
Fragmentation mixte et duplication III.2- Transparence et autonomie
1. FRAGMENTATION MIXTE : horizontale et verticale 1. Transparence :

du reseau
2. FRAGMENTATION et DUPLICATION :
de la localisation
Duplication de fragment(s)
connaissance minimale sur les lieux de rangement des donnees
Fragmentation de duplicata, etc.
2. Autonomie :
Liee a la transparence
Convention de nommage des fragments et des copies :
Degre dindependance vis-a-vis du systeme distribue
Designation Objet : Fragment
Analyse selon les points de vue :
Designation Objet : Copie
(1) Nommage des objets
Exemple : Site2.Produit.F3.C4
(2) Fragmentation et Duplication des donnees
(3) Localisation
(1/3) Transparence et autonomie : Nommage des objets (2/3) Transparence : Fragmentation et duplication
Assurer lunicite des noms DUPLICATION :
Solution 1 : Serveur de noms centralise Utilisateur : Pas de designation de copie
(-) Autonomie locale Quelle copie acceder ?
(-) Surcharge du serveur ; Blocage en cas de panne Quelle(s) copie(s) mettre a jour ?
Solution 2 : Nom du site Nom Objet FRAGMENTATION :
(+) Pas de controle centralise : Meilleure autonomie locale Utilisateur : Pas de designation de fragment
(-) Pas de Transparence du reseau Comment localiser ?
(3/3) Transparence : Localisation Schema dalgorithme de localisation
Definition dalias (sans nom du site)

(+) (Legere) transparence a lutilisation
(+) Tranparence si changement de localisation
Exemple : Site1 : alias compte local pour le fragment Site1.compte.F1
Principe de la localisation
1. Remplacer compte local par Site1.compte.F1
2. Si Site1.compte.F1 duplique
Acces a la table des copies (dictionnaire)
Choisir une copie
3. Si copie fragmentee Consulter la table des fragments
Chapitre IV : Traitement des requetes Traitement des requetes
Processus de traitement des requetes : PLAN dEXECUTION REPARTI :

Traitements Locaux et Operations de Communication de donnees
intermediaires
Comprend le necessaire pour les executions locales et la
synchronisation globale
Et la fragmentation ?
Representation canonique de requete algebrique
Identification et localisation des fragments
Extension de la representation canonique par les sous-arbres de
reconstruction des fragments
Traitement des requetes : Exemple Traitement des requetes : Regles de transformation
REGLES CLASSIQUES de transformation

AUTRES REGLES :
1. Condition de selection et expression de fragmentation identiques
Selection INUTILE
2. Fragmentation horizontale : Resultat vide si
Selection
Libelles des produits du depot 4 ?
Condition de selection et expression de fragmentation
select libelle from Produit p, Stock s CONTRADICTOIRES
where s.prod# = p.prod# and s.dep# = 4 3. Fragmentation verticale : Resultat vide si
Fragmentation verticale de liste L
Projection de liste L

Optimisation : Objectifs et facteurs Optimisation : Types de decisions
Minimiser une fonction cout Decisions incluses dans le plan dexecution

Fonction generale : (n : nombre de sites Ordre des jointures
impliques) Strategie de jointure (voir plus loin)
Autres : Tenir compte Selection des copies (site le plus proche, le moins engorge)
du parallelisme Choix des sites dexecution (couts des communications)
des couts des transferts Choix des algorithmes dacces repartis
des prols des fragments (Taille, nombre de n-uplets, etc.) Choix du mode de transfert (tuple/tuple, paquets)
de la taille des resultats intermediaires
de linstant de loptimisation (compilation/execution)
de la topologie du reseau
du cout de loptimisation, etc.
Strategies devaluation des requetes Strategie 1/3 : Jointures simples
En centralise : cout des acces Pas de fragmentation ni de duplication
Cadre distribue : SITE : Produit (Depot Stock)

Transmission de donnees Produit : Site
Traitement parallele des (sous-)requetes
Depot : Site
Attention particuliere aux jointures
Stock : Site
STRATEGIES :
Site emetteur de la requete :
1. Jointures simples avec transferts
2. Jointures paralleles
3. Semi-Jointures
Strategie 1/3 : Jointures simples Strategie 1/3 : Jointures simples
Jointures simples : Strategie 1 Jointures simples : Strategie 2

1. Transfert des relations sur 1. Transfert de Stock vers
2. Optimisation sur 2. Calcul de TEMP1 = (Depot Stock)
3. Execution locale 3. Transfert de TEMP1 vers
4. Calcul de TEMP2 = (Produit TEMP1)
5. Transfert de TEMP2 vers
Jointures simples : Discussion Strategie 2/3 : Jointures paralleles
STRATEGIE 1 :
Reconstruction eventuelle des index sur
sur site
Volume des transferts
Jointures paralleles :
STRATEGIE 2 : Volume des transferts
1. Sur :
2. Sur :
3. Envoi des nuplets vers au fur et a mesure du calcul
4. evalue parallelement aux evaluations
sur et
Strategie 3/3 : Semi-Jointure ( ) Strategie 3/3 : Semi-Jointure ( )
Exemple :
Strategie permettant deviter le transfert de tuples non utiles pour la
jointure
Correction de la strategie : Demontrer que
EXEMPLE : = ?

sur sites , respectivement
Strategie Semi-Jointure, resultat sur
1. :
2. : Envoi de TEMP1 a
3. :
4. : Envoi de TEMP2 a
5. :
Strategie 3/3 : Discussion Traitement des requetes : Cas des Vues
Hypothese : Selectivite faible Rappel : Vue = relation calculee
Vue definissable sur fragments repartis

Transfert de moins couteux que celui de Traitement de requetes sur vues
Ce gain devrait compenser le cout du transfert de 1. Par re-ecriture
Augmentation du nombre doperations 2. En utilisant des vues concretes

3. En utilisant des cliches (Snapshots)
MAIS sur de plus petites relations
Gain proportionnel a la selectivite de la jointure
1/3. Requetes sur vues et re-ecriture 3/3. Requetes sur vues et cliches
1. Requete sur vue re-ecrite en une requete sur relations Cliche : Vue mise a jour periodiquement
2. Traiter comme une requete repartie Reduction du cout par mises a jour differentielles (Vue sur une relation,
definie par
Estampillage des tuples de la relation
2/3. Requetes sur vues et vues concretes
Estampillage du cliche
Calcul et stockage des valeurs des vues Calcul dune relation contenant les tuples du cliche a modifier
Mise a jour du cliche (et de ses copies)
Mises a jour systematiques
Duplication eventuelle sur les sites utilisateurs frequents
SOLUTION ACCEPTABLE si vue definie sur beaucoup de fragments

(Diminution du cout de son calcul)
3/3. Requetes sur vues et cliches
Produit Clich 10:30

estampille #prod libell pu
#prod pu
10:00 11 P11 10
11 10
10:15 22 P22 20
22 20
10:30 33 P33 30
33 30
11:00 44 P44 40 Chapitre V : Contraintes dintegrite et Confidentialite
Clich 11:00
Produit 11:00 #prod pu
#prod pu 11 10
44 40 22 20
33 30
44 40
Confidentialite Contraintes dintegrite
1. Identication des utilisateurs distants : CI = Formule du calcul relationnel

Sous-transactions dune transaction comportent Verifier CI :
lidentification de lauteur de (Nom, Mot de passe)
Produit cartesien des relations impliquees satisfait la formule
2. Identication du site emetteur :
Solution immediate : CI satisfaite si
Un site naccepte des (sous-)transactions de que si
(X (Relations impliquees)))
connat
(X (Relations impliquees)) : comme une requete repartie
Fragmentation et CI contradictoires : Pas dacces aux donnees

En mise a jour : Si violation alors ROLLBACK
Chapitre VI : Transactions et Acces concurrents Gestion des transactions
Validation ou avortement sur chacun des sites impliques Chaque gestionnaire de transactions :
Validations independantes ? NON car certaines transactions peuvent Gere le Log
avoir avorte Participe a la coordination des executions selon un protocole
Un gestionnaire local par site
Chaque coordonnateur :
Modele de systeme : Lance lexecution dune transaction
1. Un gestionnaire des transactions locales et distantes Decompose une transaction
2. Un coordonnateur de la gestion des transactions Transfere les transactions vers les bons sites
Coordonne la validation
Gestion des transactions : Plan La validation des transactions

1. Validation des transactions (p. 58) Protocole de validation a deux phases (Two-Phase Commit Protocol) :
(a) Le protocole de validation a deux phases (2PC) Lampson 1976, Gray 1978
(b) 2PC et echecs (p. 65) Le plus connu et implemente
(c) Implementations du protocole (p. 69) Execute par chaque site
2. Gestion de la concurrence (p. ??) Controle par un site matre (coordonnateur)
(a) Estampillage (p. 73) Assure lAtomicite (sauf dans le cas de la destruction du log)
(b) Verrouillage (p. 77) Correction prouvee dans J.L. Baer and al.: The Two-Step
(c) Verrouillage et Interblocage (p. 84) Commitment Protocol: Modeling, Specication and Proof
Methodology, ICSE81, San Diego.
Le protocole de validation a deux phases Validation a deux phases et echecs
1. Preparation : Coordonnateur demande aux sites de se preparer

(Ecriture Logs coordonnateur et sites, . . . ) S1
2. Validation/Annulation : Coordonnateur ordonne la validation ou Prepare Ready Commit Commited
lavortement en fonction des resultats de la premiere phase Coord

Prepare Ready Commit Ready Commit Commited
S2
Panne de S2
Temps
- PANNE du SITE 2 APRES READY
Validation a deux phases et echecs Validation a deux phases
Transaction T initiee sur site

S1
coordonnateur de
Prepare Ready Prepare Ready Commit Commited
Coord Chaque site participant a T informe de la fin de sa contribution
Prepare Ready Prepare Ready Commit Commited
1. Phase 1 :
S2
:
Panne du Coord.
Journalise PREPARE T
- PANNE du COORDINATEUR APRES les READY - Temps Envoie PREPARE TO COMMIT aux sites
Chaque :
Si validation possible
Alors Journalise et envoie PRET T a
SINON Journalise NO T et envoie ABORT T a
Validation a deux phases Validation a deux phases
2. Phase 2 : CAS REUSSITE (tous les PRET T sont parvenus) Exercice :

Journalisation de COMMIT T sur et les Decrire le protocole de validation a deux phases sous la forme dun
diagramme dinteraction, sachant que tous les sites utilisent le Write Ahead
Les envoient un ACK a
Log Protocol.
journalise COMPLETE T apres reception des ACK.
3. Phase 2 : CAS ECHEC

Un des repond ABORT T
ou tous les PRET T non parvenus a dans un delai d
:
Journalise ABORT T
Envoie ABORT T aux
Validation a deux phases et pannes 1/4. Validation a deux phases : Panne dun site
Apres REPRISE, examen du Log de : Cas

1. Panne dun site participant
1. Pas dinformation sur T dans le Log : na pas repondu au
2. Panne du site du coordinateur UNDO(T)
3. Rupture de liaison 2. : REDO(T)
3. : UNDO(T)
4. Partition du reseau
4. :
Consulter puis UNDO(T) ou REDO(T)
Cas en Panne : Comment obtenir des informations sur T ?
Envoi de aux autres
Si reception dune reponse : UNDO ou REDO
Si pas de reponse ou si auncun na linformation, poursuite
des envois de par (avec etat
et verrous eventuels chez )
2/4. Validation a deux phases et Panne du coordinateur 3/4. Validation a deux phases et Rupture dune liaison
T est validee ssi actif Messages ne parviennent plus
T est annulee ssi actif Chaque partie pense que lautre est en panne
Sinon attendre la reprise de Application du schema Panne dun site
4/4. Validation a deux phases et Partition du reseau
Si et tous les dans la meme partition : Pas de probleme
Sinon cas similaire a la rupture dune liaison
Validation a deux phases : Implantations Validation a deux phases : Mise en uvre pratique
1. Centralise (cf. ce qui precede) Une transaction matresse (coordonateur) connaissant la

fragmentation
2. Lineaire
Une transaction par sous-requete
3. Distribue
Transaction matresse :
lance les sous-requetes ( appel de procedure distante)
Coordonne la validation a deux phases
Communication par appel de procedures distantes (Remote Procedure
Call)
Validation a deux phases : conclusion Gestion de transactions : Plan
Bloquant si panne du coordonnateur : Maintien des ressources jusqua 1. Validation des transactions (p. 58)
sa reprise (a) Le protocole de validation a deux phases (2PC)
Blocage du a la transition directe PRET, VALIDER (b) 2PC et echecs (p. 65)
(c) Implementations du protocole (p. 69)
Protocole a trois phases (Implantation ?)
Introduit par D. Skeen 2. Gestion de la concurrence (p. ??)
Non-Blocking Protocols, ACM-SIGMOD Conference, An (a) Estampillage (p. 73)
Arbor, Michigan, May 1981 (b) Verrouillage (p. 77)
Etat intermediaire PRET a VALIDER (c) Verrouillage et Interblocage (p. 84)
Si atteint alors VALIDER TOUJOURS
en panne et aucun na recu PRET a VALIDER alors
UNDO
I. Les techniques destampillage Estampillage
Ordre de serialisation obtenu par association dune estampille unique a SYNCHRONISATION des HORLOGES ou des COMPTEURS
chaque transaction Probleme : Un site genere plus rapidement que les autres
Gestion centralisee ou distribuee des estampilles
Mecanisme de controle de la generation saine des estampilles
1. Gestion centralisee
Site : Horloge
UN site
recoit un message estampille t, s avec
Compteur logique ou horloge locale
avance a t + 1
2. Gestion decentralisee
Estampille, Identifiant du Site
Mecanisme similaire si utilisation dhorloges physiques
Estampille : compteur logique ou fonction de lhorloge locale
SYNCHRONISATION des HORLOGES ou des COMPTEURS
Estampilles et acces concurrents Estampillage et acces concurrents : Conclusion
Chaque granule garde trace de la derniere transaction qui la utilise Beaucoup de ROLLBACK et de UNDO
Ordonnancement : Melange de 2-Phase Commit et estampillage : Protocole assurant la

serialisabilite sans cascade de ROLLBACK
veut acceder a un granule estampille j
Si j i Technique delaissee au profit du verrouillage (+ gestion de deadlock)
Alors peut sexecuter
Sinon ABORT( ) et reprise ulterieure
avec estampille
Finsi
ESTAMPILLAGE et ROLLBACK
Conflits geres par des ROLLBACK et pas par des attentes
Donc, risque de cascades de rollback
II. Acces concurrents : Techniques de verrouillage 1/5. Verrouillage et donnees non dupliquees
1. Donnees non dupliquees Un Gestionnaire de verrous par site
2. Protocole de la majorite Demande de verrou dun granule D, sur un site par une transaction
T:
3. Coordonnateur unique
T envoie sa demande a
4. Protocole partial
D verrouille dans un mode incompartible avec celui demande
5. Protocole de la copie primaire Demande mise en attente
Verrou appose informe T
Mecanisme SIMPLE : Deux envois de messages
Demandes de verrouillage et de deverrouillage
Gestion COMPLEXE du deadlock
2/5. Verrouillage et protocole de la majorite 3/5. Verrouillage et Coordonnateur unique
Version modifiee du protocole sans duplication Sur un site

D est detenu par une transaction T si T obtient le verrou sur une
Recoit les demandes de (de)verrouillage
majorite de copies
Lecture sur tout site detenant une copie
Un Gestionnaire de verrous par site
Granule D localise sur N sites Ecriture : concerne tout site detenant une copie
Demande concernant D adressee a M sites, M N/2 Si verrou apposable : informer le demandeur
Verrouillage ou attente sur les M sites Sinon : informer et mettre en attente

(+) Pas de controle centralise avec duplication APPROCHE SIMPLE :
(-) Gestion complexe du deadlock Trois transferts de messages : 2 (Verrouillage) + 1 (Deverrouillage)
(-) 2(n/2 + 1) messages (Verrouillage) Gestion du deadlock : cf. BDD centralisee
(-) + (n/2 + 1) messages (Deverrouillage)
3/5. Verrouillage et Coordonnateur unique 4/5. Verrouillage et Protocole partial
INCONVENIENTS : Similaire au protocole de la majorite

Engorgement de Favoriser les verrous partages au detriment des verrous exclusifs
Blocage en cas de panne Un gestionnaire de verrous par site
charge des verrous sur les donnees locales
ALTERNATIVE :
Verrou partage : demande adressee a un des sites detenant la donnee
Coordonnateurs sur plusieurs sites
Verrou exclusif : demande adressee a tous les sites
Distribution de la gestion des verrous
Chaque gestionnaire se charge dun sous-ensemble de donnees Mise en attente ou apposition
(+) Reduction engorgement (+) Overhead inferieur a celui des autres protocoles
(-) Gestion plus complexe du deadlock (-) Overhead neanmoins, en ecriture

(-) Gestion complexe du deadlock
5/5. Verrouillage et Protocole de la copie primaire III. Verrouillage et Interblocage
SITE PRIMAIRE : site privilegie dune donnee dupliquee D Cadre centralise :

Site primaire recoit les demandes relatives a D Graphe dattente
(+) Gestion de la concurrence similaire au cas non duplique Scrutation periodique
(+) Simplicite de limplementation Si cycle, tuer une transaction
(-) Blocage en cas de panne sur le site primaire Cadre distribue : Gestion du graphe dattente ?
Un graphe par site

Verrouillage et Interblocage 1/3. Gestion centralisee de linterblocage
T1 T2
T2 T4 COORDONNATEUR de detection de deadlock sur site
Graphe global gere sur
T5 T3
- Graphe Local 1 - T3 - Graphe Local 2 -
Communication des modifications des graphes locaux
T1 T2 T4 GRAPHE GLOBAL
AVEC DEADLOCK Mise a jour periodique du graphe global
T5 T3 Apres chaque modification dun graphe local
Apres un certain nombre de modifications
Approches pour la gestion de linterblocage :
Avant la scrutation
1. Centralisee
2. Repartie
3. Hierarchique
1/3. Gestion centralisee de linterblocage Exemple de faux deadlock
Graphe global construit : Approximation du graphe reel Global

Site 1 Site 2
Cycle sur le graphe construit T2
T1 T1
Resolution (Tuer transaction et ROLLBACK) T1 T2 T3
T3
Information aux sites impliques dans
!!! FAUX DEADLOCK et ROLLBACK INUTILE - Situation Initiale -
Global
Site 1 Site 2
T2
T1 T2 T1 T3 T1
T3
T2
- Evolutions sur les sites - - Faux Deadlock -
Exemple de Rollback inutile 2/3. Gestion repartie de linterblocage
Site 1 Site 2
: Nouveau type de nud (Transaction NON locale)
Global
T1
Arc : en attente dun autre site
T2 T2 T4 T1 T2
Arc : en attente dune ressource locale
T3 T3 T3 T4
Principe de la detection :
SI
- SITUATION INITIALE -
ALORS SI
- SITE1 AVORTE T2 ALORS DEADLOCK LOCAL
- COORDONNATEUR DETECTE LE CYCLE ET AVORTE T3 SINON - RISQUE de DEADLOCK
- T3 VICTIME INNOCENTE
- DETECTION [et RESOLUTION]
FINSI
FINSI
2/3. Gestion repartie de linterblocage 2/3. Gestion repartie de linterblocage
: Transaction k du site
T1 T2 T2 T4
detecte le cycle : en attente de et ext = j
envoie un message a :
Description du cycle
T3 T T T3
ext ext Demande de detection de deadlock
- Graphe Local 1 - - Graphe Local 2 -
:
Mise a jour du graphe local
Cycle necessairement de la forme :
Recherche de cycle dans : graphe
cycle local : Resolution
cycle AVEC : Faire comme
Nombre ni dessais : detection echoue ou reussit
2/3. Gestion repartie de linterblocage : exemple 3/3. Gestion hierarchisee de linter-blocage
S1: Text T2 T3 S1 envoie la description Hierarchisation des sites

du cycle S2
Graphe dattente dun nud : graphe global aux sites descendants

Graphe de S2 :
Text T3 T4 T2 Detection de deadlock sur les sous-arbres
(+) Reduit lactivite a la racine (cf. approche centralisee)
Graphe de S2 mis jour
Performances fonction de ladequation Hierarchie-Localisation des
Text T3 T4 T2 transactions
CYCLE LOCAL T3, T4, T2, T3 : A RESOUDRE
Securite de fonctionnement et reprise
Nouveaux types de pannes :

Panne dun site
Rupture dune liaison
Perte de message
Chapitre VII : Securite de fonctionnement Partition du reseau
Procedure :
1. DETECTION
2. RECONFIGURATION du SYSTEME
3. REPRISE
1/3. Securite de fonctionnement : Detection 2/3. Securite de fonctionnement : Reconfiguration
Souvent possible Avortement des transactions actives (Liberation des ressources)

Identification de panne difficile Inhiber lacces aux donnees dupliquees du site en panne (MAJ
ne communique plus avec catalogue)
en panne ou rupture de liaison ? Si site en panne = site central (coordonnateur, etc.) : Remplacement
Si partition du reseau :
Tolerer lexecution de transactions dans les partitions
Eviter lelection de plusieurs serveurs centraux dans une partition
Eviter la MAJ de donnees dupliquees par plusieurs partitions
3/3. Securite de fonctionnement : Reprise Remplacement dun site coordonnateur
Appliquer les MAJ qui ont eu lieu sur les donnees dupliquees Coordonnateur UNIQUE RISQUE de BLOCAGE
MAIS, ces donnees peuvent ENCORE etre en cours de MAJ Designation dun remplacant :
Solution 1 : 1. Doublure pre-definie (BACK-UP)
Arret du systeme et remise en etat 2. Election
Eventuellement, negociation humaine pour la coherence des copies 3. Preemption
Solution 2 : Reprise Serie de transactions

Reprise apres partition du reseau :
Informer les sites de la reparation de la liaison (message broadcast)
1/3. Coordonnateur back-up 2/3. Election de coordonnateur
Recoit les memes messages que le vrai Identifiants UNIQUES des sites
Execute les memes algorithmes Panne du site de coordination :
Gere les memes informations Choix dun site
Prend le relai en cas de panne Informer les autres sites

Prevoir dinformer les sites en panne
(+) Reprise rapide Panne (presumee) du coordinateur : Pas decho pendant t
(-) Overhead Election
2/3. Election de coordonnateur : Algorithme bulldozer 3/3. Preemption
Algorithme : = initiateur de lelection Reprise dun site : Execution du meme algorithme
Message delection vers les sites didentifiants superieurs

SI pas de reponse APRES t SI
ALORS TOUS en PANNE ALORS DEVIENT COORDONNATEUR
: JE SUIS LE COORDINATEUR FINSI
informe tous les sites didentifiants inferieurs
SINON Attente election dun site didentifiant superieur
SI PAS dinformation a lissue de lattente
ALORS PANNE du site ayant repondu
REFAIRE une ELECTION
FINSI
FINSI
Chapitre VIII : Architecture des SGBD distribues VIII.1- Bases de donnees distribuees homogenes
, successeur de SYSTEM-R, IBM, San Jose, 1979-1984
1. Homogenes Sites autonomes dotes du meme SGBD
2. Heterogenes Independance vis-a-vis de la localisation
3. Systemes multi-bases Transparence vis-a-vis de la duplication et de la fragmentation (ignoree
pour simplifier limplementation)
4. Bases de donnees paralleles
Extensions de SYSTEM-R
5. Architectures client/serveur
Definition de donnees et Dictionnaire
Traitement des requetes
Dictionnaire reparti
Unicite des noms et immutabilite : Nom genere par le site qui cree un
objet
Architecture de : Traitement des requetes
1. Compilation de requetes :
TRAITEMENT GESTION des
des REQUETES TRANSACTIONS Site client prend des decisions globales :
Choix des sites dexecution (cf. jointures)
Choix de la methode de transfert
GESTION MEMOIRE COMMUNICATION
des DONNEES Generation de plan
Sites serveurs :
S.G.F Ordre de jointures
COMMUNICATION Plans dexecution locaux
INTER-SITES
BASE(s)
: Traitement des requetes : Gestion des transactions
2. Execution :
2-Phase Commit (Modifie)
Un processus par site inter-agissant avec un programme
daplication Detection repartie de deadlock
Processus vivant jusqua la fin du programme Resolution de deadlock locaux et globaux

Communication inter-sites :
Entre processus
Totalement controlee par
VIII.2- Bases de donnees distribuees heterogenes Integration : approche 1 (approche nave)
Objectif : Independance, autonomie, transparence des SGBD locaux n*(n-1) traducteurs
Integration en une base globale de bases existantes sous des SGBD Difficulte de developpement : (in)compatibilite des modeles
differents
Probleme difficile : certains systemes nadmettent que des SGBD Modle1 Modle2
relationnels ou ne supportent que des requetes dinterrogation
Nouvelles fonctions : Correspondance/Traduction

Modeles (et representation) de donnees
Langages de manipulation
Modle4 Modle3
Integration : approche 2 (modele pivot ou commun) Exemples de systemes
Modele pivot (Relationnel, Objet, (XML ?)) ORACLE/STAR : SGBD reparti relationnellement heterogene
Schema global et LMD dans le modele pivot
Autant de traducteurs (bi-directionnels) que de modeles (2*n) Sybase
Facilite la conception et la manipulation

INGRES/STAR : SGBD relationnels et non relationnels
Dificulte dintegration (conflits semantiques, de nommage, etc.)
(theoriquement)
Modle1 Modle2
PIVOT
Modle4 Modle3
Architecture de Ingres/Star VIII.3- Multibases distribuees

SQL RESULTATS
SGBD logiquement integres distribues :
INGRES/STAR
Vision de toute la base
BASES Base globale = Bases locales
COMMUNICATION INGRES
SGBD multi-bases distribues :
COMMUNICATION COMMUNICATION Federation de bases de donnees
Vision de parties de bases locales que chaque SGBD veut partager
TRADUCTEUR TRADUCTEUR
Base globale Bases locales
DL/1 Rsultats SQL Rsultats
IMS DB2 Avec ou sans schema conceptuel global
Bases Bases
Composants fonctionnels des systemes multi-bases 1/2. Multi-bases avec schema global
SCHEMA EXTERNE SCHEMA EXTERNE

Prsente sur chacun des
sites en cas de ditribution COUCHE MULTIBASE
SCHEMA CONCEPTUEL GLOBAL

TRAITEMENT TRAITEMENT
des REQUETES des REQUETES
SCHEMAS SCHEMAS
GESTION des GESTION des EXTERNES EXTERNES
TRANSACTIONS TRANSACTIONS
REPRISE REPRISE SCHEMA SCHEMA

CONCEPTUEL CONCEPTUEL
SUPPORT SUPPORT LOCAL LOCAL
dEXECUTION dEXECUTION
SCHEMA SCHEMA
INTERNE INTERNE
LOCAL LOCAL
2/2. Multi-bases sans schema global 2/2. Multi-bases sans schema global
Couche SGBD locaux + Couche systeme multibase

SCHEMA SCHEMA --- SCHEMA Acces aux bases delegue au mecanisme de correspondance entre
EXTERNE EXTERNE EXTERNE
schema externe et schema conceptuel local
Schema des dependances inter-bases : expression de liens semantiques
SCHEMA SCHEMA SCHEMA Extensions du LDD
CONCEPTUEL CONCEPTUEL --- CONCEPTUEL
LOCAL LOCAL LOCAL Manipulation de schemas (dependances, externes, multibase)
CREATE, ALTER, DROP relation ou base
SCHEMA SCHEMA SCHEMA CREATE TABLE a partir de donnees dune base privee
INTERNE INTERNE INTERNE CREATE DATABASE : introduire une base dans la federation
LOCAL LOCAL LOCAL
Nommage : Nom base Nom relation
CREATE VIEW multibase
LMD : SQL + Ouverture/Fermeture de plusieurs bases
Systemes Multi-bases : Conclusion VIII.4- Bases de donnees paralleles
Technologie pas (encore) au point Beneficier des architectures paralleles et multi-processeurs

Oracle et Sybase offrent des possibilites de requetes multi-bases Exemples :
centralisees Machine transactionnelle NonStop SQL
Solutions techniques dans les SGBD repartis inadaptees aux Machine base de donnees DBC/1012 [Tera Data Corp.]
multi-bases
Architectures multi-processeurs : Unites de traitement independantes
Problematique similaire dans la construction dentrepots de donnees cooperant via un reseau
(Data Warehouse)
Caracteristiques dun SGBD parallele Caracteristiques dun SGBD parallele
Ressemble a un SGBD reparti homogene fortement integre Exemple : Sybase MPP (Sybase11, 1995)
Chaque nud correspond a un site 128 processurs ou plus
Sun-Sparc Center 2000E, 16 processurs :
Differe dun SGBD reparti :
4544 tpmc; 26 % Informix
Specialisation dun nud (gestion de donnees) implantation
plus simple et plus efficace HP 9000 T500, 12 processurs :
5621 tpmc; 300 % Oracle
Nombre de nuds peut etre tres eleve (Jusqua 1024 processeurs a
MIPS dans DBC/1012)
VIII.5- Architectures client-serveur Architecture client-serveur
Stations de travail et machines paralleles

Serveur dapplications : station executant des programmes
(anciennement machine hote)
INTERFACE UTILISATEUR
SERVEUR
Serveur de donnees : machine dediee (anciennement machine bases de
ANALYSEUR de REQUETES
dAPPLICATIONS
donnees, back-end)
INTERFACE SERVEUR DONNEES
Architectures :
1. Serveur de donnees centralise SERVEUR de
INTERFACE SERVEUR APPLICATIONS
2. Serveurs distribues FONCTIONS BASES de DONNEES DONNEES
1/2. Architecture centralisee Architecture centralisee
Alternative moins couteuse que SGBD distribue

Acces efficace au serveur de donnees
Memes inconvenients quune architecture classique
Rseau Local Informations du dictionnaire en lecture seule sur les stations

Taches locales de controle (autorisations, vues, etc.)
INTERFACE
Reduction du flux de communication avec le serveur de donnees

FONCTIONS BASES de DONNEES
Serveur de donnees mono/multi-processeur(s)
2.2/ Architecture Distribuee 2.2/ Architecture Distribuee
Serveurs dapplications peuvent etre similaires a ceux de larchitecture

centralisee
Requete addressee au serveur local,
Rseau Local
Serveur local se charge de lexecution repartie
INTERFACE INTERFACE
Alternative plus complexe : Dictionnaire et traitements de requetes
distribues sur chaque serveur dapplications
SGBD DISTRIBUE --- SGBD DISTRIBUE
GESTION LOCALE des DONNEES GESTION LOCALE des DONNEES
Conclusion
Systeme distribue : Sites gerant des bases locales
AUTONOMIE, TRANSPARENCE et COOPERATION
ROBUSTESSE :
Detection panne
Chapitre IX : Conclusion Reconfiguration (Tolerance au fonctionnement en mode degrade)
Reprise apres panne
Remplacement du coordonnateur
ATOMICITE des transactions PLUS COMPLEXE (2PC)

ADAPTATION des mecanismes classiques a la gestion des acces
concurrents (Verrous, estampilles)
Conclusion References
Gestion centralisee, distribuee, hierarchisee du deadlock [1] Abiteboul (S.), Buneman (P.) et Suciu (D.). Data on the Web; From
Relations to Semi-Structured Data and XML. San Francisco, CA, Morgan
Graphes dattente locaux, globaux Kaufmann Publishers, 2000.
[2] Agrawal (R.) and al.. The Claremon Report on Database Research.
Technologie trop complexe ? CACM, 52(6), June 2009. http://doi.acm.org/10.1145/1516046.1516062.
% architecture client/serveur et outils de connectivite (ODBC, JDBC) ? [3] ANSI/X3/SPARC. Study Group on Data Base Management Systems.
Interim Report - ACM, 1975.
Le Web comme une base de donnees distribuee ?
[4] Besancenot (J.) et al. Les systemes transactionnels: concepts, normes et
prouits. Paris, Editions Hermes, 1997, Collection informatique.
[5] Boudjlida (N.). Tutoriel Objets Distribues, Interoperabilite, CORBA
(Distributed Objects, Interoperability, CORBA : a tutorial). In : Journees
Bases de Donnees Avancees, BDA98. Hammamet, Tunisie, Octobre 1998.
(in French, http://www.loria.fr/ nacer).
[6] Boudjlida (N.). Bases de donnees et systemes dinformations. Le modele [11] Elmasri (R.) et Navathe (S.B.). Fundamentals of database systems. The
relationnel: langages, systemes et methodes. Dunod, Paris, 1999. Cours et Benjamin/Cummings Publishing Company, Inc., 1989.
exercices corriges. Collection Sciences Sup.
[12] Gardarin (G.) et Gardarin (O.). Le Client-Serveur. Paris, Eyrolles, 1996.
[7] Boudjlida (N.). De la technologie bases de donnees aux technologies web.
[13] Oszu (M. Tamer) et Valduriez (P.). Principles of Distributed Database
Conference invitee, 7th Maghrebian Conference on Software Engineering and
Artificial Intelligence, MCSEAI2002, Annaba, DZ, May 2002. Systems. Prentice Hall International, December 1998. 2nd edition.
http://www.loria.fr/ nacer/PUBLI/Tut-MCSEAI02.ZIP.
[8] Boudjlida (N.). Gestion et Administration des Bases de Donnees:
Application a Sybase et Oracle. Dunod, Paris, 2003.
[9] Boudjlida (N.) et Belhamissi (Y.). Traitement de requetes reparties : des
modeles a leur implementation. In : Actes des Journees Internationales des
Sciences Informatiques, JISI94. Tunis, Tunisie, Mai 1994.
[10] Bouneffa (M.A.) et Boudjlida (N.). Managing Schema Changes in
Object-Relationship Databases. In : Proceedings of the 14th Object-Oriented
and Entity-Relationship International Conference, OO-ER95, ed. par
Papazoglou (M.P.). pp. 113122. Gold Coast, Australia, December 1995.

Base de Données

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de Données

Transféré par

Droits d'auteur :

Formats disponibles

Bases de donnees reparties Universite de Lorraine, FST/MIAE, Dept.

Bases de donnees reparties

Support de cours. Des complements importants seront donnes en cours.

Bases de donnees distribuees : Definitions Bases de donnees distribuees : Definitions (fin)

QUOI distribuer ? Problemes lies a la distribution

Donnees Conception des bases distribuees :

Traitements Partitionnement des donnees (FRAGMENTATION,

Problemes lies a la distribution (suite) Problemes lies a la distribution (suite)

Traitement des requetes : Acces concurrents

Facteurs : Techniques : verrouillage, estampillage

Problemes lies a la distribution (suite) Problemes lies a la distribution (fin)

Securite et reprise en cas dincident Heterogeneite

Bases de donnees reparties : Contenu

Chapitre II. Typologie des SGBD distribues (p. 12)

Chapitre IV. Traitement des requetes (p. 33)

Chapitre VIII. Architecture des SGBD distribues (p. 105)

Bibliographie (p. 134)

Caracteristiques dun SGBD distribue Caracteristiques dun SGBD distribue

1. Transparence du reseau 3. Transparence de la fragmentation dans le traitement des requetes

Criteres de classification Typologie (1/3)

Mesure le degre dindependance

Typologie (2/3) Typologie (3/3)

Fdr Htrogne Multi-bases

Architecture de reference ANSI/SPARC (1/2) Architecture de reference (2/2)

Gestion de Donnes Locales

Gestion de Donnes Locales

Administrateur Processeur de Schma

1. Processeur de donnees 2. Processeur dapplications

SCHEMA INTERNE DICTIONNAIRE GLOBAL

III.1- Fragmentation et duplication de donnees

Fragmentation horizontale Fragmentation verticale

Fragmentation mixte et duplication III.2- Transparence et autonomie

1. FRAGMENTATION MIXTE : horizontale et verticale 1. Transparence :

Assurer lunicite des noms DUPLICATION :

Solution 1 : Serveur de noms centralise Utilisateur : Pas de designation de copie

(-) Autonomie locale Quelle copie acceder ?

Solution 2 : Nom du site Nom Objet FRAGMENTATION :

(-) Pas de Transparence du reseau Comment localiser ?

(3/3) Transparence : Localisation Schema dalgorithme de localisation

Definition dalias (sans nom du site)

Exemple : Site1 : alias compte local pour le fragment Site1.compte.F1

Chapitre IV : Traitement des requetes Traitement des requetes

Processus de traitement des requetes : PLAN dEXECUTION REPARTI :

Traitement des requetes : Exemple Traitement des requetes : Regles de transformation

REGLES CLASSIQUES de transformation

Optimisation : Objectifs et facteurs Optimisation : Types de decisions

Minimiser une fonction cout Decisions incluses dans le plan dexecution

Strategies devaluation des requetes Strategie 1/3 : Jointures simples

En centralise : cout des acces Pas de fragmentation ni de duplication

Cadre distribue : SITE : Produit (Depot Stock)

Strategie 1/3 : Jointures simples Strategie 1/3 : Jointures simples

Jointures simples : Strategie 1 Jointures simples : Strategie 2

Jointures simples : Discussion Strategie 2/3 : Jointures paralleles

Strategie 3/3 : Semi-Jointure ( ) Strategie 3/3 : Semi-Jointure ( )

Strategie 3/3 : Discussion Traitement des requetes : Cas des Vues

Hypothese : Selectivite faible Rappel : Vue = relation calculee

Vue definissable sur fragments repartis

Augmentation du nombre doperations 2. En utilisant des vues concretes

Gain proportionnel a la selectivite de la jointure

SOLUTION ACCEPTABLE si vue definie sur beaucoup de fragments

3/3. Requetes sur vues et cliches

Produit Clich 10:30

Confidentialite Contraintes dintegrite