Bases de Données Distribuées Chapitre 22, Sections 22.6–22.14 The slides for this text are organized into chapters. This lecture covers the material on distributed databases from Chapter 22. The material on parallel databases can be found in Chapter 22, Part B. 1

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

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 d’indépendance logique et physique). L’atomicité 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.

Tendances Récentes Les utilisateurs doivent savoir où les données sont stockées, i.e. L’indépendance des données distribuées et l’atomicité 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.

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

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

Stockage des Données Fragmentation 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

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 n’est pas désirable (car ne préservant pas l’autonomie locale). Le schème suivant préserve l’autonomie locale : <local-name, birth-site> 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 l’information 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.

SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND S.rating < 7 Requêtes Distribuées 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. On doit d’abord reconstruire la relation au moyen d’un 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.

Joins Distribués Sailors Reserves LONDON PARIS Joins Distribués 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 (D+S) D est le coût pour lire/écrire une page; S est le coût de transport d’une 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 d’envoyer les deux relations vers le site de la requête et y calculer le join.

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 d’envoyer toute la relation Reserves. Utile entre autre s’il y a une sélection sur Sailors et si la réponse est désirée à London.

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: S’il 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 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.

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 à l’optimisation dans les SGBDs centralisées. Différence 1: Coûts de la communication doivent être pris en compte. Différence 2: L’autonomie 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.

Mise à Jour des Données Distribuées Reproduction synchrones : toutes les copies d’une relation modifiée (ou d’un 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 d’une relation modifiée (ou d’un 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.

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 n’est pas attractive car les lectures sont courantes. ‘Read-any Write-all’: Les écritures sont plus lentes et les lectures sont rapides, relativement au vote. C’est l’approche la plus commune à la reproduction synchrone. Le choix d’une technique détermine le mécanisme de verrouillage à utiliser.

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 l’attente 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 s’il n’y a pas de pannes, le nombre de messages échangés pour valider est très grand. D’où la reproduction asynchrone est largement utilisée.

Reproduction Asynchrone Permet aux transactions de modification de valider leur travail avant que toutes les copies n’aient é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’’).

Reproduction Poste-à-Poste Plus d’une des copies d’un item de la base de données peuvent servir de copies originales. Des changements à la copie originale doivent être propagés aux autres copies d’une manière ou d’une autre. Si deux copies originales sont changées d’une manière conflictuelle, ce conflit doit être résolu (p.ex. le Site1 change l’expérience d’un 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.

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 d’une 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. D’abord capturer les changements faits par les transactions validées. Ensuite appliquer ces changements.

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.

Application des Changements On obtient d’abord 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.

Entreposage des Données et Reproduction Construction d’entrepôts géants de données à partir de multiples sources. Ces entrepôts sont utilisés dans l’aide à 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, l’accent 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.

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

Verrouillage Distribué Trois approches pour la gestion des verrous au travers des sites: Centralisée: un site s’occupe 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 d’une donnée requiert l’accès au site de verrouillage aussi bien qu’au 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 d’une donnée requiert l’accès à tous les sites où des copies sont à modifier.

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 T2 T1 T2 T1 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).

Reprise Distribuée Deux problèmes: Nouveaux types de pannes: faillite des liens de communication et des sites distants. Si des sous-transactions d’une transaction sont exécutées sur différents sites, toutes doivent être validées ou alors aucune d’elles ne doit l’être. D’où le besoin d’un 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.

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’.

2PC (Suite) Deux rondes de communication: d’abord un vote; ensuite une terminaison. Les deux sont initiées par le coordonateur. Chaque site peut décider de l’abandon d’une transaction. Chaque message est le reflet de la décision de son expéditeur; pour s’assurer que cette décision survive une faillite éventuelle, elle est d’abord 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.

Reprise après une Faillite d’un 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. S’il n’y 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.

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 s’ils 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 l’un d’eux vote ‘no’.

Faillite des Liens de Communication et des Site Distants Si un site distant ne répond pas pendant l’exécution du protocole 2PC pour une transaction T à cause d’une faillite d’un site distant ou d’un lien de communication: Si le site courant est coordonateur pour T, ce site abandonne T. Si le site courant est un subordonné qui n’a 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.

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 d’avoir écrit ‘commit/abort’ dans le log, il doit abandonner la transaction lorsqu'il reprend. Si une sous-transaction ne fait aucun changement, qu’elle valide son travail ou pas n’est plus relevant.

2PC avec l’Operation ‘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 n’attend pas les messages ‘acks’; il suppose que T est abandonnée si T n’est pas dans la table des transactions. Les noms des subordonnés ne sont pas repris dans l’enregistrement ‘abort’ du log. Les subordonnés n’envoient 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 n’est plus nécessaire.

Résumé Les SDBDs distribuées offre une autonomie des sites ainsi que une distribution de l’administration. 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 l’accès simultané ainsi que de la reprise.