1 Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14.

Présentation au sujet: "1 Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14."— Transcription de la présentation:

1 1 Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14

2 2 Objectifs v Introduction aux bases de données distribuées v Stockage: fragmentation v Catalogue distribué v Évaluation des requêtes distribuées: –joins –optimisation v Mise à jour des données distribuées v Transactions distribuées: –Accès simultané –Reprise

3 3 Introduction v Les données sont stockées sur plusieurs sites, chacun géré par un SGBD qui peut exécuter indépendamment. v Indépendance des données distribuées : Les utilisateurs ne doivent pas nécessairement savoir où les données sont stockées (Ceci est une extension de la notion dindépendance logique et physique). v Latomicité des transactions distribuées: Les utilisateurs doivent être à mesure décrire et exécuter des transactions qui ont accès à plusieurs sites à la manière des transactions locales.

4 4 Tendances Récentes v Les utilisateurs doivent savoir où les données sont stockées, i.e. Lindépendance des données distribuées et latomicité des transactions distribuées ne sont pas supportées. v Ces propriétés sont fort difficiles à supporter de manière efficiente. v Pour des sites qui sont repartis globalement, ces propriétés pourraient même ne pas être désirable à cause du surdébit administratif nécessaire pour rendre la localisation des données transparente.

5 5 Types de Bases de Données Distribuées v Homogène: Chaque site exécute le même type de SGBD. v Hétérogène: Différents sites exécutent différents SGBDs (i.e. différents SGBDs relationnels, voire différents SGBDs non- relationnels). SGBD1SGBD2SGBD3 passerelle

6 6 Architectures des SGBDs Distribuées v Client-Serveur v Serveurs collaboratifs CLIENT SERVEUR REQUETE SERVEUR REQUETE Le client expédie une requête à un seul site. La requête est entièrement exécutée sur le serveur. - client léger vs. lourd - communication orientée ensemble - antémémoire sur le client (caching). Une requête peut sétendre sur plusieurs serveurs/sites. Cas spécial: middleware

7 7 Stockage des Données v Fragmentation –Horizontale: les fragments sont généralement disjoints. –Verticale: la décomposition doit être à jointure sans perte (lossless-join); utilisation des tid s pour ce faire. v reproduction –Accroit la disponibilité des données. –Décroit le temps dévaluation des requêtes. –Synchrone vs. asynchrone. u Varient selon la manière de garder les copies à jour. TID t1 t2 t3 t4 R1 R2 R3 SITE A SITE B

8 8 Gestion du Catalogue Distribué v Maintien de la distribution des données à travers les sites. –Si une relation est fragmentée, le SGBD doit être capable de nommer chaque copie de chaque fragment. Un schème de nommage global nest pas désirable (car ne préservant pas lautonomie locale). –Le schème suivant préserve lautonomie locale : u –Catalogue du site: Décrit tous les objets (fragments, copies) sur un site et maintient les traces des copies des relations créées sur ce site. u Pour trouver une relation et de linformation sur elle, consulter le catalogue de son birth-site. u Le birth-site ne change jamais, même si la relation a été déplacée.

9 9 Requêtes Distribuées v Cas de figure possibles pour le stockage de Sailors: –Fragmentation horizontale: Tuples avec rating = 5 à Tokyo. u On doit calculer SUM(age), COUNT(age) sur les 2 sites et ensuite calculer la moyenne finale. u Si WHERE ne contenait que S.rating>6, Toyo suffirait. –Fragmentation verticale : sid et rating à Shanghai, sname et age à Tokyo, tid sur les deux sites. u On doit dabord reconstruire la relation au moyen dun join sur tid, ensuite on évalue la requête. –reproduction: Sailors est copiée sur les deux sites. u Choix du site pour évaluer la requête dépend des couts locaux, et ceux du transport. SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND S.rating < 7

10 10 Joins Distribués v Puiser aux besoins (as Needed), utilisant des boucles imbriquées à pages (Sailors est externe): –Coût: 500 D + 500 * 1000 (D+S) – D est le coût pour lire/écrire une page; S est le coût de transport dune page. Si la requête nétait pas soumise à London, il faut ajouter le coût du transport du résultat vers le site de la requête. –On peut aussi faire des boucles imbriquées à index à London en puisant les tuples correspondants de Reserves de Paris vers London au fur et à mesure des besoins. v Transporter vers un des sites: Reserves va à London. –Coût: 1000 S + 4500 D (SM Join) –Si le résultat est très large, il serait bon denvoyer les deux relations vers le site de la requête et y calculer le join. SailorsReserves LONDONPARIS 500 pages1000 pages

11 11 Réduction de la Taille des Relations à Transporter: Semijoin v Algorithme: –London calcule la projection de Sailors sur les colonnes de join et envoie le résultat de cette projection à Paris. –Paris, calcule le join de la projection de Sailors avec Reserves (Le résultat de ce join est appelé réduction de Reserves par rapport à Sailors). –Paris envoie la réduction de Reserves à London. –London calcule le join de Sailors avec la réduction de Reserves. v Idée: Compromis entre le coût des calculs au niveau local (Paris et London) ainsi que celui des différents transports et le coût denvoyer toute la relation Reserves. v Utile entre autre sil y a une sélection sur Sailors et si la réponse est désirée à London.

12 12 Réduction de la Taille des Relations à Transporter: Bloomjoin v Algorithme: –London calcule un vecteur de bits V en faisant le hachage des valeurs des colonnes de join vers une plage des valeurs allant de 0 à k-1: –Sil existe un tuple t de Sailors tel que h(t(sid))= i, alors V[i] = 1, sinon V[i]=0 ( -1 < 0 <k ). u V est envoyé à Paris. –Paris va hacher chaque tuple de Reserves de la même manière et éliminera les tuples t tels que h(t(sid))!= i pour aucun i (i.e. les tuples qui donne 0 dans V ; on obtient ainsi une reduction de Reserves p.r. Sailors). –Paris envoie la réduction de Reserves à London. –London calcule le join de Sailors avec la réduction de Reserves.

13 13 Optimisation des Requêtes Distribuées v Approche basée sur le coût; considère tous les plans et choisit le plan le moins cher; similaire à loptimisation dans les SGBDs centralisées. –Différence 1: Coûts de la communication doivent être pris en compte. –Différence 2: Lautonomie des sites locaux doit être respectée. –Différence 3: Les algorithmes de join sont distribués. v Le site de la requête construit le plan global avec des plans locaux suggérés (des sous-requêtes destinées aux sites locaux) qui décrivent le traitement de la requête pour chaque site. –Si un site peut améliorer le plan suggéré, il peut le faire.

14 14 Mise à Jour des Données Distribuées v Reproduction synchrones : toutes les copies dune relation modifiée (ou dun fragment modifié) doivent être mises à jour avant que la transaction responsable de la modification ne valide son travail (i.e. avant le Commit). –La distribution des données est transparente. v Reproduction asynchrones : les copies dune relation modifiée (ou dun fragment modifié) ne sont mises à jour que périodiquement; différentes copies peuvent être temporairement hors synchronisation. –Les utilisateurs doivent être conscients de la distribution des données. –Les SGBDs actuels suivent cette approche.

15 15 Reproduction Synchrones v Voting: Une transaction doit écrire une majorité de copies afin de modifier un objet; doit aussi lire assez de copies pour être sûre de voir au moins la plus récente copie. –E.g. avec 10 copies, 7 écrites pour modification; 4 copies lues. –Chaque copie a un numéro de version. –Cette version nest pas attractive car les lectures sont courantes. v Read-any Write-all: Les écritures sont plus lentes et les lectures sont rapides, relativement au vote. –Cest lapproche la plus commune à la reproduction synchrone. v Le choix dune technique détermine le mécanisme de verrouillage à utiliser.

16 16 Coût de la Reproduction Synchrones v Avant que une transaction de modification ne valide son travail, elle doit obtenir un verrou sur toutes les copies modifiées. –Envoyer les requêtes de verrouillage aux sites distants et garder tous les autres verrous pendant lattente de la réponse du site distant. –Si des sites distants ou des liens tombent en panne, la transaction ne peut pas valider tant que les pannes ne sont pas réparées. –Même sil ny a pas de pannes, le nombre de messages échangés pour valider est très grand. v Doù la reproduction asynchrone est largement utilisée.

17 17 Reproduction Asynchrone v Permet aux transactions de modification de valider leur travail avant que toutes les copies naient été modifiées. v Les lectures ne sont effectuées que sur une seule copie. –Les utilisateurs doivent savoir quelle copie ils sont entrain de lire et que les copies peuvent ne pas être à jour pour une courte période de temps. v Deux approches: reproduction à site primaire (Primary Site) et reproduction poste-à-poste (Peer- to-Peer). –Elles diffèrent dans le nombre de copies modifiables ( copies originales -- ``master copies).

18 18 Reproduction Poste-à-Poste v Plus dune des copies dun item de la base de données peuvent servir de copies originales. v Des changements à la copie originale doivent être propagés aux autres copies dune manière ou dune autre. v Si deux copies originales sont changées dune manière conflictuelle, ce conflit doit être résolu (p.ex. le Site1 change lexpérience dun marin à 7 alors que le Site2 la change à 8). v Cette approche est bonne dans les cas où le nombre de conflits potentiels est très bas: –P.ex. lorsque chaque site contient un fragment disjoint des fragments qui sont sur les autres sites. –P.ex. lorsque un seul site peut opérer un changement à la fois.

19 19 Reproduction à Site Primaire v Exactement une seule copie de la relation est désignée comme la copie originale. Les copies sur les autres sites ne peuvent pas être changées directement. –La copie originale dune relation est publiée. –Les autres sites souscrivent aux fragments de la relation; les reproductions de la copie originale sur les sites autres que le site primaire sont des copies secondaires. v Problème majeur: comment propager les changements de la copie originale aux copies secondaires? Ceci est fait en deux étapes. –Dabord capturer les changements faits par les transactions validées. –Ensuite appliquer ces changements.

20 20 Capture des Changements des Transactions Validées v Capture basée sur le log: le log maintenu pour la reprise est utilisé pour générer une table de changement des données (Change Data Table -- CDT). –Ceci peut être fait lors de lécriture de la queue du log; dans ce cas il faut enlever les changements faits par les transactions qui seront abandonnée dans la suite. v Capture procédurale : une procédure qui est automatiquement invoquée (p.ex. un trigger) effectue la capture; ceci est typiquement fait en prenant un instantané (snapshot) de la copie primaire. v La capture basée sur le log est moins couteuse et plus rapide que la capture procédurale, mais a le défaut dêtre liée à la structure du log.

21 21 Application des Changements v On obtient dabord périodiquement les changements survenus au CDT du site primaire et on effectue ensuite des changements sur les copies secondaires. –La période peut être déterminée par un temporisateur ou par les applications. v La copie peut être une vue sur la relation modifiée. –Dans ce cas la reproduction consiste en un changement incrémental de la vue matérialisée au fur et à mesure que la relation change. v La capture basée sur le log, plus une application des changements en continue, minimalise les retards dans la propagation des changements. v La capture procédurale, plus les changements guidés par les applications, est le moyen le plus flexible pour changer la copie originale avant de changer les copies secondaires.

22 22 Entreposage des Données et Reproduction v Construction dentrepôts géants de données à partir de multiples sources. –Ces entrepôts sont utilisés dans laide à la décision basée sur les données de toute une organisation (Voir Chapitre 25). v Les entrepôts peuvent être vues comme une instance de reproduction asynchrones. –Puisque les sources sont typiquement contrôlées par différents SGBDs, laccent est mis sur le nettoyage des données au moment de la création des copies. v La capture procédurale, plus les changements guidés par les applications, est adaptée à cet environnement.

23 23 Transactions Distribuées v Une transaction est soumise à un site, mais peut accéder aux données sur des sites distants. La portion dune transaction se trouvant sur un site est appelée une sous-transaction. v Plusieurs aspects nouveaux sajoutent eu égard à la distribution des données: –Accès simultané: u gestion des verrous à travers plusieurs sites u détection et traitement des deadlocks –Reprise: latomicité et la durabilité doivent valoir sur tous les sites; doù la nécessité de protocoles appropriés pour Commit et Abort.

24 24 Verrouillage Distribué v Trois approches pour la gestion des verrous au travers des sites: –Centralisée: un site soccupe de tous les verrouillages. u Vulnérable: point de défaillance unique. –Copie primaire: tous les verrous pour un objet sont obtenus sur le site primaire. u La lecture dune donnée requiert laccès au site de verrouillage aussi bien quau site où la donnée est stockée. –Entièrement distribuée: le verrouillage pour une copie est fait par le gestionnaire des verrous du site où la copie est stockée. u Lécriture dune donnée requiert laccès à tous les sites où des copies sont à modifier.

25 25 Détection Distribuée des Deadlocks v Chaque site maintient un waits-for graph local. v Un deadlock global peut exister même si les graphes waits-for locaux ne contiennent aucun cycle: T1 T2 SITE ASITE BGLOBAL v Trois solutions existent: - Centralisée (envoyer tous les graphes locaux à un site); - Hiérarchique (organiser les sites en une hiérarchie et envoyer les graphes locaux au sommet de la hiérarchie); - Dépassement de temps (Timeout) (abandonner une transaction si elle attend trop longtemps).

26 26 Reprise Distribuée v Deux problèmes: –Nouveaux types de pannes: faillite des liens de communication et des sites distants. –Si des sous-transactions dune transaction sont exécutées sur différents sites, toutes doivent être validées ou alors aucune delles ne doit lêtre. Doù le besoin dun protocole de Commit pour ce faire. v Un log est maintenu sur chaque site à la manière des SGBDs centralisées et les actions du protocole de Commit sont aussi journalisées.

27 27 Le protocole « Two-Phase Commit » (2PC) v Le site où la transaction est initiée est le coordonateur; les autres sites impliquées sont des subordonnés. v Si la transaction veut exécuter une action Commit: Le coordonateur envoie une message prepare à tous ses subordonnés. Les subordonnés écrivent un enregistrement de type abort ou prepare dans le log et envoient un message no ou yes au coordonateur. Si le coordonateur reçoit un vote yes unanime, il écrit un enregistrement de type commit dans le log et envoie un message commit à tous ses subordonnés. Sinon il écrit abort dans le log et envoie un message abort. Les subordonnés écrivent abort ou commit dans le log selon le message reçu et envoient une message ack au coordonateur. Le coordonateur écrit end dans le log après avoir reçu tous les messages ack.

28 28 2PC (Suite) v Deux rondes de communication: dabord un vote; ensuite une terminaison. Les deux sont initiées par le coordonateur. v Chaque site peut décider de labandon dune transaction. v Chaque message est le reflet de la décision de son expéditeur; pour sassurer que cette décision survive une faillite éventuelle, elle est dabord enregistrée dans le log local. v Tous les enregistrements du protocole de validation pour une transaction contiennent transId et coordinatorId. Les enregistrement de type abort et commit du coordonateur incluent les identités de tous les subordonnées.

29 29 Reprise après une Faillite dun Site v Si nous avons un enregistrement de type commit (ou abort) dans le log pour une transaction T, mais pas un de type end, on doit faire un REDO (ou UNDO) de T. –Si le site en question est le coordonateur pour T, ce site enverra continuellement des messages commit (ou abort) à tous ses subordonnées jusquà ce que des acks soient reçus, après quoi un end est écrit dans le log. v Si nous avons un enregistrement prepare dans le log pour T, mais pas de commit ni abort, ce site est alors un subordonné pour T. –Le site contacte continuellement le coordonateur afin de trouver le statut de T; ensuite il écrit un commit ou abort dans le log, fait un REDO ou un UNDO selon le cas et écrit end dans le log. v Sil ny a aucun prepare dans le log pour T, abandonner unilatéralement T et effectuer un UNDO. –Si le site est coordonateur, envoyer un message abort à tous.

30 30 Reprise après une Faillite: Blocage v Si le coordonateur pour T est en panne, les subordonnés qui ont voté yes ne peuvent pas décider sils devraient faire un Commit ou un Abort de T jusquà ce que le coordonateur revienne à la vie. –T sera bloquée. –Même si tous les subordonnés se connaissent mutuellement (via un champ spécial du message prepare), ils seront bloqués, à moins que lun deux vote no.

31 31 Faillite des Liens de Communication et des Site Distants v Si un site distant ne répond pas pendant lexécution du protocole 2PC pour une transaction T à cause dune faillite dun site distant ou dun lien de communication: –Si le site courant est coordonateur pour T, ce site abandonne T. –Si le site courant est un subordonné qui na pas encore voté yes, ce site abandonne T. –Si le site courant est un subordonné qui a déjà voté yes, ce site est bloquée jusquà ce que le coordonateur réponde.

32 32 Observations sur le 2PC v Les messages ack sont utilisés pour faire savoir au coordonateur quand il peut oublier une transaction T: le coordonateur doit garder T dans sa table des transactions tant que tous les messages acks ne lui sont pas encore parvenus. v Si le coordonateur tombe en panne après avoir envoyé un message prepare, mais avant davoir écritcommit/abort dans le log, il doit abandonner la transaction lorsqu'il reprend. v Si une sous-transaction ne fait aucun changement, quelle valide son travail ou pas nest plus relevant.

33 33 2PC avec lOperation Presumed Abort v Quand le coordonateur abandonne T, il défait les opérations de T et enlève immédiatement T de la table des transactions. –Il nattend pas les messages acks ; il suppose que T est abandonnée si T nest pas dans la table des transactions. Les noms des subordonnés ne sont pas repris dans lenregistrement abort du log. v Les subordonnés nenvoient pas de messages acks lors des abandons. v Si une sous-transaction ne fait pas de changements, elle répond à un message prepare par reader au lieu deyes/no. v Le coordonateur ignore les lectrices. v Si toutes sous-transactions sont des lectrices, la 2 ème phase nest plus nécessaire.

34 34 Résumé v Les SDBDs distribuées offre une autonomie des sites ainsi que une distribution de ladministration. v La distribution des données entraine la révision des notions de stockage des données, des techniques de catalogage, du traitement des requêtes, du contrôle de laccès simultané ainsi que de la reprise.