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