01 BD Reparties

Bases de donnes rparties rparties et fdres
Mars 2001
Ren J. Chevance
chevance@cnam.fr
Contenu
Dfinitions Exemple de BD rpartie Rpartition des donnes Rpartition - Fdration Fdration de BD
Quelques cas de conflits
Traduction des schmas Architecture de rfrence Accs aux BD multiples

API commune FAP commun avec passerelles FAP commun support par les SGBD
Niveaux de transparence Client/Multibases :

RDA, DRDA, SQL-CLI, ODBC Vues rparties SGBD rpartis
Quelques problmes des BD rparties et fdres Partitionnement et placement des donnes

Quelques rgles pour le partitionnement
Expdition de donnes et Expdition de Fonction Recherche du partitionnement idal Optimisation des requtes rparties Rplication dans les BD Un aperu sur les SGBD du commerce
Un peu dhistoire : Ingres/STAR IBM DB2, Informix, Oracle, Sybase
valuation des SGBD rpartis Bibliographie Page 2 RJ Chevance 2001
Dfinitions
SGBD rparti ou SGBD distribu (Distributed DBMS)
Systme grant une collection de BD logiquement relies, rparties sur diffrents sites en fournissant un moyen d accs rendant la distribution transparente
Base de donne fdre - a priori htrogne (Federated BD)

Plusieurs BD htrognes capables dinteroprer via une vue commune (modle commun)
Multibase
Plusieurs BD (htrognes ou non) capables dinteroprer sans une vue commune (absence de modle commun)
Page 3 RJ Chevance 2001
Pourquoi des BD rparties ou fdres?

Rparties :
Amlioration des performances (placer les traitements lendroit o se trouvent les donnes) Disponibilit en raison de lexistence de plusieurs copies Maintient dune vision unique de la base de donnes malgr la rpartition
Fdration :
Donner aux utilisateurs une vue unique des donnes implmentes sur plusieurs systmes a priori htrognes (plate-formes et SGBD) Cas typique rencontr lors de la concentration dentreprises : faire cohabiter les diffrents systmes tout en leur permettant dinteroprer
Exemple de BD rpartie
Schma global entit - relation
Viticulteurs Viticulteurs
Produits
Consommateurs Consommateurs Commandes
Vins Vins
Schma des donnes rparties

Paris Consommateurs Consommateurs Commandes Commandes Bordeaux Vins Vins Producteurs Producteurs Produits Produits
Dijon Vins Vins Producteurs Producteurs Produits Produits
Rpartition des donnes

a) - Cas centralis ABC
+ galit des accs + Facilit de gestion - Contention sur la BD
b) - Rpartition B
+ Rapidit daccs au donnes locales + Autonomie locale de chaque site + Accs possible aux autres sites - Gestion globale de la BD
c) - Duplication
BC
+ Disponibilit des donnes + Rapidit d accs aux donnes locales - Coordination des mises jour
ABC
ABC
Rpartition - Fdration
Approche descendante
Conception dune BD rpartie
Approche ascendante
Intgration/fdration de BD existantes
BD rpartie
BD fdre
BD1 BD1
BD2 BD2
BDN BDN
BD1 BD1
BD2 BD2
BDN BDN
Matrise de la complexit de la rpartition (fragmentation, duplication, placement) Dfinition des schmas locaux partir du schma global
Matrise de lhtrognit smantique (BD) et syntaxique (SGBD, communications,.) Matrise de lintgration des schmas locaux pour crer un schma global
Fdration de BD
Procdure dintgration :
Traitement de lhtrognit smantique Traduction des schmas (rsolution de lhtrognit syntaxique) Intgration des schmas
Htrognit smantique
Origine : Rsulte des conceptions indpendantes des diffrentes BD Effet : Dsaccord sur la signification des donnes Solution : Analyse smantique compare des donnes pralable la fdration souvent groupe avec la phase de traduction
Fdration de BD (2)
Traduction des schmas (rsolution de lhtrognit syntaxique)
Origine : utilisation de modles diffrents dans les BD composantes Effet : ncessite des traductions de tous les modles vers tous les modles Solution : traduction de tous les schmas dans un modle commun (dit canonique ou pivot) Problmatique :
Le modle canonique doit avoir un pouvoir de modlisation ceux des modles des BD composantes Ncessit de complter smantiquement des modles de BD composantes qui seraient trop pauvres
Choix du modle canonique :

Entit - Association et Relationnel Objet
Fdration de BD (3)
Intgration des schmas
Schma conceptuel global Schma conceptuel global
Intgrateur Intgrateur
Schma intermdiaire 1 Schma intermdiaire 1
Schma intermdiaire 2 Schma intermdiaire 2
Schma intermdiaire N Schma intermdiaire N
Traducteur 1 Traducteur 1
Traducteur 2 Traducteur 2
Traducteur N Traducteur N
Schma export 1 Schma export 1
Schma export 2 Schma export 2
Schma export N Schma export N
Procdure :
Identifier les lments de base qui sont lis Choisir la reprsentation la plus adquate pour le schma global Intgrer les lments des schmas intermdiaires
Fdration de BD (4)
Dmarche dintgration
Pr-intgration : : Pr-intgration tablissement du plan dintgration tablissement du plan dintgration Comparaison :: Comparaison mise en vidence des conflits mise en vidence des conflits Mise en conformit :: Mise en conformit rsolution des conflits rsolution des conflits Fusion :: Fusion fusion des schmas fusion des schmas Restructuration :: Restructuration amlioration du schma global amlioration du schma global
Fdration de BD (5)
Dmarche dintgration
Pr-intgration :
Mise en vidence des dpendances induites par les schmas Dfinitions des quivalences entre domaines Convention de dsignation
Comparaison ou analyse - mise en vidence des conflits :

de dsignation (homonymie, synonymie) structurels de domaine de contraintes .
Mise en conformit : rsolution des conflits

renommage pour les conflits de noms tude au cas par cas pour les conflits structurels
Fusion des schmas - Qualits recherches :

compltude (pas de perte dinformation) minimalit (absence de redondance) clart
Restructuration - Amlioration du schma global

pour lessentiel recherche de clart sans remise en cause des qualits recherches
Quelques cas de conflits

Conflits dattributs
Conflit de nom Conflit de type renommage conversion
Attribut sans quivalent dans lautre relation

Attribut optionnel valeur nulle Attribut indispensable relation auxiliaire
Conflit de relation
Conflit multi-attribut : un attribut correspond plusieurs dans lautre relation (ex. adresse et N, rue, code, ville) utilisation dun calcul sur les attributs (ex. extraction) Conflit de cl
pas la mme cl changement de cl la cl dune des relations composantes nest pas une cl gnrale :
gnration dune nouvelle cl par ajout dun lment (ex. nom de commune pas dterminant au niveau national ajout du numro de dpartement au nom de la commune pour crer la nouvelle cl)
Traduction des schmas

IMS IMS IDS IDS IMS IMS Modle canonique Modle canonique Relationnel Relationnel Objet Objet Relationnel Relationnel N traducteurs Objet Objet IDS IDS
N x (N - 1) / 2 traducteurs
C Passage par un modle canonique : DChaque site possde un traducteur local/canonique DChaque traducteur ralise 3 conversions : schma local schma quivalent en modle canonique donnes locales donnes quivalentes en modle canonique requtes en langage du modle canonique requtes quivalentes en modle local + Dveloppement dun seul traducteur par SGBD + Simplification de la modlisation + Transparence
- Difficult de dfinir un modle canonique aussi riche que les modles locaux - Temps de rponse accru pour les interrogations locales
Architecture de rfrence
Organisation des schmas Niveau des langages
Niveau local
Niveau local
Modle pivot tendu Schma interoprrable
Langage daccs
Gestion objets intgrs Accs objets distants Accs objets locaux Adaptateur local
Modle pivot Schma import
Gestion objets intgrs Accs objets distants Accs objets locaux Adaptateur local
Niveau communication
Niveau communication
Requtes pivot localises
Modle pivot Schma export
Niveau interoprable
Modle X (RDBMS,..) Schma local
Niveau interoprable
Requtes pivot sur objets locaux Requtes spcifiques X (SQL, OQL,..)
Accs aux BD multiples

diteurs multiples - la situation la plus difficile :
Appli BD A Appli BD A API SQL Pilote A
Appli BD B Appli BD B API SQL Pilote B
Appli BD C Appli BD C API SQL Pilote C FAP A, FAP B, FAP C
Serveur BD A
Serveur BD B
Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C
Accs aux BD multiples (2)

Solution N1 : API (SQL) commune
Appli BD Appli BD
Appli BD Appli BD API SQL commune
Appli BD Appli BD
Serveur BD A
Pilote A
Pilote B
Pilote C FAP A, FAP B, FAP C Serveur BD B
Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C

Solution N2 : FAP commun avec passerelles
Appli BD Appli BD
Appli BD Appli BD API SQL commune Pilote passerelle
Appli BD Appli BD
Serveur passerelle
Serveur BD A
FAP de la passerelle
Serveur passerelle
Serveur BD B
Serveur passerelle Administration SGBD A Administration SGBD B Administration SGBD C
Serveur BD C

Solution N3 (idale) : FAP commun implment par les fournisseurs de SGBD
Appli BD Appli BD Appli BD Appli BD API SQL commune Pilote passerelle FAP SQL standard Serveur BD B Appli BD Appli BD
Serveur BD A
Serveur BD C
Administrateur de base de donnes unique
Niveaux de transparence la localisation

Trois types daccs :
Client / Multibases :
RDA (Remote Data Access) - Standard ISO DRDA (Distributed Relational Database Architecture) dIBM (semble tre en voie de disparition) SQL-CLI (Call Level Interface) de lOpen Group ODBC (Open Database Connectivity) de Microsoft JDBC (Java Database Connection) de SUN
Vues rparties (sur BD fdres) SGBD rparti
RDA - Remote Data Access

Les usagers connaissent la localisation Si une jointure est ncessaire, elle doit tre ralise par lapplication
Application multibases Application multibases Protocole RDA Protocole RDA
Protocole RDA Protocole RDA
SGBD local SGBD local
BD locale
BD locale
BD locale
RDA - Remote Data Access (2)

Exemple
Site 1 : Cartes grises Personne (N personne, nom, prnom, adresse, ) Voiture (N vhicule, marque, type, ) Conducteur (N personne, N vhicule, NB_accidents,..) Site 2 : Base SAMU Accident (N accident, date, departement, N vhicule, N personne, ) Bless (N accident, N personne, gravit, .) Site 3 : requte Liste des blesss graves dans une voiture de marque xxx et de type yyy dans rgion parisienne Requte en centralis :
SELECT P.nom,P.prnom FROM Personne P, Bless B, Accident A, Voiture V WHERE P.N personne = B.N personne AND B.gravit > commotion AND B.N accident = A.N accident AND A.N vhicule = V.N vhicule AND V. marque = xxx AND V. type = yyy AND A.dpartement IN (75, 78 , 91, 92 ,93, 94, 95)
Solution RDA
Requte sur site 1 : SELECT N vhicule FROM Voiture WHERE marque = xxx AND type = yyy INTO temp1 Requte sur site 1 : SELECT * FROM Personne INTO temp2 Requte sur site 2 : SELECT B.N personne, A.N vhicule FROM Bless B, Accident A WHERE B.gravit > commotion AND B.N accident = A.N accident AND A.dpartement IN (75, 78 , 91, 92 ,93, 94, 95) INTO temp3
Conclusion
Il est ncessaire denvoyer 3 requtes pour seulement 2 sites La totalit de la relation Personne doit tre transfre Lintgration du rsultat final doit tre faite par lapplication : SELECT P.nom, P.prnom FROM temp2 P, temp3 B, temp1 V WHERE P.N personne = B.N personne AND B.N vhicule = V.N vhicule Page 22 RJ Chevance 2001
Difficults : Programmation et adhsion de lindustrie des SGBD au protocole RDA
SQL-CLI
Formation, en 1988, dun consortium (le SAG pour SQL Access Group) regroupant 44 diteurs de SGBD avec pour objectif de dfinir :
un standard dinteroprabilit entre clients et SGBD; une interface (CLI Call Level Interface) dfinissant un ensemble dAPI (Application Programming Interface) communes pour les diffrents SGBD.
Exemple : Composants de la CLI ODBC de Microsoft

Application Application Application Application API ODBC Gestionnaire de pilotes ODBC Pilote pour Oracle SQL*Net API fournisseur de services Pilote pour Pilote pour SQL Server DB2 Net Lib
ESQL/DRDA
Application Application
BD Oracle
BD SQL Server
BD DB2
ODBC - Open Database Connectivity

Spcification contrle par Microsoft et supporte par les principaux fournisseurs de SGBD Difficult : niveau de SQL support, dveloppement des pilotes, ..
Appli BD Appli BD Appli BD Appli BD API ODBC Gestionnaire de pilotes ODBC Pilote A Pilote B Pilote C FAP A, FAP B, FAP C Serveur BD B Appli BD Appli BD Serveur BD A
Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C Page 24 RJ Chevance 2001
JDBC - Open Database Connection

Spcification commune Sun et diffrents fournisseurs de SGBD Difficult : risque potentiel dintrusion dans des systmes par lintermdiaire du code mobile (byte-code)
Appli BD Appli BD Appli BD Appli BD API JDBC Gestionnaire de pilotes JDBC Pilote A Pilote B Pilote C FAP A, FAP B, FAP C Serveur BD B Appli BD Appli BD Serveur BD A
Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C Page 25 RJ Chevance 2001
Vues rparties
La transparence la localisation est assure par la dfinition des vues rparties Les jointures inter-bases sont excutes par le systme Les mises jour sont supportes au moyen des vues rparties Un protocole de validation 2 phases est support
Vues rparties Vues rparties
Calcul final
Gestionnaire des vues rparties Gestionnaire des vues rparties Sous-requtes
BD locale
BD locale
BD locale
Vues rparties (2)

Dfinition de la vue rpartie (sur le site 3)
CREATE VIEW Accident-grave {Npersonne, nom, prnom, adresse,gravit, dpartement, N vhicule, marque, type} AS SELECT P.Npersonne, P.nom, P.prnom, P.adresse, B.gravit, A.dpartement,V.N vhicule, V.marque, V.type FROM S1.Personne P, S2.Bless B, S2.Accident A, S1.Voiture V WHERE P.Npersonne = B.Npersonne AND B.gravit > commotions AND A.Nvhicule = V.Nvhicule AND A.N.accident = B.Naccident
Requte sur la vue rpartie (sur le site 3) : liste des blesss graves dans une voiture yyy de marque xxx dans la rgion parisienne
SELECT Npersonne,nom,prnom,adresse FROM Accident-grave WHERE marque = xxx AND type = yyy AND dpartement IN (75, 78, 91, 92, 93, 94, 95)
Vues rparties (3)

Fonctions ralises par le gestionnaire des vues rparties :
La transformation de la requte sur les relations de base La dcomposition de la requte en requtes mono-site :
Requte sur site 1 : SELECT Nvhicule FROM Voiture . Requte sur site 1 : SELECT * FROM Personne Requte sur site 2 : SELECT B.Npersonne, A.Nvhicule FROM Bless B, Accident A, .
Le contrle de lexcution des requtes Lintgration du rsultat en effectuant les diffrentes oprations (dont les jointures)
Conclusion
Le systme apparat lapplication comme un vrai SGBD rparti mais Il y a toujours 3 requtes diffrentes pour 2 sites La totalit de la relation personne doit tre transfre
SGBD rparti
La transparence la localisation est assure par la dfinition de la base rpartie Les diffrentes oprations sont prises en charge par les diffrents SGBD Un protocole de validation 2 phases est support
Schma conceptuel global

SGBD rparti SGBD rparti
BD locale 1 SGBD rparti SGBD rparti
SGBD rparti SGBD rparti
BD locale 2
BD locale N
SGBD rparti (2)

Schma conceptuel de la base :
Personne (N personne, nom, prnom, adresse, ) Voiture (N vhicule, marque, type, ) Conducteur (N personne, N vhicule, NB_accidents,..) Accident (N accident, date, dpartement, N vhicule, N personne, ) Bless (N accident, N personne, gravit, .)
Implmentation de la base :
Sites 75, 78, 91, 92, 93, 94, 95
Bases prfectorales avec Voitures, Conducteur et Personne pour les voitures immatricules dans le dpartement (Personne, Voiture, Conducteur)
SAMU : base SAMU de la rgion parisienne (Accident, Bless)
La requte liste des blesss graves dans une voiture type yyy de marque xxx dans la rgion parisienne mane dun site appel Interrogation
SGBD rparti (3)

Plan dexcution rpartie
Requte sur site SAMU :
SELECT B.Npersonne, A.Nvhicule FROM Bless B, Accident A WHERE B.Naccident = A.Naccident AND B.gravit > commotions AND A.dpartement IN (75, 78, 91, 92, 93, 94, 95) INTO temp1 SEND temp1 to S75, S78, S91, S92, S93, S94, S95
Requtes sur S75, S78, S91, S92, S93, S94, S95 :

RECEIVE temp1 FROM SAMU SELECT P.nom,P.prnom FROM Personne P, temp1 T, Voiture V WHERE P.Npersonne = T.Npersonne AND T.Nvhicule = V.Nvhicule AND V.marque = xxx AND V.type = yyy INTO temp2.i SEND temp2.i TO Interrogation
Requte sur site Interrogation :

RECEIVE temp2.75 FROM S75 RECEIVE temp2.95 FROM S95 UNION temp2.75, temp2.78,..temp2.95 INTO rsultat
Conclusion
Le SGBD rparti a pris en charge tous les problmes lis la rpartition Les transferts sont minimiss :
seuls les N des blesss et des vhicules sont transfrs
Quelques problmes des BD rparties et fdres

Validation deux phases
Ds quune mise jour sadresse plus dun site ou plus dune base sur un mme site, il convient dutiliser le protocole de validation deux phases
Verrouillage
Les SGBD utilisent le verrouillage deux phases pour assurer la srialisation des transactions (phase dacquisition des verrous puis phase de relchement des verrous) Un SGBD sait dtecter les treintes fatales locales (dtection dun cycle dans le graphe dattente) Dans le cas distribu, on peu utiliser plusieurs techniques pour traiter le cas des treintes fatales :
Prvention = viter que le problme ne survienne :
Technique destampillage : dater les transactions et tuer les transactions en attente en fonction de leur ge :
Die Wait = tuer les transactions demandant des ressources dtenues par des transactions plus anciennes et reprendre la transaction tue avec la mme estampille Wound Wait = blesser les transactions en attente de ressources dtenues par une plus ancienne, on tue la transaction blesse si elle demande une ressource dtenue par une autre transaction. On reprend la transaction tue .
Dtection :
Construction dun graphe global dattente par union des graphes locaux
Prsomption :
Abandon des transactions nayant pas termin leur excution aprs un certain temps (horloge de garde ou Watch Dog)
Partitionnement et placement des donnes

Objectifs
Rduction de la charge (accs aux donnes, communication, espace de recherche) quilibrage de charge Accroissement du travail utile (e.g. effet de cache)
Partitionnement vertical
Table
Projection, dont un attribut commun, sur chacun des sites Table globale reconstitue par une jointure selon cet attribut
Systme 2
Systme 1
Note : Relation avec l'organisation des applications (minimisation des interactions entre les systmes et validation deux phases)
Partitionnement horizontal
Systme 1 Table Systme 2
Slection, selon des valeurs disjointes dun critre sur chaque site Table globale reconstitue par UNION
Page 33
Note : Prise en compte de la validation deux phases par le SGBD
RJ Chevance 2001
Partitionnement des donnes (2)

Mthodes de partitionnement horizontal (exemples)
Domaine Round robin
A...E
F...J
K...N
O...S
T...Z
1, 6
2, 7
3, 8
4, 9
5,10
Les donnes sont rparties en fonction des domaines de valeur des cls
Hash
Chaque article est rang dans la partition suivante en squence
D, S
C, L
F, N
M, Z
R, W
Un algorithme appliqu la cl de l'article dtermine son numro de partition

Page 34
Note : Il existe des mthodes hybrides, ce sont des combinaisons/variations des RJ Chevance mthodes de base. 2001
Quelques rgles pour le partitionnement

Equilibrage des partitions (pour viter le "data skew") Quelques caractristiques des mthodes de base
Domaine de valeur
Permet des optimisations Risque de dsquilibre des partitions et de la charge
Round Robin
quilibre, par dfinition, des partitions Ne facilite pas la rduction de la charge
Hash
Choix de la fonction de hashing Pas optimal pour les recherches fondes sur des domaines de valeur
Possibilit de dupliquer les donnes : problme avec les mises jour (validation deux phases)
Expdition de donnes et Expdition de Fonction

Deux modles fonctionnels dans le cas d'une architecture de SGBD rparti Expdition de donnes "Data Shipping"
Excution de la requte
A...E
F...J
K...N
O...S
T...Z
Expdition de fonction "Function Shipping"

Demande d'excution de la fonction Excution de la requte (partielle) Rsultats Excution de la fonction
A...E
F...J
K...N
O...S
T...Z
Recherche du partionnement idal

Expos :
Soit une BD rpartie implante sur un ensemble de p sites (S={S1, S2,.Sp} et un ensemble de r fragments composant la base (F={F1, F2,Fr}) Trouver la rpartition optimale de F sur S
Formalisation :
Pour un fragment Fk, Rl et Ul sont, respectivement, les taux daccs en lecture et en mise jour depuis le site Sl Soit Clm, le cot de communication unitaire de Sl Sm Soit Dl le cot de stockage du fragment Fk sur le site Sl
Problme :
Trouver lassignation optimale de Fk {X1, X2,Xm} telle que Xl = 1 si Fk est assign sur Sl et 0 sinon et minimisant le cot de la communication et du stockage exprim par la formule : cot = l (m (Xm x Um x Clm + Rm x Min {Clm|Xm=1})) + l Xl x D Ce problme est NP-complet (ne pouvant pas tre rsolu efficacement). De plus, il est soumis des contraintes de limitation (capacit de stockage, de communication, de temps de rponse).
Optimisation des requtes rparties

tablissement dun plan dvaluation optimal Optimisation dune fonction de cot ou de temps de rponse de la forme :
cot global = a x cot(E/S) + b x cot(Processeur) + c x cot(Communication) + d x cot(Transfert des donnes)
Rappel : la compilation dune requte SQL produit un arbre dvaluation compos dun certain nombre doprateurs de base :
Projection : X R projection de la relation R sur la liste d attributs X Slection : P R slection des tuples de R vrifiant le prdicat P quijointure : R1 R2 jointure des relations R1 et R2 selon lattribut A (R1.A=R2.A)
A
Produit cartsien : x produit de deux relations Union : union de 2 relations Intersection : intersection de deux relations
Loptimisation vise transformer larbre dvaluation en un arbre optimal
Optimisation des requtes rparties (2)

Schma gnral de traitement et doptimisation dune requte rpartie
Requte sur la BD rpartie
Dcomposition de la requte Dcomposition de la requte
Schma global Normalisation de l criture de la requte Analyse -vrification limination de la redondance R-criture Schma de rpartition
Arbre d valuation de la requte sur les relations rparties
Site de contrle
Localisation des donnes Localisation des donnes
Requtes sur les fragments
Optimisation globale Optimisation globale
Statistiques sur les fragments
Requtes sur les fragments optimises avec oprations de communication
Site local Page 39 RJ Chevance 2001
Optimisation locale Optimisation locale
Schma local
Requtes locales optimises

Exemple - Dfinition de la base de donnes :
B : buveurs (NB, nom, prnom, ville) V : vins (NV, cru, millsime, degr) C : commandes (NV,NB, date, quantit)
Exemple de requte de sa traduction et de son optimisation en labsence de rpartition :

SELECT nom, prnom FROM buveurs (B), vins (V), commandes (C) WHERE V.cru = Volnay AND V.degr > 12 AND C.quantit > 100 AND C.NV = V.NV AND C.date >1/1/2000 AND B.NB = C.NB AND B.ville = Paris
X
Arbre rsultant de la traduction directe
B.nom, B.prnom B.ville= Paris B.NB NB
Arbre optimis par restructuration algbrique
B.nom, B.prnom
C.NB NB C.NB
B.NB
C.NB
X
V.NV
X
C.NV
B.NB B.nom, B.prnom
P
V.NV
C.date>1/1/2000 C.NV NV
Buveurs V.NV
NV C.NV,C.NB
P B.ville= Paris
Buveurs
P P
V.degr>12 V.cru= Volnay
P P
C.quantit=100
V.degr>12 & V.cru= Volnay
C.date >1/1/2000 & C.quantit>100
Commandes Vins Commandes Vins

Hypothse de volume :
Buveurs (B) : 10 000 tuples Vins (V) : 1 000 tuples Commandes : 200 000 tuples
Hypothse de distribution des BD :

Paris : Dijon : Buveurs (B) Vins 1 (V1) restriction NV<= 400 Commandes 1 (C1) restriction NV<= 400 Bordeaux : Vins 2 (V2) restriction NV > 400 Commandes 2 (C2) restriction NV>400
Requte mise sur le site de Paris : Noms des buveurs parisiens nayant pas command en dcembre 2000 Slectivits supposes : 20% de parisiens et 1% nayant pas command Stratgies :
Simpliste : transfrer C1 et C2 vers Paris (200 000 tuples) et faire C = C1 C2 et valuer SELECT B.nom FROM Buveurs (B) WHERE B.ville = Paris AND B.NB NOT IN (SELECT NB FROM C WHERE C.date>1/12/2000 AND C.date<1/1/2001) Amliore : Transfrer vers Dijon et Bordeaux Buveurs.NB des seuls parisiens (= 2 x 2 000 petits tuples). valuer sur les sites de Dijon et Bordeaux : Buveurs.NB NOT IN (SELECT NB FROM Ci WHERE Ci.date>1/12/2000 AND Ci.date<1/1/2001) Transfrer les rsultats vers Paris (= 2 x 20 petits tuples) et faire lintersection des rsultats
Rplication dans les BD

Objectifs de la rplication :
Amlioration de la disponibilit des donnes Amlioration des performances
Difficults de la rplication :
Synchronisation des copies Transparence de la gestion
Mise jour synchrone et asynchrone

Synchrone :
+ Maintien de toutes les copies en cohrence - Perte de performance du fait de la mise en uvre de la validation deux phases
Asynchrone : mise jour diffres des copies

+ Incidence minime sur les performances - Ncessit de mise niveau de la copie ou des copies en cas de reprise
Rplication des donnes

Objectifs de la rplication de donnes :
Disponibilit des donnes Respect de lintgrit des donnes Optimisation des accs Administration centralise Gestionnaires de donnes htrognes Autonomie locale
Options de rplication de donnes :

Modle de rplication
Rplication synchrone Rplication asynchrone
Technologie
Validation deux phases
Vidage et rechargement
Copie de table
Rplication base de rgles ou de triggers
Rplication fonde sur le journal
Problmes
Disponibilit des systmes et des rseaux
Donnes pas jour
Consistance des transactions
Performance et administration
Rplication des donnes (2)

Quelques exemples dutilisation
Mouvement dinformation (OLTP DSS)
BD production
Rplication
BD dcisionnelle
Distribution dinformation
BD Entreprise globale
BD Afrique
BD Amrique
BD Asie
BD Europe

Consolidation dinformations
Site A Site B Site C
Site A
Site A Site B Site C Site A Site B Site C
Site Central
Site B
Mises jour sans conflit

Site C
Site A
Site A Site B Site C Page 45 RJ Chevance 2001
Site C
Site B

Mises jour avec conflits daccs
Exemple : socit de logiciel au niveau mondial (travaillant donc 24 x 24 du fait des dcalages horaires) maintenant une base de donnes pour le support de ses clients (erreur connues, corrections, dtours,.). La base doit tre accessible en permanence et tre jour.
Base commune
Amrique
Base commune
Europe
Base commune
Asie
La rsolution des problmes de mise jour implique la mise en uvre dune stratgie particulire (e.g. mise jour d une copie matre qui est ensuite propage)

Illustration de stratgies de mise jour en cas de conflit daccs
Site matre
Difficult de conception Difficult de reprise aprs panne Impact des mises jour sur le fonctionnement des nuds (overhead)
Mises jour asynchrones partir dun site matre Un seul point de rfrence Faible impact des mises jour sur le fonctionnement des nuds

Rplication en vue de la rsistance aux dfaillances (Disaster Recovery)
Propagation des modifications Base principale Base rplique
Site de secours Site primaire
La rplication peut tre partielle ou totale Elle peut se fonder sur une sauvegarde totale priodique (e.g. hebdomadaire) et la copie du journal des transactions intervalles rguliers. La base rplique est alors rgnre partir de la dernire sauvegarde totale et du journal
Un aperu sur les SGBD du commerce

A la fin des annes 80 et au dbut des annes 90, la plupart des fournisseurs de SGBD avaient des projets voire des produits de versions rparties de leur SGBD et des capacit fdrer des BD (homognes et htrognes) Les diffrentes expriences faites, par les utilisateurs dans le cadre dapplications, avec ces SGBD ont montr leurs limites, en particulier dans un contexte avec mise jour Au dbut des annes 2000, les fournisseurs ne mettent plus en avant les aspects distribus. Les fournisseurs ont volu vers des solutions base de rplication des bases de donnes et des moyens daccs des bases de donnes trangres A titre dillustration de cette volution, Ingres qui proposait la solution la plus lgante et la plus avance en matire de distribution a renonc cette ambition. Ingres a t acquise par CA (Computer Automation). CA ne met pas lemphase sur laspect distribu Nous allons passer rapidement en revue certaines des solutions proposes par diffrents fournisseurs de SGBD
Un peu dhistoire : Ingres/STAR

Parmi les diffrents modles deSBD distribus, Ingres proposait incontestablement lun des modles les plus labors Vision Ingres/STAR
Utilisateur local Utilisateur distant
Administrateur
Gestion des dictionnaires rpartie : - Dictionnaire global sur site matre - Caches des informations dans les sites participants - Droits daccs rpartis Excution des requtes rparties : - Requtes multi-bases en Ingres-SQL ou Open-SQL - Dfinition de curseurs multi-sites Contrle des transactions rparties : - Validation deux phases - Dtection des treintes fatales
Une seule base de donnes virtuelle globale Une seule base de donnes virtuelle globale
Serveur Ingres/STAR Serveur Ingres/STAR
Donnes Ingres distantes
Donnes Ingres locales
Donnes trangres locales
Donnes trangres distantes
Un peu dhistoire : Ingres/STAR (2)

Architecture Ingres/STAR
Application Application SQL Donnes
Ingres/STAR Ingres/STAR
BD Ingres
Ingres Ingres
Communication Communication
Passerelle Passerelle SQL
Passerelle Passerelle
Base DB2
DB2 DB2
IMS IMS
Base IMS
IBM DB2
Trois produits (entre autres) :
DataLinks DataJoiner DataPropagator
DataLinks :
Permet DB2 d accder des donnes stockes indpendamment de DB2 Permet diffrents niveaux de contrle sur ces donnes externes :
Intgrit rfrentielle Contrle daccs Oprations de sauvegarde et de restauration coordonnes Transactionnel distribu
Composants de DataLinks :
Nouveau type de donnes DATALINK (URL - Uniform Resource Locator) DB2 Data Links Manager qui a deux composantes :
Data Links File Manager (DLFM) Data Links Filesystem Filter (DLFF)
API DBMS/DLFM pour dialoguer avec les Data Links File Managers
IBM DB2 - DataLinks (2)

Exemple :
Requtes SQL
Applications Applications
Requtes fichiers Data Links Filesystem Filter Table des salaris
Nom
Dpartement
Photo (type = datalink)
API DBMS/DLFM
D L F M
Images stockes dans des fichiers externes
Architecture :
Application Application SQL Donnes (y compris URLs) Systme de fichiers
DB2 + extension Datalinks
Chemin de contrle pour les accs aux fichiers externes
DB2 Datalinks Manager
Donnes Page 53 RJ Chevance 2001 Fichiers Stockage hirarchis
IBM DB2 - DataJoiner (3)

Permet laccs aux donnes gres par des SGBD diffrents (relationnels ou non) Supporte les fonctions :
SQL DB2 Validation deux phases (XA) Procdures stockes Dfinition globale des donnes (DDL) Accs ODBC, JDBC, SQL-CLI
Fonctionne en relation avec les mcanismes de rplication

IBM DB2 - DataPropagator

DB2 Datapropagator assure la mise jour de bases de donnes distribues (dune source vers des cibles ) Les composants de DataPropagator sont :
Change Capture : dtection des changements dans la base source et stockage dans des tables intermdiaires (staging tables) Apply : prend les donnes stockes dans les tables intermdiaires et applique les changements aux bases des donnes cibles Administration : fonctions permettant de spcifier et de contrler le processus de rplication
Illustration du fonctionnement :
Source Dtection des changements fonde sur le journal Change Capture Change Capture Table intermdiaire
ply Appply A
Cible
DB2
Source non DB2
Dtection des changements fonde sur les dclencheurs (triggers) Change Capture Change Capture Table intermdiaire
Da a Dta J o ta in Jo e inr er plyy Apppl A
DB2
Cible non DB2

Da DtaJoi a ta n Jo er in e r
ABC
XYZ Page 55 RJ Chevance 2001
Informix - Virtual Table Interface

Virtual Table Interface
Capacit de dfinir des mthodes daccs en complment de celles offertes par Informix Ces mthodes daccs peuvent oprer soit :
sur des donnes gres par Informix sur des donnes non gres par Informix (pas de service transactionnel ni de sauvegarde/restauration fournit par Informix pour ces donnes)
Programme client Programme client
Informix Dynamic Server

Table Informix Moteur SQL Mthode daccs Mthode daccs Informix Informix Table Virtuelle Stocke dans un espace connu dInformix
Mthode daccs dfinie Mthode daccs dfinie par l utilisateur par l utilisateur Page 56 RJ Chevance 2001
Table Virtuelle
Stocke dans un espace inconnu dInformix
Informix - Enterprise Replication

Architecture
Dfinition de la Dfinition de la rplication rplication
Catalogue global Cible1
Journal
Capture des Capture des transactions transactions
Acheminement fiable Acheminement fiable des messages des messages
Ciblen
Composants fonctionnels :
Configuration et contrle Capture des transactions (via le journal) Acheminement des informations (type MOM scuris) Prise en compte des mises jour sur site distant (mises jour suivant une logique transactionnelle) Rsolution de conflits. Possibilits :
Priorit la dernire modification en date Stratgie dfinie par programme Ignorance
Oracle - Transparent Gateways

Solution Transparent Gateways
Permet laccs de nombreux (40?) gestionnaires de donnes Constitue de deux composants :
Services htrognes (Heterogeneous Services)
Service transactionnel (validation deux phases) Service SQL
Traduction SQL Oracle vers SQL non Oracle Traduction de dictionnaire de donnes
Service procdural (excution de procdures stockes)
Transparent Gateway
SQL and Data Dictionary Translation Information : fournit aux services htrognes les informations ncessaires la traduction Traduction des types de donnes Assure la connexion des systmes non-Oracle Plusieurs possibilits concernant la localisation du Gateway
Oracle - Transparent Gateways (2)

Architecture gnrale :
Base Oracle Services Htrognes Transparent Gateway Base non-Oracle
Localisation du Gateway
Application Application Application Application
Oracle Oracle
GW GW
SGBD SGBD
Oracle Oracle
GW GW
SGBD SGBD
Oracle Oracle Page 59 RJ Chevance 2001
GW GW
SGBD SGBD
Oracle Oracle
GW GW
SGBD SGBD
Oracle Database Replication

Notions de base :
Replication Object : objet existant de multiples exemplaires Replication Groups : regroupement logique dobjets rpliqus en vue de faciliter ladministration de la rplication Replication sites :
Master Site : contient la copie complte des objets dun groupe de rplication Snapshot Site : supporte des extraits en lecture seule dun replication group ou un extrait susceptible de mise jour
Site matre A
Site matre B
Site extrait D
Site matre C
Oracle Database Replication (2)

Multimaster Replication : Plusieurs sites, dans un mode dgal gal (peer-to-peer), grent des objets rpliqus. Utilisation :
Recouvrement en cas de dfaillance Distribution de la charge de travail
Site matre A
Site matre B
Replication Group
Replication Group
Site matre C
Replication Group
Difficult : synchronisation

Snapshot Replication :
Snapshots en lecture seule (Read-Only Snapshots) :
Rplication complte ou partielle dune table matre . Avantages :
Les tables matre nappartiennent pas ncessairement au mme groupe de rplication Les snapshots peuvent rsulter de la composition de plusieurs BD) Excution locale de requte (allgement de la charge du site matre)
En lecture seule ou avec possibilit de mise jour de la fonction de mise jour distante (interaction avec le site dtenant la base matre)
Mise jour distante Requte locale
Table rplicat (lecture seule)
Base rplique
Base matre
Table matre (mise jour possible)

Snapshots avec mise jour (Updateable Snapshots) :
Les snapshops supportant la mise jour ne dpendent que dune seule table matre et sont mis jour (refresh) de faon incrmentale ou immdiate Les mises jour sont propages depuis le snapshot vers la base matre. Les mises jour peuvent tre rpercute vers dautres sites Les snapshots supportant la mise jour sont remis jour Avantages :
Permet aux utilisateurs de consulter et de mettre jour les donnes (locale) mme en cas de dconnexion avec le site matre Rduction possible du volume de la base rplique
Site matre B
Replication Group
Site snapshot
Site snapshot
Sous-ensemble du Replication Group Page 63 RJ Chevance 2001
Copie complte du Replication Group
Sybase - Replication Server

Composants du Replication Server
Application Application Replication Replication Server Server SQL Server SQL Server
SQL Server SQL Server
Log Transfer Log Transfer Manager Manager
Replication Replication Server Server
Rseau Autres Autres serveurs de serveurs de donnes donnes
Replication Replication Server Server
Log Transfer Manager : dtection du changement des donnes

Le LTM (Log Transfer manager) est un thread qui surveille le journal de la base de donnes laquelle il est associ Le LTM traduit les modifications quil dtecte sous une forme indpendante comprhensible par le Replication Server : le LTL (Log Transfer Language) qui est une composante du RCL (Replication Control Language) Cette interface est publique (ce qui permet dimplmenter le dveloppement des composants ncessaires pour des environnements htrognes) Utilisation de files dattente de messages (MOM ou Message Oriented Middleware) pour palier lindisponibilit des systmes
Sybase - Replication Server (2)

Quelques exemples :
Partage dinformations entre sites
Une rgle simple : un seul site fait les mises jour des donnes qui le concernent
Site A
Site C
Site B
Exemple de mise jour (le site A demande la mise jour dune donne concernant le site C)
1 - Demande de modification dune donne concernant le site C Site A Site B Site C Site A Site B 3 - Rplication de la modification Site A Site B Page 65 RJ Chevance 2001 Site C 2 - Modification de la donne Site C
Site A
Site C
Site B
valuation des SGBD rpartis

Les 12 + 1 critres de C Date
0 - Transparence pour lutilisateur 1 - Autonomie de chaque site 2 - Absence de site privilgi 3 - Continuit de service 4 - Indpendance vis--vis de la localisation 5 - Indpendance vis--vis de la fragmentation 6 - Indpendance vis--vis de la rplication 7 - Traitement rparti des requtes 8 - Gestion rpartie des transactions 9 - Indpendance vis--vis du matriel 10 - Indpendance vis--vis du systme dexploitation 11 - Indpendance vis--vis du rseau 12 - Indpendance vis--vis du SGBD
Bibliographie
Claude Chrisment, Genevive Pujolle, Gilles Zurfluh Bases de donnes rparties Les Techniques de lIngnieur Georges et Olivier Gardarin Le Client - Serveur Eyrolles Robert Orfali, Dan Harkey, Jerry Edwards Client/Serveur Guide de survie John Wiley, Thomson Publishing Serge Miranda, Anne Ruols Client-Serveur Eyrolles Polycopis des cours CNAM dIntgration des Systmes Client/Serveur des annes prcdentes par :
Batrice Finance Jean-Pierre Meinadier Jean-Marc Saglio, Yann Viemont
Sites des principaux fournisseurs de SGBD :

http://www.ibm.com http://www.informix.com http://www.oracle.com http://www.sybase.com

01 BD Reparties

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

01 BD Reparties

Transféré par

Droits d'auteur :

Formats disponibles

Bases de donnes rparties rparties et fdres

Traduction des schmas Architecture de rfrence Accs aux BD multiples

Niveaux de transparence Client/Multibases :

Quelques problmes des BD rparties et fdres Partitionnement et placement des donnes

valuation des SGBD rpartis Bibliographie Page 2 RJ Chevance 2001

Base de donne fdre - a priori htrogne (Federated BD)

Page 3 RJ Chevance 2001

Pourquoi des BD rparties ou fdres?

Page 4 RJ Chevance 2001

Consommateurs Consommateurs Commandes

Schma des donnes rparties

Dijon Vins Vins Producteurs Producteurs Produits Produits

Rpartition des donnes

Page 7 RJ Chevance 2001

Choix du modle canonique :

Schma intermdiaire 1 Schma intermdiaire 1

Schma intermdiaire 2 Schma intermdiaire 2

Schma intermdiaire N Schma intermdiaire N

Schma export 1 Schma export 1

Schma export 2 Schma export 2

Schma export N Schma export N

Comparaison ou analyse - mise en vidence des conflits :

Mise en conformit : rsolution des conflits

Fusion des schmas - Qualits recherches :

Restructuration - Amlioration du schma global

Quelques cas de conflits

Attribut sans quivalent dans lautre relation

Page 13 RJ Chevance 2001

Traduction des schmas

Modle pivot tendu Schma interoprrable

Modle pivot Schma import

Requtes pivot localises

Modle pivot Schma export

Modle X (RDBMS,..) Schma local

Requtes pivot sur objets locaux Requtes spcifiques X (SQL, OQL,..)

Page 15 RJ Chevance 2001

Accs aux BD multiples

Appli BD A Appli BD A API SQL Pilote A

Appli BD B Appli BD B API SQL Pilote B

Appli BD C Appli BD C API SQL Pilote C FAP A, FAP B, FAP C

Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C

Page 16 RJ Chevance 2001

Accs aux BD multiples (2)

Appli BD Appli BD API SQL commune

Pilote C FAP A, FAP B, FAP C Serveur BD B

Serveur BD C Administration SGBD A Administration SGBD B Administration SGBD C

Page 17 RJ Chevance 2001

Accs aux BD multiples (3)

Appli BD Appli BD API SQL commune Pilote passerelle

Serveur passerelle Administration SGBD A Administration SGBD B Administration SGBD C

Page 18 RJ Chevance 2001

Accs aux BD multiples (4)

Administrateur de base de donnes unique

Page 19 RJ Chevance 2001

Niveaux de transparence la localisation

Vues rparties (sur BD fdres) SGBD rparti

Page 20 RJ Chevance 2001

RDA - Remote Data Access

Protocole RDA Protocole RDA

Protocole RDA Protocole RDA

Protocole RDA Protocole RDA

SGBD local SGBD local

SGBD local SGBD local