Bases de Donnes Distribues

Chapitre 22, Sections 22.622.14

Objectifs
Introduction aux bases de donnes distribues Stockage: fragmentation Catalogue distribu valuation des requtes distribues:

joins optimisation

Mise jour des donnes distribues Transactions distribues:

Accs simultan Reprise

2

Introduction

Les donnes sont stockes sur plusieurs sites, chacun gr par un SGBD qui peut excuter indpendamment. Indpendance des donnes distribues : Les utilisateurs ne doivent pas ncessairement savoir o les donnes sont stockes (Ceci est une extension de la notion dindpendance logique et physique). Latomicit des transactions distribues: Les utilisateurs doivent tre mesure dcrire et excuter des transactions qui ont accs plusieurs sites la manire des transactions locales.
3

Tendances Rcentes

Les utilisateurs doivent savoir o les donnes sont stockes, i.e. Lindpendance des donnes distribues et latomicit des transactions distribues ne sont pas supportes. Ces proprits sont fort difficiles supporter de manire efficiente. Pour des sites qui sont repartis globalement, ces proprits pourraient mme ne pas tre dsirable cause du surdbit administratif ncessaire pour rendre la localisation des donnes transparente.
4

Types de Bases de Donnes Distribues

Homogne: Chaque site excute le mme type de SGBD. Htrogne: Diffrents sites excutent diffrents SGBDs (i.e. diffrents SGBDs relationnels, voire diffrents SGBDs nonrelationnels). passerelle

SGBD1

SGBD2

SGBD3
5

Architectures des SGBDs Distribues

Client-Serveur

REQUETE

Le client expdie une requte un seul site. La requte est entirement excute sur le serveur.
- communication oriente ensemble - antmmoire sur le client (caching).

CLIENT

CLIENT

- client lger vs. lourd

SERVEUR

SERVEUR

SERVEUR

SERVEUR SERVEUR SERVEUR

6

Serveurs collaboratifs

Une requte peut stendre sur plusieurs serveurs/sites. Cas spcial: middleware

REQUETE

Stockage des Donnes

TID t1 t2 t3 t4

Fragmentation Horizontale: les fragments sont gnralement disjoints. Verticale: la dcomposition doit tre jointure sans perte (lossless-join); utilisation des tids pour ce faire. reproduction Accroit la disponibilit des donnes. Dcroit le temps dvaluation des requtes. Synchrone vs. asynchrone.

R1

R3
SITE A SITE B

Varient selon la manire de garder les copies jour.

R1

R2
7

Gestion du Catalogue Distribu

Maintien de la distribution des donnes travers les sites.

Si une relation est fragmente, le SGBD doit tre capable de nommer chaque copie de chaque fragment. Un schme de nommage global nest pas dsirable (car ne prservant pas lautonomie locale). Le schme suivant prserve lautonomie locale : <local-name, birth-site> Catalogue du site: Dcrit tous les objets (fragments, copies) sur un site et maintient les traces des copies des relations cres sur ce site. Pour trouver une relation et de linformation sur elle, consulter le catalogue de son birth-site. Le birth-site ne change jamais, mme si la relation a t dplace.
8

Requtes Distribues

SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND S.rating < 7

Cas de figure possibles pour le stockage de Sailors:

Fragmentation horizontale: Tuples avec rating < 5 stock Shanghai, ceux avec rating >= 5 Tokyo.
On

doit calculer SUM(age), COUNT(age) sur les 2 sites et ensuite calculer la moyenne finale. 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.
doit dabord reconstruire la relation au moyen dun join sur tid, ensuite on value la requte. reproduction: Sailors est copie sur les deux sites. Choix du site pour valuer la requte dpend des couts locaux, et ceux du transport.
On

LONDON

PARIS

Joins Distribus

Sailors
500 pages

Reserves
1000 pages

Puiser aux besoins (as Needed), utilisant des boucles imbriques pages (Sailors est externe):
Cot: 500 D + 500 * 1000 (D+S) D est le cot pour lire/crire une page; S est le cot de transport dune page. Si la requte ntait pas soumise London, il faut ajouter le cot du transport du rsultat vers le site de la requte. On peut aussi faire des boucles imbriques index London en puisant les tuples correspondants de Reserves de Paris vers London au fur et mesure des besoins.

Transporter vers un des sites: Reserves va London.

Cot: 1000 S + 4500 D (SM Join) Si le rsultat est trs large, il serait bon denvoyer les deux relations vers le site de la requte et y calculer le join.
10

Algorithme:

Rduction de la Taille des Relations Transporter: Semijoin

London calcule la projection de Sailors sur les colonnes de join et envoie le rsultat de cette projection Paris. Paris, calcule le join de la projection de Sailors avec Reserves (Le rsultat de ce join est appel rduction de Reserves par rapport Sailors). Paris envoie la rduction de Reserves London. London calcule le join de Sailors avec la rduction de Reserves.

Ide: Compromis entre le cot des calculs au niveau local (Paris et London) ainsi que celui des diffrents transports et le cot denvoyer toute la relation Reserves. Utile entre autre sil y a une slection sur Sailors et si la rponse est dsire London.
11

Rduction de la Taille des Relations Transporter: Bloomjoin

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).
V

est envoy Paris.

Paris va hacher chaque tuple de Reserves de la mme manire 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 rduction de Reserves London. London calcule le join de Sailors avec la rduction de Reserves.
12

Optimisation des Requtes Distribues

Approche base sur le cot; considre tous les plans et choisit le plan le moins cher; similaire loptimisation dans les SGBDs centralises.
Diffrence 1: Cots de la communication doivent tre pris en compte. Diffrence 2: Lautonomie des sites locaux doit tre respecte. Diffrence 3: Les algorithmes de join sont distribus.

Le site de la requte construit le plan global avec des plans locaux suggrs (des sous-requtes destines aux sites locaux) qui dcrivent le traitement de la requte pour chaque site.
Si un site peut amliorer le plan suggr, il peut le faire.
13

Mise Jour des Donnes Distribues

Reproduction synchrones : toutes les copies dune relation modifie (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 donnes est transparente.

Reproduction asynchrones : les copies dune relation modifie (ou dun fragment modifi) ne sont mises jour que priodiquement; diffrentes copies peuvent tre temporairement hors synchronisation.
Les utilisateurs doivent tre conscients de la distribution des donnes. Les SGBDs actuels suivent cette approche.
14

Reproduction Synchrones

Voting: Une transaction doit crire une majorit de copies afin de modifier un objet; doit aussi lire assez de copies pour tre sre de voir au moins la plus rcente copie.
E.g. avec 10 copies, 7 crites pour modification; 4 copies lues. Chaque copie a un numro de version. Cette version nest pas attractive car les lectures sont courantes.

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.

Le choix dune technique dtermine le mcanisme de verrouillage utiliser.

15

Cot de la Reproduction Synchrones

Avant que une transaction de modification ne valide son travail, elle doit obtenir un verrou sur toutes les copies modifies.
Envoyer les requtes de verrouillage aux sites distants et garder tous les autres verrous pendant lattente de la rponse 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 rpares. Mme sil ny a pas de pannes, le nombre de messages changs pour valider est trs grand.

Do la reproduction asynchrone est largement utilise.

16

Reproduction Asynchrone

Permet aux transactions de modification de valider leur travail avant que toutes les copies naient t modifies. Les lectures ne sont effectues 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 priode de temps.

Deux approches: reproduction site primaire (Primary Site) et reproduction poste--poste (Peerto-Peer).
Elles diffrent dans le nombre de copies modifiables ( copies originales -- ``master copies).
17

Reproduction Poste--Poste

Plus dune des copies dun item de la base de donnes peuvent servir de copies originales. Des changements la copie originale doivent tre propags aux autres copies dune manire ou dune autre. Si deux copies originales sont changes dune manire conflictuelle, ce conflit doit tre rsolu (p.ex. le Site1 change lexprience dun marin 7 alors que le Site2 la change 8). Cette approche est bonne dans les cas o le nombre de conflits potentiels est trs 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 oprer un changement la fois.

18

Reproduction Site Primaire

Exactement une seule copie de la relation est dsigne comme la copie originale. Les copies sur les autres sites ne peuvent pas tre changes directement. La copie originale dune relation est publie. 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. Problme 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 valides. Ensuite appliquer ces changements.
19

Capture des Changements des Transactions Valides

Capture base sur le log: le log maintenu pour la reprise est utilis pour gnrer une table de changement des donnes (Change Data Table -- CDT).
Ceci peut tre fait lors de lcriture de la queue du log; dans ce cas il faut enlever les changements faits par les transactions qui seront abandonne dans la suite.

Capture procdurale : une procdure qui est automatiquement invoque (p.ex. un trigger) effectue la capture; ceci est typiquement fait en prenant un instantan (snapshot) de la copie primaire. La capture base sur le log est moins couteuse et plus rapide que la capture procdurale, mais a le dfaut dtre lie la structure du log.

20

Application des Changements

On obtient dabord priodiquement les changements survenus au CDT du site primaire et on effectue ensuite des changements sur les copies secondaires.
La priode peut tre dtermine par un temporisateur ou par les applications.

La copie peut tre une vue sur la relation modifie.

Dans ce cas la reproduction consiste en un changement incrmental de la vue matrialise au fur et mesure que la relation change.

La capture base sur le log, plus une application des changements en continue, minimalise les retards dans la propagation des changements. La capture procdurale, plus les changements guids par les applications, est le moyen le plus flexible pour changer la copie originale avant de changer les copies secondaires.

21

Entreposage des Donnes et Reproduction

Construction dentrepts gants de donnes partir de multiples sources.

Ces entrepts sont utiliss dans laide la dcision base sur les donnes de toute une organisation (Voir Chapitre 25).

Les entrepts peuvent tre vues comme une instance de reproduction asynchrones.
Puisque les sources sont typiquement contrles par diffrents SGBDs, laccent est mis sur le nettoyage des donnes au moment de la cration des copies.

La capture procdurale, plus les changements guids par les applications, est adapte cet environnement.
22

Transactions Distribues

Une transaction est soumise un site, mais peut accder aux donnes sur des sites distants. La portion dune transaction se trouvant sur un site est appele une sous-transaction. Plusieurs aspects nouveaux sajoutent eu gard la distribution des donnes: Accs simultan: gestion des verrous travers plusieurs sites dtection et traitement des deadlocks Reprise: latomicit et la durabilit doivent valoir sur tous les sites; do la ncessit de protocoles appropris pour Commit et Abort.
23

Verrouillage Distribu

Trois approches pour la gestion des verrous au travers des sites:

Centralise: un site soccupe de tous les verrouillages.
Vulnrable:

point de dfaillance unique.

Copie primaire: tous les verrous pour un objet sont obtenus sur le site primaire.
La

lecture dune donne requiert laccs au site de verrouillage aussi bien quau site o la donne est stocke.

Entirement distribue: le verrouillage pour une copie est fait par le gestionnaire des verrous du site o la copie est stocke.
Lcriture

dune donne requiert laccs tous les sites o des copies sont modifier.
24

Dtection Distribue des Deadlocks

Chaque site maintient un waits-for graph local. Un deadlock global peut exister mme si les graphes waits-for locaux ne contiennent aucun cycle:
T2 SITE A T1 SITE B T2 T1 T2 GLOBAL

T1

Trois solutions existent:

-

Centralise (envoyer tous les graphes locaux un site); Hirarchique (organiser les sites en une hirarchie et envoyer les graphes locaux au sommet de la hirarchie); Dpassement de temps (Timeout) (abandonner une transaction si elle attend trop longtemps).

25

Reprise Distribue

Deux problmes:
Nouveaux types de pannes: faillite des liens de communication et des sites distants. Si des sous-transactions dune transaction sont excutes sur diffrents sites, toutes doivent tre valides ou alors aucune delles ne doit ltre. Do le besoin dun protocole de Commit pour ce faire.

Un log est maintenu sur chaque site la manire des SGBDs centralises et les actions du protocole de Commit sont aussi journalises.

26

Le protocole Two-Phase Commit (2PC)

Le site o la transaction est initie est le coordonateur; les autres sites impliques sont des subordonns. Si la transaction veut excuter une action Commit:
Le coordonateur envoie une message prepare tous ses subordonns. Les subordonns crivent un enregistrement de type abort ou prepare dans le log et envoient un message no ou yes au coordonateur. Si le coordonateur reoit un vote yes unanime, il crit un enregistrement de type commit dans le log et envoie un message commit tous ses subordonns. Sinon il crit abort dans le log et envoie un message abort. Les subordonns crivent abort ou commit dans le log selon le message reu et envoient une message ack au coordonateur. Le coordonateur crit end dans le log aprs avoir reu tous les messages ack.
27

2PC (Suite)

Deux rondes de communication: dabord un vote; ensuite une terminaison. Les deux sont inities par le coordonateur. Chaque site peut dcider de labandon dune transaction. Chaque message est le reflet de la dcision de son expditeur; pour sassurer que cette dcision survive une faillite ventuelle, elle est dabord enregistre dans le log local. 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 identits de tous les subordonnes.
28

Reprise aprs une Faillite dun Site

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 subordonnes jusqu ce que des acks soient reus, aprs quoi un end est crit dans le log.

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.

Sil ny a aucun prepare dans le log pour T, abandonner unilatralement T et effectuer un UNDO.
Si le site est coordonateur, envoyer un message abort tous.
29

Reprise aprs une Faillite: Blocage

Si le coordonateur pour T est en panne, les subordonns qui ont vot yes ne peuvent pas dcider sils devraient faire un Commit ou un Abort de T jusqu ce que le coordonateur revienne la vie. T sera bloque. Mme si tous les subordonns se connaissent mutuellement (via un champ spcial du message prepare), ils seront bloqus, moins que lun deux vote no.

30

Faillite des Liens de Communication et des Site Distants

Si un site distant ne rpond pas pendant lexcution 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 dj vot yes, ce site est bloque jusqu ce que le coordonateur rponde.
31

Observations sur le 2PC

Les messages ack sont utiliss 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. Si le coordonateur tombe en panne aprs avoir envoy un message prepare, mais avant davoir crit commit/abort dans le log, il doit abandonner la transaction lorsqu'il reprend. Si une sous-transaction ne fait aucun changement, quelle valide son travail ou pas nest plus relevant.

32

2PC avec lOperation Presumed Abort

Quand le coordonateur abandonne T, il dfait les oprations de T et enlve immdiatement T de la table des transactions.
Il nattend pas les messages acks; il suppose que T est abandonne si T nest pas dans la table des transactions. Les noms des subordonns ne sont pas repris dans lenregistrement abort du log.

Les subordonns nenvoient pas de messages acks lors des abandons. Si une sous-transaction ne fait pas de changements, elle rpond un message prepare par reader au lieu de yes/no. Le coordonateur ignore les lectrices. Si toutes sous-transactions sont des lectrices, la 2me phase nest plus ncessaire.
33

Rsum
Les SDBDs distribues offre une autonomie des sites ainsi que une distribution de ladministration. La distribution des donnes entraine la rvision des notions de stockage des donnes, des techniques de catalogage, du traitement des requtes, du contrle de laccs simultan ainsi que de la reprise.

34