P. 1
GG2-BDReparties

GG2-BDReparties

|Views: 203|Likes:
Publié parJassem

More info:

Published by: Jassem on Jan 09, 2011
Droits d'auteur :Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

11/11/2011

pdf

text

original

Bases de Données Réparties

1. 2. 3. 4. 5. 6. Définition Architectures Conception de BDR Traitement des requêtes Transaction répartie 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 sélection
• Client1 = Client where ville = "Paris" • Client2 = Client where ville ≠ "Paris"
Client nclient C1 C2 C3 C4 Client1 nclient C1 C3 Client2 nclient C2 C4
IX.10

nom Dupont Martin Martin Smith

ville Paris Lyon Paris Lille

nom Dupont Martin

ville Paris Paris

Reconstruction Client = Client1 U Client2

nom Martin Smith

ville Lyon Lille

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

Cde1 ncde D1 D2 nclient C1 C1 produit P1 P2 qté 10 20

Cde2 ncde D3 D4 nclient C2 C4 produit P3 P4 qté 5 10

IX.11

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

Cde2 ncde D1 D2 D3 D4 produit P1 P2 P3 P4 qté 10 20 5 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 nclient C1 C3 nom Dupont Martin ville Paris Paris Client2 nclient C2 C4 nom Martin Smith ville Lyon Lille

Cde1 ncde D1 D2 client C1 C1 Site 1 produit P1 P2 qté 10 20

Cde2 ncde D3 D4 client C2 C4 Site 2 produit P3 P4 qté 5 10

IX.14

Evaluation de requêtes réparties
Requête sur tables globales

Fragmentation

Schéma de fragmentation

Requête sur fragments

Optimisation

Schéma 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 R2 = R2 @ Site2 R2 = R2 @ Site3

Optimisation

Select A from R1 @ Site1 where B = b union Select A from R2 @ Site3 where B = b
IX.16

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

Gérant de Transactions Globales STrans. Gérant de Transactions Locales STrans. Gérant de 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 INITIAL
ARE PREP

Participant

INITIAL

write begin_commit in log

OR -AB OTE V

T

write abort in log

No

Ready to Commit ? Yes write ready in log

WAIT

VOTE-COMMIT

Any No? No write commit in log

Yes

write abort in log

GLOBAL-ABORT

READY

(Unilateral abort)

IT OMM AL-C B GLO

Abort write abort in log

Type of msg ? Commit write commit in log

ACK COMMIT ABORT ACK write end_of_transaction in log

ABORT

COMMIT

IX.19

Validation normale
P1 Coordinateur P2

préparer prêt valider fini

préparer prêt valider fini

IX.20

Panne d'un participant avant Prêt
P1 Coordinateur P2

préparer prêt

préparer
timeout

abandon fini

abandon

4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

panne

}
fini

reprise

IX.21

Panne d'un participant après Prêt
P1 Coordinateur préparer prêt valider fini prêt
timeout

P2

préparer prêt valider
4 4 4 4 4 4

panne

}

reprise

valider fait

IX.22

Panne du coordinateur
P1 Coordinateur préparer prêt
4 4 4 4 4 4 4

P2 préparer prêt

préparer prêt valider fini

préparer prêt valider fini

IX.23

SGBD réparti hétérogène
Outils

SGBDR Interface réseau Interface réseau Interface SGBD1 SGBD1 Interface réseau Interface SGBD2 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 nonOracle
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*Connect DB2 SQL*Net SQL*Connect 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é Définition de vues intégrées Réponse BDR Modèle relationnel – vues par 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. 2. 3. 4. 5. 6. Intérêt de la réplication Diffusion synchrone et asynchrone Réplication asymétrique Gestion des défaillances Réplication symétrique 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 Write (x1) Write (x2) Write (x3) Commit x1 x2 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) ... Commit T2
. .

x2 ... x1
Copie primaire

xm
Copies secondaires

Tn
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 x, y w[x] w[y] SP1: Write(x) Write(y) replicate SP1: Write(x) Write(y) w[x] w[y] DB-B 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 Initially x=0 T1: X=1 Send (X=1) X=1 Send (X=1) X=2 Send (X=2) X=2 X=1 Copie primaire Initially x=0 copie 2 Initially x=0 T2: X=2 Send (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 T1: read x=0 (TS=0) T1: X=1, TS=1 Send (X=1, TS=1) 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 Copie primaire Initially x=0 (TS=0) Copie 2 T1: read x=0 (TS=0) T2: X=2, TS=2 Send (X=2, TS=2)

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
Intég.

R ou R/W
Intég.

diffusion asynchrone

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  Cohérence globale

• Défaillances de réseau et de copies primaires mal gérées; nécessité de solutions applicatives • 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é Définition de vues intégrées Réponse Réplication Modèle relationnel – vues par fragmentation horizontale et verticale à partir des copies primaires. Droits d’accès Requêtes SQL de sélection (réplication asymétrique) et de mise à jour (réplication symétrique). Atomicité des mises à jour seulement dans le mode de diffusion synchrone
IX.51

Langage de manipulation de données

Règle d’urbanisation réplication
Caractéristiques données sources Caractéristiques données cibles SGBD relationnels homogènes Coopération forte entre sources Données physiques Convergence mais cohérence faible des données – effort d’administration Transformation simples (union, jointure) Bonne disponibilité Bonnes performances d’accès réglage performance/cohérence Gestion des défaillances Cohérence globale

Coût

IX.52

You're Reading a Free Preview

Télécharger
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->