Najib OURADI-Hightech 2013-2014.  « To the user, a distributed system should look exactly like a nondistributed system» (C. Date, Introduction to Database.

Présentation au sujet: "Najib OURADI-Hightech 2013-2014.  « To the user, a distributed system should look exactly like a nondistributed system» (C. Date, Introduction to Database."— Transcription de la présentation:

1 Najib OURADI-Hightech 2013-2014

2  « To the user, a distributed system should look exactly like a nondistributed system» (C. Date, Introduction to Database Systems)

3  BD Répartie  Ensemble de bases localisées sur différents sites, perçues par l'utilisateur comme une base unique  Chaque base possède son schéma local  Le schéma de la base répartie constitue le schéma global  Les données sont accédées via des vues intégrées qui permettent des recompositions de tables par union/jointure  SGBD réparti ou SGBD distribué (Distributed DBMS) : Système gérant une collection de BD logiquement reliées, réparties sur différents sites en fournissant un moyen d’accès rendant la distribution transparente  Base de donnée fédérée (Federated BD) Plusieurs BD hétérogènes capables d’interopérer via une vue commune (modèle commun)  Multibase : Plusieurs BD (hétérogènes ou non) capables d’interopérer sans une vue commune (absence de modèle commun)

4

5  Réparties :  Amélioration des performances (placer les traitements à l’endroit où se trouvent les données)  Disponibilité en raison de l’existence de plusieurs copies  Maintient d’une vision unique de la base de données malgré la répartition  Fédération :  Donner aux utilisateurs une vue unique des données implémentées sur plusieurs systèmes a priori hétérogènes (plate-formes et SGBD)  Cas typique rencontré lors de la concentration d’entreprises, faire cohabiter les différents systèmes tout en leur permettant d’interopérer

6  On ne met en place une BD répartie qu’en cas  de réel besoin  Démarche de conception délicate  Gestion complexe  L’évolution du SI peut invalider la solution retenue…  Des raisons valables :  Volumes de données, sites distants, etc.  Fusions de SI  Fragilité des infrastructures télécom (backup)

7

8

9  Transparence pour l’utilisateur  Autonomie de chaque site  Absence de site privilégié  Continuité de service  Transparence vis à vis de la localisation des données  Transparence vis à vis de la fragmentation  Transparence vis à vis de la réplication  Traitement des requêtes distribuées  Indépendance vis à vis du matériel  Indépendance vis à vis du système d’exploitation  Indépendance vis à vis du réseau  indépendance vis à vis du SGBD

10  Coût : la distribution entraîne des coûts supplémentaires en terme de communication, et en gestion des communications (hardware et software à installer pour gérer les communications et la distribution);  Problème de concurrence;  Sécurité : la sécurité est un problème plus complexe dans le cas des bases de données réparties que dans le cas des bases de données centralisées;

11  Descendante : Top-down (du centralisée au distribuée)  Ascendante Bottom-up ( a partir de SGBDs existants vers des vues intégrées)

12 … BDR BD2 BD n BD1 décomposition intégration

13 Table globale fragmentation allocation Site 1Site 2

14  fragmentation  trois types : horizontale, verticale, mixte  performances en favorisant les accès locaux  équilibrer la charge de travail entre les sites (parallélisme)  duplication (ou réplication)  favoriser les accès locaux  augmenter la disponibilité des données

15  Copie de chaque relation sur plusieurs site.  Réplication complète= copie sur tous les sites.  Avantages Disponibilité des données. Augmentation du parallélisme Diminution du coût imposé par les transmissions  Inconvénients Difficulté d’assurer la cohérence des différentes copies. Propagation des mises à jour.

16  Elle consiste à découper les relations en sous-relations appelées fragments.  La répartition se fait donc en deux étapes: la fragmentation et l’allocation de ces fragments aux sites intéressés.  Pourquoi fragmenter? Généralement les applications utilisent des sous-ensembles de relations. Une relation entière peut représenter une unité de distribution très grande Utilisation de petits fragments permet de faire tourner plus d’un processus simultanément.  Comment fragmenter? On distingue trois possibilité de fragmentation: Fragmentation Horizontale Fragmentation Verticale Fragmentation Hybride

17  Complétude: R fragmentée en R 1 R 2,…,R n chaque élément se trouvant dans R doit figurer dans au moins un fragment R i  Évite les pertes de données pendant la fragmentation  Reconstruction: soit la relation R, F= {R 1, R 2,., R n }  il est toujours possible de reconstruire R en appliquant des opérations sur F  Disjonction – fragments de R contient des sous ensembles de R. R i  R j = .  Garantit l’absence de redondance

18  Les fragmentation horizontale concerne les données.  Chaque fragment représente un ensemble de tuples.  Pour fragmenter, on a besoin d’information sur la BD (schéma global,…) et les applications (requêtes utilisées,…).  Les fragments sont définis par des opérations de sélection sur les relations.

19  Fragments définis par sélection  Client1 = Client where ville = « Rabat »  Client2 = Client where ville  « Rabat » Reconstruction Client =Client1 U Client2 nclientnomville C 1 C 2 C 3 C 4 Ali Ahmed Nadia Sara Rabat Casa Rabat Fès nclientnomville C 1 C 3 Ali Nadia Rabat nclientnomville C 2 C 4 Ahmed sara Casa Fès Client Client1 Client2

20 Fragments définis par jointure Cde1 = Cde where Cde.nclient = Client1.nclient Cde2 = Cde where Cde.nclient = Client2.nclient Reconstruction Cde = Cde1 U Cde2 ncde nclient produit D 1 D 2 D 3 D 4 C 1 C 2 C 4 P 1 P 2 P 3 P 4 Cde qté 10 20 5 10 ncde nclient produit D 1 D 2 C 1 P 1 P 2 Cde1 qté 10 20 ncde nclient produit D 3 D 4 C 2 C 4 P 3 P 4 Cde2 qté 5 10

21  La fragmentation concerne le schéma.  Les fragments sont définis par des opérations de projection.  La reconstruction est définie par jointure.  La clé doit être répétée dans chaque fragment.  Pour appliquer la fragmentation verticale, il existe deux possibilités:  Clustering: affecter chaque attribut à un fragment, puis à chaque étape fusionner certains fragments et s’arrêter lors de la satisfaction de certaines conditions.  Splitting: on part de la relations, puis on décide de la partitionner en des fragments en se basant sur des informations concernant les applications et les attributs.

22  Fragments définis par projection  Cde1 = Cde (ncde, nclient)  Cde2 = Cde (ncde, produit, qté)  Reconstruction  Cde = [ncde, nclient, produit, qté] where Cde1.ncde = Cde2.ncde  Utile si forte affinité d'attributs ncde nclient produit D 1 D 2 D 3 D 4 C 1 C 2 C 4 P 1 P 2 P 3 P 4 Cde qté 10 20 5 10 ncde nclient D 1 D 2 D 3 D 4 C 1 C 2 C 4 Cde1 ncde Cde2 P 1 P 2 P 3 P 4 10 20 5 10 D 1 D 2 D 3 D 4 produit qté

23  Non-dupliquée  partitionnée : chaque fragment réside sur un seul site  Dupliquée  chaque fragment sur un ou plusieurs sites  maintien de la cohérence des copies multiples  Règle intuitive:  si le ratio est [lectures/màj] > 1, la duplication est avantageuse

24  Supposons qu’on dispose d’un ensemble de fragments F={F1, F2, …Fn} et d’un réseau constitué d’un ensemble de sites S={S1, S2, …Sn}.  Une distribution optimale de F sur S est définie en considérant deux mesures:  Un coût minimal La fonction coût est une combinaison d’un ensemble de coûts: ▪ Coût de stockage de chaque fragment Fi sur un site Sj. ▪ Coût de modification de Fi sur un site Sj. ▪ Coût d’interrogation de Fi sur un site Sj. ▪ Coût de communication.  Une meilleure performance Minimiser le temps de réponse.

25 P 1 P 2 10 20 D 1 D 2 C 1 Cde1 ncde clientproduit D 3 D 4 C 2 C 4 P 3 P 4 Cde2 qté 5 10 nclientnom ville C 1 C 3 Ali Nadia Rabat C 2 C 4 Ahmed Sara Casa Fes Client1 Client2 nclientnomville Site 1 Site 2 ncde clientproduit qté

26 FRAGMENTATION ALLOCATION Relation Globale Relations locales Fragments

27  Hétérogénéité « sans problème »  SE et réseau : géré par SGBD (si « bon » SGBD)  Version de SGBD : niveau de SGBD le plus ancien  Hétérogénéité plus délicate  SGBD : problème des dialectes de SQL  passerelles entre SGBD : ▪ Ex : ODBC (au départ sous Windows mais porté sous d’autres OS) ▪ Ex : passerelles propriétaires SGBD à SGBD

28  On dispose de différentes bases de données (les schémas locaux) et on veut les intégrer pour construire un schéma global.  L’intégration des bases de données peut être effectuée en deux étapes: la traduction des schémas et l’intégration des schémas. Traducteur1Traducteur2Traducteur n Intégrateur SCG BD1BD2BDn

29  Transformer le schéma local en un autre schéma.  Exemple: transformer un schéma en modèle réseau en un schéma en modèle relationnel Schémas intermédiaires  Pré-intégration - Identification des éléments reliés (e.g. domaines équivalents) et établissement des règles de conversion (e.g. 1 inch =2.54 cm).  Comparaison - Identification des conflits de noms (synonymes, homonymes) et des conflits structurels(clé, dépendances,…).  Conformance - Résolution des conflits de noms (renommage) et des conflits structurels (changements des clés…)  Fusion et Restructuration - Fusion des schémas intermédiaires et restructuration pour créer un schéma intégré optimal..

30  Passage par un modèle commun AvantagesInconvénients -Développement d’un seul traducteur par SGBD. -Simplification de la modélisation. -Transparence. - Difficulté de définir un modèle canonique aussi riche que les modèles locaux. -Temps de réponse accru pour les interrogations locales.

31 Fragmentation Optimisation Schéma de fragmentation Schéma d'allocation Requête sur tables globales Requête sur fragments Plan d'exécution réparti

32 Fragmentation Optimisation R = R1 U R2 Select A from R where B = b Select A from R1 where B =b union Select A from R2 where B = b Select A from R1 @ Site1 where B = b union Select A from R2 @ Site2 where B = b R1 = R1 @ Site1 R2 = R2 @ Site2

33  Minimiser une fonction coût :  Fonction générale Où (n : nombre de sites impliqués)  Autres : Tenir compte  du parallélisme  des coûts des transferts  des profils des fragments (Taille, nombre de n-uplets, etc.)  de la taille des résultats intermédiaires  de l’instant de l’optimisation (compilation/exécution)  de la topologie du réseau  du coût de l’optimisation, etc.

34  Décisions incluses dans le plan d’exécution  Ordre des jointures  Stratégie de jointure  Sélection des copies (site le plus proche, le moins engorgé)  Choix des sites d’exécution (coûts des communications)  Choix des algorithmes d’accès répartis  Choix du mode de transfert (tuple/tuple, paquets)

35 application Gérant de Transactions Globales Gérant de Transactions Locales Gérant de Transactions Locales résultats Begin Read Write Abort Commit STrans.

36  Coordinateur : composant système d’un site qui applique le protocole  Participant : composant système d’un autre site qui participe dans l'exécution de la transaction  Objectif : Exécuter la commande COMMIT pour une transaction répartie  Préparer ▪ Le coordinateur demande aux autres sites s’ils sont prêts à valider leurs mises à jour.  Succès : Valider (Commit) ▪ Tous les participants effectuent leur validation sur ordre du client.  Echec : Annuler (Rollback) ▪ Si un participant n’est pas prêt, le coordinateur demande à tout les autres sites de défaire la transaction.  REMARQUE  Le protocole nécessite la journalisation des mises à jour préparées et des états des transactions dans un journal local à chaque participant.

37 Participant Coordinator INITIAL VOTE-ABORT PREPARE write abort in log No Yes write ready in log VOTE-COMMIT Yes GLOBAL-ABORT write commit in log No GLOBAL-COMMIT write abort in log Abort Commit INITIAL WAIT READY write commit in log write abort in log ABORTCOMMIT ABORT write begin_commit in log (Unilateral abort) ACK write end_of_transaction in log Any No? Type of msg ? Ready to Commit ?

38 préparer prêt valider fini préparer prêt valider fini P1 P2 Coordinateur

39 timeout abandon panne reprise } prêt                 fini fini préparer P1P2 Coordinateur

40       } fini reprise panne prêt préparer P1P2 Coordinateur prêt fait valider prêt timeout

41 préparer fini prêt valider fini       prêt valider  préparer prêt P1P2 Coordinateur

42  TP est le standard proposé par l’ISO dans le cadre OSI  Protocole arborescent  Tout participant peut déclencher une sous- transaction  Un responsable de la validation est choisi  Un coordinateur est responsable de ses participants pour la phase 1 ▪ collecte les PREPARE ▪ demande la validation  Le point de validation est responsable de la phase 2 ▪ envoie les COMMIT Coordinateur local Point de validation (Noeud critique) Coordinateur local