No dordre: 000

THSE
prsente devant

lUniversit Pierre et Marie Curie (Paris VI)

pour obtenir le grade de

D OCTEUR DE LU NIVERSIT P IERRE ET M ARIE C URIE

Mention I NFORMATIQUE
par

Idrissa S ARR
quipe daccueil : Bases de Donnes
cole Doctorale : EDITE
Composante universitaire : L ABORATOIRE D I NFORMATIQUE DE PARIS 6
Titre de la thse :

Routage des Transactions dans les Bases de Donnes Large

Echelle
date de soutenance prvue : 07 octobre 2010
Rapporteurs :
Examinateurs :

Directeur de thse :
Encadrant :

Esther
Rachid
Pierre
Stphane
Gabriel
Samba
Anne
Hubert

PACITTI
G UERRAOUI
S ENS
G ANARSKI
A NTONIU
N DIAYE
D OUCET
NAACKE

Professeure lUniversit de Montpellier 2

Professeur lEPFL
Professeur lUPMC
Matre de Confrences lUPMC (HDR)
Charg de Recherche lINRIA de Rennes (HDR)
Matre Assistant lUCAD
Professeure lUPMC
Matre de Confrences lUPMC

Table des matires

1

Introduction
1.1 Motivations . . . . . . . . . . .
1.2 Objectifs et Contexte de la thse
1.3 Problmatiques . . . . . . . . .
1.4 Contributions . . . . . . . . . .
1.5 Organisation du manuscrit . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

5
5
6
6
7
10

Systmes rpartis grande chelle

2.1 Applications Web 2.0 . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Notions de systme distribus . . . . . . . . . . . . . . . . . . . .
2.3 Les proprits requises des systmes distribus . . . . . . . . . . .
2.3.1 Transparence . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Passage lchelle . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Disponibilit . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Autonomie . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Etude de quelques systmes distribus . . . . . . . . . . . . . . . .
2.4.1 Systmes P2P . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Les grilles informatiques ou grid . . . . . . . . . . . . . . .
2.4.3 Le cloud . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 Exemple dutilisation des systmes distribus large chelle
2.5 Implmentation dun systme distribu avec un middleware . . . . .
2.5.1 Catgories de Middleware . . . . . . . . . . . . . . . . . .
2.6 Modle darchitecture pour la gestion des donnes large chelle . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

13
13
14
16
16
16
17
18
19
19
21
22
23
25
26
28

.
.
.
.
.
.
.
.

29
30
32
32
32
35
36
44
47

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

Gestion des transactions dans les bases de donnes rpliques

3.1 Notions de transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Bases de donnes rparties et rpliques . . . . . . . . . . . . . . . . . . . .
3.2.1 Objectifs et principes des bases de donnes rparties . . . . . . . . .
3.2.2 Mcanismes de rplication . . . . . . . . . . . . . . . . . . . . . . .
3.3 Gestion des transactions dans les bases de donnes rpliques . . . . . . . . .
3.3.1 Gestion des transactions et passage lchelle en taille . . . . . . . .
3.3.2 Gestion des transactions et disponibilit . . . . . . . . . . . . . . . .
3.3.3 Gestion transparente des transactions avec transparence et autonomie
1

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

Table des matires

3.4

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.1 Modle de rplication pour les bases de donnes large chelle . . . . . . 49
3.4.2 Modle de middleware pour les bases de donnes distribues et rpliques . 50

Architecture dun Systme de Routage des Transactions

4.1 Modle et concepts . . . . . . . . . . . . . . . . . . .
4.1.1 Modle de transactions et de donnes . . . . .
4.1.2 Ordre de prcdence des transactions . . . . .
4.1.3 Structuration des mtadonnes . . . . . . . . .
4.2 Dfinition gnrale des composants de larchitecture .
4.2.1 Impact des besoins applicatifs sur larchitecture
4.2.2 Modle de communication . . . . . . . . . . .
4.2.3 Architecture dtaille . . . . . . . . . . . . . .
4.3 Description de la structure des mtadonnes . . . . . .
4.3.1 Description et structure des mtadonnes . . .
4.3.2 Implmentation du catalogue . . . . . . . . . .
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

Routage des transactions

5.1 Routage des transactions . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Dfinition du graphe de rafrachissement et du plan dexcution
5.1.2 Algorithme gnrique de routage . . . . . . . . . . . . . . . . .
5.1.3 Algorithmes de routage pessimiste . . . . . . . . . . . . . . . .
5.1.4 Algorithme de routage hybride . . . . . . . . . . . . . . . . . .
5.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Gestion des mtadonnes . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Gestion des mtadonnes avec verrouillage . . . . . . . . . . .
5.2.2 Gestion des mtadonnes sans verrouillage . . . . . . . . . . .
5.2.3 Etude comparative des deux mthodes de gestion du catalogue .
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tolrance la dynamicit des noeuds
6.1 Gestion des dconnexion prvue . . . .
6.2 Gestion des pannes . . . . . . . . . . .
6.2.1 Modle et dtection de pannes .
6.2.2 Tolrance aux pannes . . . . . .
6.2.3 Majoration du temps de rponse
6.3 Gestion contrle de la disponibilit . .
6.4 Conclusion . . . . . . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

53
53
53
55
57
58
58
60
61
66
66
67
71

.
.
.
.
.
.
.
.
.
.
.

73
74
74
75
76
81
88
89
90
90
92
93

.
.
.
.
.
.
.

95
96
98
98
99
103
104
106

Validation
107
7.1 Evaluation de la gestion du catalogue . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.1.1 Surcharge de la gestion du catalogue dans D TR . . . . . . . . . . . . . . . 108
2

Table des matires

7.2

7.3

7.4
8

7.1.2 Surcharge de la gestion du catalogue dans T RANS P EER

7.1.3 Analyse de la surcharge du catalogue . . . . . . . . . .
Evaluation des performances globales du routage . . . . . . . .
7.2.1 Impact du relchement de la fracheur . . . . . . . . . .
7.2.2 Apport du routage dcentralis . . . . . . . . . . . . . .
7.2.3 Passage lchelle . . . . . . . . . . . . . . . . . . . .
7.2.4 Conclusion sur les performance du routage . . . . . . .
Evaluation des performances de la tolrance aux pannes . . . . .
7.3.1 Configuration du temporisateur . . . . . . . . . . . . .
7.3.2 Surcharge de la gestion des pannes . . . . . . . . . . . .
7.3.3 Performances de la gestion des pannes . . . . . . . . . .
7.3.4 Conclusion sur lvaluation de la gestion des pannes . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

111
113
115
115
117
118
120
120
121
122
123
125
126

Conclusion et Perspectives
127
8.1 Synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Rsum

143

Table des matires

Chapitre 1
Introduction
1.1

Motivations

LInternet, rseau mondial dordinateurs, fournit une infrastructure pour le stockage des donnes et facilite le partage de trs grands volumes de donnes. Cette facilit de partage dinformation
est une des principales cls du succs des applications Web et particulirement celles dnommes
applications Web 2.0. Les applications Web2.0 sont ouvertes car elles peuvent tre compltes par
des applications tierces qui ajoutent du contenu ou qui accdent aux donnes de lapplication dorigine. On peut alors considrer quune application Web2.0 joue le rle de ppinire dapplications.
De plus, une application Web2.0 contrle les donnes manipules par les utilisateurs directement
ou via les applications tierces. Plus prcisment, elle gre lexcution des transactions mises par
les utilisateurs ou les applications tierces.
Aujourdhui, beaucoup dapplications Web2.0 voient leur nombre dutilisateur crotre fortement pour atteindre des centaines de millions de personnes (e.g., dbut 2010, Facebook aurait 400
millions de membres actifs). Face cette forte croissance, les applications Web2.0 sont confrontes un problme de passage lchelle. Notamment, le systme de gestion de donnes atteint
rapidement les limites de la charge quil peut traiter. Cela peut provoquer une dgradation des
temps de rponses perus par lutilisateur, situation quil naccepte pas. Pour viter une telle situation, il est ncessaire daugmenter les ressources (calcul, stockage, communication) utilises par
les applications Web2.0.
Lajout de ressource se faisant par tapes et progressivement, linfrastructure obtenue est compose de ressources htrognes (diverses capacits de stockage, calcul et communication) rparties lchelle mondiale. Du fait de sa taille et de son tendue, linfrastructure est sujette de
nombreuses pannes dont il faut tenir compte en prvoyant la redondance des donnes et des fonctions. Dans cette thse, nous apportons des solutions aux problmes soulevs par la manipulation
de donnes rparties et rpliques trs large chelle.
5

Chapitre 1. Introduction

1.2

Objectifs et Contexte de la thse

Cette thse sinscrit en partie dans le cadre du projet ANR Respire [Prod] ralis entre 2006
et 2009, et dont lobjectif principal est doffrir des fonctionnalits avances pour le partage de
ressources et de services dans les systmes pair pair, en prsence de donnes rpliques.
La rplication dans les bases de donnes a t largement tudie, au cours des trois dernires
dcennies. Elle vise amliorer la disponibilit des donnes et augmenter la performance daccs
aux donnes. Un des dfis majeurs de la rplication est de maintenir la cohrence mutuelle des
rpliques, lorsque plusieurs dentre elles sont mises jour, simultanment, par des transactions.
Des solutions qui relvent partiellement ce dfi pour un nombre restreint de bases de donnes
relies par un rseau fiable existent. Toutefois, ces solutions ne sont pas applicables large chelle
car elles ncessitent une communication rapide et fiable entre les nuds traitant les transactions ;
ce qui limite le nombre de nuds (de lordre dune centaine) et le type dinterconnexion (rseau
local).
Dans cette thse nous nous intressons la gestion des transactions dans une base de donnes
rpliques large chelle et particulirement au routage des transactions. Nos principaux objectifs
peuvent tre rsums comme suit :
rduire le temps de rponse des transactions, en quilibrant la charge des rpliques et en
tenant compte de la disponibilit des ressources (SGBD, gestionnaire de transactions).
contrler la cohrence des accs aux donnes rparties et rpliques afin de rendre aux applications des rsultats conformes leur exigence ;
garantir lautonomie des applications et des SGBD i.e. pouvoir intgrer les solutions proposes avec des applications et SGBD existants en les modifiant le moins possible.

1.3

Problmatiques

Dans les systmes dploys grande chelle comme Facebook ou eBay, le nombre de sources
de donnes, rpliques incluses, est trs lev (plus de 10.000 pour eBay). Face cette situation,
plusieurs problmes se posent parmi lesquels le problme de routage que nous tentons de rsoudre
et spcifions comme suit :
1. Soit un ensemble de bases de donnes rparties et rpliques, et une transaction envoye par
une application, le problme du routage de transactions se pose ainsi : sur quelle rplique
dcide-t-on de traiter la transaction et quel traitement doit tre effectu sur la base choisie,
afin de satisfaire au mieux les objectifs de cohrence et de performance ? Notons que le
routage ne consiste pas faire un ordonnancement des transactions entrantes mais il sagit
plutt de faire une optimisation du traitement de la transaction.
Ce problme de routage est trs important dautant plus quaujourdhui les machines hbergeant les donnes peuvent tre fournies par un service tiers tel que les ASP (Application Service Provider) ou les clouds. Ainsi, pour un fournisseur de service cloud ou ASP, il devient
indispensable davoir des mcanismes efficaces pour identifier les donnes dune application
particulire regroupes avec les donnes dautres applications pour des soucis conomiques ;
6

1.4. Contributions

2. Le problme du choix de la rplique pose la question de maintenir ltat du systme : quelle

information sur les rpliques doit-on connaitre pour en choisir une qui permettra de traiter la
transaction rapidement ? Dans un systme dcentralis et de grande taille, comment disposer
de cette information au bon endroit sachant que plusieurs demandes de transactions peuvent
arriver simultanment ?
Linformation sur les rpliques dnomme souvent mtadonnes, requiert une gestion minutieuse puisquelle dtermine tout instant ltat global du systme. Dans un environnement
grande chelle lutilisation des mtadonnes est indispensable pour exploiter les ressources
qui composent le systme. De plus, la gestion des mtadonnes fait partie des problmes les
plus important pour garantir les performances puisque la largeur dchelle implique beaucoup de mtadonnes. Cest pourquoi nous nous intressons ce problme.

1.4

Contributions

Nos contributions dans cette thse sont rsumes en cinq points dcrits ci-aprs.
Architecture globale du systme de routage
Nous concevons un intergiciel pour contrler laccs la base de donnes. Larchitecture de
lintergiciel est compose de deux parties : une partie assurant le service de mdiation entre les
diffrents composants du systme et une autre charge de la gestion des mtadonnes qui sont les
donnes ncessaires au fonctionnement du systme en entier. Notre architecture est mi-chemin
entre les systmes P2P structurs et ceux non structurs afin de tirer profit la fois des avantages
des uns et des autres. De fait, les nuds chargs dassurer le routage sont organiss autour dun
anneau logique, ce qui facilite leur collaboration et garantit le traitement cohrent des transactions.
Par contre les nuds chargs de stocker les donnes sont faiblement structurs, ce qui leur confre
une grande autonomie. Notre intergiciel est redondant pour mieux faire face la volatilit dun
environnement large chelle puisqu chaque fois quun nud charg de routage ou de stockage
des donnes tombe en panne, nous utilisons un autre nud disponible pour continuer le traitement
ou rcuprer les donnes.
Gestion dun catalogue rparti
Une exploitation optimale dune base de donnes distribue dans un systme large chelle
requiert un service dindexation (ou catalogue) des ressources qui stockent les donnes. Le catalogue est conu pour hberger des informations utiles lexcution rapide et cohrente des transactions. Nous concevons uns structure qui permet de garder les informations telles que le schma
dallocation des donnes, lhistorique de lexcution des transactions, ltat des rpliques et leur
disponibilit. Notre choix de garder uniquement ces informations se justifie par le fait que :1) elles
sont suffisantes pour pouvoir router une transaction tout en contrlant la cohrence des rpliques ;
et 2) elles sont suffisamment compactes pour ne pas trop allonger le temps de rponse.
7

Chapitre 1. Introduction

Pour des soucis de performances, nous fragmentons le catalogue en fonction des classes de
conflits. Concrtement un fragment contient les mtadonnes dcrivant une seule classe de conflit.
Cela rend possible laccs au catalogue en parallle pour router deux transactions qui ne partagent
pas la mme classe de conflit. Une classe de conflit contient les donnes que la transaction peut
potentiellement lire (resp. modifier)
Pour garantir la cohrence du catalogue lors de laccs au mtadonnes, nous proposons deux
approches : une approche utilisant le verrouillage et une autre sans verrouillage.
La gestion avec verrouillage permet de garantir la cohrence des mtadonnes et savre trs
efficace tant que les accs concurrents aux mtadonnes restent peu frquents. Malheureusement,
nous vrifions que le verrouillage ne facilite pas le passage lchelle. Cest pourquoi nous optons
pour une solution sans verrouillage lors de laccs au catalogue. De fait, nous avons conu un protocole pour coordonner les accs aux mtadonnes sans avoir recours au verrouillage. Ce protocole
offre les mmes garanties de cohrence que le verrouillage et supporte beaucoup mieux les accs
concurrents aux mtadonnes.
Routage des transactions travers un intergiciel
Lantinomie entre les besoins de performances et ceux de cohrence tant bien connue, lapproche suivie dans cette thse consiste relcher les besoins de cohrence afin damliorer la performance daccs aux donnes . Autrement dit, il sagit de relcher la fracheur pour diminuer le
temps de rponse des transactions de lecture seule. Or, dans le contexte du Web2.0, de nombreuses
applications tolrent le relchement de la fracheur i.e. , acceptent de lire des donnes qui ne sont
pas ncessairement les plus rcentes. Par exemple, il est possible de grer des transactions de vente
aux enchres (sur eBay ou Google Adsense) sans ncessairement accder la dernire proposition
de prix, puisque lenchre est sous pli cachet. Le relchement de la fracheur ouvre la voie vers de
nouvelles solutions offrant de meilleures performances en termes de dbit transactionnel, latence,
disponibilit des donnes et passage lchelle.
Nous proposons des mcanismes de routage des transactions pour garantir une excution cohrente et rapide des transactions en utilisant un modle de cot. Le modle de cot utilise le
relchement de la fracheur afin de rduire le temps de rponse et dquilibrer les charges. Nos algorithmes requirent des accs au catalogue rparti pour maintenir la cohrence mutuelle terme et
ils dfinissent lordre dans lequel les transactions doivent tre excutes pour ne pas compromettre
la cohrence.
Le premier algorithme est dit pessimiste et ordonne toutes les transactions conflictuelles en
sappuyant sur les conflits potentiels. En dautres mots, le protocole de routage assure une srialisation globale dfinie de manire pessimiste et qui est utilis pour router toutes les transactions.
Chaque transaction est associe une ou plusieurs classes de conflits. En fonction des classes de
conflits, les transactions sont ordonnes dans un graphe en sappuyant sur leur ordre darrive. Bien
que cette approche assure une srialisation globale, il rduit malheureusement la paralllisation du
traitement des transactions puisquelle sappuie sur des sur-ensembles potentiels de donnes rellement accdes.
Pou amliorer le paralllisme du traitement des transactions, nous avons propos un second
algorithme qui combine une approche pessimiste et optimiste. Ce second algorithme sappuie sur
8

1.4. Contributions

une tentative dexcution des transactions afin de minimiser davantage le temps de rponse des
transactions. Autrement dit, les transactions accdant aux mmes classes de conflit sont excutes
de manire optimiste et une phase de validation est utilise la fin pour garantir la cohrence. Dans
le contexte des applications Web 2.0 o les transactions courantes et potentiellement conflictuelles,
sont peu nombreuses, les chances de russite du routage optimiste savrent trs leves, ce qui fait
quil soit plus adapt. De plus, nous mettons jour le graphe de srialisation pour le rendre plus
prcis.
Lune des caractristiques de notre intergiciel est quil assure une transparence complte de la
distribution des ressources en jouant le rle dinterface entre les applications et les donnes. Les
transactions envoyes par les applications sont transmises aux sources de donnes par lintergiciel,
mais les rsultats sont directement envoys aux applications. Ce protocole de communication permet notre architecture de scarter de la structure client/serveur et de faciliter aussi le passage
lchelle.
Gestion des pannes
Nous proposons galement un mcanisme de gestion des pannes. Ce mcanisme est bas sur la
dtection slective des fautes et sur un algorithme de reprise des transactions. Contrairement la
plupart des autres approches, notre mcanisme nimplique pas lutilisation de nuds qui ne participent pas lexcution de la transaction en cours, ce qui permet de passer lchelle. Pour cela,
nous adaptons des approches existantes de dtection des pannes afin de les rendre oprationnelles
pour chaque type de nud (gestionnaire de transaction et nud de donnes) de notre systme.
Nous avons propos un protocole permettant de grer toutes les situations lorsquun nud quitte
le systme pendant le traitement dune transaction. Ceci est ncessaire et suffisant pour contrler
la cohrence du systme, surtout en cas de dconnexions intempestives.
Cependant, pour maintenir le dbit transactionnel en cas de frquentes pannes, il faut tre
capable dajouter de nouvelles ressources en fonction des dconnexions. Pour ce faire, nous avons
propos un modle permettant de dterminer et contrler le nombre de rpliques requises pour
garder le systme disponible. Ce modle permet de dterminer le nombre minimum de rpliques
ncessaires au bon fonctionnement du systme et donc de minimiser les surcots lis la gestion
des rpliques. Notons que les pannes des noeuds sont dtectes et prises en compte de manire
compltement transparent aux applications.
Validation et rsultats
Pour valider la faisabilit de nos approches, nous implmentons deux prototypes nomms respectivement D TR (Distributed Transaction Routing) et T RANS P EER (TRANSaction on PEER-topeer). Limplmentation de deux prototypes est lie au besoin de grer le catalogue avec verrouillage ou sans verrouillage. De fait, D TR constitue le prototype dvelopp avec verrouillage du
catalogue alors que T RANS P EER est conu pour une gestion du catalogue sans verrouillage et un
modle de communication de type P2P. Puis, nous effectuons quelques simulations pour tudier
le passage lchelle et la tolrance aux pannes de notre solution. Notre choix dutiliser la fois
de lexprimentation et de la simulation se justifie par le fait que : (1) lexprimentation permet
9

Chapitre 1. Introduction

dvaluer un systme dans des conditions relles ; et (2) la simulation est une reprsentation simplifie du systme, facile raliser et requiert moins de ressources que limplmentation, ce qui
favorise lvaluation dun systme grande chelle. Nous avons men une srie dexpriences sur
nos deux prototypes pour tudier les performances de notre systme : dbit transactionnel, temps
de rponse, passage lchelle et tolrance aux pannes.
Les rsultats obtenus pendant la thse ont fait lobjet de plusieurs publications : [SNG08a,
SNG10b, SNG10c, GSN09, SNG10a, SNG08b, DSS10].
Ces rsultats montrent que lutilisation dun catalogue pour stocker les mtadonnes permet de
router les transactions en contrlant le niveau de fracheur sollicit par les applications. De plus,
la surcharge induite par la gestion dun catalogue rparti est faible et donc na pas trop dimpact
ngatif sur le dbit du routage. Les expriences ont montr que le relchement de la fracheur
des donnes amliore le temps de rponse des requtes et lquilibrage des charges, ce qui est
conomiquement important vis--vis de lutilisation totale des ressources disponibles. Les rsultats
montrent galement que la redondance du routeur accrot le dbit de routage et rduit le temps
de rponse tout en introduisant plus de disponibilit. Les rsultats obtenus avec notre prototype
T RANS P EER dmontrent le gain de la gestion des mtadonnes sans verrouillage, ce qui favorise
la rduction du temps de rponse. Enfin, nous avons montr que la prise en compte de la dynamicit
du systme permet de maintenir les performances. Les mthodes de dtection et de rsolution des
pannes utilises sont simples mettre en uvre et savrent bien adaptes pour un systme large
chelle.

1.5

Organisation du manuscrit

Ce manuscrit est structur en huit chapitres.

Le chapitre 1 prsente lintroduction de nos travaux.
Le chapitre 2 prsente les systmes distribus. Nous y dcrivons nos applications vises et
larchitecture et le fonctionnement des systmes distribus : caractristiques, avantages et
implmentation via un intergiciel. Puis nous faisons une discussion sur le modle darchitecture requis pour grer une base de donnes destines des applications grande chelle.
Le chapitre 3 dcrit les travaux connexes au ntre. Il prsente quelques mthodes existantes
pour grer les transactions dans les bases de donnes rpliques. Plus prcisment, nous
tudions les solutions de gestion de transactions en privilgiant quatre caractristiques des
systmes distribus que nous dtaillons dans le chapitre 2 savoir le passage lchelle,
la tolrance aux pannes (ou disponibilit), la transparence et lautonomie des donnes. Les
solutions tudies sont places dans notre contexte afin de bien situer leurs limites mais aussi
de bien comprendre les principes mettre en uvre pour mieux satisfaire les applications
large chelle.
Le chapitre 4 prsente larchitecture de notre systme. Il dtaille les diffrents composants
du systme de routage, leur rle et leur interaction pour assurer le traitement des transactions.
Le chapitre 5 dcrit nos mcanismes de routage et de gestion du catalogue. Dans ce chapitre,
nous dtaillons les algorithmes de routage pour envoyer les transactions vers les rpliques
optimales et nous prsentons les algorithmes proposs pour grer le catalogue rparti afin
10

1.5. Organisation du manuscrit

dassurer sa cohrence .
Le chapitre 6 prsente la gestion des pannes. Nous y tudions la dtection et la rsolution
des pannes afin de maintenir la cohrence et de borner le temps de rponse.
Le chapitre 7 dtaille notre validation. Nous y tudions les performances de notre systme :
dbit transactionnel, temps de rponse, passage lchelle et tolrance aux pannes. Pour ce
faire, nous tudions dabord la surcharge lie la gestion du catalogue, puis les performances
globales du routage et enfin les apports de la gestion des pannes.
Le chapitre 8 prsente la conclusion et les perspectives de cette thse.

11

Chapitre 1. Introduction

12

Chapitre 2
Systmes rpartis grande chelle
La gestion des donnes dans un environnement grande chelle est indispensable pour prendre
en compte les besoins des nouvelles applications telles que les applications Web 2.0. Si la gestion des donnes dans les systmes distribus a t largement tudie dans les dernires annes,
des solutions efficaces et bas cot tardent voir le jour cause de la complexit des problmes
introduits par la largeur de lchelle et le caractre htrogne et dynamique de lenvironnement.
Plus particulirement, ltude des applications Web 2.0 nous a permis de comprendre leurs exigences satisfaire. Ces exigences qui peuvent se rsumer en un grand dbit transactionnel, une
haute disponibilit et une latence faible, ncessitent de nouvelles approches de concevoir et de grer les systmes distribus. Ceci se dcline en deux problmes qui sont, i) une bonne conception
et implmentation des architectures rparties qui hbergent les services ; et ii) des mcanismes efficaces de gestion des donnes utilises par ces applications. Dans ce chapitre, nous dcrivons les
spcifications dune implmentation des systmes distribus.
Nous dcrivons dabord nos applications vises avant de dcrire larchitecture et le fonctionnement des systmes distribus : caractristiques, avantages et implmentation via un intergiciel.
Puis, nous faisons une discussion sur le modle darchitecture requis pour grer une base de donnes destines des applications grande chelle.

2.1

Applications Web 2.0

Dans cette section nous dcrivons les applications Web 2.0 qui sont nos applications cibles. La
dfinition du Web 2.0 est malaise. Il nen reste pas moins que lensemble des applications Web
2.0 prsente des caractristiques communes, parmi lesquelles nous pouvons citer :
lutilisation du rseau internet comme une plateforme puisque quelles interagissent avec les
autres applications via des navigateurs ;
loffre dun environnement collaboratif en donnant lopportunit aux utilisateurs dajouter et
de contrler leur propre contenu ;
la proposition de services permettant de mettre en relation des utilisateurs partageant des
intrts commun, par exemple les rseaux sociaux.
13

Chapitre 2. Systmes rpartis grande chelle

Les types dapplications Web 2.0 sont trs nombreux, par exemple, weblogging, wikis, rseaux
sociaux, podcasts, flux, etc. Pour tous ces exemples dapplication, le dfi majeur consiste dlivrer
le service attendu par lutilisateur et assurer sa satisfaction en termes de fonctionnalits et de
temps de rponse. De plus, si la mission premire dun site web consiste, par exemple, "convertir
les visiteurs en clients", son principal objectif peut tre rsum comme tant "tout dabord dattirer
suffisamment de visiteurs, puis de convertir suffisamment de visiteurs en clients".
Pour atteindre cet objectif, les applications Web 2.0 doivent satisfaire les exigences suivantes :
haute disponibilit, forte ractivit (temps de rponse faible), maintenance ou volution facile,
chacune tant essentielle son succs. Lenvironnement Web 2.0 offre de nouveaux moyens pour
atteindre ces objectifs, mais croise galement de nouveaux obstacles. En effet le nombre de visiteurs convertis en utilisateurs (ou clients) est trs important et dpasse facilement une centaine de
millions, par exemple plus de 200 millions pour Facebook, ou eBay ou Myspace, etc. Ce nombre
dutilisateurs engendre des traoctets de donnes grer puisque chaque utilisateur peut diter et
contrler son propre contenu. Par consquent, le nombre de requtes qui en dcoule correspond
des dizaines de milliards dinstructions par jour. De plus, certaines applications Web 2.0 fonctionnent en mode pair--pair, ce qui largit la taille de lapplication mais aussi les difficults de
grer les donnes du fait de leur htrognit.
Cependant cette forte charge applicative gnre par les utilisateurs des applications Web 2.0
est trs particulire comme le montre ltude de Jean-Francois Ruiz [Rui]. En effet, parmi les utilisateurs dune application Web 2.0, il y a 1% qui gnrent ou crent un contenu, 10% qui ragissent
(commenter, amliorer, noter, voter) sur le contenu et 89% qui ne font que consulter, i.e. lire le
contenu. En dautres mots, la charge applicative est fortement domines par les requtes de lecture
mais cela nempche pas que la charge dcriture restante est suprieur 30 millions dinstructions dcritures par jour pour un site comme Facebook. Cette valeur est obtenue en supposant que
chaque utilisateur ne fasse au plus quune opration dcriture par jour.
Cette brve tude montre les fortes exigences des applications Web 2.0 qui sont entre autres,
un grand dbit transactionnel, une haute disponibilit, une latence faible, etc.
De plus, cette tude montre que la charge dcriture intensive est due un un volume important
de donnes modifies et non pas par une faible portion de donnes trs frquemment mises
jour (hotspot). Cette caractristique des applications Web 2.0 qui est la consquence directe de
lautorisation accorde aux utilisateurs ne modifier que leurs propres donnes ou celle de leurs
accointances est trs importante car elle rvle que les conflits daccs aux donnes sont rares dans
ce contexte.

2.2

Notions de systme distribus

Selon Tanenbaum [TS99], un systme rparti est un ensemble dordinateurs (ou processus) indpendants qui apparat un utilisateur comme un seul systme cohrent. Les ordinateurs peuvent
garder leur autonomie et tre regroups dans un mme lieu ou disperss sans que cela ne soit visible de lextrieur par un utilisateur. Du fait que lensemble des ordinateurs forment un systme
en entier, la dfaillance dun ordinateur peut avoir un impact ngatif le fonctionnement du systme et introduire des incohrences. En prenant en compte cet aspect, un systme distribu peut
14

2.2. Notions de systme distribus

tre dfini comme "un systme qui vous empche de travailler si une machine dont vous navez
jamais entendu parler tombe en panne, (Leslie Lamport). Sil existe moult dfinitions dont nous
ignorons le nombre, on peut dire que les principaux objectifs des systmes rpartis sont de faire
cooprer plusieurs ressources dans loptique de partager des tches, de faire des traitements parallles, etc . Ainsi, un systme distribu peut tre vu comme une application qui coordonne les
tches de plusieurs quipements informatiques (ordinateurs, tlphones mobile, PDA, capteurs...).
Cette coordination se fait le plus souvent par envoi de messages via un rseau de communication
qui peut tre un LAN (Local Area Network), WAN (Wide Area Network), Internet, etc.

Les systmes distribus peuvent tre classs de diffrentes manires et dans [TS99], trois
classes ont t essentiellement identifies savoir les systmes de calcul distribu (Distributed
Computing Systems), les systmes dinformation distribus (Distributed Information Systems) et
les systmes pervasifs distribus (Distributed Pervasive Systems). Cette classification est axe essentiellement sur les domaines applicatifs des systmes distribus plutt que sur leur organisation
interne (rpartition gographique et support de communication) et les spcificits des ressources
(htrognit, stabilit des ressources, etc.). Pourtant, lorganisation et les caractristiques des
ressources sont des lments essentiels qui permettent de bien prendre en compte les besoins spcifiques des applications en termes de performance. Ce faisant, nous avons fait un classement qui
sappuie plus sur lorganisation et les caractristiques des ressources.

la grappe dordinateur (Cluster) : cest un ensemble dordinateurs connects par un rseau

LAN rapide et fiable pour assurer la disponibilit. Les ressources quasi-homognes (mme
systme dexploitation, logiciels quasi-similaires) sont sous le contrle dun seul noeud appel noeud matre ;
la grille informatique (Grid) : cest une collection dordinateurs htrognes rparties sur diffrents sites maintenus par plusieurs organisations. Les sites sont relis par un rseau WAN
et chacun dentre eux contient plusieurs ressources informatiques administres de manire
autonome et uniforme ;
les systmes pair--pair (peer-to-peer (P2P)) : cest un ensemble dordinateurs appels pairs,
qui saccordent excuter une tche particulire. Les ressources peuvent tre des ordinateurs
ou des assistants personnels interconnects via Internet, ce qui rend le systme beaucoup plus
flexible mais aussi moins fiable et stable ;
cloud : du point de vue systme, le cloud est un ensemble dordinateurs (ressources) stocks
sur de vastes grilles de serveurs ou de data centres. Les ressources du cloud sont mutualises
travers une virtualisation qui favorise la monte en charge, la haute disponibilit et un plan
de reprise mondre cot.
les rseaux de capteurs (Sensor Network) : cest une collection de micro-ressources informatiques (micro-capteur ou systme embarqu) relies le plus souvent par un rseau sans fil en
vue de collecter, dchanger et de transmettre des donnes (en gnral environnementales)
vers un ou plusieurs points de collecte, dune manire autonome.
15

Chapitre 2. Systmes rpartis grande chelle

2.3

Les proprits requises des systmes distribus

Un systme rparti doit assurer plusieurs proprits pour tre considr comme performant.
Nous ne citerons dans cette section que celles que nous trouvons les plus connexes notre contexte
dtudes : la transparence, le passage lchelle, la disponibilit et lautonomie.

2.3.1

Transparence

La transparence permet de cacher aux utilisateurs les dtails techniques et organisationnels

dun systme distribu ou complexe. Lobjectif est de pouvoir faire bnficier aux applications une
multitude de services sans avoir besoin de connatre exactement la localisation ou les dtails techniques des ressources qui les fournissent. Ceci rend plus simple, le dveloppement des applications
mais aussi leur maintenance volutive ou corrective. Selon la norme (ISO, 1995) la transparence a
plusieurs niveaux :
accs : cacher lorganisation logique des ressources et les moyens daccs une ressource ;
localisation : lemplacement dune ressource du systme na pas tre connu ;
migration : une ressource peut changer demplacement sans que cela ne soit aperu ;
re-localisation : cacher le fait quune ressource peut changer demplacement au moment o
elle est utilise ;
rplication : les ressources sont dupliques mais les utilisateurs nont aucune connaissance
de cela ;
panne : si un noeud est en panne, lutilisateur ne doit pas sen rendre compte et encore moins
de sa reprise aprs panne ;
concurrence : rendre invisible le fait quune ressource peut tre partage ou sollicite simultanment par plusieurs utilisateurs.
Le parcours de cette liste montre quil nest pas vident dassurer une transparence totale. En
effet, masquer compltement les pannes des ressources est quasi impossible aussi bien dun point
de vue thorique que pratique. Ceci est dautant plus vrai quil nest pas trivial de dissocier une
machine lente ou surcharge de celle qui est en panne ou dans un sous-rseau inaccessible. En
conclusion, le choix dun niveau de transparence moyen, ne prenant en compte que les spcificits
des applications Web 2.0 que nous ciblons dans cette thse, est ncessaire pour amoindrir les cots
de mise en place du systme et de sa complexit.

2.3.2

Passage lchelle

Le concept de passage lchelle dsigne la capacit dun systme continuer dlivrer avec
un temps de rponse constant un service mme si le nombre de clients ou de donnes augmente
de manire importante. Le passage lchelle peut tre mesur avec au moins trois dimensions : i)
le nombre dutilisateurs et/ou de processus (passage lchelle en taille) ; ii) la distance maximale
physique qui spare les noeuds ou ressources du systme (passage lchelle gographique) ; iii) le
nombre de domaines administratifs (passage lchelle administrative). Le dernier type de passage
lchelle est dune importance capitale dans les grilles informatiques car il influe sur le degr
dhtrognit et donc sur la complexit du systme (voir section 2.4.2).
16

2.3. Les proprits requises des systmes distribus

Pour assurer le passage lchelle, une solution coteuse consiste ajouter de nouveaux serveurs puissants (plusieurs dizaines de CPU) pour garder le mme niveau de performance en prsence de fortes charges. Ce type de passage lchelle est plus connu sous le nom de Scale Up.
Le problme avec cette solution est que si le systme est sous-charg les ressources consomment
de lnergie inutilement et ne servent rien. Dautres solutions moins chres consistent utiliser
plusieurs machines moins puissantes (dun deux CPU par machine) pour faire face aux pics des
charges, on parle alors de Scale Out. Trois techniques peuvent tre utilises pour favoriser le passage lchelle faible cot. La premire technique consiste ne pas attendre la fin dune tche
pour commencer une autre si elles sont indpendantes. Cela permet de cacher la latence du rseau
ou la lenteur dune ressource. Ce modle de fonctionnement est appel modle asynchrone. La
deuxime technique consiste partitionner les donnes et les stocker sur plusieurs serveurs. Ceci
permet de distribuer la charge applicative et de rduire le temps de traitement global des tches. Il
est aussi possible deffectuer certains traitements aux niveaux des clients (Java Applets). La troisime technique est lutilisation de la rplication et/ou des mcanismes de cache. Laccs des
informations stockes dans un cache rduit les accs distants et donne de bonnes performances
aux applications de type web. La rplication, quant elle, permet une distribution des traitements
sur plusieurs sites permettant ainsi une amlioration du dbit du traitement.
Cependant, lutilisation de ces techniques prsente quelques inconvnients. En effet, le partitionnement et la distribution dun traitement ncessitent des mcanismes de contrle plus complexes pour intgrer les rsultats et assurer leur cohrence. En plus, garder plusieurs copies dune
mme donne (caches ou rpliques) peut entraner des incohrences chaque fois que lon met
une copie jour. Pour viter ce problme, il faut penser faire des synchronisations, ce qui est
souvent contradictoire avec la premire technique de passage lchelle savoir faire de lasynchronisme. En conclusion, les besoins de passage lchelle et de cohrence sont en opposition,
do la ncessit de trouver des compromis en fonction des besoins des applications cibles.

2.3.3

Disponibilit

Un systme est dit disponible sil est en mesure de dlivrer correctement le ou les services
de manire conforme sa spcification. Pour rendre un systme disponible, il faut donc le rendre
capable de faire face tout obstacle qui peut compromettre son bon fonctionnement. En effet,
lindisponibilit dun systme peut tre cause par plusieurs sources parmi lesquelles nous pouvons
citer :
les pannes qui sont des conditions ou vnements accidentels empchant le systme, ou un
des ses composants, de fonctionner de manire conforme sa spcification ;
les surcharges qui sont des sollicitations excessives dune ressource du systme entranant
sa congestion et la dgradation des performances du systme ;
les attaques de scurit qui sont des tentatives dlibres pour perturber le fonctionnement
du systme, engendrant des pertes de donnes et de cohrences ou larrt du systme.
Pour faire face aux pannes, deux solutions sont gnralement utilises.
La premire consiste dtecter la panne et la rsoudre, et ce dans un dlai trs court. La
dtection des pannes ncessite des mcanismes de surveillance qui sappuient en gnral sur des
timeouts ou des envois de messages priodiques entre ressources surveilles et ressources sur17

Chapitre 2. Systmes rpartis grande chelle

veillantes. Cette dtection, outre la surcharge quelle induit sur le systme, ne donne pas toujours
des rsultats fiables. En effet, avec lutilisation des timeouts, chaque fois quun timeout est expir,
la ressource sollicite, ne pouvant tre contacte ou narrivant pas envoyer une rponse, est en
gnral suspecte dtre en panne. Par consquent, une simple variation de la latence du rseau ou
de la surcharge dune ressource peut entraner lenvoi et/ou la rception dune rponse en dehors
du timeout et donc conduire des fausses suspicions. Par ailleurs, une fois la panne dtecte, il
faut des mcanismes de rsolution efficace pour arriver la cacher aux clients. Cette tche est loin
dtre triviale car il existe plusieurs types de pannes et chacune dentre elle requiert un traitement
spcifique (voir chapitre suivant).
La deuxime solution consiste masquer les pannes en introduisant de la rplication. Ainsi,
quand une ressource est en panne, le traitement quelle effectuait est dplac sur une autre ressource
disponible. La rplication peut tre aussi utilise pour faire face la seconde cause dindisponibilit
dun systme (surcharge du systme). Pour rduire la surcharge dune ressource, les tches sont
traites paralllement sur plusieurs rpliques ou sur les diffrentes rpliques disponibles tour de
rle (tourniquet). Une autre technique qui permet de rduire la surcharge dune ressource consiste
distribuer les services (ou les donnes) sur plusieurs sites et donc de les solliciter de manire
parallle. Le partitionnement des services ou des donnes permet disoler les pannes et donc de les
contrler plus simplement.
Enfin, la gestion de la dernire source dindisponibilit ncessite des politiques de scurit sur
laccs et lutilisation des ressources. Ces politiques ont pour objet la mise en uvre de mcanismes permettant de garantir les deux proprits suivantes : la confidentialit et lintgrit des ressources ou informations sensibles. La confidentialit permet de protger les accs en lecture aux
informations, alors que lintgrit permet de protger les accs en criture. Sil existe une seule
politique de scurit pour lensemble des ressources, la scurit est dite centralise, dans le cas
contraire, elle est dite distribue et permet chaque partie du systme davoir sa propre politique.
Il est noter quune politique de scurit distribue permet plus dhtrognit et sadapte des
systmes comme les grilles informatiques mais ncessite des mcanismes plus complexes. Nous
mentionnons aussi que bien que la scurit est capitale pour la disponibilit, nous ne laborderons
pas dans cette thse pour ne pas trop sloigner de nos objectifs.
Nous venons de voir que quelque soit la manire dont la gestion de la disponibilit est assure, des modules supplmentaires sont requis (gestion de rplication, dtection et rsolution des
pannes, politique de scurit, etc.). Ceci entrane dune part, une surcharge du systme (nombre de
messages trs important, collection de processus en arrire-plan) et dautre part, une complexit du
systme. Une solution idale serait de minimiser la complexit mais aussi la surcharge introduite
pour assurer la disponibilit. Ainsi, les modules supplmentaires intgrs doivent tre trs lgers
(requirent peu de ressources pour leur fonctionnement) et les techniques de dtection/rsolution
des pannes ne doivent pas tre ralises sur la base dune communication qui gnre plusieurs
messages (ex : broadcast).

2.3.4

Autonomie

Un systme ou un composant est dit autonome si son fonctionnement ou son intgration dans
un systme existant ne ncessite aucune modification des composants du systme hte. Lautono18

2.4. Etude de quelques systmes distribus

mie des composants dun systme favorise ladaptabilit, lextensibilit et la rutilisation des ressources de ce systme. Par exemple, une ressource autonome peut tre remplace avec une autre
ressource plus riche en termes de fonctionnalits, ce qui tend les services du systme. Le changement du pilote daccs une base de donnes ODBC par un pilote JDBC illustre bien cette notion
dautonomie et son impact dans le fonctionnement dun systme, puisquaucune modification ne
sera effectue au niveau du SGBD.
Lune des motivations de maintenir lautonomie est que les applications existantes sont difficiles remplacer car dune part, elles sont le fruit dune expertise dveloppe pendant plusieurs
annes et dautre part, leur code nest pas souvent accessible, i.e. les SGBD tels que Oracle, SQL
Server, Sybase, etc. Pourtant, il est indispensable de sappuyer sur les applications existantes car
les clients ont leurs prfrences et ne sont pas ncessairement prts confier leur traitement une
nouvelle application ou de stocker leurs donnes sur un SGBD nouveau qui ne prsente pas les
mmes garanties quun systme connu, fiable et maintenu. Une solution pour garder lautonomie
dune application ou dun SGBD est dintgrer toute nouvelle fonctionnalit supplmentaire et
spcifique une application sous forme dintergiciel.
Cependant, limplmentation de lintergiciel introduit de nouvelles surcharges en ajoutant une
couche de plus laccs aux donnes. A cela, sajoute que lintergiciel devient indispensable au
fonctionnement du systme et peut devenir trs rapidement source de congestion sil est partag
par plusieurs applications. Pour minimiser ces impacts ngatifs, lintergiciel doit tre conu de tel
sorte quil soit toujours disponible et non surcharg. La complexit de son implmentation doit
tre contrle afin de minimiser le cot de sa traverse. Pour ce faire, il faut viter de concevoir un
intergiciel trs gnrique destination de plusieurs applications au profit dun intergiciel ad-hoc.

2.4

Etude de quelques systmes distribus

Dans cette section, nous tudions trois catgories de systmes distribus savoir les systmes
pair--pair (P2P), les grilles informatiques et le cloud. Le choix dtudier ces trois catgories est
fortement tributaire de leur caractre trs htrogne et leur besoin de passage lchelle, que
nous avons privilgi dans cette thse. Ltude met laccent sur les architectures et les mcanismes
permettant dassurer la disponibilit, le passage lchelle et la transparence et lautonomie.

2.4.1

Systmes P2P

Comme nous lavons mentionn ci-avant, le terme P2P fait rfrence une classe de systmes
distribus qui utilisent des ressources distribues pour raliser une tche particulire de manire
dcentralise. Les ressources sont composes dentits de calcul (ordinateur ou PDA), de stockage
de donnes, dun rseau de communication, etc. La tche excuter peut tre du calcul distribu,
du partage de donnes (ou de contenu), de la communication et collaboration, dune plateforme
de services, etc. La dcentralisation, quant elle, peut sappliquer soit aux algorithmes, soit aux
donnes, soit aux mtadonnes, soit plusieurs dentre eux.
Lune des particularits des systmes P2P est que tous les nuds (pairs) sont en gnral symtriques, cest dire quils jouent la fois le rle de client et de serveur. En particulier, les
19

Chapitre 2. Systmes rpartis grande chelle

systmes de partage de fichiers permettent de rendre les objets dautant plus disponibles quils
sont populaires, en les rpliquant sur un grand nombre de nuds. Cela permet alors de diminuer
la charge (en nombre de requtes) impose aux nuds partageant les fichiers populaires, ce qui
facilite laugmentation du nombre de clients et donc le passage lchelle en taille des donnes.
Les pairs sont organiss autour dune architecture qui peut tre centralise ou non. Dans larchitecture centralise, un noeud joue le rle de coordinateur central (serveur, ou index central) et
gre soit les partages, soit la recherche, soit linsertion dinformations et de nouveaux nuds. Cependant lchange dinformations entre noeuds se passe directement dun noeud lautre. Daucun
considrent que de telles architectures ne sont pas pair--pair, car un serveur central intervient dans
le processus. Par contre dautres arguent que ce sont bien des systmes pair--pair car les fichiers
transfrs ne passent pas par le serveur central. Nanmoins, cest une solution fragile puisque le
serveur central est indispensable au rseau. Ainsi, sil est en panne ou non accessible, tout le rseau
seffondre. En plus, le systme nest pas transparent puisque les nuds ont besoin de savoir tout
moment lemplacement de lindex et sont sensibles tout changement de celui-ci. Un exemple de
solution P2P centralise est Napster [Nap], qui utilise un serveur pour stocker un index ou pour
initialiser le rseau.
Pour faire face ces insuffisances, une architecture distribue simpose, puisquun nud pourrait solliciter plusieurs serveurs en mme temps. Le systme est ainsi plus robuste mais la recherche dinformations est plus difficile. Elle peut seffectuer dans des systmes dcentraliss
non-structurs, comme Gnutella [Gnu]. Dans ce systme, la recherche se fait par propagation de la
requte aux voisins jusqu trouver les rsultats, ce qui ncessite ds lors un nombre de messages
lev, proportionnel au nombre dutilisateurs du rseau (et exponentiel suivant la profondeur de
recherche). Dans les systmes dcentraliss structurs, une organisation de connexion et de rpartition des objets partags est maintenue entre les nuds. Souvent cette organisation est base sur
les tables de hachage distribues, permettant de raliser des recherches en un nombre de messages
croissant de faon logarithmique avec le nombre dutilisateurs du rseau, comme CAN [RFH+ 01],
Chord [SMK+ 01], Kademlia [MM02] Pastry [RD01a], etc.
Une autre solution possible est lutilisation de super-pairs , noeuds du rseau choisis en
fonction de leur puissance de calcul et de leur bande passante, ralisant des fonctions utiles au
systme comme lindexation des informations et le rle dintermdiaire dans les requtes. Cette
solution que lon retrouve dans Kazaa [KaZ], rend le systme un peu moins tolrant aux pannes
que les systmes compltement dcentraliss et englobe un peu lide de client-serveur entre pairs
et super-pairs.
Comme tous les noeuds sont au mme niveau avec les architectures compltement distribues,
celle-ci offrent plus de transparence dans lorganisation et la localisation des ressources que les
architectures centralises ou semi-centralises (super-pairs).
Les systmes P2P soulvent plusieurs problmes bien quils facilitent le passage lchelle et
la disponibilit des ressources avec un faible cot. Il faut noter en premier lieu que les noeuds du
systme sont totalement autonomes et donc quils peuvent choisir de partager ou non leur CPU
et leur capacit de stockage. Cette autonomie leur confre aussi le choix de rejoindre ou quitter
le systme tout moment. Cela a pour effet de compromettre la capacit de calcul totale et relle
du systme mais aussi la disponibilit des ressources (informations, capacit de stockage, etc.). En
20

2.4. Etude de quelques systmes distribus

second lieu, le systme de communication utilis est de faible bande passante (en gnral Internet),
ce qui peut crer une surcharge du systme et une latence plus leve que dans les clusters. Enfin,
labsence dinfrastructures de contrle sur les systmes P2P rend ces derniers moins pratiques pour
prendre en compte certains types dapplications qui exigent une grande qualit ou des services
transactionnels. Nanmoins, les systmes P2P sont devenus incontournables aujourdhui dans le
domaine du partage de fichiers, de la recherche dinformation et de la collaboration.

2.4.2

Les grilles informatiques ou grid

Le terme anglais grid dsigne un systme distribu dlectricit. Initialement, le concept de

grille partait du principe dun tel systme : les ressources dun ordinateur (processeur, mmoire,
espace disque) taient mises la disposition dun utilisateur aussi facilement que lon branche un
appareil lectrique une prise lectrique. Une grille informatique est une infrastructure virtuelle
constitue dun ensemble de ressources informatiques potentiellement partages, distribues, htrognes, dlocalises et autonomes. Une grille est en effet une infrastructure, cest--dire des
quipements techniques dordre matriel et logiciel. Cette infrastructure est qualifie de virtuelle
car les relations entre les entits qui la composent nexistent pas sur le plan matriel mais dun
point de vue logique. Dun point de vue architectural, la grille peut tre dfinie comme un systme
distribu constitu de lagrgation de ressources rparties sur plusieurs sites et mises disposition par plusieurs organisations diffrentes [Jan06]. Un site est un lieu gographique regroupant
plusieurs ressources informatiques administres de manire autonome et uniforme. Il peut tre
compos dun super-calculateur ou dune grappe de machines (cluster).
Contrairement aux systmes P2P, une grille garantit des qualits de service non triviales, cest-dire quelle rpond adquatement des exigences (accessibilit, disponibilit, fiabilit, ...) compte
tenu de la puissance de calcul ou de stockage quelle peut fournir.
Il existe plusieurs projets de grilles qui on t mis en place aussi bien des chelles nationales
quinternationales : la grille exprimentale franaise Grid5000 [Proc], la grille de calcul scientifique nord amricain TeraGrid [proe], la grille chinoise CNGrid [prob], la grille Asie-Pacifique
ApGrid [proa], etc.
Les grilles informatiques sont caractrises par une forte htrognit et une grande dynamicit. En effet, les machines dune grappe sont relis par un rseau gigabits alors que les sites sont
lis par un rseau WAN, dont la latence peut aller jusqu 100 millisecondes. De l, nous pouvons
noter une diffrence importante de la latence entre deux machines dun mme site et celle entre
deux machines de deux sites. En outre, chaque site est administr de manire autonome et par
consquent les politiques de scurit varient dun site lautre. Un autre exemple dhtrognit
relve de la composition interne dun site. Chaque site est libre de choisir le type de processeur de
ses machines (Intel, AMD, IBM, ...), la capacit de stockage et le rseau dinterconnexion entre
machines (Gigabit Ethernet, Infiniband, ...). Enfin linfrastructure dune grille est compose dun
nombre important de sites et de machines qui sont susceptibles de tomber en panne tout moment.
A cela sajoute le fait que de nouveaux sites peuvent tre ajouts ou retirs de la grille sans trop
impacter le fonctionnement de la grille. De par leur htrognit, leur gestion dcentralise et
leur taille, les grilles sont des infrastructures trs complexes mettre en oeuvre. La transparence
nest assure qu moiti parce qu il faut avoir une information prcise des ressources dans un site
21

Chapitre 2. Systmes rpartis grande chelle

pour pouvoir distribuer les tches convenablement. Cependant lintrieur dun site, la machine
qui effectue concrtement la tche nest pas connue en gnral.

2.4.3

Le cloud

Le cloud est un concept plus rcent dont une dfinition unanime tarde voir le jour [VRMCL09,
Gee09, BYV08, WLG+ 08]. Cette divergence dcoule des principes considrs par les chercheurs
pour dfinir le cloud. En effet , certains auteurs mettent laccent sur le passage lchelle et la
mutualisation de lusage des ressources [Gee09] alors que dautres privilgient le concept de virtualisation [BYV08] ou le business model (collaboration et pay-as-you-go) [WLG+ 08]. Cependant,
il est unanimement reconnu que le cloud permet lutilisation de la mmoire et des capacits de calcul des ordinateurs et des serveurs rpartis dans le monde entier et lis par un rseau, tel Internet.
Les ressources sont en gnral loges dans des data centres qui sont gographiquement distribus
dans loptique de garantir le passage lchelle et la disponibilit. Avec le cloud, les utilisateurs
ne sont plus propritaires de leurs serveurs informatiques mais peuvent ainsi accder de manire
volutive de nombreux services en ligne sans avoir grer linfrastructure sous-jacente, souvent
complexe. Cest pourquoi, on peut considrer le cloud comme une extension des ASP. Les applications et les donnes ne se trouvent plus sur lordinateur local, mais dans un nuage (cloud) compos
dun certain nombre de serveurs distants interconnects au moyen dune excellente bande passante
indispensable la fluidit du systme. Laccs au service se fait par une application standard facilement disponible, la plupart du temps un navigateur Web. Les service offerts par le cloud sont
nombreux parmi lesquels nous avons :
Infrastructure as a service (IaaS) : cest un service qui donne lutilisateur un ensemble de
ressources de traitement et de stockage dont il a besoin un instant prcis pour effectuer ses
tches ;
Platform as a Service (PaaS) : ce service, en dehors de fournir une infrastructure virtuelle,
assure aussi la plateforme logicielle pour que les applications de lutilisateur puissent tourner ;
Software as a Service (SaaS) : cest une alternative de toute application locale. Un exemple
de ce cas est lutilisation en ligne de la suite bureautique de Microsoft Office.
Pour assurer ces services qui varient dun utilisateur un autre, larchitecture des clouds est compose son niveau le plus basique dune couche logique compose dun ensemble de machines
virtuelles et dune couche physique compose de data centres[BYV08]. Ainsi, plusieurs machines
virtuelles peuvent tre dmarres dynamiquement sur une seule machine physique pour satisfaire
les besoins de plusieurs services. Les data centres qui regroupent les machines physiques sont en
gnral rpartis sur des sites gographiquement distants afin dassurer une haute disponibilit. En
plus cette rpartition permet aussi dassurer un niveau de performances lev en branchant un utilisateur sur le site le plus proche de son emplacement afin de rduire les dlais de communication.
La mutualisation du matriel permet doptimiser les cots par rapport aux systmes conventionnels et de dvelopper des applications partages sans avoir besoin de possder ses propres
machines ddies au calcul. Comme pour la virtualisation, linformatique dans le nuage est plus
conomique grce son volutivit. En effet, le cot est fonction de la dure de lutilisation du service rendu et ne ncessite aucun investissement pralable (homme ou machine). Notons galement
22

2.4. Etude de quelques systmes distribus

que llasticit du nuage permet de fournir des services volutifs et donc de supporter les montes de charges. Par exemple, Salesforce.com, pionnier dans le domaine de linformatique dans le
nuage gre les donnes de 54 000 entreprises, et leurs 1,5 millions demploys, avec seulement 1
000 serveurs (mars 2009). De plus, les services sont extrmement fiables car bass sur des infrastructures performantes possdant des politiques efficaces de tolrance aux pannes (notamment des
rpliques). Grce ses avantages, on assiste aujourdhui une multiplication rapide dentreprises
qui proposent des solutions cloud parmi lesquelles figurent : Amazon, IBM, Microsoft, Google,
etc.
Cependant, le problme fondamental reste dune part la scurisation de laccs lapplication
entre le client et le serveur distant. On peut aussi ajouter le problme de scurit gnrale du
rseau de lentreprise : sans le cloud computing, une entreprise peut mettre une partie de son
rseau en local et sans aucune connexion (directe ou indirecte) internet, pour des raisons de
haute confidentialit par exemple ; dans le cas du cloud computing, elle devra connecter ces postes
internet (directement ou pas) et ainsi les exposer un risque dattaque ou a des violations de
confidentialit.

2.4.4

Exemple dutilisation des systmes distribus large chelle

Les systmes large chelle tels que les P2P ou les grilles peuvent tre utiliss pour concevoir
et raliser diffrentes classes dapplications.
Communication et collaboration. Cette catgorie inclut les systmes qui fournissent des infrastructures pour faciliter la communication et la collaboration en temps rel (ex. Skype [Sky],
MSN [MSN], Yahoo [Yah], Groove [Gro]) ;
Calcul distribu. Ce type dapplication permet le partage de ressources CPU en divisant et
rpartissant le travail sur plusieurs machines. Seti@home [Pau02], le projet de recherche
dune intelligence extraterrestre de luniversit de Californie et de Berkley dune part et
Folding@Home [prof], le projet de calcul rparti tudiant les protines de luniversit de
Standford dautre part sont des illustrations de ce cas dapplication.
Support de service internet. Un nombre considrable dapplications bases sur les systmes
P2P ont t dveloppes pour supporter les services sur internet. Parmi les exemples de ce
type dapplications, nous pouvons citer les systmes de multicast P2P publish/subscribe [VBB+ 03,
CDKR02] ou les applications de scurit et dantivirus [VMR02, JWZ03, VATS04].
Systme de Base de donnes. Les sytmes distribus sont galement utiliss pour concevoir des bases de donnes distribues. Par exemple, Local Relational Model [SGMB01],
PIER [HCH+ 05] et Piazza [HIM+ 04] utilisent des architectures P2P pour stocker et exploiter des donnes.
Distribution et gestion de contenu. Elle constitue la charnire centrale des utilisations que
lon peut faire avec les systmes distribus. Elle couvre une varit dapplications allant du
simple partage de fichiers direct aux systmes sophistiqus qui fournissent des supports de
stockage distribu, une technique dindexation et de localisation efficace et enfin des procdures de mises jour. Google File System (GFS) [GGL03], Hadoop Distributed File System
(HDFS) [Prog] sont des exemples de support de stockage distribus avec un mcanisme dindexation efficace. Un autre avantage majeur de cette classe dapplications est quelle donne
23

Chapitre 2. Systmes rpartis grande chelle

aux utilisateurs la possibilit de publier, de stocker et de grer leur contenu de manire assez
efficace. Les applications Web2.0 tels que eBay [Sho07] ou Facebook [Fac] reposent sur ce
concept et en constituent des exemples trs populaires.
Dans cette thse, nos objectifs sont orients vers les applications Web 2.0. En effet, nous voulons
grer une base de donnes distribue grande chelle dans loptique de donner la possibilit aux
utilisateurs dun accs rapide et cohrent. La conception dun tel systme ncessite une tude dun
des types dapplications cibles savoir eBay pour mieux comprendre les exigences satisfaire.
Exemple dapplications Web 2.0 : eBay
eBay [Sho07] est devenu le leader mondial du commerce en ligne avec plus de 276 millions
de membres inscrits. La socit fonde en 1995, est devenue une place de march mondiale o
une communaut de passionns, compose aussi bien de particuliers que de professionnels, peut
acheter et vendre en ligne des biens et des services aux enchres ou prix fixe. Chaque jour, plus
de 113 millions darticles rpartis dans plus de 55.000 catgories sont vendre sur eBay et correspondent 2 Ptaoctects de donnes. Dun point de vue technique, la plate-forme deBay est trs
dynamique avec lajout de plus de 100.000 lignes de code tous les deux semaines pour satisfaire
les besoins de 39 pays, dans 7 langues et ce 24h/24 et 7j/7. Cette charge applicative correspond
plus de 48 milliards dinstructions SQL par jour. Les utilisateurs sont soit des vendeurs qui offrent
des biens soit des acheteurs qui achtent les biens. Un bien est dans une catgorie donne et appartient un seul vendeur. Pour faire face cette intense charge applicative, larchitecture de eBay est
conue pour prendre en compte cinq critres de performances savoir la disponibilit, le passage
lchelle, le cot, la maintenance et la latence des rponses. La prise en compte de la disponibilit
et du passage lchelle est faite en adoptant quatre stratgies :
Partitionner tout en divisant tout problme (donnes, traitement, ...) en taille matrisable :
permet de passer lchelle, assure le disponibilit par isolation des pannes, moins coteux
maintenir et requiert peu de hardware.
Introduire de lasynchronisme en mettant en uvre des processus (ou composants) asynchrones et en regroupant certains traitements (batch) : favorise le passage lchelle indpendante de chaque composant, une meilleure disponibilit par la dtection et la reprise
cibles des composants en panne et diminue la latence des rponses par paralllisation des
traitements.
Automatiser tout en intgrant des systmes auto-adaptatifs : le passage lchelle sans une
intervention manuelle, la latence comme la disponibilit sont assures par lauto-configuration
quand lenvironnement change et le cot est faible du fait de labsence de lintervention humaine.
Garder lesprit que tout tombe en panne et donc tre prt dtecter toute panne et la
rsoudre dans un dlai court : assure la disponibilit du systme
Pour stocker les donnes, eBay utilise un partitionnement horizontal et des milliers de SGBDs
MySQL comme Facebook. Pour assurer la disponibilit, eBay a dvelopp des techniques de
cache autour du SGBD MySQL, ce qui lui permet de pouvoir excuter un nombre trs significatif doprations de lecture/criture un cot relativement faible. En plus, il utilise un mcanisme
de rplication asynchrone qui est trs adapt au passage lchelle.
24

2.5. Implmentation dun systme distribu avec un middleware

Ltude de lexemple deBay montre les exigences des applications Web 2.0 en termes de dbit transactionnel, de haute disponibilit, de latence faible, etc. Pour prendre en compte tous ces
critres, il faut de nouvelles approches bases sur une bonne conception et implmentation du
systme distribu qui hberge les services mais aussi des mcanismes efficaces de la gestion des
donnes utilises par ces applications. Dans la prochaine section, nous dcrivons les spcifications
dune bonne implmentation des systmes distribus et dtaillerons les spcifications adquates de
la gestion des donnes dans le prochain chapitre.

2.5

Implmentation dun systme distribu avec un middleware

La plupart des systmes distribus sont implments avec un middleware comme le montre la
figure 2.1.

F IGURE 2.1 Architecture dun systme distribu structur avec un integiciel

Le mot middleware (intergiciel ou logiciel mdiateur en franais) dsigne un ensemble de
logiciels ou de technologies informatiques qui servent dintermdiaire entre les applications. Il
peut tre dfini aussi comme un outil de communication entre des clients et des serveurs. Ainsi, il
fournit un moyen aux clients de trouver leurs serveurs et aux serveurs de trouver leurs clients et
en gnral de trouver nimporte quel objet atteignable. Lintrt que prsente un middleware est
multiple et peut tre rsum en quatre points [Kra09] :
cacher la rpartition, cest--dire le fait quune application est constitue de parties interconnectes sexcutant des emplacements gographiquement rpartis ;
cacher lhtrognit des composants matriels, des systmes dexploitation et des protocoles de communication utiliss par les diffrentes parties dune application ;
25

Chapitre 2. Systmes rpartis grande chelle

fournir des interfaces uniformes, normalises, et de haut niveau aux quipes de dveloppement et dintgration, pour faciliter la construction, la rutilisation, le portage et linteroprabilit des applications ;
fournir un ensemble de services communs ralisant des fonctions dintrt gnral, pour
viter la duplication des efforts et faciliter la coopration entre applications.
Un middleware peut tre gnrique ou spcifique un type dapplications. Il faut remarquer que
les gains introduits par un middleware ne vont pas sans inconvnients. En effet, un inconvnient
potentiel est la perte de performances lie la traverse de couches supplmentaires de logiciel.
Lutilisation de techniques intergicielle implique par ailleurs de prvoir la formation des quipes
de dveloppement.

2.5.1

Catgories de Middleware

Les middlewares peuvent tre classs suivant plusieurs critres, incluant les proprits de linfrastructure de communication, leur propre architecture et la structure globale des applications.
Proprits de la communication
Linfrastructure de communication sur laquelle se repose un middleware peut tre caractris
par plusieurs proprits qui permettent une premire classification.
Topologie statique ou dynamique. Avec un systme de communication statique, les entits communicant sont loges dans des endroits fixes et la configuration du systme ne change pas. Si
toutefois, la configuration doit changer, elle est programme en avance, peu frquente et bien intgre dans le fonctionnement du middleware. Par contre, un systme de communication dynamique
donne la possibilit aux entits communicantes de changer de localisation, de se connecter et/ou
se dconnecter pendant le fonctionnement de lapplication (tlphones mobiles, PDA, P2P, ...).
Comportement prvisible ou imprvisible. Dans certains systmes de communication, des bornes
peuvent tre tablies dans loptique de maintenir les facteurs de performances des applications (par
exemple la latence). Hlas, dans la plupart des cas pratiques, ces bornes ne sont pas connues car
les facteurs de performances dpendent de la charge des composants du systme mais aussi du
dbit du rseau de communication. Le systme de communication est dit synchrone si le temps de
transmission dun message est born. Si par contre, cette borne ne peut tre tablie, le systme est
dit asynchrone.
Il est possible de faire une combinaison de ces diffrentes proprits pour obtenir :
topologie statique, comportement prvisible ;
topologie dynamique, comportement prvisible ;
topologie statique, comportement imprvisible ;
topologie dynamique, comportement imprvisible.
La dernire combinaison inclut les applications dployes sur les systmes mobiles ou P2P avec
lesquelles un noeud peut tout moment joindre ou quitter le systme. Cependant, le caractre
imprvisible de cette classe de systme, impose une surcharge supplmentaire au middleware afin
quil puisse maintenir un niveau acceptable les performances du systme.
26

2.5. Implmentation dun systme distribu avec un middleware

Structuration des composants des applications.

Les middlewares peuvent tre classs aussi en fonction des types dentits (composants) gres
ou en fonction de la structure des diffrents rles que jouent les composants.
Type de composants. Un middleware peut avoir sa charge plusieurs types dentits qui diffrent par leur dfinition, leur proprit et leur mode de communication. Suivant le type de lentit,
le rle du middleware peut varier. Le premier type dentit que lon peut avoir est le message.
Dans ce cas, le rle du middleware est de fournir aux applications la capacit denvoyer et de
recevoir des messages. Ce type de middleware est plus connu sous le nom Messaging-Oriented
Middleware (MOM) ou plus rcemment de Loosely Coupled Message Passing (LCMP). Un autre
type dentit que lon peut avoir est lobjet (de programmation oriente objet). Le middleware aura
comme tche de faire collaborer (communiquer) des objets qui se trouvent sur diffrentes platesformes. Comme exemple de middleware de ce type, nous pouvons citer entre autres CORBA,
J2EE, DCOM/DCOM+, ORB, etc. Un autre type dentit manipule peut tre une base de donnes, ce qui a donn naissance au middleware de base de donnes (Database Middleware). Ce type
de middleware donne le possibilit aux clients daccder des donnes htrognes et ce, quel que
soit le modle de donne ou le SGBD utilis. Ces middlewares sont souvent conus sous forme
dAPI comme ODBC, JDBC, etc.
Structure des composants. Les composants grs par un middleware peuvent jouer diffrents
rles comme celui de client (demandeur de service), ou celui de serveur (fournisseur de service),
celui dannonceur (diteur de service diffuser), ou celui dabonn (souscripteur une service).
Parfois, tous les composants peuvent tre au mme niveau et donc il est possible de trouver tous
les rles au sein dune seule entit, comme par exemple dans les systmes P2P.
Architecture des middlewares.
Les middlewares peuvent tre aussi catgoriss en sappuyant sur leur architecture. Il existe
deux types darchitectures : lune centralise et lautre distribue.
Architecture centralise. Avec larchitecture centralise, lensemble des modules du middleware sont stocks sur un seul site (machine). Cette approche est beaucoup plus facile mettre en
oeuvre mais elle facilite aussi la maintenance et lexploitation cohrente du systme. Cependant,
si le nombre de composants pris en compte devient important, cela peut induire une source de
contention et donc rduire les performances du systme.
Architecture distribue. Lapproche distribue rpartit les tches du middleware sur plusieurs
sites, ce qui donne la possibilit daccder au middleware de manire parallle. Ce type darchitecture est beaucoup plus tolrant aux pics de charges grce la rpartition des demandes sur les
diffrents composants rpartis du middleware. Cependant, la maintenance et la gestion cohrente
des entits du systmes deviennent beaucoup plus fastidieuse. En fait, les composants du middleware sont obligs de travailler de manire collaborative pour viter des incohrences. Ce qui ncessite lenvoi de messages ou le partage de structures de donnes et par consquent, des surcharges
supplmentaires. Une autre approche de la distribution dun middleware est davoir plusieurs instances du middleware qui sexcute sur plusieurs sites. Cette technique, outre la tolrance aux pics
de charges quelle offre, assure aussi une tolrance aux pannes. En fait, la duplication du middle27

Chapitre 2. Systmes rpartis grande chelle

ware sur plusieurs sites permet de masquer la panne de lune des instances du middleware ou du
site qui lhberge.

2.6

Modle darchitecture pour la gestion des donnes large

chelle

Notre objectif dans cette thse, est de proposer un modle de traitement des transactions dans
une base de donnes distribue sur un systme large chelle (grille ou P2P). Pour atteindre cet
objectif, il est ncessaire de concevoir une infrastructure qui tire profit autant des systmes P2P que
des grilles. Ce faisant, larchitecture propose doit tre auto-configurable et tolrante aux pannes
pour prendre en compte linstabilit, le caractre transitoire des composants (ou ressources) et les
pannes des systmes grande chelle limage des systmes P2P. Une telle infrastructure doit
permettre linteroprabilit entre les ressources du systme de manire compltement dcentralise. Par ailleurs, larchitecture du systme doit tre base sur une approche middleware qui ne
doit pas tre centralise pour assurer un bon niveau de transparence et dautonomie (surtout des
donnes), une haute disponibilit et une utilisation efficace des ressources du systme (minimiser
les surcharges et contrler laccs aux donnes). Dans la qute de lidal, des modules de contrle
de la scurit sont aussi envisager mais nous les ignorons dans cette thse qui tente dapporter
plutt des rponses sur les problmes lis aux pannes et aux surcharges.

28

Chapitre 3
Gestion des transactions dans les bases de
donnes rpliques
La rplication dans les bases de donnes a t largement tudie dans les trois dernires dcennies. Elle consiste en la gestion des copies stockes sur diffrents sites qui utilisent leur propre
SGBD autonome. Le dfi majeur des bases de donnes rpliques est le maintien de la conformit
des copies (cohrence mutuelle) lorsque les donnes sont mises jour. Dans le contexte des bases
de donnes les mises jour sont souvent encapsules dans des transactions. En dautres termes, la
base de donnes supporte les oprations regroupes sous forme de transactions plutt que lexcution indpendante des oprations les unes la suite des autres. Par ailleurs, les applications Web
2.0 utilisent souvent les transactions pour manipuler les donnes (lire, modifier, insrer). Cest
pourquoi la manire (quand et o) dont les transactions sont excutes sur les diffrentes copies
dune base de donnes rpliques peut avoir un impact sensible sur la cohrence des donnes et
les performances des applications. Par consquent, le modle de traitement des transactions doit
tre judicieusement choisi pour satisfaire les exigences des applications aussi bien en termes de cohrence que de performances. Les applications exigent en gnral comme performances un grand
dbit transactionnel, une latence faible, une disponibilit des donnes, un passage lchelle, une
utilisation efficiente des ressources, etc.
Cependant, il est connu de tous que les besoins de performances et de cohrence sont en opposition car le cot de maintien de la cohrence est un frein lexcution des traitements de lapplication. Par exemple, pour assurer une conformit des rpliques tout moment, il est ncessaire
de mettre jour toutes les rpliques au sein de la mme transaction. Ceci entrane le ralentissement des traitements puisquil faut attendre que tous les sites, quelque soit leur endroit et leur tat,
valident la transaction localement pour que les donnes redeviennent disponibles. Cet exemple
montre quil est indispensable de trouver un compromis entre la cohrence et les performances.
Malheureusement, ce compromis nest pas facile trouver et dpend surtout des besoins de lapplication considre. De fait, une application de type Web 2.0 qui requiert une forte disponibilit et
un passage lchelle exige ncessairement un relchement de la cohrence. Par contre, une application de gestion de stock destine un petit magasin a besoin dune cohrence plutt forte. Dans
cette thse, nos travaux se situent dans le contexte des applications Web 2.0 et donc le compromis
est pench vers le relchement de la cohrence pour un meilleur passage lchelle.
29

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

Lobjectif de ce chapitre est de donner quelques gnralits sur les transactions et leur gestion
dans une base de donnes rplique. Pour commencer, nous donnons quelques dfinitions et notions sur les transactions et sur les bases de donnes rpliques. Ensuite, nous tudions quelques
mthodes existantes pour grer les transactions dans les bases de donnes rpliques. Plus prcisment, nous tudions les solutions de gestion de transactions en privilgiant les quatre caractristiques des systmes distribus que nous avons mentionnes dans le premier chapitre savoir le
passage lchelle, la tolrance aux pannes (ou disponibilit), la transparence et lautonomie des
donnes. En dautres mots, nous ne nous intressons quaux approches proposes par certaines
solutions pour garantir ces quatre proprits. Ainsi, il faut noter quen ce qui concerne le passage
lchelle, il existe plusieurs principes qui permettent de lobtenir parmi lesquels nous avons choisi
de dtailler ceux utilisant la cohrence terme, ou la rplication partielle, ou le maintien de plusieurs versions des copies (Snapshot Isolation (SI)). Quant la gestion de la tolrance aux pannes,
deux approches seront tudies : les techniques de masquage des pannes avec la rplication active et les techniques bases sur la dtection et la rsolution des pannes. Enfin, pour aborder la
transparence et lautonomie, nous tudions les solutions de rplication bases sur des intergiciels,
qui permettent de cacher la distribution des donnes (rpartition et localisation des rpliques) mais
aussi lindisponibilit de certaines ressources. Les solutions tudies seront places dans notre
contexte afin de bien situer leurs limites mais aussi de bien comprendre les principes mettre en
uvre pour mieux satisfaire les applications large chelle.

3.1

Notions de transactions

Une transaction peut tre considre comme une unit de traitement cohrente et fiable. Une
transaction prend un tat dune base de donnes, effectue une ou des actions sur elle et gnre un
autre tat de celle-ci. Les actions effectues sont des oprations de lecture ou dcriture sur les
donnes de la base. Par consquent, une transaction peut tre dfinie comme tant une squence
doprations de lecture et dcriture sur une base de donnes, qui termine en tant soit valide
soit abandonne. Si la base de donne est cohrente au dbut de la transaction, alors elle doit rester
cohrente la fin de lexcution de la transaction bien que cette dernire peut sexcuter de manire
concurrente avec dautres ou quune panne survienne lors de son excution. Une base de donnes
est dite cohrente si elle est correcte du point de vue de lutilisateur, cest dire quelle maintient
les invariants de la base ou les contraintes dintgrit. La notion de cohrence recouvre plusieurs
dimensions comme dcrit dans [RC96]. Du point de vue des demandes daccs, il sagit de grer
lexcution concurrente de plusieurs transactions sans que les mises jour dune transaction ne
soient visibles avant sa validation, on parle de cohrence transactionnelle ou isolation. Du point de
vue des donnes rpliques, il consiste garantir que toutes les copies dune mme donne soient
identiques, on parle de cohrence mutuelle. La cohrence transactionnelle est assure travers
quatre proprits, rsumes sous le vocable ACID :
Atomicit : toutes les oprations de la transaction sont excutes ou aucune ne lest. Cest
la loi du tout ou rien. Latomicit peut tre compromise par une panne de programme, du
systme ou du matriel et plus gnralement par tout vnement susceptible dinterrompre
la transaction.
30

3.1. Notions de transactions

Cohrence : La cohrence signifie que la transaction doit tre correcte du point de vue
de lutilisateur, cest--dire maintenir les invariants de la base ou contraintes dintgrit.
Une transaction cohrente transforme une base de donnes cohrente en un base de donnes
cohrente. En cas de non succs, ltat cohrent initial des donnes doit tre restaur.
Isolation : elle assure quune transaction voit toujours un tat cohrent de la base de donnes.
Pour ce faire, les modifications effectues par une transaction ne peuvent tre visibles aux
transactions concurrentes quaprs leur validation. En outre, une transaction a une opration
marquant son dbut (begin transaction) et une autre indiquant sa fin (end transaction). Si la
transaction sest bien droule, la transaction est termine par une validation (commit). Dans
le cas contraire, la transaction est annule (rollback, abort).
Durabilit : une fois que la transaction est valide, ses modifications sont persistantes et ne
peuvent tre dfaites. En cas de panne de disque, la durabilit peut tre compromise.
Les proprits ACID sont trs difficiles maintenir car elles reprsentent un frein aux performances
du systme. Par exemple, latomicit cause un srieux problme quand lenvironnement est rparti
sur un systme large chelle puisque toutes les sites participant une transaction doivent valider
localement avant que la transaction ne soit valide globalement. Autrement dit, le maintien de la
cohrence exige que toutes les sites participants soient mises jour au sein de la mme transaction,
ce qui ralentit la validation. Pour des besoins de performances, certaines proprits ne sont pas parfois garanties dans loptique damliorer les performances du systme. En effet, les proprits C
et I peuvent tre relches au profit dun degr de concurrence plus lev et donc dun dbit transactionnel plus important. Les transactions peuvent tre classes suivant plusieurs critres [OV99].
Un des critres utilis est la nature des diffrentes oprations qui composent la transaction. Ainsi,
si une transaction contient au moins une opration qui effectue des modifications sur les donnes
de la base, la transaction est dite transaction dcriture ou de mise jour. Si toutes les oprations
ne font que des lectures sur les donnes de la base, la transaction est dite transaction de lecture.
Un autre classement peut tre fait partir de la dure de la transaction. Avec ce critre, une
transaction peut tre classe on-line ou batch [GR92, OV99]. Les transactions on-line, communment appeles transactions courtes, sont caractrises par un temps de rponse relativement court
(quelques secondes) et accdent une faible portion des donnes. Les applications qui utilisent
ce modle de transaction sont dnommes applications OLTP ( On-line Transactional Processing)
parmi lesquelles, nous avons les applications bancaires, de rservation de billets, de gestion de
stocks, etc. Les transactions batch, appeles transactions longues, peuvent prendre plus de temps
pour sexcuter (minutes, heures, jours) et manipulent une trs grande quantit des donnes. Les
applications utilisant ce type de transactions sont les applications dcisionnelles ou OLAP (On-line
Analytical Processing), de conception, de workflow, de traitement dimage, etc.
Dans cette thse nous nous focalisons sur les transactions de type OLTP, et nous allons tudier
leur traitement dans le contexte des bases de donnes distribues et rpliques dans la section
3.3. En plus, nous prcisons que nous prenons en compte aussi bien les transactions de lecture
que dcriture mais en mettant plus laccent sur les transactions dcritures qui sont des sources
dincohrences.
31

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

3.2

Bases de donnes rparties et rpliques

Dans cette partie, nous donnons quelques gnralits affrentes aux bases de donnes rparties
(distribues) et aux mcanismes de base de la rplication.

3.2.1

Objectifs et principes des bases de donnes rparties

Une base de donnes rpartie est une collection de sites connects par un rseau de communication.Chaque site est une base de donne centralise qui stocke une portion de la base de donnes.
Chaque donne est stocke exactement sur un seul site [BHG87]. La gestion dune base de donnes rpartie est gre de manire transparente par un SGBD rparti. Les transactions peuvent tre
envoyes sur chaque site puis traduites en transactions locales avant dtre routes sur les sites appropris (stockant une portion des donnes manipules). Les rsultats sont intgrs puis renvoys
aux applications clientes. Pour amliorer les performances, les donnes peuvent tre rpliques sur
plusieurs sites. La principale motivation de la rplication des donnes est laugmentation de la disponibilit. En stockant les donnes critiques sur plusieurs sites, la base de donnes distribue peut
fonctionner mme si certains sites tombent en panne. Un second avantage de la rplication consiste
lamlioration des temps de rponses des requtes grce la paralllisation des traitements et un
accs plus facile et rapide des donnes. Cependant, lintroduction de la rplication introduit un
nouveau problme car si une rplique est mise jour travers une transaction, toutes les autres
rpliques devraient ltre pour garantir la cohrence mutuelle, ce qui signifie que toutes les copies
sont identiques. Ce faisant, il est vident que plus le nombre de rpliques est grand, plus le cot du
maintien de la cohrence est important. Par consquent, il doit exister un compromis entre gestion
de la cohrence et les performances (passage lchelle, latence, ...). Ce compromis dpend surtout
des types dapplications conduisant plusieurs mcanismes de rplication que nous allons dcrire
trs brivement dans la prochaine section.

3.2.2

Mcanismes de rplication

La rplication a fait lobjet de plusieurs tudes dans le contexte des systmes distribus et aussi
dans les bases de donnes rpliques. La motivation principale est la disponibilit pour les systmes
distribus et la performance (paralllisme) pour les bases de donnes. Dans [Gan06], lauteur prsente la gestion de la rplication suivant plusieurs dimensions. Pour des soucis de prsentation,
nous regroupons les dimensions dcrites dans [Gan06] en quatre concepts savoir la distribution
ou placement des donnes, la configuration (rle) des rpliques, la stratgie de la propagation des
mises jour et enfin la stratgie de maintien de la cohrence.
Placement des donnes. Les donnes peuvent tre rpliques partiellement ou totalement.
La rplication totale stocke entirement la base de donnes sur chaque site. La rplication
partielle ncessite une partition des donnes en fragments. Chaque fragment est stock par la
suite sur plusieurs noeuds. Lavantage de la rplication partielle est quelle permet de rduire
de manire significative les accs concurrents aux donnes. En outre, le cot de la mise
jour des copies est moins important que dans le cas de la rplication totale compte tenu de la
32

3.2. Bases de donnes rparties et rpliques

faible portion des donnes sollicite par les oprations de mises jour.
Configuration des rpliques. Les mises jour peuvent tre effectues sur une seule rplique
(appele matre) avant dtre propages vers les autres (esclaves). Une telle configuration
est appele mono-matre (primary copy) car les autres rpliques ne sont utilises que pour
les requtes de lecture seule, ce qui amliore les performances des oprations de lecture
seule. Lavantage dune telle approche est quelle facilite la gestion de la cohrence globale
du systme (cohrence mutuelle) puisque toutes les mises jour sont effectues sur une
seule copie. Cependant, cet avantage est contradictoire avec le passage lchelle et avec la
disponibilit qui ncessitent que plusieurs copies soient utilises en mme temps pour faire
face une charge applicative dcritures trs importante et variable. Une approche multimatre (update anywhere), dans laquelle les mises jour peuvent tre excutes sur nimporte
quelle rplique, permet damliorer aussi bien les performances des transactions de lecture
seule que dcriture. Linconvnient de cette approche est quelle requiert des mcanismes
de contrle de concurrence distribus plus complexes pour garantir la cohrence mutuelle.
La configuration mono-matre profite plus aux applications de type OLAP avec lesquelles
les donnes de production (sujettes des modifications) doivent tre spares des donnes
danalyse (milliers doprations de lecture seule). Par contre les applications OLTP tirent
plus de bnfices de lapproche multi-matre et particulirement quand le nombre de mises
jour est trs important et provient de diverses sources (utilisateurs). Il existe beaucoup de
produits commerciaux qui offrent des solutions de rplication mono-matre ou multi-matre.
Pour les architectures mono-matre, nous pouvons citer de manire non-exhaustive Microsoft SQL Server replication, Oracle Streams, Sybase replication Server, MySQL replication,
IBM DB2 DataPropagator, GoldenGate TDM platform, et Veritas Volume Replicator. Alors
que les exemples de solutions multi-matre incluent Continuent uni/Cluster, Xkoto Gridscale,
MySql Cluster, DB2 Integrated Cluster.
Stratgies de rafrachissement (propagation). Elles dfinissent comment la propagation va
tre effectue en prcisant le contenu propager, le modle de communication utilis, linitiateur et le moment du dclenchement. Le rafrachissement est fait grce une transaction
appele transaction de rafrachissement dont le contenu peut tre les donnes modifies (writesets en anglais) ou le code de la transaction initiale [EGA08, Gan06]. La caractristique
principale dune transaction de rafrachissement est quelle est dj excute sur au moins
une rplique. La propagation de la transaction par la r-excution de celle-ci sur toutes les
rpliques, ne garantit pas toujours le mme rsultat sur chaque site si des instructions SQL
contextuelles comme RANDOM ou LIMIT ou plus simplement SYSDATE sont utilises
dans la requte [EGA08]. La propagation des donnes modifies requiert la rcupration de
celles-ci, ce qui est souvent trs coteux (triggers, log sniffing, comparaison de snapshot,
etc.) et donc peut impacter les performances du systme. Nanmoins, la propagation des
donnes modifies vite de rejouer une transaction qui a ncessit beaucoup de calcul avant
de produire un rsultat et ne dpend pas du contexte. La propagation peut tre initie par le
noeud qui a excut une premire fois les mises jour, on parle de PUSH (pousser). Elle

33

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

peut tre aussi initie par les noeuds recevant les mises jour, cest lapproche PULL (tirer).
Quant la communication, elle peut se faire de point point, ou par communication de
groupe (multicast, broadcast), de manire pidmique, etc. Cependant, le modle de communication est fortement tributaire du type de systme. Par exemple lutilisation du multicast
dans un rseau P2P rduit le nombre de messages mais nest pas toujours faisable cause du
caractre dynamique du systme.
Enfin, le dclenchement peut se faire ds la rception ou lexcution dune nouvelle transaction (immdiat), priodiquement, quand une rplique est obsolte, quand un noeud est peu
charg, la demande, etc. Comme nous allons le montrer dans le prochain chapitre, le moment du dclenchement joue un rle capital dans les performances du systme (cohrence
mutuelle, surcharge du rseau, ...). Le dclenchement la demande ou quand un noeud est
moins charg permet de rduire la surcharge du rseau en regroupant plusieurs mises jour
mais a linconvnient de laisser diverger les copies.
Maintien de la cohrence. La cohrence peut tre gre de manire stricte (rplication
synchrone) ou relche (rplication asynchrone) [GHOS96]. Avec la rplication synchrone,
toutes les rpliques sont mises jour lintrieur de la transaction. Cette approche a lavantage de garder toutes les copies cohrentes chaque instant, mais ncessite que toutes les
rpliques soient disponibles et synchronises au moment de lexcution de la transaction
(ROWA pour Read-One/ Write-All). Une amlioration de cette approche est de synchroniser
uniquement les rpliques disponibles au moment de lexcution dune transaction (ROWAA
pour Read-One/ Write-All-Available). Pour des systmes large chelle, de telles approches
entraneraient des retards dans la validation des transactions puisque la communication nest
pas toujours stable. Par consquent et comme il a t dmontr dans [GHOS96], cette solution ne passe pas gnralement lchelle.
La rplication asynchrone est plus souple car une transaction est dabord valide sur une
seule rplique avant dtre propage sur les autres rpliques dans une autre transaction. Linconvnient de cette approche est que les copies peuvent diverger. Cette divergence a pour
impact de retourner aux utilisateurs des rsultats faux (par exemple lachat dune place de
cinma qui nexiste pas) ou de faire varier les invariants (les rgles de gestion) du systme
(par exemple crditer un compte qui nest pas encore cr).
Cependant, il est possible de laisser volontairement les copies diverger dans loptique damliorer les performances du systme. En effet, il est possible deffectuer des transactions de
lectures sur des copies pas ncessairement fraches pour acclrer lexcution des transactions de lecture [GNPV07, LG06, LGV04, RBSS02]. Nanmoins, lobsolescence des copies
doit tre contrle en fonction des exigences des applications [GNPV07]. Lobsolescence
peut tre dfinie de diffrentes manires [LGV04]. Dans cette thse, nous considrons une
seule mesure savoir le nombre de transactions de mise jour manquantes. Prcisment,
lobsolescence dune rplique Ri sur un site sj est gale au nombre de transactions de mise
jour modifiant Ri sur un site quelconque mais non encore propage sur sj . Lobsolescence
tolre dune transaction de lecture est donc, pour chaque objet de la base lue par la transaction, le nombre de transactions qui ne sont pas encore excutes sur le site traitant la

34

3.3. Gestion des transactions dans les bases de donnes rpliques

transaction. Lobsolescence tolre reflte le niveau de fracheur requis par une transaction
de lecture pour sexcuter sur un site. Par exemple, si une transaction de lecture requiert des
donnes parfaitement fraches, alors lobsolescence tolre est zro. Pour des raisons de cohrence, les transactions de mise jour ainsi que celles de rafrachissement doivent lire des
donnes parfaitement fraches.
Par ailleurs, on peut classer la rplication asynchrone en deux familles : rplication optimiste
et rplication pessimiste. Avec la rplication pessimiste, les transactions sont ordonnes a
priori avant dtre envoyes sur les rpliques en respectant leurs contraintes conflictuelles.
Lordonnancement a priori ne permet pas un contrle daccs concurrent trs fin, car deux
transactions peuvent apparatre conflictuelles sans pour autant ltre rellement. La rplication asynchrone optimiste autorise lexcution de plusieurs transactions simultanment sur
plusieurs sites. Au moment de la validation globale (maintien de la cohrence mutuelle), on
vrifie les conflits et les rsoud. La rsolution peut se faire par abandon de certaines transactions ou par r-excution des transactions. Si les donnes sont bien partitionnes, les conflits
sont moins frquents et donc lutilisation de la rplication optimiste devient bnfique car le
dbit transactionnel est fortement augment.

3.3

Gestion des transactions dans les bases de donnes rpliques

Les proprits ACID dune transaction doivent tre garanties aussi bien dans le cadre dun
systme centralis que celui dun systme distribu. Lobjectif des transactions est de pouvoir assurer la cohrence de la base, mme en prsence de mises jour. Cependant dans le contexte des
bases de donnes, nous pouvons identifier deux types de cohrences prendre en compte. Tout
dabord une cohrence transactionnelle qui consiste garantir la cohrence smantique (validit
des contraintes dintgrit) dune copie de la base aprs lexcution dune transaction. Puis, une
cohrence mutuelle qui assure la conformit de toutes les copies de la base aprs lexcution de la
transaction. La gestion de la cohrence mutuelle dfinie quand et comment les modifications dune
transaction sont crites sur lensemble des copies. Comme nous lavons dj soulign dans le chapitre prcdent, si les modifications sont crites sur lensemble des copies avant que la transaction
ne soit valide, la rplication est dite synchrone, autrement, elle est dite asynchrone. Il est noter
que parfois les critures dune transaction ne sont pas appliques sur toutes les rpliques mais elles
y sont envoyes dans le seul but dassurer la cohrence globale (vrifier sil ny a pas de conflit
compromettant la cohrence) avant de valider la transaction. Une telle approche bien quelle soit
considre comme synchrone est moins stricte et favorise des temps de rponses beaucoup plus
bas. Lavantage et linconvnient dune approche dpendent de la stabilit de lenvironnement, de
sa composition et surtout des attentes des applications. Plusieurs dizaines de travaux ont abord le
problme de la gestion des transactions dans les bases de donnes rpliques en privilgiant lune
ou lautre approche en fonction des applications cibles.
Dans la suite de ce chapitre, nous allons dcrire les solutions de gestion de transactions les plus
connexes nos travaux et ce, suivant les quatre caractristiques des systmes distribus que nous
35

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

avons mentionnes dans le premier chapitre : passage lchelle, tolrance aux pannes, transparence des donnes et autonomie des applications et des donnes. Nous mentionnons galement que
dans cette thse, nous ne nous occupons pas de la gestion des contraintes dintgrit.

3.3.1

Gestion des transactions et passage lchelle en taille

Pour faire face aux besoins des nouvelles applications qui grent plusieurs millions dutilisateurs, il faut des techniques de gestion de transactions efficaces pour garder au bon niveau les
performances du systme en cas de fortes charges. Cela est dautant plus vrai que dans [GHOS96],
les auteurs ont montr que les techniques usuelles de gestion de transactions ne passent pas
lchelle si lenvironnement est dynamique.
La rplication a t introduite dans les bases de donnes pour rsoudre le problme de passage
lchelle. Malheureusement plusieurs solutions narrivent pas atteindre une large chelle cause
de deux limitations. Premirement, la plupart des approches adopte une rplication totale o chaque
site stocke intgralement la base de donnes. Par consquent, la synchronisation des rpliques
pour garantir la cohrence mutuelle entrane une surcharge supplmentaire trs importante qui
namliore gure les performances du systme partir dun certain degr de rplication [GSN09,
BGRS00]. Deuximement, les protocoles de rplication utilises sont synchrones et sappuient
souvent sur le critre de cohrence 1-copy-serializability. Dans la thorie de la srialisabilit, un
systme rpliqu est dit 1-copy-serializable si lexcution des transactions dans le systme rpliqu
est quivalent une excution srielle sur une seule copie de la base. Ce critre de cohrence exige
que toutes les copies soient synchronises avant de valider une mise jour. Ceci limite le degr de
concurrence et par consquent le passage lchelle. Pour repousser ces limites, de nouvelles solutions de rplication ont t proposes [BGRS00, BKR+ 99, CMZ05, HSAA03, PMS99, ATS+ 05,
LKMPJP05, RBSS02, PA04, JEAIMGdMFDM08, SPMJPK07, MN09, PA04, GNPV07, BFG+ 08,
LM09, ATS+ 05, PST+ 97, PCVO05, LFVM09, FDMBGJM+ 09, APV07, SSP10, ACZ03]. Lun
des principaux objectifs de ces nouvelles approches est dliminer le contraignant critre de 1copy-serializability. Pour ce faire, la solution la plus utilise est de retarder lapplication des critures dune transaction vers toutes les rpliques mais aussi de diminuer le volume des donnes
propager. En effet, le rsultat est envoy au client ds que la transaction est valide sur une des
rpliques mais avant que toutes les rpliques restantes nappliquent les critures (donnes modifies).
Pour garantir la cohrence, une premire solution est la rplication synchrone et consiste coordonner toutes les rpliques au moment de la validation dune transaction. Ce type de coordination
permet de sassurer quil ny a pas dincohrences mais aussi dobtenir des temps de rponses
faibles puisque la transaction nest crite que sur une seule rplique. Une possible cl de vote de
cette solution est, dune part, le maintien de plusieurs versions dune mme copie (Snapshot Isolation) [BBG+ 95, PGS97, DS06, CRF09, LKJP+ 09, LKMPJP05, MN09, PA04, FDMBGJM+ 09]
et dautre part, lutilisation de modles de communication par groupe [PGS03, HAA99, KA00b,
SR96, WK05] pour synchroniser les rpliques.
Une autre solution consiste excuter une transaction et la valider sans faire de coordination
entre toutes les rpliques au moment de la validation ni au moment de lexcution (rplication asynchrone). Cette solution utilise des techniques dordonnancement afin de dfinir lordre dexcution
36

3.3. Gestion des transactions dans les bases de donnes rpliques

des transactions. Une transaction est excute puis valide sur une seule rplique puis les modifications sont propages plus tard. En cas dabsence de nouvelles transactions de mises jour, le
systme converge vers un mme tat, on parle de cohrence terme. Parmi les solutions sappuyant
sur cette technique, figurent [GNPV07, BGL+ 06, BFG+ 08, LM09, ATS+ 05, PST+ 97, Vog09].
Une autre solution est de minimiser le nombre de rpliques synchroniser en fragmentant les
donnes (rplication partielle) [JEAIMGdMFDM08, SPMJPK07, PCVO05, SOMP01, HAA02,
PCVO05, LFVM09]. Avec la rplication partielle, la surcharge due aux propagations des mises
jour diminue car les sites ne stockent quune partie de la base de donnes. En fait, si un site ne
stocke pas la partie de la base de donnes modifie par une transaction, il nest pas concern ni par
le protocole de validation ni par la propagation des modifications.
Dans la suite de cette section, nous allons dcrire quelques travaux sappuyant sur le Snapshot
Isolation (SI) ou la cohrence terme pour grer la cohrence mutuelle entre les copies. Puis, nous
dcrivons quelques travaux sur la rplication partielle.
Passage lchelle avec Snapshot Isolation
Lune des proprits les plus importantes du SI est que les oprations de lecture seule ne sont
pas en conflit avec les oprations dcriture. Par consquent les oprations de lecture ne sont jamais
bloques, ce qui augmente le degr de concurrence et amliore les performances du systme et particulirement pour les transactions de lecture seule. Dans la spcification classique du SI dcrite
dans [BBG+ 95], une transaction obtient une estampille de dmarrage (ED) quand elle commence
son excution. Cette estampille indique la dernire version de la base de donnes (snapshot) vue
par la transaction. Toutes les oprations de lecture sont faites sur le snapshot associ la transaction. En fait, le snapshot associ une transaction reflte toutes les mises jour valides avant le
dbut de celle-ci. Quand une transaction met jour les donnes, elle produit une nouvelle version
qui ne sera correcte (ou cohrente) quau moment de la validation. Cependant, il faut remarquer
quune transaction peut lire tout moment ses propres modifications avant mme leur validation.
Au moment de valider une transaction, une seconde estampille dite estampille finale (EF ) lui est
associe. Les estampilles accordes au dbut et la fin dune transaction permettent de dcider si
elle peut valider ou annuler ses modifications. En effet, une transaction T valide ses critures (ou
modifications) sil nexiste aucune autre transaction T modifiant la mme donne et dont lestampille finale est comprise entre les deux estampilles (ED et EF ) de T. Cet algorithme de validation
appele rgle du "First-Committer-Wins (FCW)" signifie que deux transactions concurrentes qui
modifient les mmes donnes ne peuvent pas valider toutes les deux la fois. En pratique, la
plupart des implmentations du SI utilisent le verrouillage lors des oprations de modifications
pour empcher quune transaction crive sur une donne qui est dj modifie par une transaction
concurrente. La premire transaction qui a le verrou sur une donne est autorise la modifier : si
la transaction valide et relche le verrou, toute autre transaction qui tait en attente du verrou est
annule. Cette approche connue sous le nom de "First-Updater-Wins" produit les mmes effets que
la rgle FCW du point de vue des histoires dexcutions permises. Lalgorithme de SI est implment par les SGBDR Oracle, PostgreSQL, SQL Server 2005, Interbase 4 et Oracle Berkley DB. Il
vite les problmes connus de pertes dcritures et de lectures sales et introduit des amliorations
considrables par rapport au protocole de 2PL et notamment le Strict-2PL en augmentant le dbit
37

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

transactionnel. Cependant, comme mentionn dans [BBG+ 95], SI ne garantit pas que toutes les
excutions soient srialisables (au sens des conflits). De plus, il peut entraner la violation de certaines contraintes dintgrit par lentrelacement des transactions concurrentes. Ce problme plus
connu sous le nom de write skew [BBG+ 95, CRF09] est illustr dans lexemple suivant.
Exemple. Supposons lexcution concurrentielle de deux transactions T1 et T2 retirant de largent partir de deux comptes bancaires C1 et C2 . Les deux comptes sont lies par la contrainte
C1 + C2 > 0. Voici un entrelacement qui peut tre obtenu avec SI :
r1 (C1 = 50)r1 (C2 = 50)r2 (C1 = 50)r2 (C2 = 50)w1 (C1 = 20)w2 (C2 = 30)c1c2
Au dmarrage des deux transactions, tous les deux comptes ont chacun comme solde 50 euros et
tout moment, chaque transaction isole, maintient la contrainte C1 + C2 > 0 : quand T1 valide
il calcule la contrainte C1 + C2 = 20 + 50 = 30 et quand T2 valide il calcule C1 + C2 =
30 + 50 = 20. Pourtant les rsultats de lentrelacement produisent C1 + C2 = 50, ce qui viole
la contrainte. Ce problme dcoule du fait que seuls les conflits "criture-criture" sont considrs
et par consquent si deux transactions accdent en mme temps deux donnes et que chacune
des transactions ne modifie quune donne de manire disjointe, alors toutes les deux transactions
seront valides.
Regardons en dtail les consquences dun tel problme sur une base de donnes rplique
asynchrone. Comme T1 et T2 ne sont pas en conflit "criture-criture" sous le protocole SI, leur
modification peut donc tre valide dans lordre T1 suit T2 sur un site s1 mais avec lordre inverse
sur un autre site s2 . Ainsi, si une troisime transaction T3 lit le contenu des comptes C1 et C2
sur le site s1 obtient une version de la base de donnes non quivalente celle quelle aurait
eu si elle avait consult le site s2 . Ce problme ne survient jamais avec un systme centralis
utilisant le SI car soit T1 suit T2 soit linverse mais pas les deux la fois. Pour assurer la cohrence
mutuelle avec lutilisation de SI et viter ce problme dans les systmes asynchrone distribus
et rpliqus, les transactions doivent tre excutes dans le mme ordre sur tous les sites [DS06,
LKMPJP05, PA04, EZP05, SPMJPK07, WK05]. Ces approches tentent damliorer le degr de
concurrence, conformment lide de base du SI [BBG+ 95], dans un environnement rpliqu ou
chaque rplique utilise localement le SI comme protocole de contrle de concurrence.
Dans [LKMPJP05], les auteurs prsentent une solution de rplication base sur le SI, appel 1copy-snapshot-isolation, pour garantir la cohrence mutuelle dans les bases de donnes rpliques.
La solution conue sappuie sur un intergiciel et, limage de Postgres-R(SI) [WK05] et de Pangea [MN09], est implmente avec le SGBD relationnel PosgresSQL pour prouver sa faisabilit.
Lobjectif principal de cette solution est de permettre lexcution des transactions (lecture seule et
criture) sur nimporte quelle rplique sans savoir au pralable les donnes sollicites par la transaction. En effet, cette approche assure le contrle de concurrence deux niveaux : chaque SGBD
sous-jacent assure le SI, et un protocole appel SI-Rep dtecte les conflits entre les transactions
sexcutant sur diffrentes rpliques. Au dessus de chaque SGBD, une rplique de lintergiciel est
installe et permet la coopration avec les autres rpliques. La communication ou coopration des
intergiciels se fait via une communication par groupe. Lexcution dune transaction T requiert
plusieurs tapes. Tout dabord, T est excute sur une rplique locale. A la fin de lexcution, les
38

3.3. Gestion des transactions dans les bases de donnes rpliques

tuples modifis par T sont extraits sous forme de writesets. Lextraction des writesets est un mcanisme standard utilis par plusieurs produits commerciaux et implmente via des triggers ou
du log-sniffing [SJPPMK06]. Bien que les solutions commerciales extraient les writesets uniquement aprs la validation dune transaction, une extraction avant validation est utilise de manire
similaire aux travaux de [PA04]. Aprs rcupration des writesets, SI-Rep vrifie si il ny as pas de
conflit "criture-criture" entre T et les autres transactions excutes sur dautres rpliques et qui
sont dj valides. Si aucun conflit nest dtect alors T est valide au niveau de la rplique locale
et les writesets sont appliques de manire asynchrone sur les rpliques distantes. Si par contre il y
a un conflit, T est annule localement. Le critre de cohrence sur lequel sappuie ces travaux est
le 1-copy-SI. Ce critre signifie que lexcution de plusieurs transactions sur diffrentes rpliques
produit le mme rsultat quune excution sur un systme centralis utilisant SI comme protocole
de contrle concurrence. Un systme de bases de donnes rpliques assure le critre de 1-copy-SI
si deux conditions sont garanties :
lexcution des transactions suit lapproche ROWA : soit une transaction est valide sur
toutes les rpliques soit aucune ne lest ; par contre les transactions de lecture seule sont
toujours valides sur une seule rplique.
Soit W Slk et RSlk reprsentant respectivement les writesets et readsets (donnes lues) de Tl
sur une rplique S k , alors pour toute paire de transactions Ti et Tj :
i) si W Sik W Sjk 6= : lordre dans lequel Ti et Tj sont valides est identique lordre
produit par un systme centralis utilisant SI ;
ii) si W Sik RSjk 6= : si Ti valide avant le dbut de Tj alors, (1) Tj doit forcment lire les
critures de Ti , (2) cette relation entre Ti et Tj est quivalente celle produit par un systme
centralis utilisant SI.
Pour assurer la deuxime condition du critre de 1-copy-SI, les transactions sont envoyes vers
toutes les rpliques par multicast en utilisant des primitives de communication par groupe. Avec
ces primitives, les transactions sont envoyes dans un ordre total et traites dans cet ordre sur tous
les sites. Il est remarquer que cette approche et comme celle prsente dans [WK05] peuvent tre
considres comme synchrone car les writesets sont envoys toutes les autres rpliques avant que
la transaction ne soit valide.
Les solutions bases sur le SI offrent de bonnes performances en rduisant le temps de synchronisation entre les rpliques tout en maintenant un niveau de cohrence lev. Ces solutions ne
prennent pas en compte les conflits "lecture-criture", ce qui diminue le nombre de transactions
annules mais aussi la taille des donnes (donnes lues non incluses) envoyer aux rpliques pour
valider une transaction. Cependant, lutilisation des communications par groupe pour assurer un
ordonnancement total des transactions sur les diffrentes rpliques ne fonctionne que pour des rseaux latence faible et stable (Cluster, LAN). Dans des systmes o la latence est non ngligeable
et lenvironnement est dynamique (grille, P2P, ...), la coordination entre les rpliques ncessite plus
de temps et par consquent augmente le temps de rponse. Pour des applications de type Web2.0
qui sont conues sur des architectures large chelle avec des rseaux WAN, utiliser les mcanismes de rplication SI ne semble pas tre une solution adapte pour assurer le passage lchelle
cause de la dynamicit et de la faible latence de lenvironnement.
39

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

Passage lchelle avec la cohrence terme

La cohrence terme [Vog09] est un niveau de cohrence faible qui stipule que les diffrentes
rpliques peuvent diverger pendant une priode mais convergent terme vers un mme tat en labsence de nouvelles transactions entrantes. Ainsi, une squence daccs sur les diffrentes rpliques
ne retourne pas ncessairement la version la plus jour. La cohrence terme est de plus en plus
utilise dans les nouvelles solutions pour faire face aux besoins des applications web notamment
dans les cloud. Parmi les solutions ddies aux clouds et qui utilisent une cohrence terme, nous
pouvons citer Cassandra [LM09] et Amazon S3 [BFG+ 08]. Cependant, ces solutions du cloud qui
commencent merger ne sappuient pas sur les traditionnels SGBD et ncessitent de nouvelles
manires de concevoir les SGBD et les applications, ce qui les loignent un peu de notre contexte.
Pour rappel, notre objectif dans cette thse est de sappuyer les SGBDs existants pour concevoir
une solution de traitement de transactions large chelle.
Des approches qui utilisent les SGBDs classiques pour assurer le traitement des transactions
sont dcrites dans [DS06, PA04, RBSS02]. Dans ces approches, une rplication asynchrone avec
une configuration matre-esclave est utilise. En plus, il y a une sparation des transactions de lecture seule des transactions dcriture. Prcisment, les transactions de mises jour sont excutes
sur le site primaire alors que les transactions de lecture seule sont envoyes sur les sites secondaires. Les modifications faites par les transactions de mises jour sont propages vers les autres
rpliques travers des transactions de rafrachissement. Une transaction de rafrachissement est
utilise pour propager les transactions de mise jour sur les autres rpliques.
En plus, pour garantir la cohrence globale, les transactions de rafrachissement doivent tre
appliques dans un ordre compatible lexcution des transactions dcriture correspondantes sur
le site primaire. De manire plus prcise, si deux transactions T 1 et T 2 produisent respectivement
les transactions de rafrachissement R1 et R2, alors si T 1 valide avant T 2 sur le site primaire,
donc sur nimporte quel site secondaire R1 prcde R2. Pour atteindre ce but, une liste FIFO des
transactions valides est utilise dans [DS06] afin denvoyer les transactions de rafrachissement
conformment lordre obtenu sur le site primaire. Cependant pour acclrer lapplication des
transactions de rafrachissement sur les sites secondaires, la base de donnes locale les excute
simultanment en associant un thread chaque transaction de rafrachissement mais en veillant
ce que les critures faites par une transactions soient visibles toutes celles qui la suivent dans
la file FIFO. Les travaux mens dans [DS06] assurent aussi la cohrence globale par session. En
dautres mots, si un client envoie une premire transaction de modification, Tm , puis une autre de
lecture seule, Tl , alors cette dernire accdera la copie des donnes incluant la modification faite
par T m. Cette proprit nest pas garantie par toutes les solutions de rplication bases sur le SI
notamment [FLO+ 05].
Cependant, lutilisation dune architecture matre-esclave ne facilite pas le passage lchelle
car : i) le site matre devient trs rapidement une source de congestion si le nombre de mises
jour augmente, ii) si le nombre de noeuds esclave est important, la synchronisation entre matre
et esclaves handicape la disponibilit du noeud matre traiter de nouvelle requtes entrantes. Les
solutions proposes pour les clouds requirent souvent des data centres qui ncessitent des mcanismes de maintenance trs coteux. Pour remdier ces limites, nous envisageons de concevoir
des solutions multi-matres tout en assurant la cohrence terme. Notre solution sintgre aux tra40

3.3. Gestion des transactions dans les bases de donnes rpliques

ditionnels SGBDs existants et donc ne requiert aucune modification de leur conception ni de celles
des applications qui les utilisent.
Par ailleurs la divergence (obsolescence) introduite par lutilisation de la cohrence terme,
permet de minimiser les synchronisations entre rpliques et donc amliore significativement les
performances si la divergence est contrle [GN95]. De plus, dans le contexte du web2.0, de nombreuses applications tolrent une cohrence relche et acceptent de lire des donnes qui ne sont
pas ncessairement les plus rcentes ; cela ouvre la voie vers de nouvelles solutions offrant de
meilleures performances en termes de dbit transactionnel, latence, disponibilit des donnes et
passage lchelle. Par exemple, il est possible de grer des transactions de vente aux enchres
(sur eBay ou Google Adsense) sans ncessairement accder la dernire proposition de prix,
puisque lenchre est sous pli cachet, autrement dit, on lit les quelques informations relatives
au produit sans lire la dernire proposition de prix fait sur ce produit. Lapplication doit pouvoir
spcifier la limite de divergence tolre ainsi que la nature de cette divergence en fonction de sa
smantique. Le systme doit quant lui garantir que cette limite est respecte. Diffrents modles
de divergence ont t proposs dans la littrature [GN95, LGV04]. Pour dfinir a divergence, on
peut utiliser des mesures temporelles, numriques, par version, mixte, etc. [Pap05]. De plus, la
nature de la divergence tolre doit tre fonction de lapplication. Les approches de contrle besteffort [PA04, LKMPJP05, PMS99] permettent de minimiser la divergence temporaire des donnes
mais ne tirent pas profit de la divergence autorise, et ne garantissent pas non plus quelle reste
borne. Le projet MTCache [GLRG04] borne la divergence mais a linconvnient de ncessiter la
modification du gestionnaire de transactions. De plus, il ne prend en compte que la mesure temporelle. Nanmoins, les algorithmes proposs ncessitent de modifier le gestionnaire de transaction,
par exemple en tendant les verrous avec des compteurs [Pu91, WYP97, YV00]. Le contrle de
la divergence de certaines mesures (mesure numrique) ncessite un mcanisme de dtection des
conflits la granularit fine. Nanmoins, la seule mthode exacte et non intrusive (indpendante)
pour le gestionnaire de transaction est lanalyse de journal, rpute lourde. Dans cette thse, nous
utilisons des techniques non intrusives pour contrler la divergence tout en se passant des techniques danalyse de journal. En dfinissant la divergence dune rplique comme tant le nombre
de transactions manquantes sur cette rplique, nous utilisons le catalogue rparti qui stocke des
informations pour calculer tout moment la divergence.
Passage lchelle avec rplication partielle
La rplication totale dune base de donnes passe mal lchelle puisque toutes les mises jour
doivent tre appliques sur tous les sites [JPMPAK03], et quune augmentation du nombre de sites
ne fait quaugmenter la surcharge du systme. Dans ce contexte, la rplication partielle a plus de
sens et consiste diviser la base de donnes en plusieurs portions et rpliquer chaque portion dans
un sous-ensemble des sites du systme [SOMP01, JEAIMGdMFDM08, HAA02, SSP10]. Lun des
gains viss par la rplication partielle est la rduction de la taille des donnes propager vers les
rpliques pour vrifier les conflits. Ce gain est dune utilit capitale si le nombre de rpliques est
trs lev puisque la surcharge du systme est tributaire de la quantit des informations envoyer et
du nombre de sites destinataires. Par ailleurs, avec les applications Web 2.0, les utilisateurs ne modifient quune faible portion de leur donnes personnelles. Ce faisant, mme si le nombre dutilisa41

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

teurs est de lordre de centaines de millions, les accs aux donnes sont disjoints et par consquent
une rpartition des donnes augmente le degr de concurrence et diminue le temps de rponse. Par
consquent, le systme passe plus facilement lchelle. Dans [HAA02], les auteurs proposent un
algorithme de rplication partielle dans un environnement WAN. Chaque donne a un ou plusieurs
sites permanents qui en stockent une copie. Le protocole de rplication utilise une communication
multicast pidmique pour propager les logs des bases donnes. Les logs (readsets et writesets)
utiliss pour ordonner les transactions sont envoys sur lensemble des sites indpendamment du
fait quils stockent ou non les donnes modifies. La diffrence principale de cette approche par
rapport leur protocole de rplication totale prsent dans [HAA00] est quun site napplique les
modifications que pour les donnes quils stockent. Ceci constitue un problme car envoyer des
logs des sites qui ne stockent pas les donnes modifies nest quune source de surcharge de
trop, surtout si le nombre de site est lev. Par contre dans [SOMP01], les logs ne sont envoys
quaux sites stockant une portion des donnes sollicites par la transaction. Bien que cela rduit la
surcharge note dans les travaux de [HAA02], il demeure que lutilisation du critre de cohrence
de 1-copy-serializability sur laquelle se base lapproche rend la solution impraticable dans les systmes environnement dynamique ou latence faible. Dans [SPMJPK07, JEAIMGdMFDM08]
le protocole de rplication partielle utilis sappuie sur le SI. Par consquent, seules les donnes
modifies (writsets) sont envoyes pour dtecter les conflits au moment de la validation, ce qui
rduit le nombre de transactions annules. Si les donnes sollicites par une requte se trouvent
sur un seul site alors la transaction peut tre excute sur ce site. Par contre, si les donnes sont
rparties sur plusieurs sites, alors la transaction doit tre distribue tout en prservant la cohrence
mutuelle. Bien que la plupart des travaux sur la rplication partielle suppose quune transaction ne
sexcute que sur un seul site, la solution prsente dans [SPMJPK07] tudie par contre le cas des
transactions distribues.
Lobjectif des auteurs de [SPMJPK07] est dassurer la cohrence globale pour les transactions
distribues bien quaucun site nait une connaissance globale du systme. Pour ce faire, un coordinateur est choisi pour chaque transaction et correspond au site qui stocke au moins quelques unes
des donnes requises par les premires oprations de la transaction. Si le coordinateur stocke toutes
les donnes sollicites, il excute la totalit des oprations et valide la transaction. Autrement, il
envoie les oprations restantes aux sites contenant les donnes non disponibles sur le coordinateur.
Si un site reoit des oprations excuter, il envoie aprs excution les rsultats et les writesets
au coordinateur qui peut alors initialiser la phase de validation. Lors de la phase de validation, le
coordinateur envoie par multicast les writesets et lestampillage de la transaction qui lui est attribue son dmarrage. Ainsi toutes les rpliques peuvent valider la transaction en sappuyant sur
lestampille de la transaction et les conflits "criture-criture". Linconvnient de cette approche
est quil est bloquant car si un site ne renvoie pas sa rponse (rsultats et les writesets) pour une
quelconque raison (panne, latence faible, site charg, ...), la transaction ne peut pas tre valide. En
outre, lenvoie des writesets toutes les rpliques est quasi-identique une rplication totale avec
laquelle les transactions de mises jour ne contiennent pas beaucoup doprations de lecture.
Dans [JEAIMGdMFDM08], lapproche aborde la gestion des transactions distribues dans le
mme sens que dans [SPMJPK07]. Lune de leurs diffrences est que dans [JEAIMGdMFDM08],
le coordinateur (site matre de la transaction) transmet les oprations qui touchent des donnes
42

3.3. Gestion des transactions dans les bases de donnes rpliques

stockes dans dautres sites en envoyant, souvent, les writesets des oprations dj faites sur le
coordinateur. Ceci sexplique par le fait quune opration Oj envoye sur un site distant peut avoir
besoin des critures de Oi effectue sur le coordinateur. En outre, quand une opration Oj avec ses
writesets sont reus par un site secondaire Sk , toutes les transactions locales sur Sk sont annules
pour appliquer les writesets de Oj puis lexcuter. Ensuite, les writesets de Oj sont envoys au
coordinateur qui peut valider la transaction si toutes les oprations distantes ont russi. Tant que la
transaction nest pas valide par le coordinateur, aucune autre opration dcriture nest permise
sur Sk . Cependant, lopration Oj peut tre aussi bloque par des transactions globales en phase
de certification sur Sk et dans ce cas elle sera mise en attente. Outre le fait que ce protocole est
bloquant, lannulation des transactions peut avoir un impact trs ngatif sur le systme : i) une
transaction locale ayant dj fait toutes ses oprations est reprise mme sil ne lui reste que la
validation, ii) lannulation des transactions locales augmente la charge dun site, le rendant du
coup moins disponible pour traiter et participer la validation des transactions globales.
P-Store[SSP10] est une solution de rplication partielle pour des donnes de type "cl-valeur"
stockes sur un WAN. Lors de lexcution dune transaction seuls les sites contenant une copies
des donnes lues et/ou modifies sont synchroniss. Ceci rduit considrablement la charge de
certains nuds qui peuvent ds lors excuter en parallle dautres transactions, ce qui augmente le
passage lchelle. Une transaction globale (qui sollicite des donnes stockes sur plusieurs sites)
T , est pilote par un coordinateur appele Proxy(T). Les oprations de lecture dune transaction
sont excutes de manire optimiste et la validation le Proxy initie une phase de certification
pour assurer le critre de 1-copy-serializability. Lun des inconvnients de cette solution est quil
se base sur le critre de 1-copy-serializability et par consquent les transactions de lecture seule
sont bloques par les transactions dcriture ds quelles ne sont pas locales. En outre, la notion de
transaction dcrite nest pas identique la notion de transaction dans les bases de donnes puisque
les oprations sont trs simplistes et consistent accder une donne via sa cl. En dautres
termes, les transactions autorises sont des transactions bases sur la cl : il nest pas possible de
faire des transactions qui utilisent la valeur (ou un attribut de la valeur) comme prdicat ni de faire
des requtes par intervalle.
En conclusion, lobjectif de la rplication partielle est de rduire les situations de conflits (pour
diminuer les reprises de transactions) et donc de traiter plus de requtes de manire parallle.
Une bonne solution est dviter des mcanismes dexcution de transaction bloquants qui gnrent
souvent des annulations et donc plusieurs reprises. Certes, faire lhypothse que le partitionnement
des donnes peut tre parfait tel point quune transaction puisse se tenir sur une seule partition
est trs irraliste. Cependant, les solutions proposes pour faire face ce problme sont bloquantes
et ne sloignent pas du principe du 2-PC avec des aller-retours entre master (coordinateur) et
sites distants (participants). En outre, le partitionnement des donnes doit permettre de minimiser
le temps de synchronisation par rduction de la taille des donnes mais aussi du nombre de sites
synchroniser. De ce fait, les solutions qui coordonnent toutes les rpliques lors des phases de
validation mme si ces dernires ne stockent pas les donnes manipules sloignent de cet objectif.
Par consquent, pour un meilleur passage lchelle avec lutilisation de la rplication partielle,
il faut envisager des solutions non bloquantes et qui ncessitent une faible synchronisation des
rpliques lors de lexcution des transactions.
43

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

3.3.2

Gestion des transactions et disponibilit

La gestion des transactions dans les bases de donnes rpliques ncessite la prise en compte
de la disponibilit des rpliques pour assurer une cohrence mutuelle. En effet, il y a plusieurs
motivations qui encouragent la gestion de la disponibilit dans les bases de donnes rpliques. La
premire raison est de pouvoir borner le temps de rponse de la transaction : si elle est envoye
sur un site qui tombe en panne avant sa validation, il faut pouvoir continuer le traitement de la
transaction sur une autre rplique afin de pouvoir rpondre aux clients dans des dlais acceptables.
Une deuxime raison est quavec des systmes trs volatiles (connexion et dconnexion frquentes
des rpliques), il est important de grer lindisponibilit de certaines ressources afin de minimiser
la dgradation des performances en cas de prsence de pannes. Une autre raison est de maintenir les
copies identiques sur toutes les rpliques : si une copie est indisponible lors dune synchronisation,
il faut son retour lui envoyer toutes les modifications quelle na pas pu recevoir durant son
absence. Cependant, il est remarquer que lintroduction de modules pour grer la disponibilit
entrane des surcharges dans le systme et rduit donc le dbit transactionnel. Par consquent, des
compromis doivent tre trouvs pour viter de trop surcharger le systme et de grer efficacement
lindisponibilit des rpliques pouvant compromettre la cohrence du systme.
Dans le cadre des bases de donnes rpliques deux cas peuvent affecter la disponibilit du
systme savoir les dconnexions prvues et celles intempestives appeles souvent pannes. Les
dconnexions prvues causent moins de problmes car elles sont connues lavance et prises en
compte dans le processus de traitement en cours. Par contre, les dconnexions intempestives survenant lors dun processus de traitement, peuvent occasionner de srieux problmes de cohrence.
Cest pour cela quelles ont attir une attention toute particulire dans les rcents travaux sur la
rplication [PA04, ADM06, Sch90, VBLM07, AT89, JPMPAK03, PRS07, BHG87, PMJPKA05,
APV07]. Une des premires approches utilises pour grer les pannes est de les masquer ou de
les rendre transparentes vis--vis du client. Pour ce faire, le noeud effectuant les mises jour envoie une transaction toutes les rpliques. Les rpliques excutent la transaction simultanment
et envoient les rsultats (ou acquittements des copies mises jour) au noeud. Ce dernier attend
soit la premire rponse dune rplique soit une majorit de rponses identiques (quorum) avant
de dcider de terminer lexcution de la transaction. Cette approche de traitement des mises jour
plus connue sous le nom de rplication active ou state-machine approach [GS97, Sch90] et parfois
sous le nom dalgorithme base de quorum [Gif79, JPMPAK03, VS05] cache au client loccurrence dune panne dune rplique durant lexcution dune transaction. Le principal problme de
cette approche est quelle rduit les performances du systme car un instant donn, toutes les
rpliques excutent la mme transaction, ce qui rduit sensiblement le degr de concurrence. En
outre pour envoyer une transaction toutes les rpliques, il est ncessaire de les connatre toutes et
de pouvoir les localiser.
Cette technique de masquage est galement utilise dans [PRS07] o tous les noeuds stockant
une mme portion des donnes sont regroups dans une mme cellule. Un rseau logique structur
est construit aux dessus des cellules formes. Chaque cellule est un groupe de machines physiques
dynamiquement paramtr et utilise le state-machine approach dcrite dans [Sch90, Sch93]. Ce
faisant, si un noeud au sein dune cellule tombe en panne, celle-ci est masque. Par contre, cette
solution fait lhypothse quune cellule entire ne peut tomber en panne et si plusieurs noeuds
44

3.3. Gestion des transactions dans les bases de donnes rpliques

dune mme cellule tombent en panne simultanment, cette dernire sauto-dtruit et les donnes
sont redistribues sur les cellules voisines. Ainsi, la panne de certains noeuds dans une cellule
entrane la dconnexion des membres du groupe sur lesquels on pouvait faire recours pour une
meilleure disponibilit. Outre son cot, la redistribution des donnes sur les cellules voisines peut
les rendre plus charges et donc rduire leur performance.
Une deuxime solution pour grer les pannes consiste les dtecter dabord et les rsoudre
aprs. Avec cette technique, il est beaucoup plus difficile de rendre la panne transparente car sa
dtection avant sa rsolution introduit une latence. Plusieurs mcanismes de dtection de pannes
ont t proposs [CT96, LAF99, ACT99]. Ces mcanismes sont soit bass sur des changes priodiques de messages de vie [ACT99], soit sur des allers retours "ping/pong" [DGM02]. Avec la
premire technique, chaque noeud envoie priodiquement un message de vie tous les noeuds et
attend, son tour, un message de vie de chacun deux chaque priode. Linconvnient majeur
de cette technique est le modle de communication "tous-vers-tous" qui engendre beaucoup de
messages quand le nombre de sites est important. La deuxime mthode permet une dtection plus
cible car elle permet de ne surveiller quun sous-ensemble de noeuds. Cette deuxime approche
est beaucoup plus adapte dans les systmes large chelle qui contiennent des milliers de noeuds
qui ne se connaissent pas tous.
Une fois la panne dtecte, il faut lidentifier pour savoir quels mcanismes utiliser afin de la
grer. Il existe plusieurs types de pannes classes en gnral en trois catgories :
Panne franche ou crash (fail-stop) : cette dfaillance entrane larrt total du composant.
Avant cette panne le processus a un comportement normal et partir de celle-ci, le processus
cesse dfinitivement toute activit.
Panne transitoire ou ommission (omission failure) : avec cette panne, le composant cesse
momentanment son activit puis la reprend normalement.
Panne byzantine (byzantine failure) : ce type de panne entrane le systme dans un comportement imprvisible. Ce type de panne reprsente lintgralit des comportements possibles.
Tout systme qui tolre les pannes byzantines peut tolrer tout autre type de pannes.
Dans le contexte des systmes rpliques, beaucoup de travaux ont t proposs pour faire face
aux pannes de type fail-stop [PA04, BHG87, MN09, LKMPJP05, LKJP+ 09, PRS07, PMJPKA05,
APV07, CPW07, SSP10] mais aussi de type byzantine [VBLM07, CL02, CVL10]. En gnral les
solutions proposes pour faire face aux pannes byzantines ncessitent une synchronisation de plusieurs rpliques avant la validation de toute transaction. Malheureusement cette synchronisation
est quasi-impossible raliser dans le cas dun systme grande chelle ou gnre une surcharge
en termes de messages trs important. Cest la raison pour laquelle la plus part des travaux effectus dans le domaine des bases de donnes rpliques se concentrent plus sur les pannes de
type fail-stop. Par exemple dans Ganymed [PA04], Middle-R [PMJPKA05] et Pangea [MN09],
les auteurs dcrivent des solutions de gestion de pannes trs simples bases sur une architecture
matre-esclave. En fait si le noeud matre (coordonnateur des mises jour) tombe en panne, un
noeud secondaire est choisi pour le remplacer. Il faut remarquer quavec Middle-R il nexiste
pas un seul noeud matre qui coordonne toutes les transactions mais plutt un noeud matre pour
chaque classe de conflit. Dans Pangea, les clients sont invits renvoyer au nouveau matre toutes
les transactions qui nont pas t valides avant larrive du crash. Il faut noter que loccurrence
45

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

dune panne ne peut pas compromettre la durabilit des transactions car le protocole de rplication
est totalement synchrone. Cependant avec Ganymed, le protocole utilis est asynchrone et donc
outre le fait dlire un nouveau site matre, il faut garantir que toutes les transactions qui ont valid avant le crash soient prennes. Pour ce faire, un client ne peut recevoir la notification de la
validation dune transaction que si les writesets ont t dj appliqus sur un certain nombre de
rpliques. Ce retard de notification de la fin dune transaction augmente le temps de rponse. Quant
lapproche de Middle-R, si le noeud matre dune classe de conflit tombe en panne, le premier
noeud sur la vue (liste des noeuds actifs et connects) est lu matre et est charg de continuer
toutes les transactions non encore valides. La liste des transactions non valides est connue par le
nouveau matre car chaque fois quune transaction est envoye un noeud, celui ci lenvoie par
multicast tous les autres membres du groupe de la classe de conflits. Cependant, dans tous les
deux systmes (Pangea et Ganymed), si un noeud secondaire tombe en panne celui-ci est ignor
jusqu lintervention manuelle de ladministrateur tandis que Middle-R le supprime simplement
de la liste des noeuds actifs et qui peuvent recevoir des messages. Par consquent, la panne de
plusieurs noeuds secondaires dans une courte priode pousse le noeud matre devenir une source
de congestion mais aussi de panne totale du systme.

UMS/KTS [APV07] aborde la gestion de versions des donnes dans des systmes pair--pair
structurs reposant sur une table de hachage distribue. La cohrence mutuelle est garantie laide
dun service destampillage, tolrant aux pannes, qui permet de retrouver efficacement la version
courante dune rplique. A chaque cl est associ un noeud charg de grer lestampillage de la
donne associe cette cl. A chaque fois que le noeud responsable de lestampillage tombe en
panne, un autre noeud est choisi pour le remplacer. Cependant la disponibilit des noeuds stockant les donnes nest pas tudie, ainsi une incohrence peut se produire si un noeud stockant la
dernire version dune donne quitte le systme avant davoir propag sa donne.

En conclusion, plusieurs solutions sont proposes pour faire face aux pannes dans les systmes
distribus. Certaines ne permettent pas de passer lchelle, en loccurrence la rplication active
ou state-machine approach, car introduisant des surcharges qui ralentissent le fonctionnement du
systme. Dautres proposent des solutions avec un modle matre-esclave (rplication passive) tout
en sintressant essentiellement la panne du noeud matre. Linconvnient de cette seconde solution est quelle ncessite une dtection au pralable de la panne du noeud matre puis suivie dune
lection dun nouveau matre. Cette phase de transition peut ncessiter un temps considrable, surtout dans les systmes large chelle et hlas elle est souvent ignore. En plus, comme la panne
des noeuds secondaires nest pas prise en compte, le noeud matre devient trs rapidement une
source de congestion, ce qui limite les performances du systme en cas de forte dynamicit. Pour
une meilleure prise en compte des pannes dans les systmes distribus large chelle, il faut sassurer de deux choses : i) la dtection des pannes doit tre peu coteuse en termes de messages : il
faut pour cela utiliser des techniques de dtection cible et en fonction du type de noeud surveill ;
ii) la dtection doit se faire dans les meilleurs dlais, et pour tout type de noeud dfaillant, afin de
pouvoir donner une suite positive toute transaction qui se trouvait sur ce noeud en panne.
46

3.3. Gestion des transactions dans les bases de donnes rpliques

3.3.3

Gestion transparente des transactions avec transparence et autonomie

Lapproche la plus classique pour implmenter la rplication est de lintgrer au coeur du

SGBD [BKR+ 99, KA00a, BHG87, HSAA03, SSP10]. Cependant, cette approche prsente quelques
limites et compromet lautonomie des bases de donnes. Premirement, elle ncessite un accs
aux codes sources du SGBD, ce qui signifie que seuls les propritaires des produits commerciaux
peuvent lutiliser. Deuximement, elle est fortement couple avec les autres modules du SGBD,
crant du coup une interdpendance avre des composants du mme produit, ce qui ne facilite pas
les maintenances et les volutions du protocole de rplication. Enfin, cette absence de transparence
entrane le client interroger plus frquemment certaines rpliques au dtriment dautres, ce qui
ne facilite pas une meilleure exploitation des ressources notamment lquilibrage des charges.
En outre, nous avons mentionn dans le chapitre prcdent que la transparence permet de cacher aux utilisateurs les dtails techniques et organisationnels dun systme distribu ou complexe.
Lintrt vis est de faire bnficier aux applications dune multitude de services sans avoir besoin
de connatre exactement la localisation ou les dtails techniques des ressources qui les fournissent.
Dans le cas dune base de donnes rplique, il sagit essentiellement de cacher la distribution
des donnes (rpartition et localisation des rpliques) mais aussi lindisponibilit de certaines ressources. Cette transparence a pour gain : i) de mieux exploiter les rpliques disponibles en faisant
une bonne rpartition des charges, ii) dans le cas o les transactions de lecture seule acceptent
des donnes obsoltes, il devient plus simple de les router vers les noeuds pouvant satisfaire leur
exigence afin de rserver les rpliques totalement jour pour les transactions demandant une forte
cohrence.
Pour assurer cette transparence de la rplication, des solutions bases sur des intergiciels ont t
largement tudies dans les dernires annes [GNPV07, CPW07, PMJPKA05, CMZ05, LKMPJP05,
ACZ03, PA04, PCVO05, RBSS02, MN09]. Avec cette approche, linterface utilisateur (ou client)
du SGBD est utilise pour faire la mdiation entre applications et bases de donnes. Ce faisant, les
protocoles de rplication peuvent tre modifis sans impacter le SGBD, ce qui garantit lautonomie des SGBD. De plus, le client na plus besoin de connatre la localisation et/ou rpartition des
donnes dont la connaissance est confie lintergiciel. Lintergiciel garde le niveau de cohrence
de chaque rplique (la fracheur de chaque rplique) afin de pouvoir router toute transaction sur la
rplique satisfaisant ses exigences de fracheur. Par ailleurs si le SGBD est rparti, cette approche
permet une meilleure exploitation des ressources disponibles et donc un quilibrage de charge de
bonne qualit.
Sprint [CPW07] est un intergiciel offrant de hautes performances et une haute disponibilit
pour un SGBD en mmoire et rpliqu. Sprint dissocie trois types de noeuds logique : i) Edge
Server (ES) qui joue le rle dinterface entre le client et le reste du systme ; ii) Data Server (DS)
qui stocke une base de donnes en mmoire et excute les transactions sans accs au disque dur ;
iii) Durability Server (XS) qui assure la durabilit des transactions et la reprise aprs panne. Une
transaction est envoye par un client un serveur ES qui se charge de lenvoyer sur le ou les DSs qui
stockent les portions de donnes requises, ce qui garantit une transparence totale vis--vis du client.
Si la transaction est en lecture seule, elle est valide sans aucun problme par le serveur ES qui se
charge de son excution. Par contre, quand il sagit dune transaction de modification, le serveur
ES coordonne la validation en contactant tous les serveurs DS qui ont particip lexcution de
47

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

la transaction. En effet, tout serveur DS qui est prt valider envoie par multicast son vote au
serveur ES, tous les serveur DS participant la transaction et tous les serveurs XS pour assurer
la durabilit. Si tous les serveurs DS votent "commit", la transaction est valide autrement elle
est annule. Pour garantir que les toutes transactions sexcutent dans le mme ordre sur tous les
serveurs, une communication par groupe dordre total (total order multicast) est utilise. Si les
pannes ne sont pas frquentes ou si les noeuds logiques se trouvent dans un mme rseau, cette
approche garantit de bonne performances en termes de temps de rponse. Par contre en cas de
panne ou dun environnement en grande chelle ces performances ne sont plus garanties cause
des pannes frquentes ou des latences du rseau faible (occasionne des suspicions de pannes) qui
entrane lannulation et la reprise de plusieurs transactions. De plus, lautonomie des SGBD est
compromise car le protocole de validation ncessite la mise en ouvre de protocole de terminaison
sur chaque participant afin de garantir lordre total.
FAS [RBSS02] est un intergiciel de rplication mono-matre et asynchrone. Il prend en compte
la fracheur des SGBD afin de garantir que les exigences de fracheur dune requte soient satisfaites. Il transmet les transactions sur le SGBD matre, et les requtes de lecture sur le nud
le moins charg. La synchronisation des rpliques est diffre priodiquement. FAS tant monomatre, cela ne permet pas de supporter une charge transactionnelle croissante. De plus si aucun
SGBD nest suffisamment frais pour traiter une requte, celle-ci est mise en attente, ce qui peut
provoquer la surcharge dun SGBD au moment o il devient disponible pour traiter les requtes en
attente. Dans ce cas prcis, la synchronisation anticipe des rpliques aurait t bnfique. Il faut
remarquer aussi que lapproche de FAS est quasi-similaire celle de Ganymed [PA04] en dehors
du fait que cette dernire utilise un modle de communication par groupe pour garantir le 1-copy-SI
dcrit prcdemment.
C-JDBC [CMZ05] est un intergiciel de rplication grant un cluster de SGBD. Etant conu
comme un pilote JDBC, il permet lutilisateur de traiter des transactions de manire transparente.
La stratgie de routage est simple et efficace : chaque requte de lecture seule est envoye un
SGBD diffrent tour de rle, chaque transaction est diffuse tous les SGBD. La cohrence
des rpliques nest pas garantie car la premire rplique ayant fini de traiter une transaction est
dsigne pour servir de rfrence sans tenir compte des autres rpliques. Ainsi, cette solution est
restreinte un environnement stable.
Leg@net [GNPV07] est une solution de rplication multi-matres pour le routage de transactions dans un cluster de bases de donnes. Leg@net relche autant que possible la fracheur des
donnes, dans les limites acceptes par les requtes. Cela rduit le surcot de synchronisation
des rpliques et permet ainsi dallouer davantage de ressources au traitement des transactions.
Leg@net cible les applications transactionnelles dont lautonomie doit tre prserve. Toutefois,
cette solution manque de passage lchelle car lintergiciel est centralis.
Certes, le liste des travaux cits dans cette section nest pas exhaustive mais elle reflte la quasitotalit des approches de gestion des transactions dans une base de donnes rplique travers un
intergiciel. La plupart des approches ne passent pas souvent lchelle pour plusieurs raisons parmi
lesquelles, nous pouvons citer :
lutilisation de communication par groupe pour synchroniser les rpliques [PMJPKA05,
MN09] : cette technique ncessite un environnement stable comme les clusters ou les LAN ;
48

3.4. Discussion

une configuration mono-matre ou une architecture centralise qui ne supporte pas une charge
transactionnelle croissante et en mme temps constitue une source de pannes.
une cohrence trs forte qui exige que toutes les rpliques soient synchronises (ou bloques) pour le traitement dune transaction de mise jour. En plus, chaque transaction requiert toutes les modifications des transactions conflictuelles qui la prcdent, ce qui empche lexcution simultane ou en parallle de plusieurs transactions ;
Les applications comme celle du Web 2.0 requirent une forte disponibilit et des performances
trs importantes pour des raisons conomiques. En effet ces applications sont entretenues grce
largent obtenu partir des sponsors et des publicits qui se font rares ds que le systme est trop
souvent indisponible. Ainsi pour satisfaire les besoins de telles applications il faut une gestion des
transactions efficaces et par consquent des intergiciels dcentraliss pour mieux absorber la charge
applicatives. Cette dcentralisation permet lintergiciel dtre trs disponible et dassurer un accs
rapide et pas ncessairement cohrent aux donnes, tout en exploitant au mieux lensemble des
ressources.

3.4

Discussion

Nous avons tudi dans les trois sections prcdentes la gestion des transactions dans une base
de donnes rpliques en privilgiant trois dimensions savoir le passage lchelle, la disponibilit et enfin la transparence. Nous avons prsent quelques solutions existantes et leurs limites
qui empchent leur rutilisation dans un environnement trs grande chelle. Nous rcapitulons
prsent dans cette section les choix que nous avons jugs judicieux pour repousser les limites des
solutions existantes afin de mieux prendre en compte les besoins des applications Web 2.0.

3.4.1

Modle de rplication pour les bases de donnes large chelle

Le choix dun modle de rplication exige la prise en compte de plusieurs paramtres ou dimensions qui dpendent essentiellement des applications vises. Comme dcrit par le thorme
CAP (Consistency-Availability, Performance) [Bre00], il est impossible dassurer la fois la cohrence, la disponibilit et la performance dans un systme distribu. Par consquent, pour satisfaire
les besoins des applications de type Web2.0 qui gnrent un workload avec lectures intensives,
nous avons prfr la disponibilit et la performance. Pour la simple raison que le relchement
de la cohrence est souvent tolr par les applications que nous ciblons et permet davoir un bon
passage lchelle [FJB09, GL02], le modle de rplication que nous voulons mettre en oeuvre
sappuie sur les principes suivants :
une configuration multi-matre qui donne la possibilit de rpartir aussi bien les oprations
de lecture que les oprations dcriture sur lensemble des rpliques, ce qui permet une paralllisation des traitements. En plus, cela permet dviter la surcharge de certaines ressources
au dtriment dautres, ce qui aboutit un meilleur quilibrage des charges ;
une rplication asynchrone pour viter de synchroniser toutes les rpliques lors des mises
jour, mais aussi pour rduire le temps de rponse des transactions. Entre la validation dune
transaction sur une rplique et la propagation de ses rsultats sur les autres rpliques, il peut
49

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

y avoir une divergence entre les copies. Cette divergence copies est tolre (ou introduite
dlibrment) pour amliorer les performances des oprations de lecture. Cependant, elle
doit tre toujours contrle ou borne en fonction du niveau de cohrence exig par les
applications ;
les utilisateurs des applications Web2.0 modifient en gnral une faible portion de leurs
propres donnes. Ainsi, une rplication partielle permettra davoir un grain daccs aux donnes beaucoup plus fin et par consquent, amliore le degr de concurrence.
la propagation des mises jour se fait exclusivement entre deux sites, celui qui envoie et celui
que reoit. La plupart du temps, elle est initialise pour rendre cohrente une rplique qui
doit traiter une nouvelle requte ou valider une transaction. Si la propagation est initialise
pour valider ou non une transaction, les datasets (ensemble des donnes lues par la ou les
transactions propager) sont envoys. Autrement, la propagation par envoi du code des
mises jour est utilise pour viter de surcharger le rseau. Nous supposons aussi quune
transaction ne contient pas de clauses SQL (e.g LIMIT, RANDOM, ...) qui ne reproduisent
pas le mme rsultat quelque soit la rplique sur laquelle elle est excute [EGA08]. En
dautres termes, cette hypothse permet de garantir que lexcution dune transaction sur
deux rpliques identiques donne le mme rsultat. Par ailleurs quand il sagit de valider une
transaction, lapproche PULL sera utilise par la rplique qui veut valider une transaction.
Dans le cas contraire cest lapproche PUSH qui est utilis et en gnral sous le contrle
dun TM.
la gestion de la rplication via un intergiciel permet de faire moins de modifications sur les
bases de donnes mais aussi de mieux contrler les ressources disponibles.

3.4.2

Modle de middleware pour les bases de donnes distribues et rpliques

Ltude des middleware a permis de bien comprendre leurs caractristiques mais aussi leurs
avantages. La fonction essentielle du middleware est dassurer la mdiation entre les parties dune
application, ou entre applications elles mme. Par consquent, les considrations architecturales
tiennent une place centrale dans la conception du middleware [Kra09]. Larchitecture couvre lorganisation, la structure densemble, et les schmas de communication, aussi bien pour les applications que pour les composants du middleware. Dans le contexte dun systme de bases donnes
distribues, le problme soulev est soit la persistance (conservation long terme et procdures
daccs) soit la gestion des transactions (maintien de la cohrence pour laccs concurrent aux
donnes en prsence de dfaillances ventuelles). Si la base de donnes est rplique, le maintien
de la cohrence se traduit le plus souvent par la gestion de la convergence des rpliques, dnomme cohrence mutuelle. Ce faisant, une rpartition de la base de donnes dans un environnement
large chelle, caractris par un nombre important de noeuds (clients et serveurs de donnes) et
une volatilit avre du systme, requiert un middleware redondant par duplication des instances.
La premire raison de ce choix est que la charge applicative intercepte peut tre rpartie sur les
diffrentes instances du middleware. La seconde raison dcoule du fait que les sources de congestion sont moins frquentes et le passage lchelle peut tre donc obtenu plus facilement. Une
50

3.4. Discussion

dernire raison et non la moindre est que la duplication confre une disponibilit du middleware
ou une tolrance aux pannes beaucoup plus importante.
Il est noter aussi que le modle de communication utilis pour linteraction entre les composants et le middleware doit tre le moins contraignant possible. De ce fait, un mode de communication asynchrone est beaucoup plus adapt car dans les systmes distribus tels que les rseaux
P2P, le caractre htrogne des ressources et les connexions/dconnexions frquentes des noeuds
rendent impossible toute tentative de borner la transmission des messages.
Le chapitre prochain dcrit en profondeur larchitecture que nous avons propose pour le traitement des transactions large chelle.

51

Chapitre 3. Gestion des transactions dans les bases de donnes rpliques

52

Chapitre 4
Architecture dun Systme de Routage des
Transactions
Le traitement des transactions dans une base de donnes rpartie est fortement li au modle
de rplication utilis. Dans le chapitre prcdent, nous avons argument notre choix dutiliser un
modle de rplication multi-matre asynchrone. Avec ce modle, la base de donne est rplique
sur plusieurs nuds et une transaction peut tre excute sur chaque nud, appel nud initial
pour cette transaction. Les mises jour de la transaction sont envoyes vers les autres rpliques
aprs validation. Le principal problme avec la rplication multi-matre asynchrone est dassurer
la cohrence mutuelle des rpliques mme en prsence de transactions concurrentes.
Nous proposons dans ce chapitre une architecture pour grer les transactions excutes dans
une base de donnes rplique destine aux applications Web 2.0. Larchitecture doit tre structure de telle sorte que la disponibilit, la transparence et le passage lchelle soient garantis. Notre
architecture peut tre divise en deux parties : une partie assurant le service de mdiation entre les
diffrents composants du systme (intergiciel) et une autre charge de la gestion des mtadonnes
qui sont les donnes ncessaires au fonctionnement du systme en entier. Avant de dcrire larchitecture de notre systme nous prsentons dabord quelques dfinitions et concepts indispensable
la comprhension de notre approche.

4.1

Modle et concepts

Dans cette section, nous dfinissons les gnralits et concepts sur les quelles sont dfinis notre
approche. Nous dcrivons dabord les concepts relatifs au modle de rplication et de transactions.
Puis, nous prsentons les principes gnraux sur lordonnancement des transactions.

4.1.1

Modle de transactions et de donnes

Nous considrons une base de donnes unique partiellement rplique sur m nuds de donnes
ND1 , ..., NDm . Les donnes sont partitionnes dans n relations R1 , ..., Rn et une copie locale
de Ri sur un nud NDj est note par Rji et gre par le SGBD local. Nous supposons que le
53

Chapitre 4. Architecture dun Systme de Routage des Transactions

partitionnement des donnes est fait de tel sorte quune transaction peut tre excute entirement
sur un seul nud, les transactions rparties sont exclues de cette tude. Nous utilisons un modle de
rplication asynchrone multi-matre. Chaque ND peut tre mis jour par une transaction entrante
et est appel ensuite le nud initial de cette transaction. Les autres ND sont mis jour plus tard
par propagation de la transaction. Nous distinguons trois types de transactions :
Dfinition 1. Transaction de mise jour
Une transaction de mise jour est une squence dinstructions lecture/criture dont au moins une
dentre elles modifie la base de donnes ;
Dfinition 2. Transaction de rafrachissement
Une transaction de rafrachissement est utilise pour propager les transactions de mise jour sur
les autres ND. En dautres mots, elle r-excute une transaction de mise jour ou applique les
modifications faites par cette dernire sur un ND autre que le ND initial.
Pour distinguer les transactions de rafrachissement des transactions de mise jour, on mmorise dans le catalogue rparti, pour chaque ND, les transactions dj routes sur ce ND ;
Dfinition 3. Requte
Une requte effectue une lecture sans mettre jour de la base de donnes. Ainsi, il nest pas
ncessaire de la propager.
Par ailleurs, chaque transaction (mise jour, rafrachissement, requte) lit un certain nombre
de relations. Nous dissocions les donnes supposes tre modifies par une transaction de celles
rellement modifies.
Dfinition 4. Relations potentiellement accdes par une transaction
Nous dfinissons par Rel(T ), les relations quune transaction T planifie daccder durant son excution. Nous avons Rel(T ) = {RelR (T ), RelW (T )}, avec RelR (T ) (resp. RelW (T )) les relations
que T a lintention de lire (resp. modifier).
Notons que Rel(T ) peut tre obtenu en parsant le code.
Dfinition 5. DataSet
Lensemble des tuples quune transaction T a rellement accd durant son excution est appel
DataSet(T ). Ainsi, nous avons DataSet(T ) = {ReadSet(T ), W riteSet(T )},
avec ReadSet(T ) (resp. W riteSet(T )) lensemble des tuples que la transaction T a rellement
lu (resp. modifi).
Rel(T ) est connu au moment o T est soumise pour routage et est obtenu par analyse de code
de la transaction.
Les requtes peuvent accder des donnes obsoltes dont lobsolescence est contrle par les
applications. Cette obsolescence introduite permet daccrotre le dbit et le temps de rponse des
requtes et elle peut tre mesure de diffrentes manires (i.e. mesure boolenne, mesure numrique, mesure de version, mesure temporelle, etc) [LGV04, Pap05]. Dans cette thse, nous mesurons lobsolescence en utilisant le nombre de transactions de mise jour manquantes.
54

4.1. Modle et concepts

Dfinition 6. Obsolescence
Lobsolescence de Rji est gale au nombre de transactions de mise jour modifiant Ri sur un ND
quelconque mais non encore propage sur le nud N Dj .
Le concept dobsolescence est associ souvent au concept de fracheur. La fracheur dune
rplique NDj correspond loppos de son obsolescence. La fracheur est donc maximale (ou
parfaite) si lobsolescence vaut zro, autrement dit, NDj est totalement frais par rapport Ri sil a
reu toutes les mises jour faites sur Ri .
Lobsolescence tolre dune requte est donc, pour chaque relation lue par la requte, le
nombre de transactions qui ne sont pas encore excutes sur le nud traitant la requte. Lobsolescence tolre reflte le niveau de fracheur requis par une requte pour sexcuter sur un ND.
Pour des raisons de cohrence, les transactions de mise jour ainsi que celles de rafrachissement
doivent lire des donnes parfaitement fraches : elles sont excutes toujours sur des nuds totalement frais. Notons alors que nous garantissons la cohrence terme qui peut tre dfinie comme
suit :
Dfinition 7. Cohrence terme
La cohrence terme permet que les diffrentes rpliques dune base de donnes peuvent diverger pendant une priode mais convergent terme vers un mme tat en labsence de nouvelles
transactions entrantes.
Ainsi, une squence de transactions de lectures les diffrentes rpliques ne retourne pas ncessairement la version la plus jour.
Nous calculons lobsolescence de la copie dune relation Rji en nous appuyant sur ltat global
du systme stock dans le catalogue rparti, qui donne des informations dtailles sur les transactions courantes ou dj excutes.
Bien que nous utilisons le modle de donnes relationnelle pour dcrire notre approche, nous
mentionnons que notre solution est aussi applicable pour les autres modles de donnes sur lesquelles les oprations dcriture ou de lecture sont faites travers un programme.

4.1.2

Ordre de prcdence des transactions

Nous nous plaons dans un contexte de transactions plates, sans sous-transactions imbriques,
et non distribues. Une transaction peut tre traite en totalit sur un seul nud. Soit T , une transaction de mise jour ou de lecture seule (requte), nous distinguons les tats dans lesquels T peut
se trouver :
E NTRANTE : T vient darriver dans le systme mais na commenc son excution sur aucun
nud ND. Une date de dbut, debut(T ) est affecte T par le GT qui la reu et on suppose
que chaque transaction arrive une date diffrente. Chaque transaction a son identifiant compos du numro du client (NA) qui la envoy et dun numro de squence local maintenu
au niveau du client. Une transaction dans cet tat est dite transaction entrante.
C OURANTE : T a commenc son excution sur un ND. Ses effets ventuels ne sont pas
encore persistants. Toute transaction dans cet tat est appele transaction courante.
55

Chapitre 4. Architecture dun Systme de Routage des Transactions

VALIDE : T est excute et valide au moins sur le nud NDi . Ses effets sont visibles
sur N Di et peuvent ltre aussi sur les nuds ND restants en fonction des exigences des
transactions entrantes. Autrement, si T 0 exige des donnes totalement fraches, alors quelque
soit le ND, les effets de T seront visibles. La date laquelle une T est valide est appele
f in(T ).
T ERMINE : T passe ltat global si elle est propage sur tous les ND du systme. Ses
effets sont visibles sur nimporte quel nud.
Une transaction valide ou termine ne peut tre dfaite et ses effets persistent durablement.
Le processus de routage dfinit lordre dans lequel les transactions entrantes doivent tre excutes sur les diffrentes rpliques pour garder le systme cohrent. Avec la rplication asynchrone
multi-matre, la cohrence mutuelle de la base de donnes peut tre compromise par lexcution
simultane des transactions conflictuelles sur diffrents sites. Pour viter ce problme, les transactions de mise jour sont excutes sur les nuds de la base dans un ordre compatible, produisant
ainsi des tats cohrents de toutes les rpliques de la base de donnes (cohrence terme des
donnes). Les requtes sont routes sur nimporte quel nud, suffisamment frais vis--vis des
conditions requises par la requte. Ceci implique quune requte peut lire diffrents tats de la
base de donnes en fonction du nud sur lequel elle est excute. Nanmoins, les requtes lisent
toujours des tats cohrents (probablement obsoltes) car elles ne sont pas distribues. Pour assurer
la cohrence globale, nous maintenons un graphe dans le catalogue, appel graphe de srialisation
global (GSG).
Dfinition 8. Graphe de srialisation globale
Un GSG <T, > est un graphe au sens mathmatique o un sommet est une transaction (T )
et un arc (), une contrainte de prcdence entre deux transactions. Il est orient et sans circuit
et garde la trace des dpendances conflictuelles entre les transactions actives i.e. les transactions
courantes mais non encore valides et les transactions valides mais pas globales.
Le GSG est construit au dpart en se basant sur la notion de conflit potentiel puis peut tre
raffin grce aux conflits rels.
Dfinition 9. Conflit potentiel
Une transaction entrante Te est en conflit potentiel avec une transaction courante ou valide Tc si
elles manipulent une mme relation et que lune des transactions effectue au moins une criture sur
cette relation, autrement dit, RelR (Te ) RelW (Tc ) 6= RelW (Te ) RelR (Tc ) 6= RelW (Te )
RelW (Tc ) 6=
Une contrainte de prcdence est un ordre pr-tabli sur les transactions conflictuelles et est
dfini suivant larrive des transactions.
Dfinition 10. Ordre de prcdence
Soient deux transactions conflictuelles T et T 0 , on dit que T prcde T 0 si debut(T ) < debut(T 0 )
et nous notons T T 0 .
A partir des deux dernires dfinition, nous notons que le GSG est un graphe qui contient lensemble des transactions conflictuelles ordonnes suivant leur date darrive. En raison des relations
56

4.1. Modle et concepts

de transitivit entre les contraintes de prcdence, nous ne maintenons que la rduction transitive
du GSG : un arc de T 1 T 2 nest pas ajout si T 1 prcde dj T 2 indirectement. La rduction
transitive tant unique du fait que le graphe est orient et acyclique, alors garder la rduction transitive suffit pour garder un ordre unique de lexcution des transactions. En outre, cause de la
rplication, le GSG contient aussi les transactions dj valides mais non encore propages sur
lensemble des rpliques. Ceci est ncessaire pour ordonner les transactions de rafrachissement.
Lordonnancement des transactions de rafrachissement peut tre base sur la notion de conflit rel.
Dfinition 11. Conflit rel
Deux transactions T et T 0 sont en conflit rel si T a lu ou modifi ce que T 0 a modifi, autrement
dit, W riteSet(T ) ReadSet(T 0 ) 6= W riteSet(T ) W riteSet(T 0 ) 6= .
Corollairement, deux transactions T et T 0 en conflit potentiel mais non en conflit rel sont dites
transactions sans prcdence et nous notons par T 6 T 0 . Autrement dit, T et T 0 peuvent tre
excutes dans nimporte quel ordre sur nimporte quelle rplique et le GSG est raffin.
Notons que nous vrifions les conflits rels entre deux transactions que lorsquelles sont en
conflit potentiel. Les dtails de la gestion du rpertoire rparti et en particulier du GSG sont dcrits
dans la section 5.2.

4.1.3

Structuration des mtadonnes

Puisque les mtadonnes contiennent plusieurs types dinformations, une structuration logique
des informations permet d acclrer les recherches au sein du catalogue.
Comme nous lavons mentionn prcdemment, notre base de donnes est fragmente en plusieurs relations. Toutes les mtadonnes relatives une relation Ri sont regroupes dans une structure appele Meta(Ri ). Cette structure contient les informations ncessaires un GT pour rcuprer
toutes les contraintes de prcdence relatives la relation Ri et ltat courant dune rplique Rji .
Les informations que lon retrouve dans cette structure sont :
GSG(Ri ), la partie du GSG relative la relation Ri ;
Lhistorique de toutes les transactions qui ont dj modifi la relation Ri mais qui ne sont
pas encore propages vers toutes les rpliques. Celle-ci correspond un sous ensemble du
GSG(Ri ) rduit aux transactions dj valides. Lhistorique, dnomme History(Ri ) mentionne galement sur quel site une transaction a t excute une premire fois et est reprsente sous forme de graphe o un sommet est un couple (Ti , DNj ) et un arc reprsente une
contrainte de prcdence. History(Ri ) permet de restaurer ltat cohrent du systme mme
en cas de panne du nud qui a reu les dernires mises jour.
State(Rji ), ltat local de chaque rplique Nj : cest la liste des transactions qui ont accd
la relation Ri et qui ont dj valid leur modification. Cette information est indispensable
pour mesurer lobsolescence de chaque rplique et la squence de transactions lui envoyer
pour quelle soit totalement frache.
57

Chapitre 4. Architecture dun Systme de Routage des Transactions

4.2

Dfinition gnrale des composants de larchitecture

Cette section prsente larchitecture du systme de routage (appel routeur par la suite). Le
systme est constitu dun ensemble de composants qui jouent des rles spcifiques.
Application : nous appelons application le composant gnrant la charge applicative. Les
applications mettent des demandes de transactions qui sont envoyes au gestionnaire de
transactions.
Gestionnaire de transactions : Cest lintergiciel transactionnel au cur du systme de routage. Il reoit les demandes de transactions et les transmet une base de donnes, de manire
optimale. Il ordonne les transactions pour conserver la cohrence des bases de donnes sousjacentes.
Catalogue. Le catalogue contient toutes les informations ncessaires au routage des transactions. Il informe le gestionnaire de transaction sur ltat des diffrents composants du
systme.
Base de donnes : nous appelons base de donnes le composant reprsentant la base de
donnes. Le composant base de donnes reoit et gre lexcution des transactions que le
gestionnaire de transactions lui envoie, puis transmet le rsultat lapplication ayant mis la
transaction.
La figure 4.1 dcrit lassemblage des 4 composants. Les deux composants gestionnaires de
transaction et catalogue forment lintergiciel de routage. Les deux autres composants, application
et base de donnes, situs aux extrmits de larchitecture, agissent comme des relais vis--vis de
lenvironnement extrieur.

F IGURE 4.1 Architecture globale en couche

De plus, cette architecture modulaire prsente lavantage de faciliter lvolution et la maintenance du systme. En effet, il est possible damliorer limplmentation de chaque module individuellement, tout en conservant intacts les autres modules.

4.2.1

Impact des besoins applicatifs sur larchitecture

La conception dune architecture modulaire se justifie pour mieux rpondre aux principaux
besoins du routeur : prserver lautonomie des applications, passer lchelle et tre disponible.
58

4.2. Dfinition gnrale des composants de larchitecture

En effet, pour chaque composant, nous dfinissons son interface avec ses composants connexes.
Puis, ltude dtaille de chaque composant permet de dfinir sa mise en uvre dans un contexte
rparti.
Besoin de prserver lautonomie des applications et des SGBD
Le routeur est conu pour amliorer des applications existantes. Pour cela, le routeur doit pouvoir sinsrer dans une application existante. Cela est possible car les applications vises sont dj
conues de faon modulaire avec deux couches bien distinctes : la couche au niveau du serveur
dapplication gre le dialogue avec lutilisateur, la couche sous-jacente contient les services de
gestion de donnes. Les deux couches communiquent travers des interfaces standards (e.g. JDBC
ou REST), ce qui permet linsertion du routeur entre ces deux couches. Par exemple, il est possible dinsrer le routeur dans une application qui utilise JDBC pour se connecter aux serveurs de
donnes. Dans ce cas, le routeur se comportera comme un pilote JDBC vis--vis de lapplication
et comme un client JDBC vis--vis du serveur de donnes. Donc, du point de vue de lapplication, le routeur se substitue au pilote daccs la base, de manire transparente, sans impliquer la
modification de lapplication existante ni celle du SGBD.
Besoin de passage lchelle et de disponibilit
Le routeur est conu pour fonctionner grande chelle en sappuyant sur une infrastructure distribue constitue dun grand nombre de ressources (ou nuds) de traitement. Le routeur doit aussi
tre hautement disponible. Ces deux exigences ncessitent de rpartir et rpliquer les composants
de larchitecture. Ainsi, chaque composant est mis en uvre par un ensemble (potentiellement
grand) de nuds. Chaque nud tant un processus, on peut avoir plusieurs nud sur une mme
machine physique et les noeuds doivent se coordonner entre eux, si ncessaire. Cependant, tous
les composants ne demandent pas le mme niveau de coordination. Cest pourquoi, nous distinguons plusieurs organisations des nuds, plus ou moins structures, selon le composant mettre
en uvre (voir la figure 4.2) :
Application : indpendance totale entre les diffrentes instances du composant application.
Il ny a pas dchange dinformations entre les applications, donc pas de liens entre applications.
Gestion des transactions : structuration forte des nuds reprsentant le routeur, organisation en anneau car leur nombre est relativement faible, et il est ncessaire dchanger trs
frquemment des informations entre les diffrentes instances du composant de gestion de
transactions puisquelles peuvent grer des transactions touchant les mmes donnes.
Catalogue : structuration forte en anneau. Les informations contenues dans le catalogue sont
rpliques pour viter leur perte. De plus, les informations sont rparties sur plusieurs nuds
pour parallliser les accs disjoints, raison pour laquelle nous lappelons aussi catalogue
rparti.
Base de donnes : structuration faible car leur nombre est trs lev et il nest pas ncessaire
pour une instance de base de donnes de connatre toutes les autres bases de donnes (cest
59

Chapitre 4. Architecture dun Systme de Routage des Transactions

le rle du catalogue et pas celui des bases de donnes). Toutefois, certains changes dinformations directs entre les bases de donnes sont ncessaires pour valider des transactions.
Pour des soucis de prsentation, nous utilisons par la suite le terme nud applicatif (NA) pour
dsigner une instance du composant "Application", gestionnaire de transaction (GT) pour une instance du "Gestionnaire de transaction", nud catalogue (NC) pour une instance du "Catalogue" et
enfin nud de donnes (ND) pour une instance du composant "Base de donnes".

F IGURE 4.2 Architecture dtaille globale du systme

4.2.2

Modle de communication

Pour garantir la communication des diffrents nuds logiques qui composent notre systme
(GT, NC, NA et ND), nous nous appuyons sur les primitives de communication des systmes P2P.
Sur la figure 4.3, la couche haute concentre les diffrents noeuds de notre systme et la couche
basse un rseau logique de P2P (ou dun systme de grille) construit sur des machines physique
connectes par Internet ou un rseau WAN. La couche basse fournit des primitives de connexions
et dconnexions au systme et des services tels que la localisation dun nud, le support didentification unique des nuds et de la communication asynchrone entre nuds. Un nud logique de
la couche basse peut regrouper plusieurs nuds logiques de la couche haute. Ce faisant, un noeud
GT peut communiquer avec un noeud ND en passant par le rseau logique P2P sous-jacent. Ce
choix dimplmentation nous pargne la tche de dvelopper des protocoles de communication via
des sockets ou autres. Il nous permet aussi de pouvoir intgrer notre solution sur nimporte quel
systme offrant des services de communication et de localisation des ressources.
Lensemble des nuds de notre systme communiquent par des messages. Chaque message
envoy, doit tre acquitt par le destinataire. Notre modle de communication est fortement li au
60

4.2. Dfinition gnrale des composants de larchitecture

F IGURE 4.3 Communication via un systme P2P ou grille

protocole de routage dcrit dans le chapitre prochain et qui permet un ND denvoyer directement
les rsultats au noeuds NA. En fait, pour excuter une transaction T , un NA contacte un GT qui
son tour va contacter un ND. Le ND envoie directement les rsultats aux NA et un message de
notification au GT. Ce message de notification permet au GT de marquer T comme excute au
moins sur un nud du systme. Pour faciliter la collaboration des nuds, des informations sont

F IGURE 4.4 Format des messages

ajoutes chaque message envoy. Les messages envoys ont le format dcrit dans la figure 4.4
et sont composs de quatre champs. Le premier champ dfinit le type de message, le deuxime
contient lidentifiant de lmetteur du message, le troisime garde le contenu du message alors que
le quatrime champ est optionnel et son contenu est fortement tributaire du type du message. Les
types de messages sont au nombre de dix dont les plus utiliss sont : les demandes de traitement
de transactions (entre NA, GT et ND), les messages de notification de fin dexcution (ND et GT),
les messages dacquittement, les messages vhiculant les rsultats et les messages de dtection de
pannes. Le type dun message est appel aussi tag. Pour envoyer un message un nud (respectivement recevoir un message dun nud), un nud utilise la primitive sendMsg() (respectivement
getMsg()).

4.2.3

Architecture dtaille

Cette section prsente larchitecture interne de chaque composant. Elle dfinit aussi la coordination de plusieurs instances dun mme composant.
61

Chapitre 4. Architecture dun Systme de Routage des Transactions

Nud Applicatif (NA)

Interfaces. Chaque NA est constitu de linstance de lapplication et de quelques modules ajouts pour des besoins spcifiques du routeur (voir figure 4.5). Ces modules additionnels jouent alors
le rle dinterface entre lapplication et le gestionnaire de transaction et nous les appelons interface cliente. Les transactions envoyes par lapplication sont encapsules par linterface cliente
dans des primitives sous forme de messages et sont envoyes au GT. En effet lapplication envoie
sa transaction via une interface standard JDBC et na pas connaissance de lexistence des GT. La
transaction est intercepte par linterface cliente qui linclut dans un message avec des informations destines aux GT. Linterface cliente qui a une connaissance de ladresse de certains GT en
choisit un et lenvoie le message pour traiter la transaction qui y est incluse. A titre illustratif, voici
un exemple de requte encapsule dans un message destination dun GT.
[msgToRoute : 123 : Update table where attribut = val ; : <123,15> ]
Le premier champ contient le tag "MsgToRoute" qui signifie que cest une transaction traiter.
Le second champ permet didentifier lidentifiant de lmetteur du message (123). Le champs
"Contenu" contient le code de la transaction excuter alors que le champs "Options" stocke
lidentifiant de la transaction (<123,15>). De mme les rponses aux transactions sont dcapsules
par linterface cliente avant de transmettre le rsultat lapplication.

F IGURE 4.5 Structure interne dun NA

Rle des composants internes. Un NA associe chaque transaction un identifiant global unique
(GId) qui est ncessaire pour viter toute ambigit durant son excution. Le GId dune transaction
est la paire <Id, SeqN>, o Id reprsente lidentifiant du client (adresse IP) et SeqN le numro de
squence local de la transaction. Il correspond <123,15> pour lexemple prcdent. Le GId est
gnr par un module spcial appel Module destampille qui doit assurer son unicit et sa monotonie. Les transactions sont envoyes par le module Ordonnanceur. Ce dernier a une connaissance
62

4.2. Dfinition gnrale des composants de larchitecture

partielle des diffrents GT existants et les choisit suivant lalgorithme du tourniquet. Toute transaction T envoye est journalise dans une structure appele Mmoire locale (ML) au niveau du NA
jusqu la rception des rsultats de son excution. Le ML stocke aussi tous les TMs connus par le
nud applicatif tout en pointant chaque instant le dernier TM qui a t contact. Ds rception
des rsultats de lexcution dune transaction, le module Planificateur efface du ML lentre correspondante T . En cas de non rception des rsultats de T au bout dun dlai fix, le Planificateur
charge le module Ordonnanceur de renvoyer la transaction avec le mme GId. Lobjectif de rmettre une transaction avec un mme GId est dune part, dviter quelle soit excute plusieurs
fois et dautre part, quelle soit prise en compte si elle ne lest pas encore. Les dtails de cette approche seront donns dans les prochains chapitres. Les nuds NA nont aucune connaissance de la
localisation et encore moins de ltat des nuds de la couche de donnes, ce qui permet dassurer
une transparence totale de la distribution des donnes.
Pour se connecter au systme, un nouveau NA a besoin de connatre un GT qui lui renvoie par
la suite les identifiants de ses voisins.
Gestionnaire de transaction(GT)
Interfaces. Les nuds gestionnaire de transactions (GT) transmettent les transactions pour excution sur les nuds de donnes (ND) tout en prservant la cohrence globale. Les GT utilisent
les mtadonnes stockes sur le catalogue rparti pour choisir le nud vers lequel envoyer une
transaction. Cest pourquoi, le GT a deux interfaces : une pour accder au catalogue et une autre
pour dialoguer avec les nuds de donnes. Linterface utilise pour communiquer avec les ND est
similaire celle utilise pour interagir avec un NA. Le message ci-aprs correspond au message
envoy par un GT pour demander lexcution dune transaction sur un ND.
[ MsgToPerform : 005 : Update table where attribut = val ; : <123,15> ; Ordre ]
Le champs "Options", contient cette fois des informations pour garder la cohrence : Ordre
contient les transactions qui doivent prcder la transaction entrante identifie par <123 ,15> (voir
section 5.1). Linterface utilise pour accder aux mtadonnes utilise des primitives offertes par
des systmes tiers qui sont utiliss pour stocker les mtadonnes (voir section 4.3).
Rle des composants interne. Les GT sont organiss sous forme danneau logique [LAF99].
Cette structuration a pour but de faciliter leur collaboration et leur communication afin de maintenir
les performances du systme (disponibilit, cohrence, ...). Pour ce faire, chaque GT est reli
k prdcesseurs et k successeurs. Lensemble des successeurs de GTi est obtenu par la formule
Suc(GTi ) = {GT((i+j) mod n) , 1 j k}, avec n le nombre total de GT. Chaque GT est compos
de quatre modules (voir figure 4.6) :
Le Module de routage (MR) est charg de rceptionner les transactions provenant des NA
et de choisir un nud ND pour lexcution de celle-ci. Le choix du nud qui traitera la
transaction se fait suivant des algorithmes que nous prsenterons dans le prochain chapitre.
La plupart de ses algorithmes sont bass sur un modle de cot qui permet de choisir un
63

Chapitre 4. Architecture dun Systme de Routage des Transactions

F IGURE 4.6 Structure interne dun GT

nud parmi plusieurs candidats potentiels. Ainsi lors du processus de routage, le MR fait
appel la fonction de cot, qui permet de retrouver le nud optimal.
Le Module de synchronisation (MS) est le module qui permet la convergence des copies vers
un mme tat. Concrtement, il initialise la propagation des modifications faites sur un nud
ND vers dautres nuds ND. Cette propagation se fait soit la demande dun GT ou dun
ND, soit priodiquement. Pour dterminer les mises jour propager, certaines informations
stockes dans le catalogue sont utilises savoir la dernire transaction excute sur un
nud, la transaction la plus rcente, etc.
Le Module de dtection des pannes (MDP) permet de prendre en compte la volatilit des
ressources du systme, particulirement les nuds ND et GT. En effet, il est responsable de
la dtection des pannes et de leur notification auprs des GT pour les pannes de nuds ND.
Quand un nud GT tombe en panne, ces prdcesseurs en seront informs pour maintenir
lanneau jour. Chaque nud ND en panne est inscrit dans une file appele file des nuds
en panne (FNP). Cette file est stocke sur le catalogue et est utilise lors des processus de
routage pour viter quun nud en panne soit choisi par un GT. Ceci augmente la chance
denvoyer une transaction sur un nud ND non dfaillant et donc les chances dobtenir une
rponse rapidement.
Le Gestionnaire des pannes (GP) est charg de dtecter le retour de tout nud prcdemment
dclar comme tant en panne par le MDP. Sil sagit dun ND, il lenlve de la file (FNP)
et dans le cas dun GT, il initialise la rorganisation de lanneau.
Les GT sont sans tat et toutes les informations dont ils ont besoin sont toujours stockes dans
le catalogue rparti. Ainsi, un GT dfaillant peut tre remplac par nimporte quel autre GT sans
perdre des informations. Un GT a besoin de connatre au moins un autre GT pour sinsrer dans
lanneau et recevoir les informations ncessaire laccs au catalogue.
64

4.2. Dfinition gnrale des composants de larchitecture

Nud de donnes (ND)

Interfaces. Les nuds ND utilisent un systme de gestion de base de donnes (SGBD) local
pour stocker les donnes et excuter les transactions envoyes par les GT. Aprs lexcution dune
transaction, les rsultats sont directement envoys au NA lorigine de la transaction, sans repasser
par les GT. Ce mcanisme permet de sloigner du fonctionnement Client/Serveur. Par consquent,
le ND a une interface pour communiquer avec le GT et le ND et une autre interface pour communiquer avec le SGBD local. La premire interface est identique celle utilise par le GT pour
communiquer avec le ND et consiste donc un message encapsulant des informations de routage.
Un exemple dun message envoy via cette interface est :
[MsgToNotify : 025 : Positive EOT : <123,15> ]
Le champ "Options" contient le GId de la transaction que le ND vient dexcuter. Le champs
"Contenu" indique ltat de lexcution de la transaction. On rappelle que la fin dune transaction
(EOT) peut tre positive si lexcution a russi et ngative dans le cas contraire.
Par contre pour communiquer avec le SGBD local, le ND utilise linterface standard JDBC
pour envoyer la transaction et recevoir les rsultats.

F IGURE 4.7 Structure dun ND

Rle des composants internes. Des informations de routage (Identifiant metteur, GId, ...) sont
ajoutes chaque transaction dans loptique de garder une traces des nuds qui ont particip
lexcution de la transaction. Pour dissocier le code de la transaction excuter des informations de
routage, un nud ND utilise un module dnomm Filtre. Ainsi, les instructions de la transaction
traiter sont transmises au SGBD local via un pilote JDBC par le Filtre et les informations de routage
sont gardes jusqu la fin de lexcution pour informer les GT de la bonne terminaison de celle-ci
mais aussi pour renvoyer les rsultats directement au NA lorigine de la transaction. Par ailleurs,
nous mentionnons quavec les systmes large chelle, que deux messages envoys avec un ordre
65

Chapitre 4. Architecture dun Systme de Routage des Transactions

peuvent tre reus dans un ordre diffrent et par consquent, engendrer quelques problmes de
cohrence. Pour prendre en compte ce genre de problme, nous avons un module Ordonnanceur
qui est charg de transmettre la transaction au SGBD tout en garantissant que lordre de prcdence
soit respect (les dtails de cette garantie seront donns dans le chapitre suivant). Ce module permet
galement un nud ND de ne pas excuter une mme transaction deux fois de suite pendant une
priode suprieure la priode de synchronisation totale des rpliques. Les informations de routage
collectes par le Filtre sont stockes dans une zone tampon sur le ND local. Enfin, un dernier
module Planificateur est charg de lenvoi des rsultats aux clients (NA) et les notifications de fin
de traitement des transactions aux GT.
Contrairement aux nuds GT, un nud ND ne connat pas les autres NDs mme si ces derniers
stockent la mme copie que lui. Toutefois, si un nud ND a besoin de collaborer avec un autre ND
pour lexcution dune transaction T , les informations ncessaires pour cela (identifiant, et adresse
IP) sont fournies lors du routage de T . Cette absence de connaissance globale du systme permet
un ND de ne pas avoir besoin de faire des mises jour lors des connexions ou dconnexions
dautres NDs.

4.3

Description de la structure des mtadonnes

Dans cette section nous prsentons la structure de mtadonnes. Nous dcrivons dabord le
contenu des mtadonnes avant de dtailler leur implmentation.

4.3.1

Description et structure des mtadonnes

Cette partie dcrit les informations qui sont stockes dans le catalogue rparti et comment elles
sont structures.
Besoin de garder des informations multiples
Les mtadonnes sont les informations relatives la distribution des donnes et des transactions excutes, autrement dit, les mtadonnes contiennent les informations sur les ND. Elles sont
stockes dans le catalogue rparti travers des nuds appels nuds catalogue (NC). Lobjectif de
garder des mtadonnes est de faciliter la recherche des ressources du systme et particulirement
ltat des bases de donnes afin de router efficacement une transaction. Plus les informations utilises pour dcrire les ressources du systmes sont nombreuses plus la recherche dune ressource satisfaisant un certain nombre de critre est rapide, prcise et fructueuse. Ainsi, pour chaque relation
Ri de la base de donnes, nous gardons plusieurs informations : (1) les identifiants de lensemble
des ND qui stockent une copie de Ri ; (2) pour chaque NDj stockant Ri , nous gardons ltat courant de la base i.e. la liste des transactions courantes et/ou dj excutes sur NDj ; (3) pour chaque
ND, nous gardons son statut i.e. sil est connect ou dconnect ; etc. Nous mentionnons que nous
gardons dans le catalogue toutes les transactions en cours et celles qui sont dj valides mais non
encore propages sur toutes les rpliques. Le choix de garder quune partie des transactions dj
66

4.3. Description de la structure des mtadonnes

excute a pour objectif de minimiser le volume des mtadonnes. En effet un volume de mtadonnes trs important peut entrainer des latences lors des accs . En outre, les transactions dj
excutes sur un quelconque ND sont propages priodiquement sur lensemble des ND distants
et sont immdiatement ffaces du catalogue. Le catalogue rparti stocke aussi, pour chaque transaction T , le temps estim pour excuter T , qui est une moyenne variable obtenue par lexcution
des prcdentes excutions de T . Il est initialis par une valeur par dfaut en excutant T sur un
nud non charg. Cette mesure est indispensable pour effectuer le routage (voir chapitre 5).
Besoin de fragmenter le catalogue
Comme nous lavions mentionn ci-avant, les GT ont besoin des mtadonnes pour assurer le
traitement des transactions envoyes par les noeuds NA et contrler la cohrence globale. De ce
fait, le catalogue devient indispensable et doit tre disponible dautant plus que les GT peuvent
simultanment solliciter laccs aux mtadonnes.
Pour garantir la disponibilit des mtadonnes et leur utilisation simultane par plusieurs GT,
les mtadonnes sont fragmentes et rpliques sur plusieurs sites. La fragmentation augmente les
accs disjoints et favorise ainsi les accs parallles, ce qui amliorer les performances du systme,
particulirement le dbit du routage. La fragmentation est faite de telle sorte que chaque fragment
ne contient que les mtadonnes relatives une relation Ri (M eta(Ri ). Ceci facilite la recherche
par nom de relation et fournit des accs indpendants de chaque GSG(Ri ). Pour trouver le graphe
global (GSG(T )) S
relatif la transaction T , il faut rcuprer les GSG(Ri ) tel que Ri Rel(T ) et
donc GSG(T ) = GSG(Ri )|Ri Rel(T ).
Cependant, la rplication peut entraner quelques problmes dans la gestion des mtadonnes,
notamment leur cohrence. Ainsi, il devient important de grer les accs concurrents au catalogue
de manire efficace afin de garantir le cohrence et de rduire la latence (cf. section 5.2).

4.3.2

Implmentation du catalogue

Pour implmenter les nuds NC, nous avons utilis des systmes tiers qui fournissent des
services de gestion et de stockage de donnes dans un environnement grande chelle. En premier
lieu, nous utilisons JuxMem [ABJ05] qui fournit un service transparent et cohrent de partage de
donnes sur une grille informatique. En second lieu, nous utilisons une DHT pour un meilleur
passage lchelle et une disponibilit plus importante du catalogue.
Architecture du catalogue avec un systme mmoire partage : JuxMem
JuxMem fournit un service transparent et cohrent de partage de donnes sur une grille informatique. Il permet le partage dun ensemble de blocs de donnes dans un systme mmoire
partag. Ainsi, il offre des primitives dcriture et de lecture de donnes stockes sur ces blocs tout
en garantissant leur cohrence et leur disponibilit. Par consquent, pour stocker les informations
du catalogue, le problme consiste travers JuxMem de demander des blocs de mmoire de blocs
ncessaire sans pour autant se soucier des endroits o le stockage physique se fera proprement fait.
Cependant, comme les blocs de JuxMem sont de taille limite, il faut viter que les informations
67

Chapitre 4. Architecture dun Systme de Routage des Transactions

dun fragment de mtadonnes se trouvent dans deux blocs, qui peuvent tre loigns et donc ralentir laccs. Cest une motivation de plus notre choix de ne pas garder dans le catalogue les
transactions dj propages afin de rduire la taille des mtadonnes.
Interfaces. JuxMem offre travers une interface plusieurs primitives pour manipuler les donnes
parmi lesquelles nous pouvons citer :
alloc (size, attributes), une primitive qui permet dobtenir un nouveau bloc dune taille donne (size) avec un degr de redondance et un protocole de contrle de cohrence mutuelle
spcifis par le paramtre attributes.
put (id, value) permet de modifier la valeur dune donne dun bloc identifi par id.
get(id) permet de rcuprer la valeur du bloc identifi par id.
lock(id) et unlock(id) respectivement pour verrouiller et dverrouiller le bloc didentifiant id.

F IGURE 4.8 Mthodes daccs au catalogue avec JuxMem

Pour manipuler les mtadonnes, les nuds GT se comportent comme des clients dans larchitecture de JuxMem (voir figure 4.8). Par consquent, un GT demande JuxMem un nouveau
bloc lors de la cration dun fragment de mtadonnes, puis utilise la primitive put (id, value) pour
insrer la structure Meta(R). Pour lire le contenu du Meta(R), il utilise la primitive get(id).
Accs concurrents avec JuxMem. La lecture et la modification des blocs avec Juxmem se fait
via lutilisation de verrous. Pour assurer la cohrence lors des routages, nous avons utilis les primitives de verrous de JuxMem pour reproduire le schma classique de verrouillage deux phases
(2PL). En dautres termes, un GT garde un verrou sur le bloc de donnes requis durant tout le
processus de routage. Ceci ne dgrade pas les performances du systme, puisque : (1) le processus
de routage est trs rapide compar lexcution de la transaction et des oprations de rafrachissement, et (2) le catalogue est dcoup de tel sorte quun seul bloc est souvent sollicit par une
transaction.
68

4.3. Description de la structure des mtadonnes

JuxMem permet dobtenir de bonnes performances si le nombre de GT concurrents est faible.

Lutilisation des verrous entrane la dgradation des performances si le nombre de GT concurrents est important puisquil faut attendre toujours le relchement dun verrou pour pouvoir traiter
(router) une transaction. Dans un environnement volatilit trs importante la panne dun noeud
cause de srieux problme lutilisation des verrous puisquun nud dtenant un verrou peut tomber tout moment en panne. En outre, JuxMem cache les dtails de stockage et de rplication
des donnes. Ainsi, il devient impossible de modifier le protocole de rplication pour des besoins
spcifiques de gestion du catalogue rparti.
Architecture du catalogue avec une DHT
Pour garantir que le catalogue rparti soit plus disponible et que son utilisation simultane par
plusieurs GT ne constitue pas une source de congestion, nous avons utilis une DHT qui permet
davoir des services dindexation passant lchelle. La DHT distribue et rplique les mtadonnes
sur plusieurs noeuds NC pour assurer la disponibilit. Dans la suite de cette section, nous dcrivons
comment nos mtadonnes sont intgrs dans une DHT.
Interfaces. Pour manipuler les mtadonnes dans la DHT, nous avons besoin doprations de
base pour les insrer, les retrouver et les modifier. Pour ce faire et compte tenu de notre contexte,
nous avons dune part les primitives natives offertes par la plupart des implmentations des DHT
et dautre part des primitives additionnelles dveloppes pour nos propres besoins (cf. figure 4.9 ).

F IGURE 4.9 Mthodes daccs au catalogue avec DHT

Mthodes daccs avec les primitives natives des DHT. En gnral, une DHT offre deux primitives doprations trs usuelles : put(k, v) pour insrer une valeur v associe une cl k, et get(k)
69

Chapitre 4. Architecture dun Systme de Routage des Transactions

pour rcuprer la valeur v associe k. Dans notre cas, k est nom dune relation R et v est la
structure Meta(R). En outre, pour tolrer la panne ou la dconnexion des noeuds, la DHT rplique
chaque couple (k, v) sur plusieurs nuds. Une opration put(k, v) cre n rpliques (k, vi )0 < i < n.
La valeur de n est initialise au moment de linsertion de la valeur et en fonction du niveau de disponibilit sollicit. En plus toute rplique peut tre utilise par la DHT sans distinction. La seule
chose assurer est quune opration get retourne toujours une des copies de la valeur associe
la cl utilise. Ainsi, deux oprations get concurrentes peuvent trouver des rpliques diffrentes
gres par deux nuds distincts. La DHT ne prend pas en compte la dtection doprations get
concurrentes puisque les DHT sont conues de tel sorte que les donnes qui y sont stockes ne
soient accessibles quen lecture seule. Cest la raison pour laquelle il ny a que deux situations
dans lesquelles, les primitives natives des DHT peuvent tre utilises. Premirement, quand une
GT route une transaction de lecture seule, il utilise la primitive get(R) pour obtenir la structure
Meta(R). Le GT ne modifie pas Meta(R), il le traverse uniquement dans lobjectif de calculer la
squence de rafrachissement. Deuximement, quand une structure Meta(R) vient dtre cre, on
utilise la primitive put pour linsrer une premire fois dans le catalogue rparti. Tout autre accs
ncessite les primitives personnalises ci dessous.
Personnalisation des mthodes daccs dune DHT Il existe deux cas dans lesquels nous avons
besoin de primitives autre que celles proposes par une DHT et correspondent des modifications
du contenu du catalogue. En effet, quand un GT route une transaction, il lit le graphe de prcdence
avec lintention de le modifier ( get_for_update), ainsi il a besoin dtre tenu inform des autres
accs concurrents pour ne pas faire diverger les copies des mtadonnes. A la fin de lexcution
dune nouvelle transaction, le GT a besoin de marquer sur le catalogue que la transaction a t bien
excute et pour ce faire il modifie le graphe de prcdence et ltat du nud sur la quelle la transaction est valide. Cette dernire opration est appele metadata_update. Limplmentation des
oprations metadata_update et get_for_update est base simplement sur les primitives daccs des
DHT. De manire plus prcis, nous modifions lgrement le protocole de rplication dune DHT
de tel sorte que tous les noeuds stockant une copie dune mme portion des mtadonnes ne jouent
pas le mme rle. Les noeuds qui stockent une copie du couple (k, v) sont appels successeurs de
la cl k. Ainsi, le premier successeur (nud dont lidentifiant est le plus proche de la cl k) est
appel nud NC matre et est utilis pour le routage des transactions de mises jour. Les autres
successeurs sont appels secondaires et sont utiliss pour le routage des transactions de lecture et
donc sont accessibles avec les primitives doprations natives de la DHT. Le NC matre est utilis
pour mettre jour les mtadonnes et est donc responsable de la synchronisation avec les autres
successeurs.
Accs concurrent avec une DHT. Pour grer laccs concurrent au catalogue lors du routage,
nous ajoutons une entre dans le catalogue appele Last(R) . Last(R) est un pointeur sur le dernier
GT qui a accd la structure Meta(R). Ceci permet dordonner les critures des GT accdant
simultanment la structure et donc de prserver la cohrence. Le choix de garder le dernier GT
accder la structure Meta(R) est guid par notre principe de conception qui consiste ne jamais
utiliser de verrous durant laccs aux mtadonnes. Nous argumentons cela par le fait que les
70

4.4. Conclusion

mcanismes de verrous ne passent jamais lchelle notamment parce quun noeud dtenant un
verrou peut quitter le systme et donc bloquer tous les autres nuds qui souhaitent accder aux
mme mtadonnes. Cependant, nous avons besoin de contrler laccs simultan de plusieurs GT
afin dviter des incohrences au niveau du graphe de prcdence. En bref, Last(R) permet aux
GT de reconstruire le graphe de prcdence complet de manire cohrent. Nous donnerons plus de
dtails sur la gestion de la cohrence des mtadonnes dans la section 5.2

4.4

Conclusion

Dans ce chapitre nous avons prsent, larchitecture de notre solution en spcifiant ses diffrents composants, leur rle et leur modle de communication. Le choix dune architecture hybride
mi-chemin entre les systmes P2P structurs et ceux non structurs nous permet de tirer profit des
avantages des uns et des autres. En fait, la structuration des noeuds GT autour dun anneau logique
permet de faciliter leur collaboration pour assurer le traitement cohrent des transactions alors que
la structuration faible des nuds ND leur confre une grande autonomie. Notre intergiciel redondant permet de faire face la volatilit dun environnement large chelle puisqu chaque fois
quun nud GT ou ND tombe en panne, nous utilisons un autre nud disponible pour continuer le
traitement ou rcuprer les donnes. Lutilisation dun catalogue rparti facilite lexploitation des
ressources disponibles et un contrle global de ltat du systme. Pour rendre disponible les informations stockes lintrieur du catalogue, nous avons utilis JuxMem, puis une DHT qui sont
des systmes de gestion de donnes large chelle. Pour exploiter avec efficacit, les ressources
du systmes (quilibrer les charges, identifier rapidement le nud optimal, etc.), nous collectons
plusieurs informations dans le catalogue comme mtadonnes et nous les avons structurs logiquement pour que leur manipulation (lecture et modification) soit simple en se basant sur les interfaces
offertes par JuxMem ou par la DHT.
Dans le prochain chapitre, nous dcrivons comment les diffrents composants de notre architecture interagissent pour garantir un traitement de transaction adapt large chelle et tolrant
aux pannes.

71

Chapitre 4. Architecture dun Systme de Routage des Transactions

72

Chapitre 5
Routage des transactions
Nous considrons un environnement constitu dune base de donnes rpartie trs grande
chelle, et dont les fragments sont rpliqus sur plusieurs nuds de donnes. Dans un tel environnement, le routage dune transaction consiste tout dabord localiser les rpliques contenant
les donnes manipuler. Ensuite, il sagit de choisir, parmi les rpliques candidates, celle qui sera
accde. Le choix de la rplique vise un objectif de performance : la rplique minimisant le temps
de rponse de la transaction, est choisie. Plus prcisment, le choix de la rplique sappuie sur
une fonction de cot qui estime la dure de traitement dune transaction sur un nud de donnes,
en tenant compte des pr-traitements ncessaires au maintien de la cohrence des donnes. Le
cot dune transaction est lestimation de son temps de rponse, en fonction de la charge du nud
et de la latence des communications entre les diffrents nuds impliqus dans le routage de la
transaction.
Dans ce chapitre, nous dtaillons les deux principales tches du routage :
1. Rpertorier les rpliques candidates et leur tat. Nous dcrivons laccs au catalogue rparti et la gestion des mtadonnes quil contient. Les solutions proposes garantissent la
cohrence des mtadonnes. Deux variantes sont dcrites et leurs avantages respectifs sont
prsents.
2. Grer le traitement dune transaction sur une rplique. Les solutions proposes ordonnent
les transactions de telle sorte que les ordres, sur chaque rplique, soient tous compatibles
entre eux, i.e. , quils soient tous conformes au graphe de srialisation dfinit dans le chapitre prcdent. Il existe plusieurs faons dexcuter une transaction sans compromettre la
cohrence des donnes. Nous distinguons deux algorithmes dexcution des transactions. Le
premier algorithme appel routage pessimiste consiste excuter au pralable lensemble
des transactions pouvant tre en conflit avec la transaction demande, puis excuter ensuite
la transaction proprement dite. Le deuxime algorithme appel routage hybride consiste
omettre certains traitements pralables afin de gagner du temps. Une tentative dexcution
optimiste de la transaction est effectue au risque de compromettre la cohrence des donnes.
Il sen suit une vrification de ltat de la base de donnes afin de rejeter les tentatives qui
introduiraient des incohrences. Les risques de conflits entre transactions tant faibles avec
les applications Web 2.0, alors le routage hybride savrera plus performant que le routage
73

Chapitre 5. Routage des transactions

pessimiste.
Le chapitre sorganise comme suit. La section 5.1 prsente le routage des transactions en dtaillant
tout dabord lalgorithme de routage de manire gnrique 5.1.2. Puis lalgorithme pessimiste 5.1.3
et enfin lalgorithme hybride 5.1.4 sont dtaills. La section 5.2 prsente la gestion des mtadonnes et laccs au catalogue rparti.

5.1

Routage des transactions

Cette section prsente les dtails de lalgorithme de routage. Le routage est effectu par un gestionnaire de transaction (GT). Le routage a pour objectif de dterminer pour chaque transaction, un
nud de donnes (ND) apte traiter rapidement la transaction tout en assurant que les diffrentes
rpliques restent cohrentes. La solution tant entirement dcentralise, lalgorithme de routage
se droule sur chaque nud GT. Ainsi, un GT doit tenir compte des autres GT lorsquil effectue
le routage, afin dviter que des choix de routage contradictoires se produisent. La condition suffisante pour viter un routage contradictoire est que chaque GT ordonne les transactions quil reoit
dans lordre dfini par le graphe GSG.
Par consquent, on suppose ici que chaque GT peut lire et complter le GSG de manire cohrente. Les mcanismes garantissant la cohrence du GSG, sont dcrits dans la section suivante.
Linterface daccs au GSG pendant le routage de la transaction T consiste en deux mthodes getMetaData(T) et putMetaData(G) qui ont t dfinis dans la section 4.3.2 du chapitre architecture.

5.1.1

Dfinition du graphe de rafrachissement et du plan dexcution

Lalgorithme de routage a pour rle de dterminer, chaque fois quune nouvelle transaction
T arrive, le plan dexcution de T . Le plan dexcution de T sur un nud de donne ND, nomm
P (T, N D) est la procdure suivie pour excuter T sur ND. Dans notre approche, cest lordonnancement de lensemble des transactions qui prcdent T , appel graphe de rafrachissement (GRT )
suivi de T elle mme.
Dfinition 12. Graphe de rafrachissement pour une transaction T
Un graphe de rafrachissement dune transaction T pour un nud NDi est un graphe orient et
acyclique not GRTi <G, > tel que :
i) GRTi est un sous graphe du GSG ;
ii) T 0 G, T 0 est une transaction de mise jour ;
iii) T 0 G, T 0 T ;
iv) lexcution de toutes les transactions de G sur NDi est suffisante et ncessaire pour rendre NDi
suffisamment frais vis--vis de T , autrement dit, T peut dmarrer son excution.
GRiT est le plus petit sous-graphe du GSG tel que lexcution des nuds de G dans lordre
rend NDi suffisamment frais pour lexcution de T . En dautres termes, aprs application de GRT
sur NDi , lobsolescence de ce dernier par rapport chaque relation lue par T est infrieure
lobsolescence tolre par T pour la relation correspondante.
Nous dfinissons de manire formelle, le plan dexcution de T sur un NDi comme suit :
74

5.1. Routage des transactions

Dfinition 13. Plan dexcution

Le plan dexcution de T sur un nud NDi est : Pi (T, N Di ) = GRTi {T }, i.e. GRTi avec tous les
arcs allant de GRTi vers T .
Aprs avoir dtermin le plan dexcution, il faut lexcuter. Lexcution de P peut se faire de
deux manires : 1) soit on excute totalement le plan sur un NDi , on parle dalgorithme de routage
pessimiste ; 2) soit on excute uniquement T et la fin on vrifie sil existe des conflits rels entre
T et les transactions de GRTi , on parle dalgorithme de routage optimiste. Le second algorithme
fait lhypothse que le plan dexcution est obtenu partir des conflits potentiels puisquil est un
sous-graphe de GSG et ne correspond pas totalement aux conflits rels. Avant de dcrire ces deux
algorithmes qui dfinissent comment les transactions sont excutes et valides sur les ND, nous
prsentons dabord le scnario global de routage qui est identique pour les deux algorithmes.

5.1.2

Algorithme gnrique de routage

Le processus de routage dbute ds la rception de la transaction et prend fin aprs excution

de la transaction. Lalgorithme de routage est schmatis par la figure 5.1.

F IGURE 5.1 Scnario de routage

Au dbut, un nud applicatif NA envoie une transaction T un nud GT. Si T est une transaction de mise jour, alors les tapes suivantes sont suivies :
1. Le GT identifie dabord les classes de conflits, i.e. les relations sollicites par T (Rel(T )).
Pour chaque classe de conflit, le GT demande au rpertoire rparti deux types dinformations : les contraintes de prcdence existantes et relatives la transaction T , et la localisation de tous les sites dont le contenu inclut toutes les donnes sollicites par T . Le GT reoit
du rpertoire rparti, une description de tous les sites candidats avec leur tat mentionnant
les transactions dj valides ou en cours sur chaque rplique.
75

Chapitre 5. Routage des transactions

2. Ensuite, le GT choisit le ND le plus optimal, i.e. le nud de donnes qui minimise le temps
estim par une fonction de cot pour excuter T . Une fois un ND choisi, le GT lui envoie le
plan dexcution.
3. Le ND qui reoit le plan dexcution, excute soit toutes les transactions de P (T, N D), soit
T seulement en fonction de lalgorithme de routage choisi. Une fois que le ND a valid T , il
envoie une notification au GT et au NA. Pour NA, la notification correspond aux rsultats de
lexcution de T alors que pour GT, elle consiste en information sur la fin de la transaction
(valide ou annule). A la rception de la notification du ND, le GT mentionne dans le
rpertoire que la transaction T est valide avec succs sur le ND ou la route de nouveau sur
un autre ND.
Les dtails du calcul du nud optimal ainsi que les mcanismes dexcution de P (T, N D) seront
donns dans la section 5.1.3 (resp. section 5.1.4) pour lalgorithme de routage pessimiste (resp.
optimiste).
Si T est une requte, alors la premire tape est identique celle dune transaction de mise
jour. A ltape 2, le plan P (T, N D) inclut uniquement les transactions propager pour rendre le
ND correspondant frais vis--vis des exigences de la requte. Le GT choisit le ND qui minimise le
cot du plan dexcution. A ltape 3, le ND excute toujours le plan compltement.

5.1.3

Algorithmes de routage pessimiste

Dans cette section nous dcrivons la mise en uvre du scnario dcrit dans la section prcdente avec un modle dexcution pessimiste. Le principe de base est que les transactions sont
excutes dans lordre dfini par le plan dexcution. Nous prsentons dabord lalgorithme pour
choisir un nud ND afin dexcuter une transaction T . Puis, nous dtaillons lexcution de T sur
ND.
Choix du nud optimal
Nous dfinissons par Card(G) le nombre de sommets dun graphe, autrement dit, le nombre de
transactions. La fonction getF irst(G) retourne le premier sommet (i.e. sommet sans prdcesseur)
dun graphe G. Le choix du nud sur lequel excuter une transaction est base sur le cot et utilise
la synchronisation la demande. Il tient compte du cot de rafrachissement dun nud dans le
calcul du cot global dun nud.
Dans un premier temps, lalgorithme value, pour chaque nud NDj de la liste des candidats
potentiels :
la charge de NDj . Cette composante du cot du nud est obtenue en valuant le temps
dexcution restant de toutes les transactions actives sur NDj ;
le cot de rafrachissement de NDj afin que celui-ci soit suffisamment frais par rapport
lobsolescence tolre par la transaction T (on rappelle que si T fait des mises jours, cette
tolrance est forcment nulle). A cet effet, lalgorithme calcule le graphe de rafrachissement
GRjT pour NDj . La procdure de calcul de GRjT est donne par lalgorithme 1.
76

5.1. Routage des transactions

Algorithme 1: CalculRafraichissement (NDj , Obs)

entres : NDj nud de donnes, Obs obsolescence tolre, GSG.
sorties : GRjT graphe de rafraichissement
variables : GV fracheur du nud NDj i.e. graphe de transactions dj valides et/ou en
cours sur NDj .
1 begin
2
GRjT = ;
3
while Card(GSG) card(GV ) Obs do
4
T 0 = getF irst(GSG GV ) ;
5
GRjT = GRjT T 0 );
6
GV = GV T 0 ;
7

return GRjT

Le cot de rafrachissement est donc le temps total estim pour excuter toutes les transactions dans GRjT . Nous mentionnons galement que GRjT peut contenir des transactions dj
valides et des transactions en cours.
le cot dexcution de T elle-mme. Ce cot est obtenu en calculant la moyenne glissante
du temps dexcution des dernires transactions excutes sur le systme ;
le cot total de lexcution de T sur NDj appel CoutExec(N Dj , T ) est obtenu en faisant
la somme des trois cots prcdents.
Ensuite le ND avec un cot dexcution le plus faible est choisi comme nud optimal et correspond
NDk dfini par notre fonction de cot CoutExec(N Dk , T ) = M in({(CoutExec(N Di , T )})
tel que pour tout NDi appartenant aux nuds candidats. La fonction ChoisirNoeud() dcrite par
lalgorithme 2 donne les dtails du calcul du nud optimal.
Excution cohrente des transactions au niveau du ND
Dans cette section nous prsentons comment un ND assure la cohrence mutuelle en excutant
une transaction conformment aux exigences du plan dexcution. Nous montrons dabord quune
excution suivant le plan dexcution est cohrente puis nous prsentons lalgorithme utilis pour
excuter le plan.
Maintien de la cohrence. Ce paragraphe dcrit pourquoi le plan dexcution gnr par lalgorithme 5.1.3 est suffisant pour garantir la cohrence mutuelle. Pour ce faire nous nonons la
proprit suivante.
Proprit 1. Si lordre dexcution des transactions sur chaque nud est compatible avec lordre
global (GSG), alors la cohrence terme est garantie puisque toutes les transactions seront excutes sur tous les nuds dans un ordre compatible.
Preuve: Soient deux transactions T 1 et T 2 (avec debut(T 1) < debut(T 2)) routes respectivement
77

Chapitre 5. Routage des transactions

Algorithme 2: ChoisirNoeud (LC, Obs)

entres : LC liste des nuds candidats, Obs obsolescence tolre.
sorties : Nopt nud ND choisi, P plan dexcution.
variables : GC : Graphe de transaction en cours sur le ND considr, GR le graphe de
rafraichissement, AV G(T ) : temps moyen dexcution des transactions, Min : rel,
CoutExec : cot dexcution de T
1 begin
2
M in = ;
3
foreach N LC do
4
GR = CalculRaf raichissement(N, Obs);
5
CoutExec(N, T ) = AV G(T ) [(Card(GR) + Card(GC)) + 1];
6
if CoutExec(N, T ) < M in then
7
M in = CoutExec(N, T );
8
Nopt = N ;
9

return Nopt

par GT 1 et GT 2 sur ND1 et ND2. Supposons que T 1 et T 2 soient excutes dans un ordre diffrent
sur les deux ND, par exemple, T 1 T 2 sur ND1 et T 2 T 1 sur ND2.
Cela veut dire que GT 1 et GT 2 ont utilis chacun un GSG diffrent pour calculer les plans
dexcution de T 1 et T 2, autrement dit, GT 2 na pas lu les modifications faites sur le GSG par
GT 1. Ceci nest pas possible puisque le GSG est unique et est gr de tel sorte que tout accs
concurrent soit srialis (cf. section 5.2). Ainsi GT 2 utilise forcment le mme GSG que GT 1
vient de modifier, ce qui veut dire que GT 2 inclut T 1 dans le graphe de rafrachissement requis
pour excuter T 2 et ds lors T 1 T 2.
De plus comme toutes les transactions de mise jour et de rafrachissement sont routes avec
cet algorithme 5.1.3, alors la convergence des copies ne peut pas tre compromise puisque les ND
excutent les transactions dans le mme ordre quils les reoivent (cf. paragraphe ci-aprs).

Excution des transactions. Pour excuter les transactions sans compromettre la cohrence mutuelle, il faut garantir la proprit 2, qui son tour exige une application parfaite de (P (N D, T )).
Pour respecter lordre de P (N D, T ), lOrdonnanceur dun nud ND ne transmet au SGBD local
la transactions T que lorsque toutes les transactions qui lont prcdes ont t transmises et valides avec succs. Si une ou plusieurs transactions prcdant T ne peuvent pas tre excutes pour
une raison quelconque, lOrdonnanceur avise le Planificateur qui son tour renseigne le GT de la
situation en lui faisant parvenir ltat de rafrachissement du nud si toutefois il a t entam. En
dautres mots, si une partie des transactions de rafrachissement a t valide avec succs, alors le
GT est tenu au courant pour quil mette jour les informations du catalogue. Lalgorithme 3 dfinit
la procdure droule par lOrdonnanceur pour sassurer de la bonne excution de P .
La fonction delivrer(Tc ) permet denvoyer la transaction courante au SGBD local pour excu78

5.1. Routage des transactions

Algorithme 3: ExecuterP (P )
entres : P plan dexcution.
sorties : boolen
1 begin
2
while Card(P ) 6= 0 do
3
Tc = (getF irst(P ));
4
delivrer(Tc ) ;
5
repeat
6
attendre();
7
until fin transaction;
8
if Tc .etat=validee then
9
P = P Tc ;
10
11
12

else
return Echec ;
return Succes;

tion. De plus, lOrdonnanceur via la fonction attendre() est bloqu jusqu ce que Tc soit valide
ou annule. Si Tc est annule alors la transaction T choue puisque le nud ne sera pas suffisamment frais pour lexcuter. Une fois le GT averti de lchec de lexcution de T ou dune
excution en partie de la squence de transaction qui devrait la prcder, il choisit un autre nud
pour reprendre lexcution de T mais en recalculant la nouvelle squence de prcdence relative au
nouveau ND choisi. Ce processus est itr jusqu ce que la transaction puisse tre excute sur un
ND. En cas de non excution de la transaction aprs avoir sollicit toutes les rpliques candidates,
le client est inform.
Exemple. La figure 5.2 illustre un systme compos de deux nuds de donnes N D1 et N D2.
Le catalogue rparti indique que N D1 a reu T 1 et T 2 alors que N D2 na excut que T 1 avec
la contrainte T 1 prcde T 2. Supposons qu partir de cet tat du systme, il arrive une troisime

F IGURE 5.2 GSG avant routage

79

Chapitre 5. Routage des transactions

transaction T 3 avec un niveau de fracheur maximal. En dautres mots, T 3 requiert ltat le plus
rcent des donnes. La figure 5.3 montre que le GT ayant reu T 3, par lintermdiaire de lalgorithme dcrit prcdemment dsigne le nud N D2 comme nud optimal. Ce qui fait que le GR
correspondant est T 2 puisque cest lunique transaction dans le GSG ne pas tre excute sur
N D2. Enfin, le GT envoie le GR et T 3 N D2 puis met jour le catalogue. Ainsi, comme le
montre la figure 5.3, le GSG est complt avec T 3 et ltat de N D2 inclut dsormais les deux
dernires transactions qui viennent dtre envoyes. Lenvoi de GR suivi de T 3 signifie et sera
interprt par ailleurs par N D2 que T 2 T 3.

F IGURE 5.3 GSG aprs routage

Nous mentionnons que le GSG est utilis que pour garder la cohrence par consquent, il ne
contient que les transactions de mises jour qui peuvent introduire des incohrences.
Discussion
Le mcanisme de routage dcrit dans cette section assure une srialisation globale de manire
pessimiste. Il est utilis aussi bien pour router les transactions de mise jour que les requtes.
Chaque transaction est associe avec ses classes de conflits, qui contiennent les donnes que la
transaction peut potentiellement lire (resp. modifier). En fonction des classes de conflits, les transactions sont ordonnes dans un GSG en sappuyant sur leur ordre darrive. Bien que cette approche assure une srialisation globale, il rduit malheureusement la paralllisation du traitement
des transactions puisquelle sappuie sur des sur-ensembles potentiels de donnes rellement accdes. Par exemple, si les transactions T et T 0 crivent sur la relation R, alors elles seront excutes
sur chaque nud dans le mme ordre. Pourtant, si T et T 0 naccdent pas aux mme tuples, elles
pourraient tre excutes dans nimporte quel ordre, ce qui accrot le paralllisme et donc le dbit
transactionnel.
Par consquent, pour accrotre la paralllisation du traitement des transactions, nous proposons
dans la prochaine section, un second algorithme hybride qui combine une approche pessimiste et
optimiste.
80

5.1. Routage des transactions

5.1.4

Algorithme de routage hybride

Lobjectif du routage hybride est de traiter une transaction plus rapidement en rduisant les
pr-traitements appliqus juste avant le traitement de la transaction proprement dite.
Le routage hybride se droule comme suit : Un GT reoit une nouvelle transaction entrante,
nomme T . Puis le GT consulte le catalogue et obtient le graphe de rafraichissement contenant
toutes les transactions courantes (notes TC) ou valides (notes TV) qui prcdent T. Il obtient
aussi la description de toutes les rpliques candidates pour traiter T . Pour chaque rplique candidate, le GT construit un plan dexcution constitu des TV et de T , de telle sorte que chaque
transaction dans TV prcde T . On rappelle que lide est de ne pas inclure les TC dans le plan. Le
cot de chaque plan est estim, celui de moindre cot est choisi pour tre excut. Le GT demande
au nud de donne (ND) de traiter le plan dexcution. Lorsque le ND reoit le plan, il excute
et valide toutes les TV. Puis il excute T sans la valider. Il compare les donnes accdes par T
avec celles accdes par les transactions TC afin de dtecter un conflit. Deux issues peuvent se
produire : (1) Sil ny a pas de conflit, alors T est valide. Le ND notifie ensuite le GT de labsence
conflit entre T et TC. Le GT rpercute cette information au niveau du catalogue afin de simplifier
le graphe de prcdence : toutes les prcdences entre T et les TC sont supprimes. (2) En cas de
conflit, T est abandonne. Le ND bascule en mode pessimiste. Il traite lensemble des TC puis finit
par traiter T .
Nous exposons ci-aprs les principales raisons qui justifient le routage hybride. Lavantage du
routage hybride repose sur notre aptitude dterminer la prsence dun conflit rel entre deux
transactions. Plus prcisment, si on peut prouver que le graphe de rafraichissement est disjoint de
la transaction traiter, alors le traitement de T sans rafraichissement est acceptable, et videmment
plus rapide.
Or, dans notre contexte, la preuve que le rafraichissement nest pas ncessaire, se base sur la
connaissance des conflits rels, ce qui ncessite davoir dj trait la transaction. Cest pourquoi le
routage hybride consiste tout dabord tenter, de manire optimiste, de traiter la transaction sans
son rafraichissement, puis vrifier, postriori, que cela est correct.
Naturellement, la probabilit que la transaction accde aux mmes donnes quune autre transaction est proportionnelle au nombre de transactions considres. Par consquent, nous sommes
confronts un compromis : dune part ne pas trop rafraichir si cela nest pas ncessaire, dautre
part rduire le risque dchec en rafraichissant malgr tout
Afin de trouver une issue ce compromis, nous dcidons de conserver les pr-traitements qui
peuvent tre appliqus rapidement, lobjectif principal tant dacclrer le traitement dune transaction. Ainsi, toutes les transactions dj valides (TV) sur un autre nud seront appliques car
elles ont lavantage de pouvoir tre appliques immdiatement sans tre r-excutes, donc beaucoup plus rapidement que lexcution initiale. Lapplication immdiate dune transaction valide
consiste propager ses effets sans la r-excuter. Notons que lapplication immdiate est plus rapide que la r-excution du fait de notre contexte applicatif o une transaction passe beaucoup
de temps lire des donnes et faire des calculs et peu de temps crire des donnes. En fin de
compte, le "pari optimiste" ne portera que sur les quelques transactions courantes (TC) quon ne
peut pas appliquer immdiatement car elles nont pas encore valid. Les transactions courantes et
potentiellement conflictuelles, tant peu nombreuses par hypothse (faible taux de conflit des ap81

Chapitre 5. Routage des transactions

plications, comme expliqu en section 2.1), les chances de russite du routage optimiste savrent
trs leves.
Dans cette section, nous dtaillons comment le scnario dcrit dans 5.1.2 est mise en uvre
avec un modle dexcution optimiste des transactions. Nous prsentons dabord lalgorithme pour
choisir un nud ND qui excutera T . Puis, nous dtaillons lexcution de T sur ND.
Choix du nud optimal
La fonction ChoisirNoeudhyb() dfinie par lalgorithme 4 dtaille le calcul du nud optimal.
Contrairement lalgorithme prsent dans la section 5.1.3, le cot de rafrachissement des
transactions en cours nest pas pris en compte dans le cot global, autrement dit, seul le cot
de rafraichissement des transactions dj valides avant debut(T ) sont prises en compte. Toute
transaction T 0 tel que debut(T ) f in(T 0 ) < f in(T ) est considre comme transaction courante.
Ainsi, nous dissocions les transactions valides de celles en cours dans la squence des transactions
qui ont prcdes T . Les transactions dj valides doivent tre appliques sur le ND choisi avant
de commencer lexcution de T . Par contre, les transactions en cours ne sont pas reprises sur le
ND mais leurs modifications doivent tre confrontes avec celles de T pour garder la cohrence.
Ce choix de comparer avec T que les transactions courantes et non celles dj valides avant son
arrive se justifie par le souci dune excution rapide de T . De fait, comparer les modifications avec
toutes les transactions courantes et valides est beaucoup plus coteux et long que lapplication des
transactions valides sur le ND qui excute T .
Pour calculer le graphe de rafrachissement GR dun ND lors de lexcution de T , nous utilisons la mme procdure de lalgorithme 1 mais en enlevant toutes les transactions non encore
valides. La fonction CalculConcurrent() (ligne 4) retourne toutes les transactions courantes et
qui sont en conflits avec T . Ainsi, le graphe de rafrachissement GR est obtenu en appliquant la
diffrence entre CalculRaf raichissement et CalculConcurrent(). Lestimation du cot prend
aussi en compte la charge des nuds ND et du cot dexcution de la transaction (obtenu par talonnage). La fonction CalculConcurrent() retourne un graphe dont les sommets ne sont pas des
transactions mais des couples (T, ND), qui signifie que T a comme nud initial ND. Autrement
dit, ND est le nud sur lequel T est excute une premire fois par consquent, il est capable de
fournir DataSet(T ). La ligne 6 de lalgorithme 5 montre comment on ajoute un nouveau sommet
au graphe GRT . Le terme (getF irst(GSG GV )) permet de retrouver une transaction prcdant
T alors que la fonction getInitial(T 0 ) renvoie le nud ND sur lequel T 0 a t excute. Le code
de la fonction CalculConcurrent() est donn par lalgorithme 5.
Le cot obtenu avec lalgorithme 4 est sous-estim quand un conflit rel advient puisque toutes
les transactions conflictuelles courantes (GC) doivent tre excutes avant T . Cependant ce cas
est rare et donc a un impact ngligeable sur le fonctionnement du systme. Une fois le nud ND
choisi, le GT lui envoie le plan dexcution compos des transactions de GR, de GC et de T .
Validation des transactions
Pour acclrer le traitement, le ND qui reoit un plan dexcution excute GR puis T . Une
fois T en phase de validation, le ND compare les modifications de T avec celles des transactions
82

5.1. Routage des transactions

Algorithme 4: ChoisirNoeudHyb (LC, Obs)

entres : LC liste des nuds candidats, Obs obsolescence tolre.
sorties : Nopt nud ND choisi.
variables : GC : Graphe de transaction en cours sur le ND considr, AV G(T ) : temps
moyen dexcution des transactions, Min : rel, GR graphe de rafrachissement ( de
transactions valides sur les autres ND)
1 begin
2
M in = ;
3
foreach N LC do
4
GR = CalculRaf raichissement(N, Obs) CalculConcurrent(N, Obs)
CoutExec(N, T ) = AV G(T ) [Card(GC) + Card(GR) + 1];
5
if CoutExec(N, T ) < M in then
6
M in = CoutExec(N, T );
7
Nopt = N ;
8

return Nopt

Algorithme 5: CalculConcurrent (NDj , Obs)

entres : NDj nud de donnes, Obs obsolescence tolre, GSG.
sorties : GC graphe de concurrence
variables : GV fracheur du nud NDj i.e. graphe de transactions dj valides et/ou en
cours sur NDj .
1 begin
2
GC = ;
3
while Card(GSG) card(GV ) Obs do
4
T 0 = getF irst(GSG GV ) ;
5
if debut(T ) f in(T 0 ) < f in(T ) then
6
GC = GC (T 0 , getInitial(T 0 ));
7
GV = GV T 0 ;
8

return GC

83

Chapitre 5. Routage des transactions

en cours GC. En effet, le ND contacte tous les ND qui ont excute des transactions comprises
dans GC. Nous rappelons que GC est un graphe dont les sommets sont composs des transactions
conflictuelles en cours et les ND sur lesquels elles sexcutent.
Par exemple, soient deux nuds de donnes ND1 et ND2. Supposons que GR = , i.e. il
nexiste pas de transaction valide non encore propage sur ND2 et GC = (T1 ,ND1 ) (T2 , ND2 ).
Cette squence signifie que T1 est en train dtre excute sur ND1 et que debut(T1 ) < debut(T2 ).
Aprs avoir excut T2 , ND2 demande ND1 les donnes rellement manipules par T1 (i.e.
les DataSet(T1 )) pour toute relation R Rel(T1 ). Une fois les DataSet(T1 ) reus par le ND2,
alors ce dernier compare les DataSet(T2 ) avec ceux de T1 . A la suite de cette comparaison deux
cas peuvent se prsenter :
soit DataSet(T1 ) DataSet(T2 ) = , i.e. il ny a pas dintersection entre les donnes
modifies et lues par T1 et T2 , par consquent, T2 peut valider. De plus, ND2 notifie le GT en
lui informant que le conflit potentiel entre T1 et T2 nest pas un conflit rel, ce qui veut dire
que T1 6 T2 .
soit DataSet(T1 ) DataSet(T2 ) 6= , i.e. T2 a lu ou modifi des donnes modifies
par T1 , alors T2 est annule et ND2 excute dans lordre T 1 puis T 2. Mais comme les
DataSet(T1 ) contiennent les modifications de T1 , alors ND2 ne r-excute pas T 1 mais
plutt il se contente dappliquer les modifications. Le conflit potentiel prdfini sur T1 et
T2 est rel et donc T1 et T2 seront excutes sur toute les rpliques en respectant lordre de
prcdence.

F IGURE 5.4 Validation des transactions

Nous notons par ailleurs que si le nombre de transactions concurrentes T est suprieur un
(i.e. Card(GC) > 1), alors le ND est oblig de comparer les DataSet(T ) avec tous DataSet(Ti )
84

5.1. Routage des transactions

tels que Ti GC. Cependant, pour rcuprer tous les DataSet(Ti ), un seul ND est contact. Les
dtails de cette stratgie de communication seront donnes dans les prochaines sections.

Exemple. La figure5.4 illustre la phase de validation de trois transactions concurrentes T 1, T 2 et

T 3 (avec debut(T 1) < debut(T 2) < debut(T 3)), chacune manipulant la mme relation P roduit.
Supposons que GT 1 reoit T 1 et la route sur ND1, GT 2 (respectivement GT 3) route T 2 vers ND2
(respectivement T 3 vers GT 3).
Quand GT 2 route T 2 vers ND2, il indique que T 1 qui prcde T 2 est excute sur ND1 :
(T 1, ND1 ) (T 2, ND2).
De mme, GT 3 indique ND3 les nuds sur lesquels sexcutent T 1 et T 2 : (T 1, ND1)
(T 2, ND2) (T 3, ND3).
Quand ND1 veut valider T 1, cela se passe sans problme car il ny a aucune transaction qui
prcde T 1.
Par contre, quand N D2 tente de valider T 2, il rcupre les informations de T 1. En faisant
la comparaison des modifications de T 1 et T 2, il trouve que :DataSet(T 1) DataSet(T 2) =
{11, stylo, 23}. Il annule alors T 2, applique les DataSet(T 1) et reprend T 2.
GT 3 effectue aussi la mme procdure et trouve que : (1) DataSet(T 1) DataSet(T 3) =
{8, cahier, 16} ; et (2) DataSet(T 2) DataSet(T 3) = . Il conclut que T 1 T 3 par contre
T 2 6 T 3. Il annule ainsi T 3, applique les modifications de T 1 et reprend T 3. Linformation
dabsence de prcdence entre T 2 et T 3 sera remonte au GT pour quil corrige le GSG.
Lavantage majeur de cette vrification de conflits en fin dexcution de la transaction est quil
favorise plus de paralllisme et donne lopportunit de diffrer les propagations. Avec lexemple
prcdent, lexcution parallle de T 2 et T 3 favorise un temps de rponse plus faible que T 2 suivi
de T 3. Cette stratgie est trs adapte notre contexte dans lequel les conflits sont rares.
Calcul dintersection des DataSets. Dans ce paragraphe, nous dfinissons comment les conflits
sont dtects lors de la validation. Les DataSet(T ) sont un sous-ensemble des tuples de Rel(T ) et
sont obtenus avec des rgles actives. Chaque tuple un identifiant unique appel Id et correspond
la cl de la relation. Nous supposons que la cl dune relation nest jamais modifie par une transaction de mise jour. Lors de lextraction des DataSet(T ), les valeurs de tous les attributs dun
tuple t modifi ou lu par T sont associes avec leur Id pour former un nouveau tuple tacc . A cela
sajoute le type dopration (lecture ou criture) permettant dobtenir tacc . Ainsi les DataSet(T )
sont similaires une vue obtenue par slection sur Rel(T ) en gardant les mmes noms des attributs. Nous associons alors chaque DataSet(T ) un schma relationnel appel DataSetSc (T ).
Le schma relationnel dun DataSet(T ) est compos des noms des attributs de Rel(T ) alors que
DataSet(T ) est la relation associ tous les tuples modifis ou lus.
Supposons la relation Produit (Id, nomproduit, stock) et les deux transactions suivantes lies par
la contrainte de prcdence Ti Tj .
Ti : SELECT NOMPRODUIT FROM P RODUIT WHERE I D =25 ;
Tj : UPDATE P RODUIT SET STOCK =17 WHERE I D =25 ;
85

Chapitre 5. Routage des transactions

Alors les schmas des DataSet(Ti ) et DataSetTj sont respectivement DataSetSc (Ti )={Id, nomproduit} et DataSetSc (Tj )={Id, stock}. Lalgorithme 6 dtaille le calcul des intersections. Pour
faire la comparaison des DataSet(Ti ) et DataSet(Tj ), les schmas sont dabord compars (ligne
2-5). Sil nexiste aucun attribut en commun en dehors des Id, cela est suffisant pour conclure que
Ti 6 Tj . Par contre, si un attribut figure en mme temps dans les deux schmas, les valeurs des
attributs sont compares pour identifier sil y a rellement un conflit (ligne 8-12).
Algorithme 6: CalculIntersection (DataSet(Ti ), DataSet(Tj )
entres : DataSet(Tk ) les datasets comparer.
sorties : Boolen
variables : Tab : tableau de chaine de caractres
1 begin
2
foreach attr1 DataSetSc (Ti ) do
3
foreach attr2 DataSetSc (Tj ) do
4
if (attr2 = attr1) et (attr1 6= Id) then
5
Ajouter attr2 dans Tab;
6
7
8
9
10
11
12

13

if Tab est vide then

return false;
else
foreach tupleA DataSet(Ti ) et tupleB DataSet(Tj ) do
foreach attr T ab do
if (tupleA.Id = tupleB.Id) et (tupleA.attr 6= tupleB.attr) then
Sil existe au moins une criture return true;
return false;

Nous remarquons que lalgorithme 6 permet de vrifier lintersection des DataSet(T) que si les
transactions concernes ne font que des modifications. Lorsque lune des deux transactions Ti et
Tj lies par le conflit potentiel Ti Tj fait des insertions ou des suppressions, alors lalgorithme
6 conclut que Ti 6 Tj puisquil nexiste pas de tuples accds en commun. Pourtant, ceci nest
pas toujours vrai comme le montrent les cas suivants :
Ti fait des insertions et Tj des modifications (ou des suppressions), alors les tuples insrs
par Ti peuvent satisfaire les conditions requises par Ti pour faire une modification. Donc,
lexcution de Ti et de Tj dans nimporte quel ordre ne donne pas le mme rsultat ;
Ti et Tj font des insertions. Si les insertions dpendent dune lecture pralable de la base,
alors lordre de Ti et de Tj a une influence sur ltat de la base.
Pour viter ce genre de problme, nous maintenons le mme ordre dfini grce aux conflits potentiels. Autrement dit, nous concluons que les conflits rels sont identiques aux conflits potentiels
chaque fois que lune des transactions concernes contiennent des insertions. Cependant ce cas
est rare car la plupart des applications Web 2.0 et des ASP maintiennent des serveurs pour insert86

5.1. Routage des transactions

only dans le souci de faciliter le passage lchelle, de maintenir plusieurs versions, dassurer la
cohrence terme, etc. [FJB09].
Gestion des surcharges induites par la validation
La procdure de validation utilise pour terminer lexcution dune transaction T peut engendrer quelques surcharges. En effet la rcupration des DataSet(T ) peut allonger le temps de rponse des transactions puisque T nest valide quaprs comparaison de DataSet(T ) avec tous les
DataSet(Ti ) correspondant aux modifications des transactions concurrentes. Ainsi, les messages
envoys peuvent tre important si le nombre de transactions concurrentes est important. Dans ce
paragraphe, nous tudions les mcanismes utiliss pour borner le temps de rponse et le nombre de
messages. Nous dtaillons aussi comment les DataSet(T ) peuvent tre utiliss pour rendre plus
frais les rpliques mme en situation de conflit.
Gestion des messages. Pour valider une transaction, un ND a besoin de contacter tous les ND
qui ont excut une transaction conflictuelle et courante. Ainsi, le cot de la communication devient trs significatif quand le nombre de ND contacter est important. Pour limiter le nombre
de message, un ND cache les DataSet(T ) quil a reu dun autre ND pour pouvoir les transfrer
dautres ND qui en auront besoin. En dautres mots, un ND qui valide T contacte toujours le
ND qui a excut la dernire transaction pour chacune des classes de conflits dans lesquelles T est
implique. Un ND qui doit fournir les DataSet(T 0 ), transmet galement tous DataSet(Ti ) tel que
Ti soit dans la squence des transactions concurrentes qui prcde T 0 .
Par exemple, soit la squence de prcdence suivante T1 T2 T3 T4 route respectivement sur N D1, N D2, N D3 and N D4. Quand N D2 veut valider T2 , il demande les DataSet(T1 )
quil met en cache leur rception. Ensuite, quand N D3 cherche valider T3 , il contacte seulement N D2 qui est capable de lui dlivrer la fois DataSet(T1 ) et DataSet(T2 ). Ainsi, en cas
dabsence de panne , deux messages sont largement suffisants pour dcider de valider ou dannuler
une transaction.
Propagation indirecte des mises jour. Pour rcuprer les DataSet(T 0 ) dune transaction T 0
prcdant une transaction T en cours de validation, nous utilisons des triggers et linterface JDBC
avec laquelle nous accdons au SGBD local dun ND. Cela gnre un cot supplmentaire non
ngligeable quand le volume des donnes lues est importante. Par consquent, une fois que les
DataSet(T ) sont obtenus, les ND en font une exploitation maximale. En effet, la rception
des DataSet(T ) pour valider T 0 , nous avons dcrit que deux cas pouvaient se prsenter savoir
lexistence de conflit ou labsence de conflit entre T et T 0 . Dans tous les deux cas, le ND applique
les modifications de T . De fait, si T et T 0 sont en conflit rel, le ND est oblig dexcuter dabord T
puis T 0 . Si heureusement, T 6 T 0 , le ND valide dabord T 0 et ensuite applique les modifications de
T puisquil a dj sa possession les DataSet(T ). Ainsi, mme en cas dannulation de transaction
la rcupration des DataSet(T ) nest pas une perte en soit puisquils ont permis rendre plus
frais un ND, ce qui fera de lui un candidat potentiel pour les prochaines excution. Le gain obtenu
avec cette approche est comparable celui obtenu avec la synchronisation prcoce dcrite dans
87

Chapitre 5. Routage des transactions

[GNPV07]. Il permet de rduire la squence de transaction ncessaire pour rendre un nud plus
frais pour les futures transactions et donc diminue le temps de rponse global.
Majoration du temps de rponse. Pour valider T , un ND est oblig dattendre les modifications
de toutes les transactions conflictuelles et courantes. Pour viter des temps rponses levs, nous
bornons le temps dattente pour lobtention des DataSet(Ti ). Ce temps dattente est appel Temps
de Dcision (T D ). A lexpiration de T D , le ND contacte le GT en lui envoyant le DataSet(T )
pour quil prenne une dcision finale. Cette situations est trs dlicate car plusieurs scnarios sont
envisageables. Par exemple, une transaction Ti prcdant T peut tre dj excute sur un ND qui
tombe en panne tout juste avant denvoyer les DataSet(Ti ), ou mme que Ti na pu tre traite et
donc il nexiste aucun DataSet(Ti ) envoyer. La dtection et la gestion des pannes sont dtailles
dans le chapitre 6.
De plus, si le nud ND1 qui veut valider T narrive pas rcuprer les DataSet(Ti ) des
transactions qui prcdent T , alors tous les ND qui attendaient les DataSet(T ) hriteront du mme
problme. Pour viter que tous ces ND bloqus contactent les GT, ND1 les avisent afin que ces
derniers puissent allonger leur temps de dcision.
Ce temps de dcision est choisi en prenant en compte la latence du rseau et correspond
T D 2n (Avg(T ) + N ), avec (N ), la latence du rseau, Avg(T ), le temps de traitement
dune transaction, et n le nombre de transaction prcdent Ti .
Pour trouver cette borne, supposons que ti (Tj ) soit la date denvoi de Tj un ND et N le dlai
coul avant la rception de Tj . A tout instant, le temps dexcution restant pour excuter Tj peut
tre obtenu par :
RT (Tj ) = Avg(T ) (GTsys ti (Tj ))
avec GTsys la date systme du nud GT qui a rout Tj . Pour obtenir les datasets , chaque ND
fait un aller-retour qui est quivalent 2 N . Ainsi, en supposant que le temps dextraction des
datasets est identique au temps dexcution de la transaction, le temps total de rcupration de tous
les datasets est :
RT (Tj ) = 2 Avg(T ) (GTsys ti (Tj )) + 2 N
Si le nombre de transaction prcdent Ti est gal n, alors
T D

k=n
X

(2 Avg(T ) (GTsys ti (Tk )) + 2 N )

k=0

Do :
T 2n (Avg(T ) + N )

5.1.5

Discussion

Dans cette section, nous avons prsent notre protocole de routage. Les applications spcifient leurs exigences en termes de besoin de cohrence, puis lintergiciel honore ces exigences en
88

5.2. Gestion des mtadonnes

contrlant la cohrence des donnes. Nous avons dfini deux protocoles pour maintenir la cohrence globale, en fonction de la connaissance des donnes manipules par les transactions. Le premier protocole ordonne les transactions partir de la dfinition a priori des donnes accdes. Le
deuxime protocole dtermine un ordre plus souple, en comparant les donnes accdes, le plus
tardivement possible, juste avant la validation des transactions. La deuxime solution offre plus
dopportunit de paralllisme surtout dans le contexte des applications web2.0 avec lesquelles les
conflits sont rares. De plus, lutilisation du temps de dcision permet de borner le temps de validation des transactions, puisque son expiration entrane lintervention du GT qui a une connaissance
plus dtaille de ltat des ND, ce qui peut acclrer le traitement. Cette majoration associe
une gestion des pannes permet de garde de bonnes performances en garantissant lexcution dune
transaction quelque soient les problmes de pannes et de latence. Nous dtaillons la gestion des
pannes dans le chapitre 6. Dans la prochaine section nous tudions comment les GT accdent et
manipulent rellement les mtadonnes afin de garantir leur cohrence en cas daccs concurrent.

5.2

Gestion des mtadonnes

Le scnario de routage dcrit dans la section 5.1.2 se droule chaque fois quun GT reoit
une transaction dun client. Ainsi, deux ou plusieurs GT peuvent avoir des accs concurrent sur
le mme nud NC si leurs transactions partagent une mme classe de conflit, ou un mme ND
si le nud avec le plus faible cot choisi est le mme pour tous les deux GT. Soient GT 1 et
GT 2 deus routeurs voulant accder M eta(R1 ) pour router respectivement deux transactions T1
et T2 qui tentent de modifier la relation R1 . Chaque GT obtient une copie de M eta(R1 ) via le
catalogue. Supposons que GT 1 route T1 vers le nud de donnes N D1 et met jour M eta(R1 ) en
crivant (T1 , ND1) qui signifie que T1 est entrain de sexcuter sur N D1. Si GT 2 route T2 vers un
second nud de donnes ND2 sans prendre en compte T1 , la cohrence mutuelle est compromise
puisquune transaction de mise jour doit lire toujours des donnes totalement fraches.
Pour viter cette situation, il faut des mcanismes daccs concurrents au catalogue rparti pour
maintenir la cohrence des mtadonnes lors des oprations de routage.
Pour ce faire, nous proposons deux approches : une approche utilisant le verrouillage et une
autre sans verrouillage. La gestion avec verrouillage garantit la cohrence des mtadonnes et en
particulier le GSG. La gestion avec le verrouillage est implmente via JuxMem dans le but dintgrer nos travaux dans le cadre du projet ANR Respire [Prod]. Malheureusement, nous avons
remarqu que le verrouillage ne facilite pas le passage lchelle puisque lattente de lobtention
dun verrou peut tre longue et rallonger les temps de rponse. Cest pourquoi, nous avons opt
pour une solution sans verrouillage lors de laccs au catalogue. De plus, nous nous sommes rendu
compte quil existait des systmes tels que les DHT qui permettent de grer des donnes rpliques
sans utilisation de mcanismes de verrouillage. Ainsi, nous avons implment la gestion du catalogue travers une DHT dautant plus que celle-ci favorise le passage lchelle et une grande
disponibilit, deux caractristiques trs importantes pour notre systme de routage.
89

Chapitre 5. Routage des transactions

5.2.1

Gestion des mtadonnes avec verrouillage

Nous dcrivons dans cette section les dtails de la gestion du catalogue avec JuxMem. Comme
nous lavons dj mentionn, un GT a besoin daccder au catalogue pour lire les mtadonnes
et les modifier. Avec lutilisation de JuxMem, un GT se comporte comme un client via--vis de
JuxMem. Par consquent, toute opration de lecture ou dcriture ncessite un verrou. Quand il
sagit dopration de lecture, un verrou partag est accord au lecteur tandis quun verrou exclusif
est fourni lors dune opration dcriture. Autrement dit, un GT fait une demande de verrou partag
quand il veut lire les mtadonnes et un verrou exclusif lorsquil veut crire dans le catalogue.
Conformment la spcification du routage, chaque fois quune transaction veut manipuler
une donne, le routeur doit accder au catalogue pour retrouver lensemble des nuds qui stockent
une copie de la donne, puis la modifier en cas de besoin. Supposons que lon ait deux transactions
T 1 et T 2 qui manipulent simultanment la mme relation Ri . Les deux transactions sont interceptes respectivement par GT 1 et GT 2. GT 1 accde la partie du catalogue qui contient M eta(Ri )
pour avoir la liste des nuds candidats en lecture. Pour ce faire, Juxmem va allouer un verrou
partag GT 1 qui le relchera ds quil finira sa lecture. A ce moment GT 2 acquiert un verrou
partag sur M eta(Ri ) et va lire la mme chose que GT 1. Si un des deux GT finit son traitement et
met jour le catalogue, la copie de M eta(Ri ) qui est en train dtre manipule par lautre GT est
errone. Pour viter ce problme, on utilise une mthode simple qui consiste demander et garder
un verrou exclusif durant tout le choix du nud optimal. Autrement dit, on fait toujours une lecture
avec intention dcriture. Ainsi, chaque fois quun GT dtient le verrou exclusif il fait toutes ses
oprations de lecture et dcriture avant de relcher les verrous.
Pour viter des situations dinter-blocages entre GT, les M eta(Ri ) sont ordonns suivant le
nom de la relation. Ainsi, le GT qui gre T rcupre les GSG(Ri ) en respectant cet ordre. Par
exemple, si T a besoin de manipuler R1 et R2, le GT demande dabord un verrou exclusif sur
M eta(R1 ) et tant que le verrou ne lui sera pas accord, le GT ne peut demander un verrou exclusif
sur M eta(R2 ). Cette situation ou un GT doit demander et obtenir tous les verrous pour commencer
le processus du routage est comparable la mthode de verrouillage deux phases.
Ce mcanisme a la lourde consquence daugmenter le nombre de transactions en attente dtre
routes au niveau dun GT puisque lattente dun verrou peut tre long ou indfini si toutefois le
GT qui le dtient est en panne. Pour viter ces problmes nous avons propos une solution sans
verrouillage laide dune DHT.

5.2.2

Gestion des mtadonnes sans verrouillage

Bien que le GSG ne soit pas verrouill par le NC, il faut sassurer que lorsquun GT modifie
un GSG, aucun autre GT ne modifie le GSG simultanment, sinon il y a risque dincohrence du
GSG. Un GT doit obtenir laccs exclusif au GSG avant de pouvoir le complter. Cela est ralis
par un accord entre les GT concurrents et en ordonnant les accs au GSG
Pour atteindre ce but, les GT dclarent leur intention de modifier les mtadonnes chaque
fois quils tentent de router une transaction de mise jour. Ce faisant, un GT utilise la primitive
get_for_update pour rcuprer un GSG. Toute demande daccs faite partir de cette primitive ne
peut tre rsolue que par le NC matre de la relation correspondante. Ainsi, le NC matre dtecte
90

5.2. Gestion des mtadonnes

les accs concurrents et peut informer les GT qui en ont besoin. Concrtement, chaque fois quun
GT sollicite un GSG, le NC matre lui donne une copie mais aussi dans le cas chant lui indique le
dernier GT qui a accd simultanment au mme GSG. Bien que le NC ne maintienne pas lordre
des GT effectuant des demandes concurrentes, cet ordre existe sous la forme dun chanage entre
les GT, car chaque GT connait son prdcesseur (Last). Un GT doit complter le GSG quil reoit
en contactant le dernier GT ayant lu le GSG avant lui. Les dtails de la gestion cohrente du GSG
sont donns ci-aprs.
Pour obtenir le GSG le plus cohrent, un GT contacte dabord la DHT et particulirement le
ou les NC matres de la portion des mtadonnes sollicits. Chaque NC matre contact, envoie au
GT le M eta(R) quil gre. Le M eta(R) contient les informations comme le GSG(R), ltat de
chaque rplique (State(Ri )) et le pointeur Last(R). A la rception de la rponse du NC matre, le
GT a deux alternatives :
i) si le pointeur Last(R) est vide, alors le GSG reu est le plus rcent et donc le GT effectue
son choix, i.e. dtermine le ND qui va excuter la transaction ;
ii) si le pointeur nest pas vide, cela signifie quil y a des accs concurrents, ainsi le GT
contacte le GT point par Last(R) pour obtenir des dernires modifications faites sur le
GSG avant de router la transaction.
Lutilisation du pointeur permet de connatre tout moment le dernier GT qui a accd au GSG
et donc de pouvoir retrouver les rcentes modifications qui y sont annexes. Quand un GT point
(Last(R)) est contact par un autre GT qui veut recevoir les dernires modifications, il envoie
uniquement le sous-graphe quil a obtenu des GT qui lont prcd et auquel il ajoute la dernire
transaction quil vient de router. En dautres termes, un GT point nenvoie pas le GSG global
mais uniquement le sous-graphe manquant au GT qui la contact. Lenvoi que du sous-graphe
manquant un GT minimise les informations transfrer et par consquent la surcharge.
A titre illustratif, la figure 5.5 schmatise le scnario pour construire un GSG cohrent en
cas daccs concurrent aux mtadonnes. Trois applications clientes soumettent trois transactions
T 1, T 2 et T 3 aux routeurs GT1 , GT2 , and GT3 respectivement. Les trois transactions mettent
jour la mme relation R. Pour router T 1, GT1 demande au NC matre le M eta(R) via lopration
getM etadata(T1 , R1 ) : le GSG et le pointeur Last sont initialement vide. Puis, GT2 voulant router T2 , demande au NC le M eta(R), et reoit Last=GT1 . Ainsi, GT2 contacte GT1 pour les mises
jour manquantes sur le GSG (getP reced(R)) ; GT1 lui envoie le sommet T 1. Par consquent,
GT2 reconstruit le GSG complet qui devient : T 1 T 2. Enfin, GT3 droule le mme procdure
que GT2 et obtient Last=GT2 . Alors, GT3 contacte son tour GT2 pour rcuprer le sous-graphe
manquant et obtient T 1 T 2. Ce faisant, GT3 reconstruit le GSG complet : T 1 T 2 T 3.
Quand une transaction T accde plusieurs relations, le GSG correspondant est obtenu en
runissant les diffrents GSG(Ri ). Cependant, laccs plusieurs relations peut engendrer des
problmes. Soient deux transactions concurrentes T1 et T2 . T1 souhaite modifier la relation R1
puis R2 alors que T2 dcide de modifier R2 avant R1 . Supposons que GT 1 se charge de router
T1 alors que GT2 soccupe de T2 . GT 1 demande au NC matre de R1 le GSG(R1 ) et GT 2 fait
la mme chose pour R2 . Alors quand chacun des GT cherchera de rcuprer le second GSG,
91

Chapitre 5. Routage des transactions

F IGURE 5.5 Routage concurrent

voici la situation qui arrive : pour GT 1, Last(R2 ) = GT 2 alors que pour GT 2, Last(R1 )=GT 1.
Ceci amne une situation de blocage des deux GT puisque chacun attend la rponse de lautre
pour pouvoir lui donner une rponse son tour, on parle de prcdence croise. Pour viter ce
problme, les M eta(Ri ) sont ordonns suivant le nom de la relation. Ainsi, le GT qui gre T
rcupre les GSG(Ri ) en respectant cet ordre. Par exemple, si T a besoin de manipuler R1 et R2 ,
le GT rcupre dabord GSG(R1 ) via M eta(R1 ) avant de rcuprer GSG(R2 ) dans M eta(R2 ).
Le graphe globale de T sera obtenu par GSG(T ) = GSG(R1 ) GSG(R2 ). Cette stratgie permet
dviter loccurrence des prcdence croise et donc de pourvoir construire toujours le GSG dune
transaction.
En conclusion, malgr le fait que les NC dlivrent des versions obsoltes du GSG, les GT sont
capable de reconstruire un GSG complet et cohrent avec une surcharge limite par un aller-retour
de communication. Le bnfice de cette approche est quun GT arrive router une transaction
sans attendre que les modifications faites sur les mtadonnes soient inscrites dans la DHT. Les
modifications sur les mtadonnes sont propages dun GT un autre, donc regroupes avant
dtre insres dans la DHT. Lcriture en bloc des modifications constituent galement un gain de
taille. En outre, nous mentionnons que le GSG reste de taille faible puisque que toute transaction
termine valide sur lensemble des rpliques) est soustraite du GSG.

5.2.3

Etude comparative des deux mthodes de gestion du catalogue

Intuitivement, la solution sans verrouillage est plus rapide que celle avec verrouillage car elle
demande moins de communication avec le catalogue. Plus prcisment, nous souhaitons quantifier
la diffrence de cot entre les deux solutions. Le cot pour obtenir laccs exclusif au GSG est
exprim en nombre de messages. Nous distinguons deux types de messages dont les cots diffrent.
Un message GT GT (ou NC GT) a un cot unitaire m correspondant une communication
92

5.3. Conclusion

directe entre deux noeuds. Un message GT NC a un cot plus lev car il doit effectuer plusieurs
sauts avant datteindre sa destination. Le nombre de sauts (not r) dpend de lorganisation des
nuds NC. La valeur de r est souvent suprieure 2, par exemple, avec notre implmentation de
JuxMem, r vaut 3, car il faut contacter un groupe local et ou un groupe global. De plus, notons que
r augmente avec le nombre de nuds grant le catalogue. Nous dtaillons le cot pour que GT 2
obtienne laccs exclusif lorsque GT 1 dtient le GSG.
1. Cot avec verrouillage
GT 1 demande et obtient le GSG ;
GT 2 demande le GSG au NC : r m ;
NC met en attente GT 2 ;
GT 1 renvoie le GSG modifi au NC : r m ;
NC accorde leGSG GT 2 : m ;
le nombre de message total est : C = (2r + 1)m
2. Cot sans verrouillage
GT 1 demande et obtient le GSG ;
GT 2 demande le GSG au NC : r m ;
GT 2 demande le GSG GT 1 : m
GT 1 envoie le GSG GT 2 : m
le nombre de message total est : C 0 = (r + 2)m
On ne prend pas en compte dans la deuxime solution le cot de transmettre le GSG modifi au NC
car cela est fait de manire dcouple et peu frquente. En faisant la comparaison des deux cots,
nous observons avec la mthode sans verrouillage, un bnfice de C C 0 = (2r+1)m(r+2)m =
(r 1)m.
Ce rsultat montre que si tous les NC se trouvent dans un mme rseau LAN et que chaque
NC connait tous les autres NC, alors les solutions avec verrouillage ou sans verrouillage sont
quivalentes car r = 1. Par contre, quand les NC sont sur diffrents LAN, comme dans le cas de
JuxMem, ou bien chaque NC ne connait que quelques NC (par exemple le cas des DHT), alors la
gestion des mtadonnes sans verrouillage est toujours meilleure puis que r est largement suprieur
un.

5.3

Conclusion

Nous avons dcrit dans ce chapitre, notre approche pour grer les traitements des transactions
et le catalogue rparti en cas daccs concurrents. Nous proposons deux approches pour srialiser
et router les transactions : une approche pessimiste base sur les conflits potentiels et une seconde
qui est plutt hybride puisquil fait un premier ordonnancement des transactions en se basant sur
les conflits potentiels, puis corrige cet ordonnancement en se basant sur les conflits rels. Notre
seconde approche favorise plus le paralllisme puisque les transactions sont excutes de manire
optimiste, ce qui est trs bnfique dans le contexte des applications web 2.0 o les conflits sont
rares. Pour maintenir la cohrence globale, nous avons conu un catalogue pour stocker les mtadonnes. Le catalogue est maintenu de tel sorte quil soit disponible et passant lchelle.
93

Chapitre 5. Routage des transactions

94

Chapitre 6
Tolrance la dynamicit des noeuds
La dynamicit, qui peut tre dfinie comme tant lattitude des nuds joindre ou quitter volontairement ou non le systme, est un aspect important prendre en compte lors dune conception
dun systme rparti grande chelle. Ceci est vrai pour la simple raison que la dynamicit a deux
impacts ngatifs dans le fonctionnement du systme : (1) une diminution de la capacit du systme
(quand plusieurs nuds quittent le systme) et (2) des pertes dinformations quand un nud quitte
le systme durant le traitement dune tche, ce qui peut entrainer des incohrences du systme.
Nous dissocions deux situations dans la gestion de la dynamicit : la dconnexion intempestive
dun nud que nous appelons panne dun nud et la dconnexion prvue dun nud. Le problme
des dconnexions prvues est assez simple rsoudre (cf. section 6.1). Cest pour cela ce chapitre
se concentre sur le cas des pannes.
Dans le chapitre prcdent, nous avons prsent les algorithmes de routage pour contrler lexcution cohrente des transactions. Cependant, ces algorithmes supposent que tous les nuds impliqus dans lexcution dune transaction ne tombent pas en panne. Cette hypothse est loin dtre
plausible dans le contexte dun systme grande chelle o les nuds qui composent le systme
peuvent tomber en panne tout moment. Pourtant, loccurrence des pannes peut entraner des situations dincohrences mme si le routage est fait de manire correcte. Pour illustrer le problme
introduit par les pannes, supposons quune application de vente en ligne A envoie une transaction
T pour acheter un objet. Lobjet se trouve dans deux rpliques R1i et R2i et il y a deux routeurs
GT 1 et GT 2. Supposons que GT1 reoit T et lenvoie sur R1i qui lexcute mais tombe malheureusement en panne avant denvoyer les rsultats A. Au bout dun moment, A nayant pas reu de
rponse, renvoie T . Supposons cette fois ci que T soit intercepte par GT 2. GT 2, nayant aucune
connaissance de la premire excution de T sur R1i , route T sur R2i . Si lexcution de T se droule
avec succs sur R2i , alors T est excute deux reprises et A aurait achet deux fois le mme objet. Pour viter ce genre de problme, il faut contrler loccurrence des pannes des nuds durant
lexcution des transactions.
Ce chapitre aborde la tolrance la dynamicit des nuds pour lalgorithme de routage dfini
dans le chapitre prcdent. Le systme de routage que nous proposons (cf chapitre 4) est redondant : il contient plusieurs nuds GT, et NC, et les donnes sont rpliques sur plusieurs nuds
ND. Il y a deux raisons cette redondance :
1. accroitre les ressources permet de traiter les transactions plus rapidement ;
95

Chapitre 6. Tolrance la dynamicit des noeuds

2. disposer de plusieurs nuds identiques permet dassurer une continuit de service malgr la
panne de certains nuds.
Cette dernire raison ncessite de concevoir un algorithme de routage capable de ragir correctement face loccurrence dune panne. Lobjectif principal de ce chapitre est de rendre lalgorithme
de routage tolrant aux pannes. Le deuxime objectif de ce chapitre est dtudier de manire thorique la disponibilit de notre systme dans le temps : quelles conditions garantissent quil y a
toujours au moins un nud actif (i.e. en service) pour traiter une transaction, autrement dit, comment dfinir le nombre de rpliques optimal pendant une priode donne afin davoir toujours un
nud disponible pour traiter la transaction.
Nous prcisons que nous tudions la dtection et la rsolution des pannes afin de maintenir la
cohrence et de borner le temps de rponse uniquement. Autrement dit, nous ne nous intressons
pas restaurer les nuds en panne.
Le reste de ce chapitre est organis comme suit. La section 6.1 prsente la gestion des dconnexions prvues. La section 6.2 dcrit les mcanismes utiliss pour faire face aux pannes. La
section 6.3 tudie le nombre minimal de rpliques en dessous duquel, le systme nassure plus la
disponibilit du systme.

6.1

Gestion des dconnexion prvue

Une dconnexion prvue survient si un nud dcide volontairement de quitter le systme et

en informe aux GT responsable du systme. Nous rappelons que nous intressons quaux dconnexions des GT et des ND qui peuvent compromettre la cohrence du systme.
Dconnexion prvue dun GT
Nous supposons que deux nuds GT adjacents (lis par la relation prdcesseur - successeur)
ne quittent jamais lanneau en mme temps. Ils le font lun la suite de lautre. La figure 6.1 dcrit
sommairement le processus de dconnexion dun GT. Quand GT2 qui a comme prdcesseur GT1
et comme successeur GT3 dcide de quitter le systme, il informe GT1 de son intention de quitter
lanneau. Pour ce faire, GT2 envoie un message Quitte Anneau (QA) GT1 en prcisant qui tait
son successeur. Cette information permet GT1 de savoir qui va devenir son nouveau successeur.
Par la suite, GT2 envoie un message Maj Anneau (MA) GT3 qui, la rception de ce message, met
jour sa vue (i.e. dfinit GT1 comme son nouveau prdcesseur). Durant la phase de dconnexion,
GT2 ignore simplement les messages entrants et particulier les transactions entrantes.
Dconnexion prvue dun ND
Si un ND veut se dconnecter, il envoie un message appel Requte Dconnexion (RD) au
dernier GT qui lui a envoy une transaction. Supposons comme le montre la figure 6.2, GTi est
le dernier GT qui ait contact ND1 et GTj lavant dernier GT. Donc ND1 contacte dabord GTi et
attend pendant une priode pour recevoir laval de ce dernier. Si ce GTi narrive pas rpondre
au bout de cette priode, ND1 contacte GTj . Si toutefois le GTj nest pas aussi disponible, ND1
96

6.1. Gestion des dconnexion prvue

F IGURE 6.1 Dconnexion dun GT

contactera le GT qui la contact avant GTj , et ainsi de suite. Quand GTj reoit le message RD, il
enlve ND1 de la liste des ND disponibles pour viter quun autre GT route une transaction vers ce
nud en cours de dconnexion. Par la suite, GTj envoie ND1 un message appel Dconnexion
Reue (DR), ce qui permet ce dernier de se dconnecter. Si aprs plusieurs tentatives de contacter
un GT, ND1 ny arrive pas, il se dconnecte et son dpart sera interprt comme une panne par tout
GT qui tentera de lui envoyer une transaction implicite (cf. section suivante).

F IGURE 6.2 Dconnexion dun ND

97

Chapitre 6. Tolrance la dynamicit des noeuds

6.2

Gestion des pannes

Dans cette section nous tudions les mcanismes de gestion des pannes dans le but de maintenir
la cohrence des donnes et de borner le temps de rponse en cas de pannes des nuds du systme.
Pour dtailler nos protocoles de gestion des pannes, nous prsentons les types de pannes que nous
prenons en compte dans cette tude. Puis nous dcrivons comment ces pannes sont dtectes puis
rsolues.

6.2.1

Modle et dtection de pannes

Dans cette section, nous prsentons les types de pannes que nous prenons en compte et comment elles sont dtectes.

Modle de pannes
Dans cete section, nous considrons les systmes constitus uniquement de deux types de composants : les nuds qui traitent les transactions (NA, ND et GT), et les canaux de communications.
Chacun de ces types de composants peut tomber en panne durant le fonctionnement du systme,
engendrant ainsi une panne de nud ou de communication. Les nuds du catalogue NC, sont
exclus car ils sont grs via une DHT ou JuxMem qui ont leur propre mcanisme de gestion des
pannes. Dans la suite de ce travail, nous axons notre rflexion sur les types de pannes suivants :
Panne dun nud. Quand un nud tombe en panne, ses traitements sarrtent anormalement, ce qui peut conduire des incohrences. Nous supposons quun nud fonctionne
correctement ou sarrte compltement (il est en panne). En dautres mots, nous ne prenons
en compte que les pannes franches et non les pannes byzantines ;
Panne de communication. Une panne de communication survient quand un nud Ni est
incapable de contacter le nud Nj , bien quaucun dentre eux ne soit en panne. Si une telle
panne survient, aucun message nest dlivr. Dans notre contexte, la communication est
asynchrone et chaque message reu par un nud doit tre acquitt. Sans cet acquittement,
nous supposons que le message est perdu cause dune panne de communication ou dun
nud.
Par ailleurs, chaque noeud (NA, GT, ND) qui rejoint le systme est capable de contacter un
noeud GT disponible. Le GT contact est alors responsable dinclure le nouveau nud en mettant
jour lanneau (arrive dun GT) ou le rpertoire partag (connexion dun NA ou ND). Comme
notre principal objectif est de prserver la cohrence quand un nud quitte le systme, nous restreignons notre tude aux pannes des GT et ND (si un NA quitte le systme, la cohrence du
systme nest nullement menace puisque le NA dlgue lexcution des transactions aux GT).
De plus, nous supposons quil y a toujours au moins un nud disponible (GT ou ND) sur lequel
on peut sappuyer chaque fois que lon dtecte une panne de nud. Autrement dit, il ny a pas
doccurrence simultane de pannes de tous les nuds du systme.
98

6.2. Gestion des pannes

Dtection des pannes

En gnral, les pannes sont dtectes soit par des messages priodiques de type heartbeat [ACT99],
soit la demande par des messages ping-pong [LAF99]. [CT96] prsentent les principes de dtection collaborative pour les systmes large chelle. Nous nous inspirons de ces travaux en combinant lutilisation des messages heartbeat et ping-pong. En effet, nous utilisons une dtection de
pannes la demande pour les ND et une dtection priodique pour les GT. Lutilisation des messages priodiques pour dtecter les pannes des GT se justifie par le nombre rduit de GT compar
celui des ND, gnrant moins de messages. En outre la dtection des pannes de ND se fait par
collaboration entre les GT, do limportance de dtecter le plus tt possible une panne de GT. Par
contre lutilisation de cette technique pour dtecter les pannes des ND engendrerait beaucoup de
messages du fait de leur nombre important. Ainsi, pour dtecter les pannes des ND sans surcot
significatif, on intgre la dtection dans le protocole de routage utilisant la mthode ping-pong.
De ce fait, un ND en panne nest dtect que si un GT essaie de lui envoyer une transaction. Pour
prendre en compte des pannes survenant lors de laccs au rpertoire rparti, nous nous appuyons
soit sur JuxMem qui empche quun lecteur (ou crivain) en panne verrouille laccs aux donnes
indfiniment, soit sur la DHT qui offre des primitives de rcupration ou de localisation de ressources mme en prsence de pannes, autrement dit, elle a ses propres mcanismes de gestion de
panne.
Les dconnexions prvues nont pas besoin dtre dtectes car elles sont dclares avant leur
occurrence par les nuds qui lexprimentent. Nous prsentons dabord les mcanismes de gestion
des dconnexions prvues avant de prsenter ceux des pannes.

6.2.2

Tolrance aux pannes

Dans loptique de grer les pannes, nous reprenons notre protocole de routage dcrit dans 5.1.2
en faisant abstraction de laccs aux mtadonnes. En effet laccs aux mtadonnes est considr
dans cette section comme tant une action interne dun GT. Ce choix dcoule du fait que nous
dlguons la gestion des pannes des nuds stockant les mtadonnes JuxMem ou la DHT. Le
protocole de routage peut tre dcoup en trois phases. La figure 6.3 reprsente le droulement du
processus dexcution de la transaction T en absence de pannes.
1. phase dinitialisation : Durant cette phase, un NA envoie T un GT ;
2. phase de routage : Le GT excute un des algorithmes de routage (voir section 5.1.4 et section 5.1.3) et envoie ainsi la transaction un ND ;
3. phase dexcution : Pendant cette phase, un ND reoit une transaction T , lexcute localement et envoie le rsultat au NA qui avait initi la transaction. Il informe aussi le GT qui la
contact que T a t correctement excute.
Dans la suite, nous utilisons les noms de messages dfinis dans la figure 6.3. A chacune des
phases de notre protocole, des pannes peuvent survenir, empchant alors lexcution correcte des
tches qui sont alloues aux GT et ND participant lexcution dune transaction. Suivant la phase
en cours, un nud (NA, GT ou ND) peut dtecter la panne dun nud participant lexcution
99

Chapitre 6. Tolrance la dynamicit des noeuds

F IGURE 6.3 Les phases dexcution dune transaction

de la transaction et donc essayer de la rsoudre. Ainsi, lors de la premire phase, un NA peut

exprimenter la panne dun GT et tente de rsoudre celle-ci, on parle alors de gestion des pannes
faite par le NA. De mme durant la phase de routage ou dexcution, un GT peut dtecter la panne
dun ND quil rsoudra : il sagit de la gestion des pannes faites par le GT. Enfin, durant la phase
dexcution, un ND peut dtecter la panne dun GT ou dun NA et on parle de gestion faite par un
ND. Dans les trois prochaines sections nous prsentons comment un nud arrive dtecter ou
suspecter une panne et comment il le prend en compte.
Gestion des pannes faite par le NA
Un NA envoie un message req un GT et initialise ensuite un temporisateur a (cf. figure 6.4).
Quand a expire, le NA conclut que le message req ou lacquittement ack1 est perdu cause dune
panne de communication ou du GT contact. Alors, NA retransmet le message req avec le mme
identifiant global. Pour accrotre les chances de russite de la retransmission, le NA incrmente
le nombre de GT cibles. Plus prcisment, le NA ajoute un GT de plus sur la liste des destinataires chaque fois quil retransmet req. Les GT candidats sont choisis parmi les GT connus par
le NA en utilisant lalgorithme du tourniquet. Remarquons que la cohrence ne peut tre compromise puisque la transaction nest transmise aucun ND pour excution. Mme si plusieurs GT
reoivent la mme transaction, cette dernire nest transmise qu un seul ND grce lutilisation
de lidentifiant global et de laccs exclusif au rpertoire partag.
Quand un NA reoit ack1 de la part dun GT, il arrte toute tentative de retransmission de req
et initialise un autre temporisateur s . Si le NA na pas de rsultats jusqu lexpiration de s , il
conclut que la transaction T est toujours en excution ou ses rsultats sont perdus ou T a chou.
Ce faisant NA envoie req aux GT prcdemment contacts (req ressemble req, mais signifie
aussi que le NA avait dj reu ack1). Afin de rduire les retransmissions inutiles, les valeurs des
100

6.2. Gestion des pannes

temporisateur sont bases sur la latence du rseau et le temps moyen dexcution des transactions.
Do, a 2 N et s 2 a + D + Avg(T ) avec N la latence du rseau, D est le temps
pour lire/crire sur le rpertoire partag et Avg (T) est le temps moyen dexcution de T .

F IGURE 6.4 Comportement du NA en fonction des temporisateur

Gestion des pannes faite par le GT

A la rception dun message req, le GT envoie lacquittement ack1 au NA. Ensuite, le GT
vrifie si la transaction T est termine ou est encore en excution. Si T nest pas mentionne dans
le rpertoire partag, alors le GT route T vers un ND (ceci vite dexcuter deux fois la mme
transaction).
A la rception dun message req de la part dun NA, trois cas peuvent tre identifis en fonction
de ltat de la transaction T :
1. si T est dj excute sur le nud NDi , alors le GT retransmet T sur NDi . Ce cas survient,
si le rsultat de lexcution de la transaction na pu tre envoy cause dune panne de communication ;
2. si T est en progression (dj route mais non encore excute), alors le GT rpond par un
message wait au NA. Ce cas se prsente quand T dure plus longtemps que prvu cause dune
panne dun nud ND ;
3. si T nest pas mentionne dans le rpertoire partag, alors le GT achemine T vers un ND.
Ce cas est identifi si le GT tombe en panne avant de choisir un ND (donc avant dcrire sur le
rpertoire partag).
A chaque valuation de lalgorithme de routage, le GT garde la liste des ND candidats tris
suivant lordre croissant du cot. Par la suite, le GT envoie le message proc au premier candidat
NDi , et initialise un temporisateur a . Une fois que le message ack2 est reu, le GT inscrit dans le
101

Chapitre 6. Tolrance la dynamicit des noeuds

rpertoire partag que T est en cours dexcution. A partir de ce moment, il initialise un second
temporisateur r .

F IGURE 6.5 Comportement du GT en fonction des temporisateur

Quand a et r expirent, le GT conclut quune panne de communication ou du ND est survenue.

Il envoie alors le message proc au prochain candidat NDj sur la liste (cf. figure 6.5). En parallle, il
invoque le module de dtection de pannes (cf. figure 4.6) qui vrifie si NDi est disponible ou non.
Pour cela, il contacte son prdcesseur et son successeur et chacun dentre eux essaie dentrer en
contact avec NDi en lui envoyant un message. Les rsultats de ces changes sont envoys au nud
initial. Si tous les rsultats sont ngatifs, il conclut que NDi est en panne et lajoute dans la file des
nuds en panne, appele FNP et stocke dans le rpertoire partag. Par contre, si au moins un des
rsultats est positif, le GT suppose quil y a une panne de communication temporaire entre lui et
NDi . Il peut donc considrer NDi comme un candidat potentiel lors des prochains routages.
Le GT utilise galement cette mme procdure quand un nud ND voulant valider une transaction T le contacte lexpiration du temps de dcision T D (cf. section 13).
Quelle que soit la cause de ce retard, le GT vrifie que les transactions correspondantes aux
DataSet(Ti ) manquants sont dj excutes en consultant le catalogue rparti.
Dans laffirmative, il essaie de rcuprer les DataSet(Ti ) manquants et de faire la vrification
ncessaire. Si malgr cette tentative, il narrive pas rcuprer tous les DataSet(Ti ) manquants
ou mme que les transactions correspondantes ne sont pas encore excutes, alors le GT envoie
directement au ND les transactions manquantes en tenant compte des vrifications positives faites
avec DataSet(Tk ) qui ont pu tre rcuprs. Prcisment, si avec les DataSet(Tk ) dj reus, le
GT dtecte des conflits il demande au ND de reprendre la transaction T . Par contre, sil existe des
transactions qui ne sont pas rellement en conflit avec T , le GT avise le ND en lui donnant une
nouvelle squence de contraintes de prcdence.
Si un nud NDj excutant une transaction Ti qui prcde T narrive pas tre joint par le GT,
102

6.2. Gestion des pannes

ce dernier lance le module de dtection de pannes.

Le gestionnaire des pannes, appel module de reprise sur panne (cf. figure 4.6), est charg
de vrifier la reprise de chaque nud en panne et de lenlever de la file FNP comme dcrit dans
[CT96].
Finalement, quand un GT reoit un message eot de la part dun NDi , il met jour le rpertoire
partag en mentionnant que T est excute sur NDi , et il envoie un acquittement ack3 NDi .
La valeur de r est proportionnelle la latence du rseau et au temps moyen dexcution de T .
Nous dfinissons r a + Avg(T ). Pour viter les messages inutiles, nous posons r < s de tel
sorte quun NC ne peut retransmettre une requte avant quun GT nait la possibilit de dtecter
une potentielle panne du ND.
Gestion des pannes faite par le ND
A la rception dun message proc, le ND rpond au GT par lenvoi de lacquittement ack2. Le
ND vrifie dabord si T nest pas dj excute (en consultant son journal). Dans la ngative, le
ND excute T . Si T a fini de sexcuter, le ND rpond par un message res (contenant le rsultat
de lexcution de T ) au client qui a initialis T . Si toutefois, T a dj t excute, le ND envoie
un nouveau message res au NA. Le ND rpond galement par un message eot au GT, et initialise
un temporisateur a . Quand a expire, le ND conclut quil y a une panne de communication ou du
GT. Alors, il ajoute un message eot dans un buffer pour lenvoyer lors de la prochaine notification
en utilisant la technique de piggybacking. Ceci a pour objectif de rduire le nombre de messages
envoys au GT par rapport une stratgie de tentatives priodiques.
En outre, nous remarquons que si le nud suspect a dj trait la transaction avant de tomber
en panne, alors lexcution de T sur un autre ND ne compromet pas la cohrence, puisque lexcution de toutes les transactions est faite de manire similaire sur tous les nuds (i.e. avec un ordre
de prcdence global).

6.2.3

Majoration du temps de rponse

Comme dcrit prcdemment, notre protocole de routage se termine malgr la prsence de

pannes. Nanmoins, le dlai pour excuter totalement une transaction augmente proportionnellement avec le nombre de pannes. Plus le nombre de retransmissions ncessaires pour excuter une
transaction est grand, plus le temps dexcution slve. Pour dmontrer lefficacit de notre approche, nous montrons que le nombre dessais requis pour excuter une transaction est souvent
faible. Dans cette perspective, nous notons avg(T ), le temps moyen dexcution dune transaction,
la taille
N , la latence moyenne du rseau, D , le temps daccs moyen au rpertoire partag et S,
de la squence de rafrachissement. En absence de toute panne, le temps ncessaire pour excuter
T est :
time(T ) = 3 N + (S + 1) avg(T ) + D
Si un GT et/ou un ND participant lexcution de T tombe en panne, alors dans le pire des cas,
la transaction va tre excute aprs k tentatives inities par le NC. Soit k le nombre de tentatives
103

Chapitre 6. Tolrance la dynamicit des noeuds

requises lors de lexcution de T , alors le temps total dexcution de T est :

timek (T ) = k time(T ) + (k 1) s
Supposons que p est la probabilit quune transaction tombe en panne (i.e. NC na reu aucun
rsultat) et X une variable alatoire reprsentant le nombre de tentatives.
P (X = i) = (1 p) (p)i1 est la probabilit que les (i-1) premires tentatives ont chou et
que la ime a russi. Le nombre de tentatives excutes est obtenu avec la formule suivante :
E(X) =

n
X

i P (X = i) = (1 p) (

i=0

n
X

i pi1 )

i=0

P
i1
possible de E(X) est E(X) < (1 p) (
). En remplaant
i=0 i p
PUne majoration
1
i1
par sa limite (1p)2 , on obtient :
i=0 i p
E(X) <

1
(1 p)

1
Par consquent, nous pouvons estimer le nombre de tentatives : k d 1p
e. Par exemple, k=2
pour une probabilit de panne infrieure 50 %. A partir de ces rsultats, nous concluons que le
nombre de tentatives dexcuter une transaction est born et il est faible.

6.3

Gestion contrle de la disponibilit

Dans la section prcdente, nous avons dcrit les mcanismes pour faire face aux pannes des
nuds lors dun traitement dune transaction. Cet algorithme suppose quil existe toujours un
nud sur lequel une transaction peut tre reprise. Nous allons tudier comment peut on garantir
cette hypothse en contrlant le degr de la rplication. Comme nous lavons spcifi dans la
section 2.3.3, la rplication permet de masquer les pannes, puisqu chaque fois quun nud tombe
en panne, un autre nud peut tre utilis pour poursuivre les traitements que le nud en panne
effectuait. Cela suppose quil existe au moins un nud sur le systme capable de faire le traitement
du nud en panne, ce qui nous amne la dfinition suivante.
Dfinition 14. Un systme est dit disponible, sil existe au moins un nud non en panne (appel
remplaant) qui peut continuer faire les traitements que le nud en panne faisait.
Sil sagit dun nud ND, le nud remplaant doit tre capable de faire les transactions du
nud en panne et sil sagit dun GT, il doit tre capable de router les transactions.
Avec cette dfinition, il apparat que pour rendre un systme disponible il suffit de garantir la
prsence dau moins un nud remplaant tout moment pendant une priode fixe.
Dans cette section nous prsentons un modle qui nous permet de savoir le nombre de rpliques
minimal pour garder le systme disponible pendant un intervalle de temps. Pour ce faire, nous
proposons une approche base sur la probabilit (ou frquence) des pannes. En effet, connaissant la
104

6.3. Gestion contrle de la disponibilit

probabilit doccurrence des pannes, nous dfinissons le nombre minimal de rpliques ncessaires
pour rendre le systme disponible pendant un intervalle de temps. Pour ce faire, nous supposons
que les pannes sont franches (cf. section 6.2.1).
Le calcul de la probabilit de pannes dans un systme distribu est un problme rsolu de
longue date. Dans [OV99], les auteurs arguent que loccurrence des pannes suit une distribution de
Poisson. De cette hypothse, la probabilit des pannes est donne par :
Pk =

(t)k t
e
k!

(6.1)

Pk reprsente la probabilit que k pannes surviennent durant lintervalle de temps t et le taux

doccurrence des pannes pendant t.
Partant de cette probabilit, nous dterminons le nombre minimal de rpliques ncessaire pour
que loccurrence de k pannes ne rend pas indisponible le systme. Pour ce faire, supposons , le
taux darrive des pannes, Ptol , la probabilit de panne des nuds que lon veut tolrer pendant
lintervalle de temps t (i.e. le nombre de pannes qui ne doit pas compromettre la disponibilit).
Pour assurer la disponibilit durant t, nous avons besoin de dfinir K le nombre de rpliques tel
que PK > Ptol .
Soit m tel que : m < K, PK < Ptol Pm .
Pour m = 2, P2 Ptol et nous pouvons obtenir par addition de termes P1 + 2P2 Ptol + 2Ptol .
Pour m = 3, P3 Ptol et P1 + 2P2 + 3P3 Ptol + 2Ptol + 3Ptol .
En continuant ce raisonnement jusquau rang m, nous obtenons lingalit suivante dont la partie
droite est une suite arithmtique puisque Ptol est constante.
P1 + 2P2 + ... + mPm Ptol + 2Ptol + ... + mPtol

(6.2)

En faisant le calcul de la somme de la suite arithmtique, nous obtenons :

m
X

m(m + 1)
Ptol
2

nPn

n=1

(6.3)

Ensuite, en remplaant Pn par sa valeur dans 6.3, nous obtenons :

e

m
X
(t)n
m(m + 1)

Ptol
(n 1)!
2
n=1

(6.4)

Lajout de quelques termes positifs dans la partie gauche de lquation 6.4 ne change pas le sens
de lingalit et donne :
t

t.e

m1
X

n=0

(t)n X (t)n
m(m + 1)
+
]
Ptol
(n)!
(n)!
2
n=m

Ceci est quivalent :

t.et

X
(t)n
n=0

(n)!

105

m(m + 1)
Ptol
2

(6.5)

(6.6)

Chapitre 6. Tolrance la dynamicit des noeuds

Par ailleurs, comme

(t)n
n=0 (n)!

= et alors, lingalit 6.6 devient :

t

m(m + 1)
Ptol
2

(6.7)

En posant m = K - 1, nous obtenons linquation suivante m2 + m P2t

0 dont la rsolution
tol
aboutit :
r
1 2t 1
+
e
(6.8)
K>d
4 Ptol 2
La formule 6.8 permet de dterminer le nombre de rplique suffisant pour tolrer une probabilit de pannes Ptol dont le taux doccurrence des pannes est . Par exemple, soit un systme avec un
taux darrive des pannes gal 0.005 ( = 0.005) et un intervalle de temps t gal 1000 secondes.
Nous calculons le nombre de pannes moyen durant t par t = 5. Par consquent, en utilisant
la formule 6.8, le nombre de rpliques est K > d7.06575e. Intuitivement, il est clair quavec 7
rpliques, il existe au moins un nud disponible durant t malgr loccurrence de 5 pannes.

6.4

Conclusion

Dans ce chapitre, nous avons prsent un mcanisme de gestion de la dynamicit. Ce mcanisme est bas sur la dtection slective des fautes et sur un algorithme de reprise. Contrairement
la plupart des autres approches, notre mcanisme nimplique pas lutilisation de nuds qui ne participent pas lexcution de la transaction en cours, ce qui le permet de passer lchelle. Pour cela,
nous adaptons des approches existantes de dtection des pannes afin de les rendre oprationnelles
pour chaque type de nud (gestionnaire de transaction et nud de donnes) de notre systme.
Nous avons propos un protocole permettant de grer toutes les situations lorsquun nud quitte
le systme pendant le traitement dune transaction. Ceci est ncessaire et suffisant pour contrler
la cohrence du systme, surtout en cas de dconnexions intempestives.
Cependant, pour garder le dbit transactionnel constant en cas de frquentes pannes, il faut
tre capable dajouter de nouvelles ressources en fonction des dconnexions. Pour ce faire, nous
avons propos un modle pour dterminer et contrler le nombre de rpliques requises pour garder
le systme disponible. Autrement dit, ce modle permet de dterminer le nombre minimum de
rpliques ncessaires au bon fonctionnement du systme et donc de minimiser les surcots lis la
gestion des rpliques. Cette tude ncessite dtre complte pour dterminer la manire dajouter
ou de rduire le nombre de rpliques en fonction de lvolution de la charge du systme ou de sa
dynamicit.

106

Chapitre 7
Validation
Pour valider la faisabilit de nos approches, nous avons implment et expriment deux prototypes nomms respectivement D TR (Distributed Transaction Routing) et T RANS P EER (TRANSaction on PEER-to-peer).
Puis, nous avons effectu des simulations pour tudier le passage lchelle et la tolrance
aux pannes de notre solution. Nous mentionnons que limplmentation de deux prototypes est lie
au besoin de grer le catalogue avec verrouillage ou sans verrouillage. De fait, D TR constitue le
prototype dvelopp avec verrouillage en sappuyant JuxMem. T RANS P EER est conu pour la
gestion du catalogue sans verrouillage et pour un modle de communication de type P2P entre
les composants du routeur et sappuie sur FreePastry [Fre]. De plus, notre algorithme de routage
pessimiste est implment dans D TR alors que lapproche hybride lest avec T RANS P EER.
De plus, notre choix dutiliser la fois de lexprimentation et de la simulation se justifie par
le fait que : (1) lexprimentation permet dvaluer un systme dans des conditions relles ; et (2)
la simulation est une reprsentation simplifie du systme, facile raliser et requiert moins de
ressources que limplmentation, ce qui favorise lvaluation dun systme grande chelle. Nous
avons men une srie dexpriences sur nos deux prototypes pour tudier les performances de notre
systme : dbit transactionnel, temps de rponse, passage lchelle et tolrance aux pannes.
Notons dores et dj que nous navons fait quune validation partielle du passage lchelle de
notre solution, autrement dit, notre solution nassure pas un grand passage lchelle. Nanmoins
les expriences effectues nous ont permis de savoir les impacts de nos diffrents choix sur le
passage lchelle. Nous dcrivons dans le section 8.2 (Perspectives), comment nous comptons
assurer ce passage lchelle.
Pour ce faire, nous tudions dabord la surcharge lie la gestion du catalogue dans la section
7.1, puis la section 7.2 les performances globales du routage et enfin les apports de la gestion des
pannes sont dcrits dans la section 7.3.

7.1

Evaluation de la gestion du catalogue

Dans cette section nous valuons les performances de la gestion du catalogue. Nous vrifions
que laccs au catalogue lors du routage nest pas une source de congestion, i.e. il ne ralentit pas le
107

Chapitre 7. Validation

Charge applicative
GT concurrents
Taux de conflit
Granularit
Degr de rplication

nombre de NA (10 80)

Nombre de GT en concurrence (1 2)
Nb total daccs concurrents / Nb total daccs (0% 100%)
Relation
Nombre de rpliques dune relation Ri

TABLE 7.1 Paramtres dvaluation de laccs au catalogue

routage des transactions.
Pour atteindre ces objectifs, nous utilisons chacun de nos deux prototypes pour mener des
sries dexpriences. Pour chaque exprience, nous mesurons le dbit du routage en faisant varier
les paramtres de notre systme qui sont regroups dans le tableau 7.1. Nous terminons par une
analyse de nos approches de gestion du catalogue, en nous plaant dans le contexte des applications
Web 2.0.
La charge applicative est constitue alatoirement de requtes et de transactions envoyes par
les NA. Un NA envoie une transaction puis attend la rponse avant denvoyer une autre. Tous les
NA ont la mme priorit i.e. leurs transactions sont traites sans tenir compte du type de lapplication. Toutes les transactions ont la mme granularit (Relation) et accdent aux donnes de manire
alatoire. La base de donnes est rpartie sur les ND de sorte quune transaction sexcute sur un
ND. Le taux de conflit, not C est dfini par le nombre total de transactions en conflit potentiel
sur le nombre total de transactions courantes. Soit TT lensemble des transactions en cours et TC ,
C|
.
lensemble des transactions en conflits, alors C = |T
|TT |

7.1.1

Surcharge de la gestion du catalogue dans D TR

Cette section prsente une srie dexpriences destines valider le modle de gestion des
mtadonnes avec verrouillage prsent dans la section 4.3.2. Ces rsultats ont fait lobjet de publications en 2008 dans la confrence nationale BDA [SNG08b] et dans le workshop international
HPDGRID [SNG08a] et en 2010, dans la revue nationale RSTI -ISI [SNG10a].
Environnement exprimental
D TR est implment avec le langage C et sappuie sur les services de JuxMem, qui est conu audessus de la plate-forme JXTA de Sun. JuxMem fournit des accs une mmoire virtuelle partage
travers une grille. Nanmoins, nous remarquons que notre systme est faiblement dpendant de
JuxMem, puisque JuxMem est utilis comme une API (une librairie). Nous pourrions donc utiliser
tout logiciel qui fournit une API daccs une mmoire virtuelle partage.
Nous avons effectu toutes les expriences sur un cluster de 20 nuds sur lesquels sexcutent
les GT, les NC et les ND avec Postgresql comme SGBD sous-jacent pour stocker les donnes. Nous
avons utilis les ordinateurs personnels des membres du laboratoire pour faire tourner les NA. Ceci
constitue au total un environnement de 40 machines physiques. Tous les nuds (P4, 3GHz, 2Gb
RAM) sont interconnects par un rseau local Fast-Ethernet 1 Gbit/s.
108

7.1. Evaluation de la gestion du catalogue

Impact de laccs au catalogue partag

Les premires exprimentations sintressent au routage proprement dit. Elles mesurent la surcharge engendre par lutilisation dun rpertoire partag pour stocker les mtadonnes. La charge
applicative est gnre par un nombre croissant dapplications, chacune dentre elles ne peut pas
envoyer plus dune transaction par seconde un routeur. Nous mesurons le dbit (en transactions
/ seconde) quun routeur peut assurer. La figure 7.1 montre que chacun des routeurs peut traiter
jusqu 40 transactions/seconde. Par ailleurs, la figure montre quau del de 40 applications (ou 40
transactions par secondes) le dbit du routage reste constant. Cela est d par le fait que chaque processus de routage requiert un accs au catalogue et un calcul du nud optimal qui est dure environ
24 millisecondes. Par consquent, au del dune charge applicative 40 transactions par seconde,
le routeur nest plus capable de les traiter toutes en moins dune seconde. Cependant, les rsultats
montrent que le temps daccs au catalogue est faible, autrement dit, le temps daccs au catalogue
est acceptable.

F IGURE 7.1 Dbit dun seul routeur avec DTR

Pour confirmer ce rsultat et valuer davantage le cot de cet accs, nous augmentons la taille
du rpertoire en ajoutant de nouvelles rpliques, puisque plus de rpliques (ND) impliquent plus
de mtadonnes et donc plus de temps pour les rcuprer et les manipuler. De plus, un grand
nombre de rplique requiert plus de temps pour dterminer le nud optimal. Nous reportons dans
la figure 7.2, le dbit trait dans trois situations : petite, moyenne et grande taille du rpertoire
(respectivement 5, 50, 100 rpliques). Nous mesurons une baisse des performances infrieure 20
% pour une grande quantit de mtadonnes (100 rpliques). Pour un degr de rplication moyen
(par exemple 50 rpliques), la baisse est uniquement de 5 %. Ceci montre que le rpertoire pnalise
peu les performances. Ce rsultat est une consquence de notre choix architectural de fragmenter
les mtadonnes et de ne garder dans le catalogue que les transactions non encore propages sur
tous les ND. De plus, ce rsultat est important si on se rfre notre contexte o le nombre de
109

Chapitre 7. Validation

transactions est si important que les garder toutes ncessiterait un espace de stockage considrable
pouvant ralentir la recherche dinformations dans le catalogue.

F IGURE 7.2 Surcharge du rpertoire

Impact de laccs concurrent

Nous tudions limpact de laccs concurrent de plusieurs routeurs au rpertoire partag. La
charge applicative est gnre de la mme manire que les premires exprimentations, cependant
les transactions sont envoyes 2 routeurs de telle sorte que la moiti de la charge va sur chacun
des nuds. Les rsultats de la figure 7.3 sont obtenus dans le pire des cas (i.e. toutes les transactions
accdent la mme relation, conduisant les routeurs accder au mme Meta(R)). Ces rsultats
montrent un dbit maximal de 21 transactions/seconde, cest--dire la moiti dun seul routeur. En
effet, lattente dun verrou dgrade considrablement les performances. Nanmoins, dans le pire
des cas o chaque accs au rpertoire est retard par un autre accs concurrent sur la mme donne,
le routeur est encore capable de fournir de bons rsultats. Bien que ce rsultat soit acceptable, nous
tentons de lamliorer en rduisant lattente au niveau de laccs aux mtadonnes par suppression
de lutilisation des verrous. Pour ce faire, nous utilisons la section suivante notre second prototype
et faisons varier le degr de concurrence entre 0 % et 100 % afin de mesurer rellement limpact
de lattente au niveau du catalogue.
110

7.1. Evaluation de la gestion du catalogue

F IGURE 7.3 Accs concurrent avec DTR

7.1.2

Surcharge de la gestion du catalogue dans T RANS P EER

Cette section prsente une srie dexpriences destines valider la gestion des mtadonnes
avec une DHT. Ces rsultats ont fait lobjet de publications en 2010 dans la confrence internationale SAC [SNG10b].

Environnement exprimental
T RANS P EER est implment avec Java 1.6 (5000 lignes de code), et peut tourner sur nimporte
quel systme qui supporte la machine virtuelle JVM 1.6. Chaque composant est dvelopp comme
une seule application Java et par consquent on peut le rpliquer autant de fois que lon souhaite. La
couche de communication P2P entre les nuds est conu avec la version libre de Pastry [RD01a]
savoir FreePastry. Pour stocker les mtadonnes, nous utilisons la DHT PAST[RD01b]. Nous
utilisons PostgreSQL comme SGBD pour stocker les donnes, puis nous passons par JDBC et des
rgles actives (triggers) pour extraire les modifications faites par les transactions. Les donnes sont
partitionnes dans des relations et chaque relation est rplique sur plus de la moiti des ND. Nous
effectuons nos expriences dans un environnement rel compos de 20 machines (P4, 2.4GHz, 2Gb
RAM) connectes par un rseau qui supporte 100 autres machines en mme temps. Les expriences
sont faites pendant que les autres machines sont utilises afin de se placer dans des conditions plus
ralistes.
111

Chapitre 7. Validation

Impact de laccs au catalogue partag

Comme avec D TR, nous valuons la surcharge li lutilisation du catalogue pour router les
transactions. La charge applicative est envoye par un nombre croissant de NA ; chacun envoie une
transaction par seconde un routeur. Nous mesurons le dbit (en transactions / seconde) que le
routeur peut assurer. La figure 7.4 montre quun seul routeur de T RANS P EER peut excuter plus de
50 transactions par seconde, ce qui reprsente 25% de plus que le dbit dun routeur de D TR. Cette
amlioration du dbit du routage dcoule de la suppression des verrous lors de laccs au catalogue.
En effet, pour crire sur le catalogue via JuxMem, un GT (client de JuxMem) initie toujours une
communication avec les leaders du groupe de donnes sollicites (Local Data Group si laccs
local est possible ou Global Data Group dans le cas ou la donne est rplique sur des clusters
distants). Cette communication nest rien dautre quune forme de synchronisation entre les leaders
des diffrents sites sur lesquels la donne est rplique afin de fournir un verrou exclusif au GT. Par
contre, avec T RANS P EER, le GT contacte directement le NC matre pour rcuprer directement les
mtadonnes, ce qui rduit le temps de routage et donc augmente le dbit transactionnel.

F IGURE 7.4 Dbit dun seul routeur avec TransPeer

Impact de laccs concurrent

En restant dans les mmes conditions dexprimentation, nous valuons limpact de laccs
concurrent de plusieurs routeurs. La charge applicative est envoye deux GT de tel sorte que
chacun reoit la moiti des transactions. Dans la figure 7.5, nous observons que le dbit du routage maximal est de 32 transactions/seconde quand le taux de conflit est de 100 %. Cependant,
contrairement D TR, la dgradation du dbit nest que de 40% par rapport un seul routeur. Cette
diminution sexplique par le fait que lors des accs au catalogue, les GT contactent dabord la DHT,
112

7.1. Evaluation de la gestion du catalogue

puis schangent des informations pour retrouver le GSG complet . De plus, cette change dinformations entre GT est aussi source dune surcharge qui est une consquence directe de laccs
concurrent au catalogue. En effet, puisque nous avons utilis Pastry [RD01a] pour implmenter
T RANS P EER, alors le cot daccs la DHT est de log2b (N ), avec N le nombre de nud NC.
Ainsi, pour our construire le GSG le plus cohrent, le nombre de messages envoys par GT1 est de
2m+1 + log2b (N ) avec m le nombre de GT qui ont prcd GT1 . Prcisment, lopration get(k)
cote 2 messages alors que les changes avec les GT prcdant GT1 correspondent 2m messages.
Cependant comme nous lavons dcrit dans le chapitre 5, le GT ne contacte que le dernier GT
parmi tous les GT qui lont prcd, ce qui fait que le cot devient 22 + log2b (N ). Ce cot est
indpendant du nombre de GT et donc du nombre de transactions courantes, raison pour laquelle
nous confirmons que la surcharge de la gestion du catalogue sans verrouillage est ngligeable et
quelle surpasse celle avec verrouillage en favorisant un dbit plus grand.

F IGURE 7.5 Accs concurrent avec TransPeer

7.1.3

Analyse de la surcharge du catalogue

Les rsultats prsents dans les deux sections prcdentes montrent que lutilisation du catalogue lors du routage ne cre pas trop de surcharge. Ce rsultat est dautant plus vrai que dans le
cas daccs concurrent le dbit minimal est de 1260 transactions/minute pour un seul routeur (avec
2 GT). Ce dbit minimal est obtenu dans le pire des cas (i.e. quand le taux de conflit est 100%
de conflit). Pourtant, un taux de conflit 100% est peu probable. De plus, mme si les transactions touchent les mmes donnes, laccs aux mtadonnes ne se fait pas toujours simultanment
cause de la latence du rseau et de la position des GT par rapports aux NC dans le systme. En
dautres termes, deux transactions en conflits peuvent tre interceptes par deux GT qui leur tour
naccderont pas simultanment aux mtadonnes, mais plutt de manire squentielle.
113

Chapitre 7. Validation

Pour vrifier cette affirmation, nous avons men une srie dexprience avec T RANS P EER pour
mesurer le taux de conflit rel au niveau des mtadonnes. Nous voulons savoir si deux transactions
conflictuelles envoyes deux GT au mme moment engendrent toujours un accs concurrent au
niveau du catalogue. Pour ce faire, nous utilisons une charge applicative gnre par deux NA et
envoye deux GT. Nous avons fait varier le taux de conflit au niveau des NA, i.e. taux de conflits
des transactions C envoyes par les NA, de 0% 100%. Puis nous avons mesur le taux de conflit
observ au niveau du catalogue. Le taux de conflit au niveau du catalogue AC , est dfini comme
tant le nombre total de GT qui sollicite un mme M eta(R), NC sur lensemble des GT, NT qui
C|
.
ont accd au catalogue, autrement dit, AC = |N
|NT |
Les rsultats de la figure 7.6 montrent que mme si le taux de conflits C est de 100%, le taux
de conflits C nest que nest que de 70%. Par consquent, les conflits aux niveau des transactions
nentranent pas forcment des conflits au niveau du catalogue, ce qui confirme notre prcdente
affirmation sur les conflits rels au niveau du catalogue.

F IGURE 7.6 Dbit dun seul routeur avec TransPeer

Paralllement nous tudions la diminution du dbit de routage quand le taux de conflit des NA
augmente. Les rsultats de la figure 7.7 montrent une diminution faible et progressive du dbit de
routage quand le taux de conflit varie. Par exemple avec un taux de conflit de 25%, la dbit na
baiss que de 5%. Cette diminution progressive est une consquence directe de la rapidit de notre
processus de routage qui fait que les GT librent trs vite laccs au catalogue.
De plus, dans le contexte des applications Web 2.0 o les utilisateurs ne modifient que leurs
propres donnes, les taux de conflits sont encore plus faibles. Ceci nous pousse affirmer que notre
solution de gestion de catalogue, qui a un faible impact sur le dbit du routage, sadapte bien aux
applications Web2.0 dautant plus que lutilisation dun catalogue dans de tels systmes permet de
contrler la cohrence des donnes mais aussi ltat du systme.
114

7.2. Evaluation des performances globales du routage

F IGURE 7.7 Accs Concurrent avec TransPeer

7.2

Evaluation des performances globales du routage

Dans cette section nous valuons les performances de notre routage. Comme nous prenons en
compte la fracheur lors de notre processus de routage nous tudions trs brivement limpact du
relchement de la fracheur dans notre systme. Nous prsentons ensuite les performances de notre
processus de routage et enfin, nous concluons cette section par une analyse de notre approche.

7.2.1

Impact du relchement de la fracheur

Dans cette section, nous tudions et mesurons linfluence du relchement de la fracheur sur
les performances en termes de temps de rponse et dquilibrage de charge. Pour ce faire, nous
nous plaons dans le mme environnement exprimental dcrit dans la section 7.1.1. Nous avons
choisi une taille intermdiaire : 40 applications (20 pour des mises jour et 20 pour des lectures)
et 20 ND. Chaque application envoie 40 transactions durant toute lexprience, ce qui donne un
nombre total de transaction gal 1600. Nous faisons varier lobsolescence tolre des transactions
de lecture. La figure 7.8 montre le temps de rponse des transactions en fonction de lobsolescence
tolre (exprime en nombre de mises jour manquantes). Les rsultats rvlent quaugmenter
lobsolescence tolre diminue considrablement le temps de rponse. Cela est principalement d
au fait que relcher la fracheur donne plus de souplesse pour retarder la synchronisation, et donc
lexcution des transactions se fait de manire plus rapide. Nous notons que si le degr dobsolescence dpasse 15, le temps de rponse ne saccrot plus. La raison est que le temps de rponse
minimal dexcution dune transaction est atteint. La valeur prcise 15 dcoule de la configuration
de la taille de notre systme, i.e. un nombre dapplications et de ND diffrents de celui que nous
avons considr engendrerait une valeur diffrente de 15.
Bien entendu, le relchement de la fracheur saccompagne dune perte de cohrence mutuelle
des rpliques. La figure 7.9 montre lobsolescence des donnes la fin de lexprience, en fonction de lobsolescence tolre des transactions de lecture. Heureusement, le nombre de transac115

Chapitre 7. Validation

F IGURE 7.8 Temps de rponse vs. obsolescence tolre

tions manquantes croit faiblement (avec une tendance logarithmique) quand lobsolescence tolre
augmente. Pour une obsolescence tolre de 24 transactions, le nombre cumul de transactions
manquantes sur tous les ND nest que de 315 soit moins de 20 % du nombre total de transactions
envoyes (1600) durant lexprience avec cependant une diminution du temps de rponse de 80%
(cf. figure 7.8).

F IGURE 7.9 Nombre de mises jour manquantes vs. obsolescence tolre

Ensuite, nous valuons limpact du relchement de la fracheur sur lquilibrage des charges.
Pour atteindre ce but, nous mesurons le taux de dsquilibre de la rpartition des charges (). Le
taux de dsquilibre montre limperfection ou la dviation de la rpartition des charges par rapport
un quilibrage parfait. Pour obtenir la dviation, nous divisons lcart type () par la moyenne de
la charge applicative (E) : = E . Les rsultats de la figure 7.10 montrent comment lobsolescence
tolre rduit par un facteur de 2 la dviation initiale, i.e. quand une fracheur maximale est requise.
En dautres mots, nous obtenons un meilleur quilibrage quand lobsolescence tolre crot. En
116

7.2. Evaluation des performances globales du routage

effet, laccroissement de lobsolescence tolre augmente le nombre de candidats et par consquent

les choix possibles.

F IGURE 7.10 Equilibrage des charges vs. obsolescence tolre

En conclusion, lintroduction du relchement de la fracheur permet daccrotre les performances en rduisant le temps de rponses surtout des requtes et en amliorant lquilibrage des
charges. Le contrle du relchement de la fracheur est effectu de manire simple en sappuyant
sur le catalogue qui stocke ltat des nuds et donc nengendre pas de surcharge ni ne compromet
lautonomie des SGBD.

7.2.2

Apport du routage dcentralis

Aprs avoir montr que la gestion du catalogue donne de bonnes performances en termes de dbit et de contrle de la fracheur des nuds. Nous valuons prsent lapport du routage distribu,
autrement dit nous mesurons le gain introduit par la redondance des gestionnaires de transactions.
En effet, nous mesurons les amliorations du routage distribu en ce qui concerne le dbit,
compares la version centralise de [GNPV07]. La charge est gnre par N applications classes
dans 3 catgories en proportion gale. Chaque type dapplication accde une partie distincte de
la base de donnes et donc est connect un routeur spcifique. En dautres termes, il n y a aucune
concurrence entre routeurs au niveau de laccs au catalogue, i.e. AC = 0. Nous mesurons le
dbit du traitement quand N varie de 15 150 applications. Sur la figure 7.11, nous comparons
ces rsultats avec le cas o un seul routeur reoit cette mme charge. Plus N saccrot, plus la
diffrence entre le routage centralis et distribu devient importante. Pour une forte charge de 150
applications, le gain avec le routage distribu atteint un facteur de 3. La raison principale est que
le routage centralis atteint ses limites trs rapidement car sappuie sur un catalogue stock sur
un seul nud. Nous observons un gain gal au nombre de routeurs, ce qui dmontre une monte
en charge linaire. De plus, la rpartition des mtadonnes sur plusieurs sites permet au GT de
fonctionner de manire totalement parallle, ce qui maintient les performances.
117

Chapitre 7. Validation

F IGURE 7.11 Routage rparti vs. routage centralis

7.2.3

Passage lchelle

Dans cette section nous tudions le passage lchelle de notre solution. Pour ce faire, nous
utilisons de la simulation afin davoir plusieurs milliers de nuds.
Nous utilisons notre prototype T RANS P EER dcrit dans 7.1.2. Notre choix dutiliser ce prototype dcoule du fait que FreePastry offre un environnement de simulation sans r-criture du code
de nos diffrents composants (GT, NA, ND et NC). Seule la couche communication qui fonctionnait avec les sockets de Java doit tre simule avec des invocations de messages conus sous forme
de thread.
Une fois notre environnement de simulation configure, nous mesurons le temps de rponse
global quand le nombre dapplications varie de 100 1000 et que le nombre de GT varie de 2
8. Nous fixons le taux de conflits des NA gal zro, i.e. les GT accdent de manire disjoints au
catalogue. Ce choix dabsence de conflits se justifie par le fait que nous voulons mesurer si le dbit
thorique correspond au dbit rel, autrement dit, lajout de n GT permet-il dobtenir un dbit gal
au dbit dun seul GT multipli par le facteur n.
La premire srie dexprience est faite pour valuer le bnfice obtenu en ajoutant des GT
quand la charge applicative augmente. Nous utilisons 100 ND pour toute lexprience pour sassurer quil sont toujours disponible et non surchargs (10 NA / ND). Par consquent seuls les ND et
le catalogue peuvent tre source de congestion.
La figure 7.12 montre deux rsultats. Premirement, pour une charge de 1000 NA, le temps
de rponse diminue si le nombre de GT augmente. Pour un nombre dapplications gal 1000, le
temps de rponse diminue de 42% si le nombre de GT passe de 2 8.
Cette amlioration est obtenue puisque laccroissement du nombre de GT rduit le temps dattente dun client pour voir sa requte tre prise en compte.
Deuximement, la figure 7.12 dtermine le nombre minimal de GT ncessaire quand la charge
118

7.2. Evaluation des performances globales du routage

applicative crot. Par exemple, avec une charge applicative entre 400 et 600 applications, 8 10
GT sont suffisants pour assurer un temps de rponse infrieur 2,5 secondes.

F IGURE 7.12 Temps de rponse vs. Nombre de NA

Ensuite, nous valuons limpact du nombre de ND quand le nombre de GT est judicieusement

choisi en fonction des rsultats de lexprience prcdente. Ainsi, nous fixons 100 le nombre de
GT suffisant pour quils ne soient pas source de congestion et nous faisons varier le nombre de ND
de 50 1200.
Nous prsentons les rsultats obtenus quand le le nombre dapplications varie de 1000 4000.
La figure 7.13 montre que le temps de rponse diminue si le nombre de ND augmente. Pour une
charge applicative de 1000 clients, le temps de rponse est acceptable puisquil est infrieur
2500 millisecondes. De plus, il reste constant mme si le nombre de ND varie. Pour les charges
applicatives plus importantes (plus de 2000 applications), lajout de nouvelles rpliques amliore
significativement le temps de rponse jusqu ce que le nombre de rpliques atteigne quelques
centaines. A partir de ce degr lajout de nouvelles rpliques naugmente gure le dbit global
pour deux raisons : (1) chaque ND est surcharg par la propagation et lapplications des mises
jour et (2) le nombre de ND est trs important et les GT perdent trop de temps choisir le ND
optimal. Dans ce cas, lajout de nouveaux GT devient ncessaire pour donner plus de choix aux
NA et donc rduire le temps de rponse.
Certes, des expriences avec une charge applicative envoye par plus de 10.000 NA permettront
de mieux situer les limites de notre systme. Cependant des contraintes environnementales nous
empchent de les faire. Ces contraintes sont entre autre lies notre modle dimplmentation et
aux nombres de thread maximum que lon peut tourner sur nos machines physiques. Nos travaux
en cours tentent de repousser ces obstacles.
119

Chapitre 7. Validation

F IGURE 7.13 Temps de rponse vs. Nombre de ND

7.2.4

Conclusion sur les performance du routage

Le relchement de la fracheur des donnes lus par les transactions permet damliorer le temps
de rponse et un meilleur quilibrage des charges. Ce rsultat est trs important dans le contexte
des applications web 2.0 o les transactions peuvent lire des donnes non fraches. Par exemple,
la consultation dun profil dami sur facebook ou la participation une vente dun objet sur eBay.
De plus, lquilibrage des charges permet de garder un certain niveau de disponibilit en liminant
ou rduisant la surcharge dun nud. Dans le contexte des applications Web 2.0 o les donnes
sont rparties sur plusieurs data centres, ce relchement de fracheur permettrait une meilleure
mutualisation des ressources puisquune requte dun client est trait sur le data centre le plus
proche de sa localisation. Ce mme constat est aussi valable pour les clouds dautant plus quil
permettrait des modles de cot plus conomiques. Par ailleurs, nous avons tudi lintroduction
de la redondance des GT. Les rsultats montrent que cela est indispensable pour le passage
lchelle. Limits par nos environnements exprimentaux, nous ne pouvons pas affirmer de manire
catgorique que notre solution fonctionne bien quand le nombre de GT passe 1.000 ou que le
nombre de ND dpasse les 10.000. Les raisons de ce doute dcoule du fait que lajout de GT
gnre plus daccs au catalogue qui peut devenir source de congestion. Nanmoins dans loptique
de rsoudre ce problme, nous sommes en train de dvelopper une approche o les GT nauront
pas besoin daccder un catalogue et par consquent le passage une chelle dune dizaine de
milliers de clients pourra tre garanti.

7.3

Evaluation des performances de la tolrance aux pannes

Dans cette section, nous valuons limpact de la gestion des pannes dans le routage des transactions. Les rsultats de ces expriences ont fait lobjet de publications en 2010 dans la revue
120

7.3. Evaluation des performances de la tolrance aux pannes

nationale RSTI-ISI [SNG10a] et dans la confrence internationale DBKDA [SNG10c]. Notre objectif est dabord dvaluer limpact de la gestion des pannes en valuant la surcharge engendre et
le gain obtenu. Puis nous valuons notre mcanisme de dtection cible des pannes en le comparant
avec une technique existante de dtection cible passant lchelle.
Nous nous plaons dans les mmes conditions exprimentales de la section 7.2.3, autrement
dit nous utilisons notre prototype T RANS P EER pour valuer la faisabilit.

7.3.1

Configuration du temporisateur

Comme nos algorithmes de dtection et de gestion des pannes sont bass sur des temporisateurs, nous commenons dabord par bien paramtrer leur valeur. Pour cela, nous faisons varier le
temporisateur de 10 millisecondes 10 secondes. Nous reportons dans la figure 7.14 le temps de
rponse quand le nombre de 2 NA, 2 GT et 10 ND constituent notre systme.

F IGURE 7.14 Temps de rponse vs. temporisateurs

Nous identifions Topt , la valeur optimale du temporisateur qui ne ncessite aucune retransmission. Nous observons que le temps de rponse diminue de 900 millisecondes jusqu environ 330
millisecondes. Topt correspond au seuil de la valeur du temporisateur partir duquel le temps de
rponse reste quasi constante et correspond 1 seconde.
Nous affirmons que cette valeur est un bon compromis entre dune part, une faible surcharge
de la gestion des pannes des pannes et dautre part une dtection rapide des pannes qui favorise
la rduction du temps de rponse des transactions concernes par une panne. Nous mentionnons
aussi que nous pouvons dynamiquement ajuster la valeur de Topt en fonction de laugmentation du
taux darrive des pannes.
121

Chapitre 7. Validation

7.3.2

Surcharge de la gestion des pannes

Une fois que nous avons bien dfini la valeur du temporisateur, nous mesurons la surcharge
engendre par la prise en compte des pannes lors du processus de routage. Nous comparons notre
solution tolrante aux pannes par apport notre approche basique qui ne prend pas en compte les
pannes. En labsence de pannes, nous mesurons les dbits de chacune des solutions.
Nous utilisons 20 PC du laboratoire connect par un rseau LAN, chacun nhbergeant quun
seul nud (NA, ND, GT ou NC) pour viter toute dgradation de performances dues des partages
de ressources. La charge applicative provient des NA qui envoient des transactions sous forme
dinstructions SQL. Chaque ND est connect un SGBD Postgresql qui excut les transactions.
Chaque exprience est rpte cinq fois afin de sassurer de la prcision des rsultats. Alors, nous
mesurons le temps de rponse moyen en variant le nombre de ND de 2 10.
La figure 7.15 montre que notre solution non tolrante aux pannes produit un temps de rponse
quasi constant autour de 150 millisecondes (seul 20 millisecondes de plus avec 10 ND quavec 2
ND), tandis que la solutions tolrante aux pannes offre des temps de rponses trs levs.

F IGURE 7.15 Surcharge routage tolrant vs. routage non tolran

En effet, la solution tolrante aux pannes fonctionne deux fois plus lentement que la solution
non tolrante puisquelle requiert des processus supplmentaire pour grer les pannes. Par exemple,
chaque nud est coupl avec un chronomtre qui signale chaque fin de temporisateur et le cot
supplmentaire dcoule des tests faits par les GT, ND, NA et NC pour sassurer que la transaction
nest excute quune seule fois. Ceci ncessite que les GT communiquent entre eux pour savoir
si une transaction est en cours ou dj excute. En plus durant le processus de routage le GT
teste si le ND choisi est en panne ou non ce qui rallonge le temps de routage et donc le temps de
rponse. Dans cette exprience, notre solution non tolrante est meilleure puisquil nexiste aucune
panne,ce qui ne reflte pas une situation relle. En situation de panne, notre solution tolrante
122

7.3. Evaluation des performances de la tolrance aux pannes

prsente plus davantage puisquil assure toujours quune transaction soit excute, ce qui nest
pas le cas avec notre solution non tolrante. Nous valuons le gain de la solution tolrante dans la
prochaine exprience.

7.3.3

Performances de la gestion des pannes

Nous valuons dans cette section les bnfices de notre solution en valuant dune part lamlioration du dbit de routage et la rapidit de notre protocole dtecter les pannes.
Gain de la gestion des pannes
Dans cette section, nous valuons lapport positif de notre solution tolrante. Ainsi, nous instancions plusieurs nuds par machine (500 NA/ 500 ND / 50 GT). Nous faisons varier le dbit de
panne des ND de 0 100%. Les pannes sont uniformment rparties sur lensemble de priode
dexprimentation, i.e. un dbit de panne de 100% signifie que le premier nud tombe en panne
au dbit et la prochaine panne arrive tf plus tard et ainsi de suite, avec tf = ( taux darrive des
pannes * temps dexprimentation total ) / nombre de nuds. Nous reportons les rsultats sur la
figure 7.16.

F IGURE 7.16 Dbit routage tolrant vs. routage non tolrant

Les rsultats montrent quavec un taux de panne faible, la solution non tolrante dpasse de
18% la solution tolrante en dbit de routage. Ceci est la consquence de la surcharge engendre
par la solution tolrante value prcdemment .
Par contre ds que le taux de panne dpasse 30%, la solution tolrante dpasse de 3% la solution
non tolrante. Ce gain dcoule du fait que la solution tolrante est capable de continuer les tches
123

Chapitre 7. Validation

dun ND en panne sur un autre ND disponible. De plus, chaque ND en panne est enregistr afin de
ne pas lutiliser pour les prochaines transactions entrantes.
Certes, le dbit de panne au del duquel la solution tolrante surpasse la solution non tolrante
est trs lev (30 %). Cependant, nous mentionnons que ce dbit inclut aussi bien les pannes que
les dconnexions prvues sans oublier les pannes de communication, ce qui augmente le nombre
de situations interprtes comme des pannes par notre solution.
Notre objectif dans cette exprience tait uniquement de montrer lapport de la gestion de la
dynamicit dans le routage des transactions. Les rsultats obtenus sont somme toute intressants
bien quils peuvent tre amliorer en dissociant la gestion des pannes de rseau de celle des pannes
afin de rduire la surcharge de notre solution tolrante. Cette amlioration inscrite dans nos perspectives, ncessite des techniques de dtection des pannes dans un rseau et peuvent tre dlgus
un systme tiers.
Cot de la dtection des pannes
Aprs avoir montr lintrt de la gestion des pannes nous nous intressons au cot de la dtection des pannes. Nous comparons notre approche de dtection cible avec celle propose dans
S WIM [DGM02], en mesurant le cot de communication (i.e. le nombre total de messages ncessaires pour dtecter les pannes). S WIM est une solution de dtection des pannes conue pour les
systmes large chelle et sappuie sur lenvoie de message "ping-pong" sur des ensembles de
nuds choisis alatoirement. Dans cette exprience, nous nous intressons uniquement la dtection des GT puisque la dtection dun ND est faite uniquement au cours de lexcution dune
transaction et ne ncessite pas plus de 5 messages (cf. section 6.2.2).
Dans S WIM, la dtection est faite en envoyant priodiquement des messages de "ping-pong"
un ensemble alatoire de nuds (nous avons choisi 4 dans notre cas). Dans notre solution, chaque
GT collabore avec les autres GT (4 dans cette exprience) pour dtecter la panne. Nous commenons la simulation avec 18 GT disponibles et 2 GT en panne. Ensuite nous faisons varier le nombre
de GT en panne de 2 18. Nous reportons sur la figure 7.17 le nombre de pannes dtectes.

F IGURE 7.17 Pannes dtectes vs. pannes survenues

124

7.3. Evaluation des performances de la tolrance aux pannes

F IGURE 7.18 Nombre de messages vs. pannes survenues

La figure 7.17 montre quavec un nombre de pannes lev, notre solution gnre de meilleures
performances que S WIM en ce qui concerne le nombre de pannes dtectes. La principale raison
est que chaque GT en panne est dtect par au moins un de ses successeurs, donc il est exclu de
lanneau logique. Au contraire, avec S WIM, un GT peut tomber en panne sans pour autant tre
dtect puisquil peut rester longtemps sans tre choisi alatoirement par les autres GT.
En outre, nous comparons le cot de communication engendr par la dtection des pannes de
notre solution celui de S WIM. Pour cela, nous calculons le nombre total de messages envoys
par les nuds pour dtecter loccurrence des pannes. Les rsultats prsents sur la figure 7.18
montrent que le nombre total de messages pour dtecter les pannes augmente si le nombre de nuds
disponibles est important. En fait, avec 20 GT le nombre de messages est suprieur 400 durant
une simulation, puisquun GT contacte ses successeurs priodiquement. En plus, nous soulignons
que notre solution requiert toujours moins de messages que S WIM lors de la dtection. En effet
lanneau logique est restructur ds quune panne est dtecte, vitant ainsi de contacter un nud
en panne plus dune fois. Avec S WIM, un nud en panne peut tre contact par les autres nuds
qui ne sont pas encore au courant de la panne, puisque la notification de panne nest pas immdiate.

7.3.4

Conclusion sur lvaluation de la gestion des pannes

Les expriences effectues dans cette section montrent limportance de la gestion des pannes
dans le protocole de routage des transactions. Les rsultats montrent qua la prise en compte des
pannes rduit la dgradation des performances en prsence de pannes. La tolrance aux pannes
borne les temps de rponse qui sont des critres forts pour les applications. Par exemple, les applications Web 2.0 fonctionnent avec les revenus gnrs par les publicits qui sont verss que sil
y a des visiteurs. Ainsi, des temps de rponses longs engendrs par les indisponibilits du service
rduisent la prsence de visiteurs et donc de fonds pour les fournisseurs dapplications.
125

Chapitre 7. Validation

7.4

Conclusion

Dans ce chapitre, nous avons prsent la validation de notre approche. Nous avons dvelopp
deux prototypes D TR et T RANS P EER pour implmenter les composants de notre routeur. D TR
est conu au dessus de JuxMem et donc nous a permis dimplmenter notre approche de gestion
du catalogue avec verrouillage. T RANS P EER est implment au dessus dun rseau P2P afin de
grer le catalogue sans verrouillage. Nous les avons utilis pour mener une srie dexpriences
et les rsultats obtenus dmontrent la faisabilit de nos approches. Les rsultats obtenus sont les
suivants :
la surcharge induite par la gestion dun catalogue rparti est acceptable ;
la redondance du routeur accrot le dbit de routage et rduit le temps de rponse tout en
introduisant plus de disponibilit ;
le choix dune gestion de catalogue sans verrouillage facilite le passage lchelle ;
le relchement de la fracheur amliore le temps de rponse et donne au routeur plus de
choix. Le calcul de la fracheur est effectu avec lutilisation du catalogue sans besoin de
contacter les SGBD.
la prise en compte de la dynamicit du systme est indispensable et permet de borner le temps
de rponse. Les mthodes de dtection et de rsolution des pannes utilises sont simples
mettre en uvre et savrent bien adaptes pour un systme large chelle.

126

Chapitre 8
Conclusion et Perspectives
8.1

Synthse

Les travaux prsents dans cette thse montrent que lutilisation dun catalogue rparti associ
un modle de routage rparti permet damliorer le dbit transactionnel dune base de donnes
rpliques large chelle tout en prservant la cohrence terme et en contrlant la fracheur des
donnes lues par les requtes. La prise en compte de la dynamicit des nuds du systme permet
de maintenir les performances du systme en cas doccurrence de pannes.
Architecture du systme de routage. Notre architecture se prsente comme un intergiciel pour
contrler laccs la base de donnes et peut tre divise en deux parties : une partie assurant le
service de mdiation entre les diffrents composants du systme (intergiciel) et une autre charge
de la gestion des mtadonnes qui sont les donnes ncessaires au fonctionnement du systme en
entier. Le choix dune architecture hybride mi-chemin entre les systmes P2P structurs et ceux
non structurs nous permet de tirer profit des avantages des uns et des autres. En fait, la structuration des nuds GT autour dun anneau logique permet de faciliter leur collaboration pour assurer
le traitement cohrent des transactions alors que la structuration faible des nuds ND leur confre
une grande autonomie. Notre intergiciel redondant permet de faire face la volatilit dun environnement large chelle puisqu chaque fois quun nud GT ou ND tombe en panne, nous utilisons
un autre nud disponible pour continuer le traitement ou rcuprer les donnes. Lutilisation dun
catalogue rparti facilite lexploitation des ressources disponibles et un contrle global de ltat
du systme. Pour rendre disponible les informations stockes lintrieur du catalogue, nous les
avons rpliques par lintermdiaire de systmes garantissant le passage lchelle et la disponibilit, notamment JuxMem et une DHT. Pour exploiter avec efficacit, les ressources du systmes
(quilibrer les charges, identifier rapidement le nud optimal, etc.), nous collectons plusieurs informations dans le catalogue comme mtadonnes et nous les structurons logiquement pour que
leur manipulation (lecture et modification) soit simple.
Protocole de routage. Nous avons propos un mcanisme de routage des transactions pour garantir une excution rapide et cohrente, des transactions. Les algorithmes de routage proposs
127

Chapitre 8. Conclusion et Perspectives

requirent des accs au catalogue rparti pour maintenir la cohrence mutuelle des rpliques et ils
dfinissent lordre dans lequel les transactions doivent tre excutes pour ne pas compromettre la
cohrence. Le premier algorithme est dit pessimiste et ordonne toutes les transactions conflictuelles
en sappuyant sur les conflits potentiels. En dautres mots, le protocole de routage assure une srialisation globale dfinie de manire pessimiste et qui est utilis pour router les transactions. Chaque
transaction est associe avec ses classes de conflits, qui contiennent les donnes que la transaction
peut potentiellement lire (resp. modifier). En fonction des classes de conflits, les transactions sont
ordonnes dans un GSG en sappuyant sur leur ordre darrive. Bien que cette approche assure une
srialisation globale, elle rduit malheureusement la paralllisation du traitement des transactions
puisquelle sappuie sur des sur-ensembles potentiels de donnes rellement accdes.
Pour amliorer le paralllisme du traitement des transactions, nous avons propos un second
algorithme qui combine une approche pessimiste et optimiste. Ce second algorithme sappuie sur
une tentative dexcution des transactions afin derduire le temps de rponse des transactions.
Autrement dit, les transactions conflictuelles sont excutes de manire optimiste et une phase de
validation est utilise la fin pour garantir la cohrence. Dans le contexte des applications Web 2.0
o les transactions courantes et potentiellement conflictuelles sont peu nombreuses, les chances de
russite du routage optimiste savrent trs leves et donc il apparat plus adapt.
Catalogue rparti. Pour maintenir la cohrence globale, nous avons conu un catalogue pour
stocker les mtadonnes (GSG). Le catalogue est utilis chaque processus de routage et peut
faire alors lobjet daccs concurrents qui peuvent tre source dincohrence. Pour garantir la cohrence du catalogue lors de laccs au mtadonnes, nous avons propos deux approches : une
approche utilisant le verrouillage et une autre sans verrouillage. La gestion avec verrouillage est
implmente via JuxMem dans le but dintgrer nos travaux dans le cadre du projet ANR Respire
[Prod]. Malheureusement, nous avons remarqu que le verrouillage ne facilite pas le passage
lchelle. Cest pourquoi nous avons opt pour une solution sans verrouillage lors de laccs au
catalogue. De plus, nous nous sommes intresss des systmes tels que les DHT qui permettent
de grer des donnes rpliques sans utilisation de mcanismes de verrouillage. Ainsi, nous avons
implment la gestion du catalogue travers une DHT dautant plus que celle-ci facilite le passage
lchelle et une grande disponibilit, deux caractristiques trs importantes pour notre systme
de routage.
Gestion des pannes. Nous avons prsent un mcanisme de gestion de la dynamicit. Ce mcanisme est bas sur la dtection slective des fautes et sur un algorithme de reprise. Contrairement
la plupart des autres approches, notre mcanisme nimplique pas lutilisation de nuds qui ne participent pas lxcution de la transaction en cours, ce qui permet de passer lchelle. Pour cela,
nous adaptons des approches existantes de dtection des pannes afin de les rendre oprationnelles
pour chaque type de nud (gestionnaire de transaction et nud de donnes) de notre systme.
Nous avons propos un protocole permettant de grer toutes les situations lorsquun nud quitte
le systme pendant le traitement dune transaction. Ceci est ncessaire et suffisant pour contrler
la cohrence du systme, surtout en cas de dconnexions intempestives.
Cependant, pour maintenir le dbit transactionnel en cas de frquentes pannes, il faut tre
128

8.2. Perspectives

capable dajouter de nouvelles ressources en fonction des dconnexions. Pour ce faire, nous avons
propos un modle permettant de dterminer et contrler le nombre de rpliques requises pour
garder le systme disponible. Ce modle permet de dterminer le nombre minimum de rpliques
ncessaires au bon fonctionnement du systme et donc de minimiser les surcots lis la gestion
des rpliques.
Validation. Pour valider la faisabilit de nos approches, nous avons implment deux prototypes
nomms respectivement D TR (Distributed Transaction Routing) et T RANS P EER (TRANSaction on
PEER-to-peer). Limplmentation de deux prototypes est lie au besoin de grer le catalogue avec
verrouillage ou sans verrouillage. De fait, D TR constitue le prototype dvelopp avec verrouillage
du catalogue alors que T RANS P EER est conu pour une gestion du catalogue sans verrouillage et
un modle de communication de type P2P. Puis, nous avons effectu quelques simulations pour
tudier le passage lchelle et la tolrance aux pannes de notre solution. Notre choix dutiliser
la fois de lexprimentation et de la simulation se justifie par le fait que : (1) lexprimentation
permet dvaluer un systme dans des conditions relles ; et (2) la simulation est une reprsentation
simplifie du systme, facile raliser et requiert moins de ressources que limplmentation, ce
qui favorise lvaluation dun systme grande chelle. Nous avons men une srie dexpriences
sur nos deux prototypes pour tudier les performances de notre systme : dbit transactionnel,
temps de rponse, passage lchelle et tolrance aux pannes. Les rsultats obtenus montrent
que lutilisation dun catalogue pour stocker les mtadonnes permet de router les transactions en
contrlant le niveau de fracheur sollicit par les applications. De plus, la surcharge induite par la
gestion dun catalogue rparti est acceptable et donc na pas trop dimpact ngatif sur le dbit du
routage. Les expriences ont montr que le relchement de la fracheur des donnes amliore le
temps de rponse des requtes et lquilibrage des charges, ce qui est conomiquement important
vis--vis lutilisation totale des ressources disponibles. Les rsultats montrent galement que la
redondance du routeur accrot le dbit de routage et rduit le temps de rponse tout en introduisant
plus de disponibilit. Les rsultats obtenus avec notre prototype T RANS P EER dmontrent le gain
de la gestion des mtadonnes sans verrouillage, ce qui favorise la rduction du temps de rponse.
Enfin, nous avons montr que la prise en compte de la dynamicit du systme est indispensable
et permet de borner le temps de rponse. Les mthodes de dtection et de rsolution des pannes
utilises sont simples mettre en uvre et savrent bien adaptes pour un systme large chelle.

8.2

Perspectives

Nos principales perspectives visent amliorer la capacit de notre solution passer lchelle
surtout et la rendre plus gnrique de telle sorte quelle soit indpendante de la dfinition des
rpliques et de leur placement.
Amlioration du passage lchelle. Notre solution prsente lavantage de sadapter dynamiquement aux volutions du systme. Cependant, son comportement en prsence de forts et nombreux pics de charge na pas t tudi. Cest pourquoi nous nous proposons dtudier un algorithme de synchronisation grant les pics de charge en prsence de pannes. Cette perspective a pour
129

Chapitre 8. Conclusion et Perspectives

but de proposer un algorithme distribu permettant de rsoudre le problme de synchronisation en

soulageant la charge des GT ddis la gestion du graphe et en rduisant les communications
ncessaires entre ces noeuds. Laccent sera mis, principalement, sur laptitude grer les pics de
charge. Ce problme est dautant plus important que dans le type dapplications vises, on cherche
davantage garantir, au plus grand nombre, une rponse dans un temps donn, qu rduire le
temps daccs moyen.
Par ailleurs, dans limplmentation actuelle de notre approche, la synchronisation des accs au
graphe repose sur lutilisation dalgorithmes centraliss excuts par quelques pairs ddis. Cette
solution prsente linconvnient de traiter toutes les requtes en parallle et donc dtre particulirement sensible aux pics de charge. Paralllement lquipe REGAL du LIP6 a dvelopp plusieurs
algorithmes distribus de synchronisation [SALAS09, SAS06] qui offrent une faible sensibilit
aux variations de charge, ainsi que de trs bonnes performances (i.e. le temps daccs conserve
un faible cart type et une faible moyenne). Cependant ces algorithmes ne prvoient pas de garantie sur la latence maximale dobtention de laccs. Ils doivent tre amliors afin davertir le
demandeur quun accs sera trop long obtenir plutt que de le faire patienter.
Pour ce faire, nous proposons de composer les approches dveloppes par les deux quipes
pour obtenir un algorithme tolrant aux fautes et restant efficace sous une forte charge momentane. Le principe consiste effectuer un accs en deux tapes : on demande laccs lalgorithme
distribu pour pouvoir, ensuite, demander laccs lalgorithme centralis. On peut alors voir
lalgorithme distribu comme une simple file dattente rpartie. Cette approche compositionnelle
prsente plusieurs avantages :
La base de donne utilisant un algorithme centralis (ou rpliqu), verra ses pics de charge
absorbs par lalgorithme distribu qui se comportera en file dattente distribue.
Lalgorithme distribu, ne grant pas directement laccs au graphe (ressource critique),
pourra traiter un problme de synchronisation un peu simplifi de faon grer plus simplement la dynamicit du systme.
Transactions multi-pairs. Actuellement nos solutions se limitent des transactions dites "monosite", qui modifient une seule base (toutes les donnes manipules par la transaction sont sur une
mme rplique). Cette limitation savre contraignante car elle empche de dfinir librement les
rpliques indpendamment des transactions. En effet, une rplique devant contenir toutes les donnes accdes par une transaction, cela peut aboutir une rplication totale des donnes, ce qui
est contraire au contexte de rplication partielle dans lequel se situe cette thse. Par consquent,
le problme se pose de traiter des transactions rparties ( ou multi sites) qui ont besoin de modifier plusieurs bases de manire atomique. Plusieurs solutions ont t proposes mais elles ne
fonctionnent pas dans le contexte des applications cibles. Certaines solutions sont limites un
cluster (de lordre de 100 nuds) donc en faisant lhypothse que le rseau sous-jacent est fiable
[PMJPKA05, ATS+ 05], dautres brisent lautonomie des sites en imposant de modifier le gestionnaire de transaction local du SGBD [CPV05].
Lobjectif de cette perspective est de concevoir une solution pour router les transactions trs
large chelle, en contrlant les traitements locaux (sous-transactions) effectues sur les pairs. Lapproche suivie consiste utiliser au mieux les SGBD existant sur chaque pair et capable de traiter
130

8.2. Perspectives

des sous- transactions localement. La difficult est de dfinir un ordre global de traitement des
transactions, de dterminer un ordre compatible avec lordre global et qui apportera un gain de
performance significatif, et finalement de garantir que cet ordre sera toujours respect par lexcution des sous- transactions sur les rpliques malgr les pannes probables dun ou plusieurs pairs.

131

Chapitre 8. Conclusion et Perspectives

132

Bibliographie
[ABJ05]

G. Antoniu, L. Boug, and M. Jan. JuxMem : An Adaptive Supportive

Platform for Data Sharing on the Grid. Scalable Computing : Practice and
Experience, 6(3) :4555, 2005.

[ACT99]

M. Aguilera, W. Chen, and S. Toueg. Using the Heartbeat Failure Detector for Quiescent Reliable Communication and Consensus in Partitionable
Networks. Theoretical Computer Science, 220(1) :330, 1999.

[ACZ03]

C. Amza, A. L. Cox, and W. Zwaenepoel. Distributed versioning :

consistent replication for scaling back-end databases of dynamic content
web sites. In Middleware 03 : Proceedings of the ACM/IFIP/USENIX
2003 International Conference on Middleware, pages 282304, 2003.

[ADM06]

G. Antoniu, J. Deverge, and S. Monnet. How to Bring Together Fault Tolerance and Data Consistency to Enable Grid Data Sharing. Concurrency
and Computation : Practice and Experience, 18(13) :17051723, 2006.

[APV07]

R. Akbarinia, E. Pacitti, and P. Valduriez. Data Currency in Replicated

DHTs. In Int. Conf. on Management of Data (SIGMOD), pages 211222,
2007.

[AT89]

A. El Abbadi and S. Toueg. Maintaining availability in partitioned replicated databases. ACM Trans. Database Syst., 14(2) :264290, 1989.

[ATS+ 05]

F. Akal, C. Trker, H. Schek, Y. Breitbart, T. Grabs, and L. Veen. FineGrained Replication and Scheduling with Freshness and Correctness Guarantees. In Int. Conf. on Very Large DataBase (VLDB), pages 565576,
2005.

[BBG+ 95]

H. Berenson, P. Bernstein, J. Gray, J. Melton, E. ONeil, and P. ONeil.

A critique of ansi sql isolation levels. In SIGMOD 95 : Proceedings of
the 1995 ACM SIGMOD international conference on Management of data,
pages 110, 1995.

[BFG+ 08]

M. Brantner, D. Florescu, D. Graf, D. Kossmann, and T. Kraska. Building a

database on s3. In SIGMOD 08 : Proceedings of the 2008 ACM SIGMOD
international conference on Management of data, pages 251264, 2008.

[BGL+ 06]

R. Baldoni, R. Guerraoui, R. R. Levy, V. Quma, and S. T. Piergiovanni.

Unconscious eventual consistency with gossips. In SSS, pages 6581, 2006.
133

Bibliographie

[BGRS00]

[BHG87]
[BKR+ 99]

[Bre00]

[BYV08]

[CDKR02]

[CL02]
[CMZ05]

[CPV05]

[CPW07]

[CRF09]
[CT96]
[CVL10]

[DGM02]

K. Bhm, T. Grabs, U. Rhm, and H. Schek. Evaluating the coordination

overhead of replica maintenance in a cluster of databases. In Euro-Par
2000 Parallel Processing, pages 435444, 2000.
P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and
Recovery in Database Systems. Addison-Wesley, 1987.
Y. Breitbart, R. Komondoor, R. Rastogi, S. Seshadri, and A. Silberschatz.
Update propagation protocols for replicated databates. SIGMOD Rec.,
28(2) :97108, 1999.
E. A. Brewer. Towards robust distributed systems (abstract). In PODC
00 : Proceedings of the nineteenth annual ACM symposium on Principles
of distributed computing, page 7, 2000.
R. Buyya, C. S. Yeo, and S. Venugopal. Market-oriented cloud computing :
Vision, hype, and reality for delivering it services as computing utilities. In
HPCC 08 : Proceedings of the 2008 10th IEEE International Conference
on High Performance Computing and Communications, pages 513, 2008.
M. Castro, P. Druschel, A. Kermarrec, and A. Rowstron. Scribe : A largescale and decentralized application-level multicast infrastructure. IEEE
Journal on Selected Areas in Communications (JSAC, 20 :2002, 2002.
M. Castro and B. Liskov. Practical byzantine fault tolerance and proactive
recovery. ACM Trans. Comput. Syst., 20(4) :398461, 2002.
E. Cecchet, J. Marguerite, and W. Zwaenepoel. C-JDBC : Flexible Database Clustering Middleware. Technical report, ObjectWeb, Open Source
Middleware, 2005.
C. Coulon, E. Pacitti, and P. Valduriez. Consistency management for partial
replication in a high performance database cluster. In ICPADS 05 : Proceedings of the 11th International Conference on Parallel and Distributed
Systems, pages 809815, 2005.
L. Camargos, F. Pedone, and M. Wieloch. Sprint : A Middleware for HighPerformance Transaction Processing. In ACM European Conf. on Computer Systems (EuroSys), pages 385398, 2007.
J. M. Cahill, U. Rhm, and A. D. Fekete. Serializable isolation for snapshot
databases. ACM Trans. Database Syst., 34(4) :142, 2009.
T. D. Chandra and S. Toueg. Unreliable failure detectors for reliable distributed systems. Journal of the ACM (JACM), 43(2) :225267, 1996.
M. Correia, G. S. Veronese, and L. C. Lung. Asynchronous byzantine
consensus with 2f+1 processes. In SAC 10 : Proceedings of the 2010
ACM Symposium on Applied Computing, pages 475480, 2010.
A. Das, I. Gupta, and A. Motivala. SWIM : Scalable Weakly Consistent
Infection-style Process Group Membership Protocol. In Int. Conf. on Dependable Systems and Networks (DSN), 2002.
134

Bibliographie

[DS06]

[DSS10]

[EGA08]

[EZP05]

[Fac]
[FDMBGJM+ 09]

[FJB09]
[FLO+ 05]

[Fre]
[Gan06]

[Gee09]
[GGL03]

[GHOS96]

[Gif79]

K. Daudjee and K. Salem. Lazy database replication with snapshot isolation. In VLDB 06 : Proceedings of the 32nd international conference on
Very large data bases, pages 715726, 2006.
O. Diallo, M. Sene, and I. Sarr. Freshness-aware metadata management :
Performance evaluation with swn. In 8th IEEE/ACS International Conference on Computer Systems and Applications, 2009 (AICCSA 2009), 2010.
C. Emmanuel, C. George, and A. Anastasia. Middleware-based database
replication : the gaps between theory and practice. In SIGMOD 08 : Proceedings of the 2008 ACM SIGMOD international conference on Management of data, pages 739752, 2008.
S. Elnikety, W. Zwaenepoel, and F. Pedone. Database replication using
generalized snapshot isolation. In SRDS 05 : Proceedings of the 24th
IEEE Symposium on Reliable Distributed Systems, pages 7384, 2005.
Facebook. www.facebook.com.
noz-Esco F. D. Mu J. M. Bernab-Gisbert, R. Juan-Marn, nigo J. E.
Armendriz- and J. R. Gonzlez De Mendvil. Revising 1-copy equivalence in replicated databases with snapshot isolation. In OTM 09 : Proceedings of the Confederated International Conferences, CoopIS, DOA, IS,
and ODBASE 2009 on On the Move to Meaningful Internet Systems, pages
467483, 2009.
S. Finkelstein, D. Jacobs, and R. Brendle. Principles for inconsistency. In
CIDR, 2009.
A. Fekete, D. Liarokapis, E. ONeil, P. ONeil, and D. Shasha. Making
snapshot isolation serializable. ACM Trans. Database Syst., 30(2) :492
528, 2005.
FreePastry. http ://www.freepastry.org/freepastry/.
S. Ganarski. Cohrence et Fracheur dans les bases de donnes rparties.
Habilitation diriger des recherches, Universit Pierre et Marie Curie, Paris
6, France, October 2006.
J. Geelan. Twenty one experts define cloud computing. electronic magazine. http ://virtualization.sys-con.com/node/612375, 2009.
S. Ghemawat, H. Gobioff, and S. Leung. The google file system. In SOSP
03 : Proceedings of the nineteenth ACM symposium on Operating systems
principles, pages 2943, 2003.
J. Gray, P. Helland, P. ONeil, and D. Shasha. The dangers of replication
and a solution. In SIGMOD 96 : Proceedings of the 1996 ACM SIGMOD
international conference on Management of data, pages 173182, 1996.
David K. Gifford. Weighted voting for replicated data. In SOSP 79 : Proceedings of the seventh ACM symposium on Operating systems principles,
pages 150162, 1979.
135

Bibliographie

[GL02]

S. Gilbert and N. Lynch. Brewers conjecture and the feasibility of

consistent, available, partition-tolerant web services. SIGACT News,
33(2) :5159, 2002.

[GLRG04]

H. Guo, P. Larson, R. Ramakrishnan, and J. Goldstein. Relaxed currency

and consistency : how to say "good enough" in sql. In SIGMOD 04 :
Proceedings of the 2004 ACM SIGMOD international conference on Management of data, pages 815826. ACM, 2004.

[GN95]

R. Gallersdrfer and M. Nicola. Improving performance in replicated databases through relaxed coherency. In VLDB 95 : Proceedings of the 21th
International Conference on Very Large Data Bases, pages 445456, 1995.

[GNPV07]

S. Ganarski, H. Naacke, E. Pacitti, and P. Valduriez. The leganet system : Freshness-aware transaction routing in a database cluster. Journal of
Information Systems, 32(2) :320343, 2007.

[Gnu]

Gnutella. http ://www.gnutella.com/.

[GR92]

J. Gray and A. Reuter. Transaction Processing : Concepts and Techniques.

Morgan Kaufmann Publishers Inc., 1992.

[Gro]

Groove. http ://office.microsoft.com/en-us/groove/default.aspx.

[GS97]

R. Guerraoui and A. Schiper. Software-Based Replication for Fault Tolerance. IEEE Computer, 30(40) :6874, 1997.

[GSN09]

M. Gueye, I. Sarr, and S. Ndiaye. Database replication in large scale systems : optimizing the number of replicas. In EDBT/ICDT 09 : Proceedings
of the 2009 EDBT/ICDT Workshops, pages 39. ACM, 2009.

[HAA99]

J. Holliday, D. Agrawal, and A. El Abbadi. The performance of database

replication using atomic broadcast group communication, 1999.

[HAA00]

J. Holliday, D. Agrawal, and A. El Abbadi. Database Replication Using

Epidemic Communication. In Euro-Par 2000 Parallel Processing, pages
427434, 2000.

[HAA02]

J. Holliday, D. Agrawal, and A. El Abbadi. Partial database replication

using epidemic communication. In ICDCS 02 : Proceedings of the 22 nd
International Conference on Distributed Computing Systems (ICDCS02),
page 485, 2002.

[HCH+ 05]

R. Huebsch, B. Chun, J. M. Hellerstein, B. Thau Loo, P. Maniatis, T. Roscoe, S. Shenker, I. Stoica, and A. R. Yumerefendi. The architecture of pier :
an internet-scale query processor. In IN CIDR, pages 2843, 2005.

[HIM+ 04]

A. Y. Halevy, Z. G. Ives, J. Madhavan, P. Mork, D. Suciu, and I. Tatarinov.

The piazza peer data management system, 2004.

[HSAA03]

J. Holliday, R. Steinke, D. Agrawal, and A. El Abbadi. Epidemic algorithms for replicated databases. IEEE Transactions on Knowledge and
Data Engineering, 15(5) :12181238, 2003.
136

Bibliographie

[Jan06]

Mathieu Jan. JuxMem : un service de partage transparent de donnes pour

grilles de calculs fond sur une approche pair--pair. Thse de doctorat,
Universit de Rennes 1, IRISA, Rennes, France, November 2006.

[JEAIMGdMFDM08] nigo J. E. Armendriz-I A. Mauch-Goya, J. R. Gonzlez de Mendvil, and

noz-Esco F. D. Mu SIPRe : a partial database replication protocol with SI
replicas. In SAC 08 : Proceedings of the 2008 ACM symposium on Applied
computing, pages 21812185, 2008.
[JPMPAK03]

R. Jimnez-Peris, no-Martnez M. Pati G. Alonso, and B. Kemme. Are

quorums an alternative for data replication ? ACM Trans. Database Syst.,
28(3) :257294, 2003.

[JWZ03]

R. Janakiraman, M. Waldvogel, and Q. Zhang. Indra : A peer-to-peer approach to network intrusion detection and prevention, 2003.

[KA00a]

B. Kemme and G. Alonso. Dont be lazy, be consistent : Postgres-r, a new

way to implement database replication. In VLDB 00 : Proceedings of the
26th International Conference on Very Large Data Bases, pages 134143,
2000.

[KA00b]

B. Kemme and G. Alonso. A new approach to developing and implementing eager database replication protocols. ACM Trans. Database Syst.,
25(3), 2000.

[KaZ]

KaZaA. http ://www.kazza.com/.

[Kra09]

S. Krakowiak. Middleware Architecture with Patterns and Frameworks.

Creative Commons License, 2009.

[LAF99]

M. Larrea, S. Arvalo, and A. Fernndez. Efficient Algorithms to Implement Unreliable Failure Detectors in Partially Synchronous Systems. In
Proceedings of the 13th International Symposium on Distributed Computing. Springer-Verlag, 1999.

[LFVM09]

A. A. Lima, C. Furtado, P. Valduriez, and M. Mattoso. Parallel olap query

processing in database clusters with data replication. Distrib. Parallel Databases, 25(1-2) :97123, 2009.

[LG06]

C. Le Pape and S. Ganarski. Replica Refresh Strategies in a Database

Cluster. In High-Performance Data Management in Grid Environments
(HPDGrid VECPAR Workshop), 2006.

[LGV04]

C. Le Pape, S. Ganarski, and P. Valduriez. Refresco : Improving Query

Performance Through Freshness Control in a Database Cluster. In Int.
Conf. On Cooperative Information Systems (CoopIS), 2004.

[LKJP+ 09]

Y. Lin, B. Kemme, R. Jimnez-Peris, M . Patino-Martnez, and nigo J. E.

Armendriz-ISnapshot isolation and integrity constraints in replicated databases. ACM Trans. Database Syst., 34(2) :149, 2009.
137

Bibliographie

[LKMPJP05]

[LM09]

[MM02]

[MN09]

[MSN]
[Nap]
[OV99]
[PA04]

[Pap05]

[Pau02]
[PCVO05]

[PGS97]

[PGS03]
[PMJPKA05]

[PMS99]

Y. Lin, B. Kemme, no-Martnez M. Pati and R. Jimnez-Peris. Middleware

based data replication providing snapshot isolation. In SIGMOD 05 : Proceedings of the 2005 ACM SIGMOD international conference on Management of data, pages 419430, 2005.
A. Lakshman and P. Malik. Cassandra : structured storage system on a
p2p network. In PODC 09 : Proceedings of the 28th ACM symposium on
Principles of distributed computing, pages 55, 2009.
P. Maymounkov and D. Mazires. A peer-to-peer information system based
on the xor metric. In 1st Int. Workshop on Peer-to-Peer Systems(IPTPS),
2002.
T. Mishima and H. Nakamura. Pangea : an eager database replication middleware guaranteeing snapshot isolation without modification of database
servers. Proc. VLDB Endow., 2(1) :10661077, 2009.
MSN. www.msn.com.
Napster. http ://www.napster.com/.
M. T. zsu and Patrick Valduriez. Principles of Distributed Database Systems. Prentice Hall, 1999.
C. Plattner and G. Alonso. Ganymed : scalable replication for transactional web applications. In Middleware 04 : Proceedings of the 5th
ACM/IFIP/USENIX international conference on Middleware, pages 155
174, 2004.
C. Le Pape. Contrle de qualit des donnes rpliques dans les clusters.
Thse de doctorat, Universit Pierre et Marie Curie, Paris 6, France, December 2005.
Pragyansmita Paul. Seti @ home project and its website. Crossroads,
8(3) :35, 2002.
E. Pacitti, C. Coulon, Patrick Valduriez, and T. Ozsu. Preventive replication
in a database cluster. Distributed and Parallel Databases, 18(3) :223251,
2005.
F. Pedone, R. Guerraoui, and A. Schiper. Transaction reordering in replicated databases. In SRDS 97 : Proceedings of the 16th Symposium on
Reliable Distributed Systems, page 175, 1997.
F. Pedone, R. Guerraoui, and A. Schiper. The database state machine approach. Distrib. Parallel Databases, 14(1) :7198, 2003.
M. Patino-Martinez, R. Jimenez-Peres, B. Kemme, and G. Alonso.
MIDDLE-R, Consistent Database Replication at the Middleware Level.
ACM Transactions on Computer Systems, 28(4) :375423, 2005.
E. Pacitti, P. Minet, and E. Simon. Fast Algorithms for Maintaining Replica
Consistency in Lazy Master Replicated Databases. Int. Conf. on Very Large
DataBases (VLDB), 1999.
138

Bibliographie

[proa]
[prob]
[Proc]
[Prod]
[proe]
[prof]
[Prog]
[PRS07]

[PST+ 97]

[Pu91]

[RBSS02]

[RC96]
[RD01a]

[RD01b]

[RFH+ 01]

[Rui]
[SALAS09]

[SAS06]

ApGrid project. http ://www.apgrid.org/.

China National Grid project. http ://www.cngrid.org/web/guest/home.
Grid5000 Project. www.grid5000.org.
Respire Project. http ://www.respire.lip6.fr.
TeraGrid project. https ://www.teragrid.org/web/about/index.
The Folding@home project. www.folding.stanford.edu.
The Hadoop Project. www.hadoop.apache.org.
S. Plantikow, A. Reinefeld, and F. Schintke. Transactions for distributed
wikis on structured overlays. In Managing Virtualization of Networks and
Services, pages 256 267, 2007.
K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and A. J. Demers.
Flexible update propagation for weakly consistent replication. In SOSP
97 : Proceedings of the sixteenth ACM symposium on Operating systems
principles, pages 288301, 1997.
Calton Pu. Generalized transaction processing with epsilon-serializability.
In In Proceedings of Fourth International Workshop on High Performance
Transaction Systems, Asilomar, 1991.
U. Rohm, K. Bohm, H. Sheck, and H. Schuldt. FAS - a Freshness-Sensitive
Coordination Middleware for OLAP Components. Int. Conf. on Very Large
DataBases (VLDB), 2002.
K. Ramamritham and P. K. Chrysanthis. A taxonomy of correctness criteria
in database applications. The VLDB Journal, 5(1) :085097, 1996.
A. Rowstron and P. Druschel. Pastry : Scalable, decentralized object location and routing for large-scale peer-to-peer systems. In IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), pages
329350, 2001.
A. Rowstron and P. Druschel. Storage management and caching in PAST, a
large-scale, persistent peer-to-peer storage utility. In 18th ACM Symposium
on Operating Systems Principles (SOSP01), pages 188201, 2001.
S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Schenker. A scalable
content-addressable network. In SIGCOMM 01 : Proceedings of the 2001
conference on Applications, technologies, architectures, and protocols for
computer communications, pages 161172, 2001.
Jean-Francois Ruiz. Web 2.0 - quelles-applications ?
J. Sopena, L. Arantes, F. Legond-Aubry, and P. Sens. Building effective mutual exclusion services for grids. The Journal of Supercomputing,
49(1) :84107, 2009.
J. Sopena, L. Arantes, and P. Sens. Performance evaluation of a fair faulttolerant mutual exclusion algorithm. In SRDS, pages 225234, 2006.
139

Bibliographie

[Sch90]

F. B. Schneider. Implementing fault-tolerant services using the state machine approach : a tutorial. ACM Comput. Surv., 22(4) :299319, 1990.

[Sch93]

F.B. Schneider. Replication Management Using the State-Machine Approach, pages 169197. Distributed Systems (2nd Ed.). ACM Press, 1993.

[SGMB01]

L. Serafini, F. Giunchiglia, J. Mylopoulos, and P. A. Bernstein. The local

relational model : Model and proof theory, 2001.

[Sho07]

R. Shoup. eBay Marketplace Architecture : Architectural Strategies, Patterns and Forces. In InfoQueue Conf. on Enterprise Software Development,
2007.

[SJPPMK06]

J. Salas, R. Jimenez-Peris, M. Patino-Martinez, and B. Kemme. Lightweight reflection for middleware-based database replication. In SRDS 06 :
Proceedings of the 25th IEEE Symposium on Reliable Distributed Systems,
pages 377390, 2006.

[Sky]

Skype. www.skype.com.

[SMK+ 01]

I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan.

Chord : A Scalable Peer-to-peer Lookup Service for Internet Applications.
In ACM SIGCOMM, 2001.

[SNG08a]

I. Sarr, H. Naacke, and S. Ganarski. Dtr : Distributed transaction routing

in a large scale network. In VECPAR, pages 521531, 2008.

[SNG08b]

I. Sarr, H. Naacke, and S. Ganarski. Routage dcentralis de transactions

avec gestion des pannes dans un rseau large chelle. In BDA, 2008.

[SNG10a]

I. Sarr, H. Naacke, and S. Ganarski. Routage dcentralis de transactions

avec gestion des pannes dans un rseau large chelle. Ingnierie des
Systmes dInformation, 15(1) :87111, 2010.

[SNG10b]

I. Sarr, H. Naacke, and S. Ganarski. Transpeer : Adaptive distributed

transaction monitoring for web2.0 applications. In SAC, pages 423430,
2010.

[SNG10c]

Idrissa Sarr, Hubert Naacke, and Stphane Ganarski. Failure-tolerant transaction routing at large scale. In DBKDA, pages 165172, 2010.

[SOMP01]

A. Sousa, R. Oliveira, F. Moura, and F. Pedone. Partial replication in the

database state machine. In NCA 01 : Proceedings of the IEEE International Symposium on Network Computing and Applications (NCA01), page
298, 2001.

[SPMJPK07]

D. Serrano, M. Patino-Martinez, R. Jimenez-Peris, and B. Kemme. Boosting database replication scalability through partial replication and 1-copysnapshot-isolation. In PRDC 07 : Proceedings of the 13th Pacific Rim International Symposium on Dependable Computing, pages 290297, 2007.

[SR96]

A. Schiper and M. Raynal. From group communication to transactions in

distributed systems. Commun. ACM, 39(4) :8487, 1996.
140

Bibliographie

[SSP10]

N. Schiper, P. Sutra, and F. Pedone. P-store : Genuine partial replication

in wide area networks. Technical Report 2010/03, University of Lugano,
2010.

[TS99]

A. S. Tanenbaum and M. VAN STEEN. Distributed Systems : Principles

and Paradigms. Prentice Hall, 1999.

[VATS04]

V. Vlachos, S. Androutsellis-Theotokis, and D. Spinellis. Security applications of peer-to-peer networks. Comput. Netw., 45(2), 2004.

[VBB+ 03]

R. VanRenesse, K. Birman, A. Bozdog, D. Dimitriu, M. Singh, and W. Vogels. Heterogeneity-aware peer-to-peer multicast. In 17th International
Symposium on Distributed Computing (DISC2003), 2003.

[VBLM07]

B. Vandiver, H. Balakrishnan, B. Liskov, and S. Madden. Tolerating byzantine faults in transaction processing systems using commit barrier scheduling. In SOSP 07 : Proceedings of twenty-first ACM SIGOPS symposium
on Operating systems principles, pages 5972, 2007.

[VMR02]

A. K. Vishal, V. Misra, and D. Rubenstein. Sos : Secure overlay services.

In In Proceedings of ACM SIGCOMM, pages 6172, 2002.

[Vog09]

W. Vogels. Eventually consistent. Commun. ACM, 52(1) :4044, 2009.

[VRMCL09]

L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner. A break

in the clouds : towards a cloud definition. SIGCOMM Comput. Commun.
Rev., 39(1) :5055, 2009.

[VS05]

D. Del Vecchio and S. H. Son. Flexible update management in peer-topeer database systems. In IDEAS 05 : Proceedings of the 9th International
Database Engineering & Application Symposium, pages 435444, 2005.

[WK05]

S. Wu and B. Kemme. Postgres-r(si) : Combining replica control with

concurrency control based on snapshot isolation. In ICDE 05 : Proceedings of the 21st International Conference on Data Engineering, pages
422433, 2005.

[WLG+ 08]

P. Watson, P. L., F. Gibson, P. Periorellis, and G. Pitsilis. Cloud computing

for e-science with carmen. In In 2nd Iberian Grid Infrastructure Conference Proceedings, pages 314, 2008.

[WYP97]

Kun-Lung Wu, Philip S. Yu, and Calton Pu. Divergence control algorithms
for epsilon serializability. IEEE Trans. Knowl. Data Eng., 9(2) :262274,
1997.

[Yah]

Yahoo. www.yahoo.com.

[YV00]

Haifeng Yu and Amin Vahdat. Efficient numerical error bounding for replicated network services. In IN INT. CONF. ON VERY LARGE DATABASES
(VLDB), pages 123133, 2000.

141

Bibliographie

142

Rsum
La rplication dans les bases de donnes a t largement tudie, au cours des trois dernires
dcennies. Elle vise amliorer la disponibilit des donnes et augmenter la performance daccs
aux donnes. Un des dfis majeurs de la rplication est de maintenir la cohrence mutuelle des
rpliques, lorsque plusieurs dentre elles sont mises jour, simultanment, par des transactions.
Des solutions qui relvent partiellement ce dfi pour un nombre restreint de bases de donnes
relies par un rseau fiable existent. Toutefois, ces solutions ne sont pas applicables large chelle.
Par ailleurs, lantinomie entre les besoins de performances et ceux de cohrence tant bien connue,
lapproche suivie dans cette thse consiste relcher les besoins de cohrence afin damliorer la
performance daccs aux donnes. Or, dans le contexte du web2.0, de nombreuses applications
tolrent une cohrence relche et acceptent de lire des donnes qui ne sont pas ncessairement les
plus rcentes ; cela ouvre la voie vers de nouvelles solutions offrant de meilleures performances
en termes de dbit transactionnel, latence, disponibilit des donnes et passage lchelle. Par
exemple, il est possible de grer des transactions de vente aux enchres (sur eBay ou Google
Adsense) sans ncessairement accder la dernire proposition de prix, puisque lenchre est
sous pli cachet. Dans cette thse, nous considrons des applications transactionnelles dployes
large chelle et dont les donnes sont hberges dans une infrastructure trs dynamique telle quun
systme pair--pair. Nous cherchons amliorer les performances des applications en contrlant
la cohrence des donnes accdes, en quilibrant la charge des rpliques et en tenant compte de
la disponibilit des ressources (SGBD, gestionnaire de transactions). Nous proposons une solution
intergicielle qui rend transparente la distribution et la duplication des ressources mais aussi leur
indisponibilit temporaire. Notre solution prserve lautonomie des applications qui demeurent
inchanges, sans quaucune modification interne du SGBD ne soit ncessaire. Les applications
spcifient leurs exigences en termes de besoin de cohrence, puis lintergiciel honore ces exigences
en contrlant le routage des transactions et ltat des ressources. Nous dfinissons deux protocoles
pour maintenir la cohrence globale, en fonction de la connaissance des donnes manipules par
les transactions. Le premier protocole ordonne les transactions partir de la dfinition a priori
des donnes accdes. Le deuxime protocole dtermine un ordre plus souple, en comparant les
donnes accdes, le plus tardivement possible, juste avant la validation des transactions. De plus,
nous avons complt notre solution en concevant un catalogue entirement dcentralis et passant
lchelle pour grer les mtadonnes ncessaires au routage des transactions. Toutes les solutions
proposes tolrent les pannes franches, fonctionnalit essentielle pour que les rsultats de cette
thse puissent tre mis en uvre trs large chelle. Finalement, nous avons implment nos
solutions pour les valider exprimentalement. Les tests de performances montrent que la gestion
143

Bibliographie

des mtadonnes est efficace et amliore le dbit transactionnel. Nous montrons galement que la
redondance de lintergiciel diminue le temps de rponse face aux situations de pannes.
Mots-cls : Bases de Donnes, Rplication asynchrone, Routage de transactions, disponibilit,
passage lchelle, cohrence mutuelle.

144