Upload
vothu
View
225
Download
1
Embed Size (px)
Citation preview
1
Base de données répartiesD’après J. Akoka - I. Wattiau
Eric Boniface
NFE113 Administration et configuration des bases de données – 2011
2
Contexte
� Technologique� Des solutions de communication efficace entre les machines� Des SGBD assurent la transparence des données réparties� Standardisation :SGBDR, SQL, middlewares,etc.
� Organisationnel� Décentralisation des activités� Subsidiarité
� Financier� « downsizing » des
matériels et logiciels
3
SGBD distribué
� Permet création/accès/manipulation de données inter reliées, sur différents sites d’un réseau informatique� Chaque site a une capacité de traitement local autonome� Chaque site participe à l’exécution d’au moins une application
globale via le réseau
� Améliorer accessibilité / partage / disponibilité / performance
� En préservant les avantages d’une B.D. centralisée� L’optimisation globale des traitements va dépendre
� du coût de communication� du coût des traitements locaux� de la stratégie d’allocation des données� de la stratégie d’exécution des traitements
4
Typologie et architecture
� Homogènes versus hétérogènes� Semi autonomes versus autonomes
Base de données fédérées
Systèmes multibases
SGBD distribué
5
Architecture SGDB fédéré
SGBD fédéré
6
Objectifs de la conception répartie
� Contrôle de la redondance des données
� Indépendance des BD locales
� Optimisation globale
� Combinaison de la fragmentation et de l’allocation
LogiqueDéfinition des fragments = unité de
distribution logique
PhysiquePlacement des fragments, stockage, chemins d’accès
7
Fragmentation
� Une table T est partitionnée en un nombre minimum de sous tables disjointes T1,T2,..,Tn
� Chaque fragment Ti doit contenir assez d ’information pour reconstruire T
� Fragmentation verticale vs horizontale� Fragmentation verticale – basée sur projections
� Subdivision des attributs de T en groupes (duplication d’une clé commune), projection sur les groupes
� Réversible par jointure
8
Fragmentation
� Fragmentation horizontale – basée sur sélection� Sélection selon un prédicat de qualification� Réversible par union
� Ex : Clients( NClient, Nom, Ville)� Client1 = Ville = Paris (Client)� Client2 = Ville != Paris (Client)
Salariés ayant peud’ancienneté
et un gros salaire
Salariés n’ayantpas un gros salaire
Salariés ayantbeaucoup
d’anciennetéet un gros salaire
9
Fragmentation
� Fragmentation mixte : verticale + horizontale� Fragment le plus grand = une table� Fragment le plus petit = un tuple
� � trop sensible aux mises à jour et trop de jointures
� Chaque fragment sur un seul site : copie unique, BD partitionnée
� Duplication de fragments� (+) performances des requêtes et disponibilité� (-) coût des màj et contrôle de concurrence plus complexe
� Fréquemment : duplication partielle
10
Allocation
� Centralisée� Taille base limitée par les capacités du site central� Disponibilité faible
� Partitionnée� Limite l’espace disque local� Meilleur si fiabilité solution centralisée pas suffisante� Intéressant si partie importante de traitement local
11
Allocation
� Répliquée� Copie de la base sur chaque site� Maximise la fiabilité� Possible si base petite et si l’inefficacité des màj tolérable
� Réplication sélective� Fragments critiques sont répliqués� Fragments non critiques localisés sur un seul site� Grande flexibilité
12
Réplication
� Synchrone : mise à jour immédiate, protocole de validation à deux phases
� Asynchrone : mise à jour différée� Mécanismes de réplication
� Maître – esclave� Le site maître répercute les màj sur les sites esclaves
� « workflow »� Création de « chemins » métiers
� Symétrique� Tous les sites peuvent mettre à jour
13
Méthode « best fit »
� Permet de déterminer le site sur lequel stocker le fragment, là où l’on maximise les traitements locaux
� N’intègre pas le problème de la réplication� Calculs simples� Nb de références < > temps d’accès
14
Méthode « best fit »
15
Méthode ABS
� « All Beneficial Sites »
� Principe : stocker un fragment sur tous les sites où le bénéfice du stockage est supérieur à son coût
� bénéfice = (tps trait distant - tps trait local) * fréquence
� coût stockage copie = coût de la mise à jour locale + coût des mises à jour distantes
16
Méthode ABS
� Si coût = bénéfice � étudier l’évolution dans le temps� Si coût > bénéfice sur tous les sites, choisir le site qui
minimise la différence
� R1 sur S4, R2 sur S3 et S5, R3 sur S2, S3, S4 et S5
17
Méthode d’allocation progressive
� Alloue la première copie d’un fragment au site qui maximise B - C
� Puis, calcule B - C connaissant cette première copie� C ne change pas� B peut changer � temps d’accès distant peut diminuer
� Exemple� 2 fragments F1 / F2 - 2 sites S1 / S2� ABS : F1 a deux copies sur S1 / S2, F2 est sur S2� Allocation progressive : F1 sur S2 et F2 sur S2� Si, après cette première allocation on a� � pas de copie de F1 sur S2
18
Remarques sur ces méthodes
� Ne tiennent pas compte de la topologie du réseau
� Difficulté à estimer les temps moyens
� Parfois on se concentre sur les transactions critiques et non sur l’ensemble des transactions
19
Niveaux de transparence
� Transparence de fragmentation� Transparence d’allocation� Transparence de langage� Pas de transparence� Exemple
� Fournisseur(num, nom, ville)� Fragmentation horizontale selon la ville (Paris ou
Marseille) fparis et fmarseille� Le fragment de Marseille est dupliqué (Marseille1 ou
Marseille2) fmarseille1 et fmarseille2� Recherche d’un fournisseur à partir de son numéro
20
Niveaux de transparence
21
Distribution dans Oracle
� Ne gère pas la fragmentation
� Assure la connectivité avec des bases Oracle et non Oracle
� Permet la définition d’une B.D. globale (un nom)
� Permet les transactions à distance, les transactions distribuées (PL/SQL)
� Pas d’intégrité référentielle distribuée
22
Réplication dans Oracle
� « Snapshots » en lecture : une table maître recopiée et mise à jour à la demande de l’esclave
� « Snapshots » modifiables : sont modifiables en direct aussi
� Réplication multi-maître « poussée » par le maître� Réplication procédurale : par package
23
SGBD distribué
� Les douze objectifs pour une bonne B.D. réparties1. L'autonomie locale2. Ne pas se reposer sur un site unique3. Une opération en continu4. Une transparence vis à vis de la localisation5. Une indépendance vis à vis de la fragmentation6. Une indépendance vis à vis de la réplication
7. Un traitement des requêtes distribuées8. Une gestion répartie des transactions9. Une indépendance vis à vis du matériel10. Une indépendance vis à vis du système d'exploitation11. Une indépendance vis à vis du réseau12. Une indépendance vis à vis du type de la B.D. relationnelle
24
Autonomie locale
� � Base individuelle locale totalement fonctionnelle même si elle ne peut pas communiquer avec les autres sites de la B.D. réparties
� � Aussi chaque site est responsable de l'intégrité de ses propres données / sécurité / gestion
� Mais atteindre les deux objectifs : l'autonomie locale et l'indépendance / transparence de la localisation des données, en même temps est impossible
� Cependant, la mise à disposition des snapshotspermet tout de même d'avoir l'ensemble des données du dictionnaire disponibles à tout moment
25
Ne pas se reposer sur un site unique
� L'objectif de ne pas se reposer sur un site unique suppose qu'il n'y a pas de centralisation dans une B.D.
� Oracle fournit deux outils différents� ORACLE Parallel Server� Advanced Replication
� Mécanismes de réplication avancée� Maintenir des B.D. avec les mêmes données sur
différents sites distants� Deux options disponibles
� réplication synchrone� réplication asynchrone
26
Ne pas se reposer sur un site unique
27
Une opération continue
� Ne pas rendre indisponible le système réparti� Par ex. pendant tâches de maintenance : « mises à
niveau » (upgrades) de l’OS ou du SGBD ou ajout / suppression de sites participants au système réparti
� Si la répartition de la base Oracle est construite sur des instantanés (snapshots) en lecture seule � pas de mise hors-service
� Si le système de réplication avancée est utilisé, Oracle impose certaines limites : l'utilisateur doit faire attention aux changements qui pourraient avoir lieu pendant l'ajout d'un nouveau site
28
Transparence de la localisation
� � ni les applications / utilisateurs ont besoin de connaître la position des tables accédées
� Oracle : via le lien de B.D. et les synonymes� Lien de B.D. = connexion d'une B.D. à une autre
� S'affranchir pour l’utilisateur de l'obligation de se connecter explicitement à une B.D.. Connexion assurée par un compte normal � droits facilement maintenables
� Synonymes = noms simples pour identifier de façon unique dans un système distribué les objets nommés
� Eviter d'appeler une table par l'ensemble des noms de base sur laquelle la table est stockée, le nom du serveur, le nom du port utilisé, etc.
29
Indépendance vis à vis de la fragmentation
� Avec Oracle : pas de réelle fragmentation� Via des snapshots / des vues : mettre à disposition des
données fragmentées� = des copies des données maîtres centralisées� Cette méthode n'apporte pas une réelle fragmentation
comme définie dans la partie théorique
� Réplication avancée � réplication que de l'ensemble des enreg. d'une table
� Mais gestion des droits sur les enreg. � rendre un site maître d'une partie des enregistrements
� Un autre site peut être maître d'une autre partie� Moyen détourné de mettre en place fragmentation
horizontale
30
Suite des règles
Cf. http://www.hds.utc.fr/~ducourth/TX/BDD/BDD-Ora-12objectifs.html