Vous êtes sur la page 1sur 52

Bases de Données Réparties

1. Définition
2. Architectures
3. Conception de BDR
4. Traitement des requêtes
5. Transaction répartie
6. Passerelles avec autres SGBD
Définitions
 Base de données répartie (BDR)
• Ensemble de bases localisées sur différents sites,
perçues par l'utilisateur comme une base unique
 Niveaux de schémas
• Chaque base possède son schéma local
• Le schéma de la base répartie constitue le schéma
global
 Il assure la transparence à la localisation des données
 Il permet des recompositions de tables par union/jointure
 il n’y a pas de base globale physique correspondant à ce
schéma

IX.2
Fonctions d’un SGBD réparti
application

Intég. Intég. Intég.

 Rend la répartition (ou distribution) transparente


• dictionnaire des données réparties
• traitement des requêtes réparties
• gestion de transactions réparties
• gestion de la cohérence et de la confidentialité

IX.3
Evaluation de l'approche BDR
 Avantages
• extensibilité
• partage des données hétérogènes et réparties
• performances
• disponibilité des données
 Inconvénients
• administration complexe
• distribution du contrôle

IX.4
Constituants du schéma global
 schéma conceptuel global
• donne la description globale et unifiée de toutes les
données de la BDR (e.g., des relations globales)
• indépendance à la répartition
 schéma de placement
• règles de correspondance avec les données locales
• indépendance à la localisation, la fragmentation et
la duplication
 Le schéma global fait partie du dictionnaire de
la BDR et peut être conçu comme une BDR
(dupliqué ou fragmenté)

IX.5
Exemple de schéma global

 Schéma conceptuel global


Client (nclient, nom, ville)
Cde (ncde, nclient, produit, qté)
 Schéma de placement
Client = Client1 @ Site1 U Client1 @
Site2
Cde = Cde @ Site3

IX.6
Conception des bases réparties

BDR
décomposition intégration

BD1 BD2 BDn


IX.7
Conception par décomposition

Table globale

fragmentation

allocation

Site 1 Site 2

IX.8
Objectifs de la décomposition
 fragmentation
• trois types : horizontale, verticale, mixte
• performances en favorisant les accès locaux
• équilibrer la charge de travail entre les sites
(parallélisme)
 duplication (ou réplication)
• favoriser les accès locaux
• augmenter la disponibilité des données
 Conception guidée par des heuristiques

IX.9
Fragmentation horizontale
 Fragments définis par Client

sélection nclient nom ville


• Client1 = Client where C1 Dupont Paris
ville = "Paris" C2 Martin Lyon
C3 Martin Paris
• Client2 = Client where C4 Smith Lille
ville ≠ "Paris"
Client1
nclient nom ville
C1 Dupont Paris
C3 Martin Paris
Reconstruction
Client = Client1 U Client2 Client2
nclient nom ville
C2 Martin Lyon
C4 Smith Lille

IX.10
Fragmentation horizontale
dérivée
Cde
Fragments définis par jointure
Cde1 = Cde where ncde nclient produit qté
Cde.nclient = Client1.nclient D1 C1 P1 10
Cde2 = Cde where D2 C1 P2 20
Cde.nclient = Client2.nclient D3 C2 P3 5
D4 C4 P4 10
Reconstruction
Cde = Cde1 U Cde2

Cde1 Cde2
ncde nclient produit qté ncde nclient produit qté
D1 C1 P1 10 D3 C2 P3 5
D2 C1 P2 20 D4 C4 P4 10

IX.11
Fragmentation verticale
 Fragments définis par projection
• Cde1 = Cde (ncde, nclient) Cde
• Cde2 = Cde (ncde, produit, ncde nclient produit qté
qté) C1 P1
D1 10
 Reconstruction D2 C1 P2 20
• Cde = [ncde, nclient, produit, D3 C2 P3 5
D4 C4 P4 10
qté] where Cde1.ncde =
Cde2.ncde
 Utile si forte affinité d'attributs
Cde1 Cde2
ncde nclient ncde produit qté
D1 C1 D1 P1 10
D2 C1 D2 P2 20
D3 C2 D3 P3 5
D4 C4 D4 P4 10

IX.12
Allocation des fragments aux
sites
 Non-dupliquée
• partitionnée : chaque fragment réside sur un seul
site
 Dupliquée
• chaque fragment sur un ou plusieurs sites
• maintien de la cohérence des copies multiples
 Règle intuitive:
• si le ratio est [lectures/màj] > 1, la duplication est
avantageuse

IX.13
Exemple d'allocation de
fragments
Client1 Client2
nclient nom ville nclient nom ville
C1 Dupont Paris C2 Martin Lyon
C3 Martin Paris C4 Smith Lille

Cde1 Cde2
ncde client produit qté ncde client produit qté
D1 C1 P1 10 D3 C2 P3 5
D2 C1 P2 20 D4 C4 P4 10

Site 1 Site 2

IX.14
Evaluation de requêtes réparties

Requête sur tables globales

Schéma
Fragmentation de fragmentation

Requête sur fragments

Schéma
Optimisation d'allocation

Plan d'exécution réparti

IX.15
Exemple d'évaluation
simple
Select A from R where B = b

Fragmentation R = R1 U R2

Select A from R1 where B =b


union Select A from R2 where B = b

R1 = R1 @ Site1
Optimisation R2 = R2 @ Site2
R2 = R2 @ Site3

Select A from R1 @ Site1 where B = b


union Select A from R2 @ Site3 where B = b

IX.16
Notion de Transaction
Répartie
application
Begin
Read
Write
Abort résultats
Commit

Gérant de
Transactions Globales

STrans. STrans.

Gérant de Gérant de
Transactions Locales Transactions Locales

IX.17
Protocole de validation en 2
étapes

 Objectif : Exécuter la commande COMMIT pour une


transaction répartie
• Phase 1 : Préparer à écrire les résultats des mises-à-jour dans
la BD
• Phase 2 : Ecrire ces résultats dans la BD

 Coordinateur : composant système d’un site qui


applique le protocole
 Participant : composant système d’un autre site qui
participe dans l'exécution de la transaction

IX.18
Etude de cas de défaillances
Coordinator Participant

INITIAL INITIAL

ARE
PREP
write
begin_commit write abort No Ready to
T
in log BOR in log Commit ?
O TE- A
V
Yes

WAIT VOTE-COMMIT write ready


in log

Yes GLOBAL-ABORT
Any No? write abort READY
in log
MIT
No
AL - COM
B
GLO

(Unilateral abort)
write commit
in log
Abort Type of
msg ?
ACK write abort
COMMIT ABORT in log Commit

ACK write commit


in log
write
end_of_transaction
in log
ABORT COMMIT

IX.19
Validation normale

P1 Coordinateur P2

préparer préparer

prêt prêt

valider valider

fini fini

IX.20
Panne d'un participant avant Prêt

P1 Coordinateur P2

préparer préparer ✧



prêt ✧

timeout ✧

✧ panne

abandon abandon





fini ✧

} reprise
fini

IX.21
Panne d'un participant après Prêt

P1 Coordinateur P2

préparer préparer
prêt prêt

valider valider ✧


✧ panne
fini ✧

prêt } reprise
timeout
valider
fait

IX.22
Panne du coordinateur

P1 Coordinateur P2

préparer préparer
prêt ✧ prêt






préparer préparer
prêt prêt
valider valider
fini fini

IX.23
SGBD réparti
hétérogène
Outils

SGBDR

Interface réseau

Interface réseau Interface réseau

Interface SGBD1 Interface SGBD2

SGBD1 SGBD2

IX.24
Produits
 SGBD relationnels
• Oracle, DB2, SQL Server 2000, Sybase, Informix
 VirtualDB (Enterworks)
• basé sur GemStone, vue objet des tables
 Open Database Exchange (B2Systems)

IX.25
Oracle/Star
 SGBD Oracle
• gestion du dictionnaire de la BDR
 SQL*Net
• transparence au réseau
• connexion client-serveur, loggin à distance
automatique
• évaluation de requêtes réparties
• validation en deux étapes et réplication
 SQL*Connect : passerelle vers les bases non-
Oracle

IX.26
Database link
 Lien à une table dans une BD distante specifié
par :
• nom de lien
• nom de l'utilisateur et password
• chaîne de connexion SQL*Net (protocole réseau,
nom de site, options, etc…)
 Exemple
• CREATE DATABASE LINK empParis
• CONNECT TO patrick
• IDENTIFIEDBY monPW
• USING Paris.emp

IX.27
Oracle/Star : architecture

Outils

Oracle

SQL*Net

SQL*Net SQL*Net

SQL*Connect SQL*Connect
DB2 Sybase

IX.28
Architecture finale de
l’infastructure

application

Intég. Intég.

Intég. Intég.

IX.29
Difficultés des bases réparties
Choix et maintien des fragments
•En fonction des besoins des applications
•Heuristiques basées sur l’affinité d’attributs et le
regroupement
Disponibilité des données
•Dépend de la robustesse du protocole 2PC; implique
une grande fiabilité du réseau et des participants
Echelle
•Le nombre de sessions simultanées est limité par
l’architecture 2-tiers; grande échelle nécessite un
moniteur transactionnel

IX.30
Fonctionnalités d’intégration BDR

Fonctionnalité Réponse BDR


Définition de vues Modèle relationnel – vues par
intégrées fragmentation et réplication à
partir des données locales.
Schéma global, droits
d’accès, contraintes
d’intégrité simples

Langage de manipulation Requêtes SQL de sélection et


de données de mise à jour.
Transactions ACID réparties
Interfaces applicatives Idem SGBD
IX.31
Règle d’urbanisation BDR
Caractéristiques données Bases de données relationnelles ou
sources sources dotées d’un connecteur
adapté (2PC, …)
Coopération forte entre sources
Caractéristiques données Données virtuelles
cibles Faibles capacités de transformation
Cohérence forte des données
Disponibilité des données fragile
Bonnes performances d’accès

Coût Robustesse du réseau et des sources


Administration

IX.32
Bases de données
répliquées

1. Intérêt de la réplication
2. Diffusion synchrone et asynchrone
3. Réplication asymétrique
4. Gestion des défaillances
5. Réplication symétrique
6. Conclusions
Définitions
Réplica ou copie de données
•Fragment horizontal ou vertical d’une table stockée dans
une base de données qui est copiée et transféré vers une
autre base de données
•L’original est appelé la copie primaire et les copies sont
appelées copies secondaires
Transparence
•Les applications clientes croient à l’existence d’une seule
copie des données qu’ils manipulent :
 soit « logique » dans le cas d’une vue
 soit physique

IX.34
Les avantages de la réplication
 Amélioration des performances
• lecture de la copie la plus proche
• évitement du goulot d'étranglement du serveur
unique
 Amélioration de la disponibilité
• lors d'une panne d'un serveur, on peut se replier sur
l'autre
• Disponibilité = 1 - probabilité_panneN
 probabilité de panne = 5% et 2 copies => disponibilité =
99.75%
 Meilleure tolérance aux pannes
• possibilité de détecter des pannes diffuses
IX.35
Les problèmes de la réplication
 Convergence
• les copies doivent être maintenues à jour
• à un instant donné, elles peuvent être différentes
• mais elles doivent converger vers un même état
cohérent où toutes les mises à jour sont exécutées
partout dans le même ordre
 Transparence : le SGBD doit assurer
• la diffusion et la réconciliation des mises à jour
• la résistance aux défaillances

IX.36
Diffusion synchrone
 Une transaction met à jour toutes les copies
de toutes les données qu ’elle modifie.
+ mise à jour en temps réel des données
- trop coûteux pour la plupart des
applications
- pas de contrôle de l ’instant de mise-à-jour
Start x1
Write (x1)
Write (x2) x2
Write (x3)
Commit x3

IX.37
Diffusion asynchrone
 Chaque transaction met à jour une seule copie et la
mise-à-jour des autres copies est différée (dans
d’autres transactions)
 Réplication asymétrique : toutes les transactions
mettent à jour la même copie
 Réplication symétrique : les transactions peuvent
mettre à jour des copies différentes
+ mise-à-jour en temps choisi des données
+ accès aux versions anciennes puis nouvelles
- l'accès à la dernière version n'est pas garanti

IX.38
Réplication asymétrique
• Désigner une copie comme primaire (“publisher”) ;
les transactions ne mettent à jour que cette copie
• les mises à jour de la copie primaire sont envoyées
ultérieurement aux copies secondaires
(“subscribers”) dans l’ordre où elles ont été
appliquées
T1: Start
… Write(x1) ... x2
Commit
...
T2 x1
.
Copie primaire xm
.

Tn Copies secondaires

IX.39
Diffusion asynchrone - asymétrique
 Collecte des mises-à-jour sur la copie primaire
via :
• des triggers (Oracle, Rdb, SQL Server, DB2, …)
• Le journal des images après (“log sniffing”) (SQL
Server, DB2, Tandem Non-Stop SQL, Sybase
Replication Server)
 Off-line
 R/W log synchronization
 administration

IX.40
Diffusion asynchrone - asymétrique
(2)
• Autre technique : diffuser une requête plutôt que
les données mises à jour (e.g., stored procedure
call)
• Problème : assurer le bon ordonnancement des
requêtes
 Les requêtes peuvent être diffusées de façon synchrone
à toutes les copies mais la diffusion est validée même si
une la mise à jour sur une copie a échoué
 nécessité d’une procédure de reprise dans ce cas

DB-A replicate DB-B


w[x] SP1: Write(x) w[x]
SP1: Write(x)
w[y] Write(y) w[y]
x, y Write(y) x, y

IX.41
Gestion des défaillances de site
 Défaillance d’une copie secondaire - rien à
faire
• Après reprise, appliquer les mises à jour oubliées
pendant la panne (déterminées à partir du journal)
• Si panne trop longue, il est préférable d’obtenir une
copie neuve
 Défaillance d’une copie primaire – idem dans
les produits

IX.42
Défaillance des communications
 Les copies secondaires ne peuvent pas distinguer 1
panne de communication d’une panne de site
 Si les secondaires élisent un nouveau primaire et
l’ancien primaire est toujours vivant, il y aura un pb
de réconciliation ...
 Une solution est qu’une partition du réseau sache
qu’elle est la seule à pouvoir fonctionner, mais elle
ne peut pas communiquer avec les autres partitions
pour le savoir.
• décision statique : la partition qui possède le primaire
gagne
• solution dynamique : consensus majoritaire

IX.43
Réplication symétrique
 Certains systèmes doivent fonctionner même s’ils sont
partitionnés
• plusieurs copies sont mises à jour (pas seulement une)
• les conflits de mise à jour sont détectés après coup
 Exemple classique - portable du commercial déconnecté
• Customer table (rarement mise à jour); Orders table (insertion)
• Customer log table (append)
• les conflits de mise à jour sont rares !
 Méthode :
• quand une copie se reconnecte au réseau, il y a “échange” :
 elle envoie ses mises à jour avec la copie primaire
 la copie primaire lui envoie les mises à jour reçues
• les mises à jour conflictuelles nécessitent une réconciliation

IX.44
Exemple de mises à jour
conflictuelles

copie 1 Copie primaire copie 2

Initially x=0 Initially x=0 Initially x=0

T1: X=1 T2: X=2


Send (X=1) Send (X=2)
X=1

Send (X=1)

X=2
Send (X=2)
X=1
X=2

IX.45
La règle d’écriture de Thomas
 Pour assurer que l’état des copies convergent :
• estampiller chaque record (e.g., id site + local clock)
• une transaction met à jour un record et son estampille
(toujours croissante)
• Une mise à jour n’est appliquée que si l’estampille de la mise
à jour est plus grande que l’estampille de la copie possedée
• Il suffit de conserver les estampilles pour les records mis à
jour récemment

 Tous les produits utilisent une variation de cette règle

IX.46
La règle de Thomas ⇒ Sérialisabilité

Copie 1 Copie primaire Copie 2

T1: read x=0 (TS=0) Initially x=0 (TS=0) T1: read x=0 (TS=0)
T1: X=1, TS=1
T2: X=2, TS=2
Send (X=1, TS=1) Send (X=2, TS=2)
X=1, TS=1

Send (X=1, TS=1)

X=2, TS=2
Send (X=2, TS=2)
X=2, TS=2 X=1,TS=1

• Ni T1 ni T2 ne lisent le résultat l’une de l’autre. Cette exécution n’est pas


sérialisable.

IX.47
Performances de la réplication
symétrique
 Déconnexions
• Plus une copie est déconnectée et effectue des
mises à jour, plus il est probable qu’une
réconciliation sera nécessaire
 Nombre de copies
• Le volume de l’activité de propagation de mises à
jour augmente avec le nombre de copies : si
chaque copie effectue des mises à jour, l’effet sera
quadratique

IX.48
Architecture de l’infrastructure

application

R/W R ou R/W

Intég. diffusion asynchrone Intég.

log sniffing

Intég. Intég.

IX.49
Difficultés de la réplication
 Maintien du compromis performance – cohérence
• Diffusion asynchrone
• Gestion des règles de réconciliation
 Gestion des défaillances
• Défaillances de réseau et de copies primaires mal gérées;
nécessité de solutions applicatives
 Cohérence globale
• Problèmes potentiels dans certaines configurations

Intég. Intég. Intég. Intég.

Intég. Intég. Intég.

IX.50
Fonctionnalités d’intégration
réplication
Fonctionnalité Réponse Réplication
Définition de vues Modèle relationnel – vues par
intégrées fragmentation horizontale et
verticale à partir des copies
primaires.
Droits d’accès
Langage de Requêtes SQL de sélection
manipulation de (réplication asymétrique) et de
données mise à jour (réplication
symétrique).
Atomicité des mises à jour
seulement dans le mode de
diffusion synchrone
IX.51
Règle d’urbanisation réplication
Caractéristiques SGBD relationnels homogènes
données sources Coopération forte entre sources

Caractéristiques Données physiques


données cibles Convergence mais cohérence faible des
données – effort d’administration
Transformation simples (union, jointure)
Bonne disponibilité
Bonnes performances d’accès

Coût réglage performance/cohérence


Gestion des défaillances
Cohérence globale

IX.52