Bases de Donn

1
Bases de Données Distribuées

• Chapitre 22, Sections 22.622.14

2
Objectifs

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

3
Introduction

• Les données sont stockées sur plusieurs sites,
  chacun géré par un SGBD qui peut exécuter
  indépendamment.
• 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).
• 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
Tendances Récentes

• 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.
• Ces propriétés sont fort difficiles à supporter
  de manière efficiente.
• 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
Types de Bases de Données Distribuées

• Homogène Chaque site exécute le même type de
  SGBD.
• Hétérogène Différents sites exécutent
  différents SGBDs (i.e. différents SGBDs
  relationnels, voire différents SGBDs
  non-relationnels).

passerelle
SGBD1
SGBD2
SGBD3
6
Architectures des SGBDs Distribuées
REQUETE

• Client-Serveur

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).
CLIENT
CLIENT
SERVEUR
SERVEUR
SERVEUR
SERVEUR

• Serveurs collaboratifs

SERVEUR
Une requête peut sétendre sur plusieurs
serveurs/sites. Cas spécial middleware
SERVEUR
REQUETE
7
Stockage des Données
TID
t1
t2
t3
t4

• Fragmentation
• Horizontale les fragments sont généralement
  disjoints.
• Verticale la décomposition doit être à jointure
  sans perte (lossless-join) utilisation des
  tids pour ce faire.
• reproduction
• Accroit la disponibilité des données.
• Décroit le temps dévaluation des requêtes.
• Synchrone vs. asynchrone.
• Varient selon la manière de garder les copies à
  jour.

R1
R3
SITE A
SITE B
R1
R2
8
Gestion du Catalogue Distribué

• 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
• ltlocal-name, birth-sitegt
• 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.
• Pour trouver une relation et de linformation sur
  elle, consulter le catalogue de son birth-site.
• Le birth-site ne change jamais, même si la
  relation a été déplacée.

9
Requêtes Distribuées
SELECT AVG(S.age) FROM Sailors S WHERE S.rating gt
3 AND S.rating lt 7

• Cas de figure possibles pour le stockage de
  Sailors
• Fragmentation horizontale Tuples avec rating lt
  5 stocké à Shanghai, ceux avec rating gt 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.ratinggt6, Toyo
  suffirait.
• Fragmentation verticale sid et rating à
  Shanghai, sname et age à Tokyo, tid sur les deux
  sites.
• 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.
• Choix du site pour évaluer la requête dépend des
  couts locaux, et ceux du transport.

10
Joins Distribués
LONDON
PARIS
Sailors
Reserves
500 pages
1000 pages

• Puiser aux besoins (as Needed), utilisant des
  boucles imbriquées à pages (Sailors est externe)
• Coût 500 D 500 1000 (DS)
• 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.
• 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.

11
Réduction de la Taille des Relations à
Transporter Semijoin

• 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.
• 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.
• Utile entre autre sil y a une sélection sur
  Sailors et si la réponse est désirée à London.

12
Réduction 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 Vi 1, sinon Vi0 (-1 lt
  0 ltk).
• 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
Optimisation des Requêtes Distribuées

• 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.
• 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
Mise à Jour des Données Distribuées

• 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.
• 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
Reproduction Synchrones

• 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.
• 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 détermine le mécanisme
  de verrouillage à utiliser.

16
Coût de la Reproduction Synchrones

• 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.
• Doù la reproduction asynchrone est largement
  utilisée.

17
Reproduction Asynchrone

• Permet aux transactions de modification de
  valider leur travail avant que toutes les copies
  naient été modifiées.
• 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.
  
• 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
Reproduction Poste-à-Poste

• Plus dune des copies dun item de la base de
  données peuvent servir de copies originales.
• Des changements à la copie originale doivent être
  propagés aux autres copies dune manière ou dune
  autre.
• 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).
• 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
Reproduction à Site Primaire

• 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.
• 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
Capture des Changements des Transactions Validées

• 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.
• 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.
• 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
Application des Changements

• 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.
• 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.
• La capture basée sur le log, plus une
  application des changements en continue,
  minimalise les retards dans la propagation des
  changements.
• 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
Entreposage des Données et Reproduction

• 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).
• 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.
• La capture procédurale, plus les changements
  guidés par les applications, est adaptée à cet
  environnement.

23
Transactions Distribuées

• 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.
• Plusieurs aspects nouveaux sajoutent eu égard à
  la distribution des données
• Accès simultané
• gestion des verrous à travers plusieurs sites
• 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
Verrouillage Distribué

• Trois approches pour la gestion des verrous au
  travers des sites
• Centralisée un site soccupe de tous les
  verrouillages.
• Vulnérable point de défaillance unique.
• Copie primaire tous les verrous pour un objet
  sont obtenus sur le site primaire.
• 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.
• Lécriture dune donnée requiert laccès à tous
  les sites où des copies sont à modifier.

25
Détection Distribuée des Deadlocks

• Chaque site maintient un waits-for graph local.
• Un deadlock global peut exister même si les
  graphes waits-for locaux ne contiennent aucun
  cycle

T1
T1
T1
T2
T2
T2
SITE A
SITE B
GLOBAL

• 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
Reprise Distribuée

• 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.
• 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
Le protocole  Two-Phase Commit  (2PC)

• Le site où la transaction est initiée est le
  coordonateur les autres sites impliquées sont
  des subordonnés.
• 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
2PC (Suite)

• Deux rondes de communication dabord un vote
  ensuite une terminaison. Les deux sont initiées
  par le coordonateur.
• Chaque site peut décider de labandon dune
  transaction.
• 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.
• 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
Reprise après 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 subordonnées
  jusquà ce que des acks soient reçus, après
  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 unilatéralement T et effectuer un
  UNDO.
• Si le site est coordonateur, envoyer un message
  abort à tous.

30
Reprise après une Faillite Blocage

• 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
Faillite des Liens de Communication et des Site
Distants

• 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
Observations sur le 2PC

• 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.
  
• Si le coordonateur tombe en panne après 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.

33
2PC avec lOperation Presumed Abort

• 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.
• Les subordonnés nenvoient pas de messages acks
  lors des abandons.
• Si une sous-transaction ne fait pas de
  changements, elle répond à un message prepare
  par reader au lieu de yes/no.
• Le coordonateur ignore les lectrices.
• Si toutes sous-transactions sont des lectrices,
  la 2ème phase nest plus nécessaire.

34
Résumé

• Les SDBDs distribuées offre une autonomie des
  sites ainsi que une distribution de
  ladministration.
• 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.