BD réparties

NFE113 Administration et configuration des bases de données – 2011
Base de données réparties
D’après J. Akoka - I. Wattiau
1
Eric Boniface
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
2
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
3
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é
4
Architecture SGDB fédéré
SGBD fédéré
5
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
Logique
Définition des fragments = unité de
distribution logique
Physique
Placement des fragments,
stockage, chemins d’accès
6
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
7
Fragmentation
Fragmentation horizontale – basée sur sélection
Sélection selon un prédicat de qualification
Réversible par union
Salariés ayant peu
d’ancienneté
et un gros salaire
Salariés ayant
beaucoup
d’ancienneté
et un gros salaire
Salariés n’ayant
pas un gros salaire
Ex : Clients( NClient, Nom, Ville)
Client1 =
Client2 =
(Client)
Ville != Paris (Client)
Ville = Paris
8
Fragmentation
Fragmentation mixte : verticale + horizontale
Fragment le plus grand = une table
Fragment le plus petit = un tuple
Chaque fragment sur un seul site : copie unique, BD
partitionnée
Duplication de fragments
trop sensible aux mises à jour et trop de jointures
(+) performances des requêtes et disponibilité
(-) coût des màj et contrôle de concurrence plus complexe
Fréquemment : duplication partielle
9
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
10
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é
11
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
« workflow »
Le site maître répercute les màj sur les sites esclaves
Création de « chemins » métiers
Symétrique
Tous les sites peuvent mettre à jour
12
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
13
Méthode « best fit »
14
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
15
Méthode ABS
R1 sur S4, R2 sur S3 et S5, R3 sur S2, S3, S4 et S5
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
16
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
17
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
18
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
19
Niveaux de transparence
20
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
21
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
22
SGBD distribué
Les douze objectifs pour une bonne B.D. réparties
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
L'autonomie locale
Ne pas se reposer sur un site unique
Une opération en continu
Une transparence vis à vis de la localisation
Une indépendance vis à vis de la fragmentation
Une indépendance vis à vis de la réplication
Un traitement des requêtes distribuées
Une gestion répartie des transactions
Une indépendance vis à vis du matériel
Une indépendance vis à vis du système d'exploitation
Une indépendance vis à vis du réseau
Une indépendance vis à vis du type de la B.D. relationnelle
23
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 snapshots
permet tout de même d'avoir l'ensemble des données
du dictionnaire disponibles à tout moment
24
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
25
Ne pas se reposer sur un site unique
26
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
27
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.
28
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
29
Suite des règles
Cf. http://www.hds.utc.fr/~ducourth/TX/BDD/BDD-
Ora-12objectifs.html
30