Bases de Donnes Rparties 1 Dfinition 2 Architectures

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. Ø 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= Client 1 @ Site 1 U Client 1 @ Site 2 Cde = Cde @ Site 3 IX. 6

Conception des bases réparties BDR décomposition BD 1 intégration BD 2 IX. 7 BDn …

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 Client nclient • Client 1 = Client where ville = "Paris" • Client 2 = Client where ville "Paris" C 1 C 2 C 3 C 4 nom ville Dupont Martin Smith Paris Lyon Paris Lille nom ville Dupont Martin Paris nom ville Martin Smith Lyon Lille Client 1 nclient C 1 C 3 Reconstruction Client = Client 1 U Client 2 nclient C 2 C 4 IX. 10

Fragmentation horizontale dérivée Cde Fragments définis par jointure Cde 1 = Cde where Cde. nclient = Client 1. nclient Cde 2 = Cde where Cde. nclient = Client 2. nclient ncde D 1 D 2 D 3 D 4 produit qté C 1 C 2 C 4 P 1 P 2 P 3 P 4 10 20 5 10 nclient produit qté P 3 P 4 5 10 nclient Reconstruction Cde = Cde 1 U Cde 2 Cde 1 ncde D 1 D 2 Cde 2 nclient C 1 produit qté ncde P 1 P 2 10 20 D 3 D 4 IX. 11 C 2 C 4

Fragmentation verticale Ø Fragments définis par projection • Cde 1 = Cde (ncde, nclient) • Cde 2 = Cde (ncde, produit, qté) Ø Reconstruction • Cde = [ncde, nclient, produit, qté] where Cde 1. ncde = Cde 2. ncde Ø Utile si forte affinité d'attributs Cde ncde D 1 D 2 D 3 D 4 IX. 12 C 1 C 2 C 4 produit qté P 1 P 2 P 3 P 4 10 20 5 10 Cde 2 Cde 1 ncde nclient ncde produit qté C 1 C 2 C 4 D 1 D 2 D 3 D 4 P 1 P 2 P 3 P 4 10 20 5 10

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 Client 2 Client 1 nclient nom ville C 1 C 3 Dupont Martin Paris C 2 C 4 Martin Smith Lyon Lille Cde 2 Cde 1 ncde client D 1 D 2 C 1 produit P 1 P 2 qté ncde client produit qté 10 20 D 3 D 4 C 2 C 4 P 3 P 4 5 10 Site 2 Site 1 IX. 14

Evaluation de requêtes réparties Requête sur tables globales Schéma de fragmentation Fragmentation Requête sur fragments Schéma d'allocation Optimisation Plan d'exécution réparti IX. 15

Exemple d'évaluation simple Select A from R where B = b Fragmentation R = R 1 U R 2 Select A from R 1 where B =b union Select A from R 2 where B = b R 1 = R 1 @ Site 1 R 2 = R 2 @ Site 2 R 2 = R 2 @ Site 3 Optimisation Select A from R 1 @ Site 1 where B = b union Select A from R 2 @ Site 3 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 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 Participant Coordinator INITIAL ARE PREP write begin_commit in log write abort in log RT BO E-A VOT No Yes VOTE-COMMIT WAIT Yes GLOBAL-ABORT write abort in log L-C LOBA G write commit in log ACK READY IT OMM No COMMIT write ready in log (Unilateral abort) Any No? Ready to Commit ? ABORT Abort write abort in log ACK Type of msg ? Commit write commit in log write end_of_transaction in log ABORT IX. 19 COMMIT

Validation normale P 1 P 2 Coordinateur préparer prêt valider fini IX. 20

Panne d'un participant avant Prêt P 1 P 2 Coordinateur préparer prêt timeout abandon fini panne } fini IX. 21 reprise

Panne d'un participant après Prêt P 1 P 2 Coordinateur préparer prêt valider fini prêt timeout valider fait IX. 22 panne } reprise

Panne du coordinateur P 1 P 2 Coordinateur préparer prêt valider fini IX. 23

SGBD réparti hétérogène Outils SGBDR Interface réseau Interface SGBD 1 Interface SGBD 2 SGBD 1 SGBD 2 IX. 24

Produits Ø SGBD relationnels • Oracle, DB 2, SQL Server 2000, Sybase, Informix Ø Virtual. DB (Enterworks) • basé sur Gem. Stone, vue objet des tables Ø Open Database Exchange (B 2 Systems) 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 emp. Paris CONNECT TO patrick IDENTIFIEDBY mon. PW USING Paris. emp IX. 27

Oracle/Star : architecture Outils Oracle SQL*Net SQL*Connect DB 2 Sybase IX. 28

Architecture finale de l’infastructure application 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 2 PC; 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 intégrées 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 sources Bases de données relationnelles ou sources dotées d’un connecteur adapté (2 PC, …) Coopération forte entre sources Caractéristiques données cibles Données virtuelles 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é_panne. N § 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 (x 1) Write (x 2) Write (x 3) Commit x 1 x 2 x 3 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 T 1: Start … Write(x 1). . . Commit x 2. . . T 2. . x 1 Copie primaire Tn xm Copies secondaires IX. 39

Diffusion asynchrone - asymétrique Ø Collecte des mises-à-jour sur la copie primaire via : • des triggers (Oracle, Rdb, SQL Server, DB 2, …) • Le journal des images après (“log sniffing”) (SQL Server, DB 2, 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] SP 1: Write(x) Write(y) replicate SP 1: Write(x) Write(y) IX. 41 w[x] w[y] DB-B x, y

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 T 1: X=1 Send (X=1) T 2: X=2 X=1 Send (X=2) Send (X=1) X=2 Send (X=2) X=2 IX. 45 X=1

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 T 1: read x=0 (TS=0) Copie primaire Initially x=0 (TS=0) T 1: X=1, TS=1 Send (X=1, TS=1) Copie 2 T 1: read x=0 (TS=0) T 2: X=2, TS=2 X=1, TS=1 Send (X=2, TS=2) Send (X=1, TS=1) X=2, TS=2 Send (X=2, TS=2) X=2, TS=2 • X=1, TS=1 Ni T 1 ni T 2 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 ou R/W Intég. diffusion asynchrone log sniffing Intég. IX. 49 Intég.

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. IX. 50

Fonctionnalités d’intégration réplication Fonctionnalité Réponse Réplication Définition de vues intégrées Modèle relationnel – vues par fragmentation horizontale et verticale à partir des copies primaires. Droits d’accès Langage de manipulation de données 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

Règle d’urbanisation réplication Caractéristiques données sources SGBD relationnels homogènes Coopération forte entre sources Caractéristiques données cibles 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 Coût réglage performance/cohérence Gestion des défaillances Cohérence globale IX. 52