Gestion de données réparties Cours 1 SGBD distribué Rend la distribution (ou répartition) des BD locales transparente – catalogue des BD – traitement des requêtes distribuées – gestion de transactions distribuées – cohérence, sécurité, réplication, etc. SGBDR SGBD1 SGBD2 Evaluation • Avantages – extensibilité – partage des données hétérogènes et réparties – performances avec le parallélisme – disponibilité (tolérance aux pannes) avec la réplication • Difficultés – administration complexe – distribution du contrôle – difficulté de migration Migration vers une BDR Décomposition physique en BD locales BD BD1 BD2 BD3 Intégration logique des BD locales existantes BD BD1 BD2 BD3 Architecture de schémas application 1 application 2 Schéma global Schéma local 1 Schéma local 2 Schéma local 3 – Avantage: indépendance applications/BDR – Inconvénient : schéma global à gérer Architecture Processeur de requêtes décomposition de la requête sous-requêtes schéma Adaptateur1 Source1 Adaptateur2 Source2 Adaptateur3 Source3 local Requêtes Résultats Schéma schéma global local schéma composition du résultat local Catalogue global des sources interfaces identiques interfaces différentes Schéma global • schéma conceptuel global – donne la description globale et unifiée de toutes les sources de données (e.g., des relations globales) – ex. Offres (emploi, ville, date), Demandes (nom, emploi) • schéma de placement – règles de correspondance avec les données locales – Offres = Offres@site1 ∪ Offres@site2 – Demandes = Demandes@site1 Fonctions d’un adaptateur Adaptateur Table virtuelle JDBC Extraction Structuration Filtrage et fusion Transformation Source Exemple d’adaptateur Offres 1 EMPLOI MECANO TECHNIC MECANO MECANO TECHNIC MECANO MECANO TECHNIC MECANO MECANO TECHNIC MECANO VILLE LYON LYON GRENOBLE ANNECY LYON GRENOBLE ANNECY ANNECY LYON GRENOBLE ANNECY LYON DATE 09/99 12/99 03/98 05/98 09/99 12/99 03/98 05/98 09/99 12/99 03/98 05/98 Adaptateur SQL Offres 1 emploi HTTP ville date Extraction Structuration select * from Annonces 1 where (emploi=mécano or emploi=technicien) and région=Rhône-Alpes Transformation Filtrage Serveur Web pages HTML/XML Offres d’adaptateurs • Fournisseurs indépendants – extracteurs indépendants entre les données sources et les outils cibles – Information Builders Inc. (IBI), Evolutionary Technology Inc. (ETI), Prism, Carleton, etc. • Editeurs de SGBD – passerelles entre le SGBD et les données sources – interface standard : ODBC, JDBC, OLE/DB, ADO – Oracle, DB2, Microsoft, Sybase, etc. Intégration de bases de données N modèles SD 1 SD 2 SD n nnn Traduction de schémas Le même modèle Traducteur 1 Traducteur 2 Schéma local 1 Schéma local 2 Intégration de schémas Intégrateur Schéma Global Traducteur n Schéma local n Modèles d’intégration • Modèle relationnel – structures de données simples et régulières • Modèle objet – structures de données complexes et régulières • Modèle semi-structuré (XML) – structures de données complexes et irrégulières – pas de schéma obligatoire Intégration de schémas • 1. pré-intégration – identification des éléments reliés et établissement des règles de conversion (e.g. 1 pouce = 2,54 cm) • 2. comparaison – identification des conflits de noms (synonymes et homonymes) et des conflits structurels (types, clés) • 3. mise en conformité – résolution des conflits de noms et des conflits structurels (changements de types, de clés) • 4. fusion et restructuration – fusion des schémas intermédiaires pour créer le schéma intégré Intégration en relationnel Emp = Emp@Site1 U Emp@Site2 prenom nom null Anne null Jean P. Dupont Martin A. Martin Smith ville Paris Nantes Nantes Lille tel. 0140... null 0235… null Emp@Site2 Emp@Site1 nom ville tel. prenom nomF P. Dupont A. Martin Paris Nantes 0140... 0235... Anne Jean Martin Smith ville Nantes Lille • Problèmes: renommage et introduction de valeurs nulles Interrogation en relationnel (SQL) select prenom, nom, tel. from Emp where ville = "Nantes" prenom nom null Anne null Jean P. Dupont Martin A. Martin Smith ville Paris Nantes Nantes Lille tel. 0140... null 0235… null prenom Anne null nom tel. Martin null A. Martin 0235… Intégration en objet Emp nom ville tel. : null Emp@site1 tel. Emp@site2 nom: (prenom, nomF) A. Martin, Nantes, 0235... • Problème: redéfinition d’attribut (Anne, Martin), Nantes Interrogation en objet (SQL3) select nom, tel. from Emp where ville = "Nantes" A. Martin, 0235… (Anne, Martin), null Traitement de requête distribuée Système d’exécution Processeur de requête Reformuler sur les schémas locaux Requête Identifier les opérations exécutables par les adaptateurs Intégrer les résultats Produire un plan d ’exéc. distribué call Adaptateur call résultat Adaptateur résultat Exemple de traitement de requête simple Select A from R where B = b Fragmentation R = R1 U R2 Select A from R1 where B =b union Select A from R2 where B = b Optimisation R1 = R1 @ Site1 R2 = R2 @ Site2 R2 = R2 @ Site3 Select A from R1 @ Site1 where B = b union Select A from R2 @ Site3 where B = b SGBD distribués • SGBD relationnels – Oracle, Ingres, Sybase, DB2, Informix • DataJoiner (IBM) – basé sur DB2 • VirtualDB (Enterworks) – basé sur GemStone, vue objet des tables • Open Database Exchange (B2Systems) Oracle et la distribution des données Admin. Requête SGBD Oracle OCI Net8 SQL*Connect OCI Net8 SQL*Connect Net8 SQL Server DB2 • SGBD Oracle – gestion du catalogue de la BDR • SQL*Net – connexion client-serveur, login à distance automatique – requêtes distribuées, transactions distribuées, réplication • SQL*Connect : passerelle vers les bases non-Oracle Database link • Lien à une table dans une BD distante specifié par : – nom de lien – nom de l'utilisateur et password – chaîne de connexion Net8 (protocole réseau, nom de site, options, etc…) • Exemple CREATE DATABASE LINK empParis CONNECT TO patrick IDENTIFIEDBY monPW USING Paris.emp Le problème d’intégration d’information • Prolifération des sources de données distribuées – publiques et privées (payantes) – très nombreuses – autonomes (contrôle local) – incohérentes (redondance) – hétérogènes • Famine d ’information – difficile d’extraire l ’information pertinente – filtrage manuel – coût élevé Les problèmes en client-serveur Appli1 Source1 Appli2 Source2 Source3 • Chaque application doit gérer – les communications – la manipulation de données – les performances • Ne passe pas à l’échelle Appli3 Source4 Entrepôt de données utilisateur requête réponse Entrepôt (BD relationnelle) Intégrateur Extraction et nettoyage de données Schéma local Source 1 Schéma local Source 2 Schéma local Source 3 Entrepôts de données • Fonctions – – – – Regroupement et récupération de données existantes Référencer les données de manière uniforme Stockage des données et de l’historique des données Mise à disposition des données pour analyse • Bilan – Bonnes performances – Données pas toujours fraîches – Nettoyage et filtrage des données Médiateur utilisateur requête réponse Schéma global Médiateur adaptateur adaptateur Schéma local Schéma local Source 1 Source 2 adaptateur Schéma local Source 3 Médiateurs d’information • Fonctions – – – – catalogue global des données intégration de schémas génération d’adaptateurs requêtes distribuées • Bilan – – – – – point d’accès unique et uniforme indépendance application/sources => évolution les données sont toujours fraîches traitement de requêtes peut être coûteux performances Réseaux Pair-à-pair • Réseau d’ordinateurs, où chaque nœud est à la fois client et serveur : met à disposition des ressources, et accède à des données se trouvant sur d’autres nœuds. • Pas de vision centralisée du système • Pas de coordination centralisée • Pas de schéma • Principe de propagation des requêtes • Grande autonomie des nœuds • Accès à des fichiers Comparaison Modèle Requêtes SGBD répartis Relationnel Entrepôts Relationnel Médiateurs P2P Hétérog énité Autono mie Nb de sources Requêtes Globale complexes, transactions Faible Faible dizaines Complexes, lecture Globale Faible Forte dizaines Relationnel, Simples, objet, semi- textuelles structuré Locale Forte Forte centaines Fichiers Locale Forte Forte milliers Simples Admin. Quelques systèmes Systèmes utilisant une approche GAV TSIMMIS (Stanford) : modèle semi-structuré HERMES (Maryland) : relationnel YAT : semi-structuré AGORA : relationnel XMLMedia : semi-structuré Systèmes utilisant une approche LAV Information Manifold (AT&T) : relationnel (+ quelques concepts objet) Tukwila (U.Washington) Xyleme : semi-structuré Produits commerciaux : Les constructeurs ont maintenant des produits (IBM Information Integrator, Microsoft : OLE-DB-NET ) Nombreuses startups Bibliographie • • • • • • A. Halevy, Answering queries using views : a survey, VLDB Journal, 2001. http://www.cs.washington.edu/homes/alon/ S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J.D.Ullman, J. Widom : The TSIMMIS Project: Integration of heterogeneous information sources, in 16th Meeting of the Information Processing Society of Japan, Tokyo, 1994. I. Manolescu, D. Florescu, D. Kossman : Answering XML queries over heterogeneous data sources, BDA 2001. G. Wiederhold: Mediators in the architecture of future information systems, Computer, 25(3):38-49, 1992. G. Wiederhold: Mediation in information systems. ACM Computing Surveys, 27(2), 1995. Transactions réparties Concept de transaction Une transaction est une collection d'actions qui transforment la BD (ou des fichiers) depuis un état cohérent en un autre état cohérent – BD cohérente (garantie par le système) – transaction cohérente (garantie par le programmeur) BD dans un BD dans un état cohérent état cohérent exécution de la transaction Begin End Problèmes liés à la répartition • Les mises à jour sont effectuées sur TOUS les sites, ou sur AUCUN => nécessité de coordonner. • Items locaux (physique) et items globaux (logique). • Transaction globale et transaction locale : le système doit garantir la sérialisabilité globale. • Verrouillage – centralisé vs décentralisé – verrous logiques et verrous physiques – verrous mortels intersites Isolation par verrouillage 2 Phases verrous T temps • Les verrous en lecture sont partageables; ceux en écriture sont exclusifs • Règle 1 – avant d'accèder à un granule x, une transaction doit acquérir un verrou sur x. Si x est déjà verrouillé de façon exclusive, la transaction attend • Règle 2 – dès qu'une transaction relâche un verrou, elle ne peut plus acquérir de nouveau verrou • 2phases strict : tous les verrous sont libérés à la fin de la transaction. Plus contraignant. Utilisé dans les SGBD répartis pour minimiser le nombre de messages. Performances L'objectif est de réduire: –les blocages • une transaction attend qu'une autre transaction relâche ses verrous –les inter-blocages • un ensemble de transactions attend que l'une d'entre elles relâche ses verrous Gestion de transactions réparties application Begin Read Write Abort Commit résultats Gérant de Transactions Globales STrans. Gérant de Transactions Locales STrans. Gérant de Transactions Locales Protocole de validation en deux étapes (2PhaseCommit) • Objectif : Exécuter 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 (lance la transaction, la découpe en sous-transactions à exécuter sur les différents sites, coordonne la terminaison de la transaction) • Participant – composant système d’un autre site qui participe dans l'exécution de la transaction Actions du protocole Coordinator Participant INITIAL INITIAL PREPARE write begin_commit in log write abort in log VOTE-ABORT No Ready to Commit ? Yes VOTE-COMMIT WAIT Any No? Yes GLOBAL-ABORT write abort in log No write ready in log READY GLOBAL-COMMIT write commit in log Abort ACK COMMIT ABORT write abort in log ACK write end_of_transaction in log Type of msg ? Commit write commit in log ABORT COMMIT Validation normale P1 P2 Coordinateur préparer prêt valider fini préparer prêt valider fini Panne d'un participant avant d'être prêt P1 P2 Coordinateur préparer préparer prêt timeout abandon abandon fini * * * * * * * * * * * * * * * * panne } fini reprise Panne d'un participant après s'être déclaré prêt P1 P2 Coordinateur préparer prêt valider préparer prêt valider fini prêt valider fait * * * * * * panne } reprise Panne du coordinateur P1 P2 Coordinateur préparer prêt préparer prêt valider fini préparer * * * * * * * prêt préparer prêt valider fini Protocoles de verrouillages répartis Traduire le verrouillage logique en verrouillages physiques. 1. Pas de réplication : - gestionnaire de verrous local sur chaque site + facile à implémenter + peu de messages (2 pour verrouiller, 1 pour libérer) - gestion des verrous mortels complexe 2. Avec réplication : - plusieurs méthodes, dont le coût (nb de messages) dépend du nombre de copies, du rapport lectures/écritures, de la concurrence (verrous refusés) Détection des verrous mortels 1. Timeout Pb : bien déterminer le délai + pas de messages - risque d’annulation de plusieurs transactions au lieu d’une seule 2. Graphe d’attente Les nœuds sont les transactions. On a un arc de Ti ->Tj si Ti attend un verrou tenu par Tj. On construit des graphes locaux, mais les cycles doivent être détectés sur le graphe global (union des graphes locaux). T1 T2 Site 1 T1 T2 Site 2 T1 T2 Graphe global Détection des verrous mortels Estampilles même principe qu’en centralisé. Les transactions s’exécutent sur n’importe quel site, et laissent une estampille pour la copie en question. En cas d’écriture, la transaction écrit sur tous les sites où se trouvent des copies. Comparaison des estampilles wait-die et wound-wait Pb. Étendre la notion d’estampille au réparti, harmoniser les horloges.