These Contrôle de Qualité des Données Répliquées dans un Cluster

Publié par

THÈSE présentée devant l’Université Pierre et Marie Curie(ParisVI) pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ PIERRE ET MARIE CURIE Mention INFORMATIQUE par Cécile LE PAPE Laboratoire d’informatique de Paris6-Equipe Base de Données Ecole Doctorale d’Informatique, Télécommunications et Electronique de Paris Contrôle de Qualité des Données Répliquées dans un Cluster Soutenue le 1er décembre 2005, devant la commission d’examen Président Pierre SENS Professeur à l’Université ParisVI Rapporteurs Marc SHAPIRO Directeur de recherche à l’INRIA Philippe PUCHERAL Professeur à l’Université de Versailles Examinateurs Michel SCHOLL Professeurau CNAM Invitée Anne DOUCET Professeur à l’Université Paris VI Directeur Patrick VALDURIEZ Directeur de recherche à l’INRIA Encadrant Stéphane GANÇARSKI
Publié le : jeudi 22 septembre 2011
Lecture(s) : 47
Nombre de pages : 120
Voir plus Voir moins

THÈSE
présentéedevant
l’UniversitéPierreetMarieCurie(ParisVI)
pourobtenirlegradede
DOCTEUR DE L’UNIVERSITÉ PIERRE ET MARIE CURIE
Mention INFORMATIQUE
par
CécileLE PAPE
Laboratoired’informatiquedeParis6-EquipeBasedeDonnées
EcoleDoctoraled’Informatique,TélécommunicationsetElectroniquedeParis
ContrôledeQualitédesDonnéesRépliquées
dansunCluster
Soutenuele1erdécembre2005,devantlacommission d’examen
Président Pierre SENS Professeuràl’UniversitéParisVI
Rapporteurs Marc SHAPIRO Directeurderechercheàl’INRIA
Philippe PUCHERAL Professeuràl’UniversitédeVersailles
Examinateurs Michel SCHOLL ProfesseurauCNAM
Invitée Anne DOUCET Professeuràl’UniversitéParisVI
Directeur Patrick VALDURIEZ Directeurderechercheàl’INRIA
Encadrant Stéphane GANÇARSKI MaîtredeConférenceàl’UniversitéParisVILaconnaissance est unarbredeviequi granditàla lumièredesautres.Remerciements
Je tiens tout particulièrement à remercier Stéphane Gançarski, Maître de Conférence à
l’UniversitéParisVI,quiaétéunguideconstant,disponible,patientetefficacetoutaulongde
cesannées.Jeleremercieégalementdesaconfiance,desonsoutiensansfailleetsagentillesse
àtouteépreuve.
Je remerciesincèrement Patrick Valduriez, Directeur de Rerchercheà l’INRIA, de m’avoir
accordé sa confiance depuis le tout début en maîtrise, puis en DEA lorsque ma grossesse a
rendulasituationdélicate.Grâceàlui,j’aibénéficiédeconditionsdetravailexceptionnelleset
d’unsoutienconstantmalgréladistance.
Je remerciePhilippe Pucheral, Professeur à l’Université de Versailles et MarcShapiro, Di-
recteurdeRechercheàl’INRIAd’avoiracceptéd’êtrerapporteursdecettethèseetpourleurs
commentairesinstructifs.
Je remercie Michel Scholl, Professeur au CNAM, d’avoir accepté de participer au jury de
cettethèse,ainsiquedelabienveillanceamicalequ’ilm’atoujoursaccordée.
JeremercieégalementPierreSens,Professeuràl’UniversitédeParisVI,d’avoiracceptéde
participeraujurydecettethèse.
Je remercie le Laboratoire de Paris 6, en particulier l’équipe d’administration et l’équipe
technique,dem’avoiraccueillidansseslocauxetd’avoirrendumonséjouraussiagréable.
Jeremercielesmembresdel’équipe BasedeDonnées duLIP6 qui m’ont accueillien DEA
et au sein de laquelle j’ai trouvé du soutien, des conseils et un cadrede travailexceptionnel :
Anne Doucet, que je remercie également d’avoir accepté de participer au jury de cette thèse,
HubertNaacke,dontladisponibilité,l’expertisetechniqueetlagentillesseenfontunprécieux
collaborateur, ainsi que Bernd Amann, Maha Abdallah, Alda Gançarski, Camélia Constantin
etJulienTanguy.
J’adresse un remerciement tout particulier à Nicolas Lumineau, compagnon de route et
ami,quiapartagétoutesmesjoies,maisaussitousmesdoutes,tousmesmomentsdefatigue,
toutesmesgalères.Monalter-ego,mondouble,monfrère.
Ma gratitude et mes remerciements les plus sincères vont également à Anneli et Bernard,
pourêtrelesamislesplusinconditionnels, lesplusexceptionnels,etbienplusencore.
Jeremercieégalement ma famille de m’avoir permis d’êtrece que je suis, d’oser avoir en-
vie,d’entreprendreetderéussir,grâceàleursoutienconstantetleuraffectionpermanente.
Enfin, mes pensées les plus émues vont, avec une tendresseet une affection sans limite, à
monfiancéFrédéricetàmafilleEline,quidonnentsimplementetentièrementtoutsonsensà
cettethèse.
J’adresseunetoutedernièrepenséeàmon amieStéphanie.Oùquetusois encejour,tues
prèsdemoi...Tabledesmatières
Introduction 3
1 Donnéesrépliquéesetdivergence 9
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Notiondedivergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Dimensions deladivergence . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.2 Divergenceetcontrôledeconcurrencelocal. . . . . . . . . . . . . . . . . 11
1.2.3 Divergenceetcontrôledescopies. . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4 Problématiqueducontrôledeladivergence . . . . . . . . . . . . . . . . 17
1.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Préventiondeladivergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1 Architectureclient/serveurenmodesérialisable . . . . . . . . . . . . . . 21
1.3.2 Méthodesderéplicationsynchrone . . . . . . . . . . . . . . . . . . . . . 23
1.4 Minimisationdeladivergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4.1 Propagationaussitôtquepossible . . . . . . . . . . . . . . . . . . . . . . 24
1.4.2 Propagationpériodique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3 Propagationévénementielle . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.4 Lessystèmescommerciaux . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 Contrôledeladivergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5.1 Mesurebooléenneetvariantes . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5.2 Mesuretemporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5.3 Mesuredeversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.5.4 Mesuresnumériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.5.5 Mesuresmixtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.6 Contrôledeladivergenceetéquilibragedecharge . . . . . . . . . . . . . . . . . 34
1.6.1 Election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.6.2 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.7 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2 Contrôledequalité 39
2.1 Modèledequalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.1.1 Etatdestransactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1.2 Ordredeprécédencedestransactions . . . . . . . . . . . . . . . . . . . . 41
2.1.3 Définition delaqualitédesdonnées . . . . . . . . . . . . . . . . . . . . . 42
2.1.4 Etatsd’unedonnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1.5 Contratdequalitépourdonnéesrelationnelles . . . . . . . . . . . . . . . 43
2.2 Evaluationetcontrôledelaqualité . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2.1 Graphedeprécédence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12 Tabledesmatières
2.2.2 Graphed’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3 Architectured’unsystèmedecontrôledelaqualité 55
3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1.1 Présentationgénérale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1.2 Contrôledesaccès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1.3 Contrôledesnœuds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.4 Evaluationdel’étatdelagrappe . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.5 Métabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2 Techniquesdegestionducontrôledelaqualité . . . . . . . . . . . . . . . . . . . 65
3.2.1 EvaluationduDataSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.2 Transcriptionducontratutilisateur . . . . . . . . . . . . . . . . . . . . . 70
3.2.3 Détectiondesconflits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.4 Evaluationdesmisesàjourd’unetransaction . . . . . . . . . . . . . . . 72
3.2.5 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.6 Stratégiesderafraîchissement . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 Validation:leprototypeREFRESCO 79
4.1 Validationdumodèledequalité . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.1 Environnementexpérimental . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.2 Paramètres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.3 Mesuresdeperformances . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.4 Impactduseuildedivergence . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.5 Impactdelagranularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1.6 Impactdunombredenœudsdelagrappe . . . . . . . . . . . . . . . . . 84
4.1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Etudedesperformancesdelajournalisationactive . . . . . . . . . . . . . . . . . 85
4.2.1 Environnementexpérimental . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.2 Paramètres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.3 Comparaisonprocédureexternevs.procédurestockée . . . . . . . . . . 86
4.2.4 Impactduseuildedivergencesurlamesurenumérique . . . . . . . . . 87
4.3 Etudedesstratégiesderafraîchissement . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.1 Modèledechargeapplicative . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.2 Chargesapplicativesexpérimentales . . . . . . . . . . . . . . . . . . . . . 88
4.3.3 Paramètres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.3.4 Comparaisonstratégiesdebasevs.stratégieshybrides . . . . . . . . . . 89
4.3.5 Impactdutauxdeconflitsurlesperformances . . . . . . . . . . . . . . . 90
4.3.6 Impactdeladivergencetoléréesurlesperformances . . . . . . . . . . . 92
4.3.7 Conclusion surlesstratégiesderafraîchissement. . . . . . . . . . . . . . 94
4.4 IntégrationdansleprojetLEG@NET . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5 Conclusion 99
Bibliographie 113Introduction
Les “clusters” sont des grappes d’ordinateurs reliés par un réseau local haut-débit. Ils
offrent depuis quelques années des environnements performants et économiquement sédui-
santspourlessitescentralisésquidoiventfairefaceàunnombretoujours croissantdeclients
tout en conservant le même niveau de disponibilité et d’efficacité.Google est un exemple de
passageà l’échelleréussi :de5 machinesoriginelles logéesdansun petitbureaudeStanford,
leurgrappecontientaujourd’huiplusde10000machines,touteshébergéesdanslemêmebâti-
mentetaccessiblessurlewebviauneuniqueURL.Lesuccèsdesgrappesestdûauxavantages
suivants:
• Le faible coût : plusieurs ordinateurs personnels bon marché sont moins coûteux qu’un
seul système multiprocesseurs au tarif d’achat et de remplacement prohibitif, surtout
pourdesentreprisesdepetiteoumoyennetaille.
• La flexibilité : il suffit d’ajouter un nœud (une machine) pour gagner en capacitéde trai-
tementetdestockageets’adapterainsiàl’évolutiondesbesoinsdesapplications.
• La disponibilité : en cas de panne, les autres nœuds sont toujours disponibles, surtout
lorsquelesdonnéessontrépliquéessurtouslesnœuds.
• L’efficacité:destraitementssimultanésdeplusieursdemandesd’accèsauxdonnéespeuvent
s’exécutersurplusieursnœudsenparallèle.
• La simplicité: une grappeoffredes délais bornés de communication, ce qui délivrecette
architecturede la gestion délicatedela plupartdesproblèmes dedistribution pure(dé-
tectiondeterminaison,consensus,etc.).
Plus récemment, des grappes de base de données ont fait leur apparition. Chaque nœud
héberge un serveur de base de données (SGBD) et les données sont accédées de façon tran-
sactionnelle. Différentesapplications peuvent bénéficier des avantages d’une grappe de base
de données pour améliorer leurs performances, comme par exemple les applications d’ASP
(ApplicationServiceProvider).EnASP,lesclientsinstallentleurapplicationsurlesitecentralisé
d’unhébergeur,lesiteétantconstituéd’unegrappedebasededonnées.L’hébergeursecharge
del’exécutionetdela maintenancedel’applicationtandisqueleclientainsi libérédestâches
techniques peut se concentrer sur ses aspects métier. Le nombre de nœuds dédiés à une ap-
plicationestfonctionducontratpasséavecleclient.Nousnousintéressonsdanscettethèseà
l’amélioration des performancesdes accès auxdonnées sur une grappede bases dedonnées.
L’objectifdecettethèseestd’exécuteruneapplicationbasededonnéessurunegrappe:
• engarantissantquelaprésencedelagrappeesttransparenteàl’applicationetauxbases
dedonnées,
• en optimisant les performances du système de gestion des données pour fournir des
34 Introduction
tempsderéponsesatisfaisants,
• encontrôlantlaqualitédesdonnéesfourniesàl’applicationetstockéessurlesnœuds.
Nousdévelopponsmaintenantcestroisaspectsendétaillantlesmécanismesnécessaireset
endonnantunaperçudeschoixquiguidentlestravauxdecettethèse.
Transparencedelagrappedebasesdedonnées
Unaspectimportantestquelaprésencedelagrappedoitêtretransparenteàl’application
et aux SGBD. D’une part l’accès aux données doit être transparent pour l’application. Autre-
ment dit, la solution doit préserver l’autonomie de l’application. La première raison est que la
conception d’une application est plus simple et plus flexible si la présence de la grappe est
transparente, suivant en cela les principes de conception logicielle de séparations des préoc-
cupations.Ceprincipe[Dij76]ditqu’unproblèmedonnéimpliquedifférentespréoccupations,
qui doivent être identifiées et séparées pour mieux gérer la complexité du problème et pour
obtenir les qualités deconception nécessaires,telles que l’adaptabilité,la maintenabilité, l’ex-
tensibilitéetlaréutilisabilité.Dansnotrecas,lalogiquedel’applicationdoitêtreséparéedela
méthode d’accès aux données. La deuxième raison pour préserver l’autonomie de l’applica-
tion est que, si l’application existe déjà, sa migration sur une grappe est un problème délicat
etcoûteuxcaruneapplicationquifonctionnedepuisdenombreusesannéespeutprendreplu-
sieurs années-hommes de travail pour être portée sur un nouveau système. Rendre l’accès
auxdonnéesdelabasetransparentàl’applicationsignifiequecertainestechniques,denature
intrusive,nesontpasenvisageables.C’estlecasd’unesolutioncommel’offredeWindowsClus-
teringdanslaquellel’applicationutilisesaconnaissancedelagrappe(clusterawareapplication)
pour optimiser l’utilisation de la grappeà ses besoins, mais qui nécessite de modifier le code
de l’application. Pour la même raison, nous n’utilisons pas de technique langage dédiée en
proposantparexempleuneextensionSQLpermettantd’adapterletraitementdel’application
àl’existencedelagrappe.Enfin,la solution proposéenedoitpasmodifierlesméthodesd’ac-
cès de l’application au SGBD, par exemple en remplaçant l’utilisation d’un driver JDBC par
un nouveau mécanisme de communication (RPC, Corba, RMI, etc.). Pour cette raison, nous
proposons une solution qui se présente comme un driver standard, rendant transparente à
l’applicationl’existencedelagrappedebasededonnées.
D’autre part, la transparence de la grappe signifie qu’un nœud de données doit pouvoir
héberger n’importe quel SGBD, sans avoir à le modifier. Autrement dit, la solution doit pré-
serverl’autonomiedesSGBD.Unavantageestderendrelasolutionplusgénériquecarellen’est
pasliéeàl’implémentationparticulièred’unSGBD(Oracle,Postgres,Sybase,DB2,MySQL,etc.).
De plus, même en spécialisantla solution à un seul SGBD, il n’est pastoujours possible d’ac-
céderaux sourcesdes SGBD propriétaires.Dans tous les cas,modifier le code d’un SGBD est
difficile,doncsourced’erreurs,carlesSGBDsontdeslogicielsextrêmementcomplexes.Enfin,
les clients ont leurs préférences et ne sont pas nécessairement prêts à stocker leurs données
surunSGBDnouveauquineprésentepaslesmêmesgarantiesqu’unsystèmeconnu,fiableet
maintenu. Néanmoins, préserver l’autonomie des SGBD rend le contrôle des accès aux don-
nées plus complexe car il n’est pas possible de contrôler la gestion interne des traitements.
Parexempleiln’estpaspossibledecontrôlerl’ordred’exécutiondesopérationsdedemandes
d’accèsconcurrentes sur un nœud de données, parexemple en contrôlant la stratégie de ver-
rouillagedu gestionnaire deconcurrence.Il devient égalementdifficiledesavoir quelles sont
les données touchées par un accès puisque cette information n’est disponible qu’en interneIntroduction 5
au moment du calcul du plan d’exécution de l’accès. Pour préserver la transparence de la
grappe, nous avons choisi d’insérer une couche intergicielle entre l’application et la grappe,
cettecouchecoordonnantlesdifférentsSGBD.
Performancesdesaccèsauxdonnées
L’efficacitédel’accèsauxdonnéesdépenddedeuxmécanismescomplémentaires:larépli-
cationdesdonnéesetl’équilibragedecharge.
Laréplicationdesdonnées
Une solution efficace pour obtenir de bonnes performances et une meilleure disponibilité
des données est la réplication des données sur plusieurs nœuds. Le traitement en parallèle
des demandes d’accès améliore les performances en terme de temps de réponse et de charge
acceptableparlesystème.Deplus,unedonnéenedevientindisponiblequesitouslesnœuds
quienpossèdentunecopietombentenpannesimultanément,d’oùunemeilleuredisponibilité
des données. Enfin, la réplication permet de répartir la charge entre les nœuds. Le problème
général lié à la réplication est celui de la cohérence des données. La notion de cohérence re-
couvredifférentesproblématiques,dontunetaxonomieaétéproposéedans[RC96].Dupoint
de vue des demandes d’accès, la gestion de la concurrence locale se préoccupe de leur iso-
lation, c’est-à-dire de les exécuter en parallèle en évitant qu’une mise à jour soit visible par
d’autres demandes d’accès tant qu’elle n’a pas été validée. Du point de vue des données,
la gestion des copies doit assurer leur cohérence mutuelle, c’est-à-dire que toutes les copies
d’une donnée soient identiques. Sans contrôle, l’exécution simultanée des demandes d’accès
peut conduire à des phénomènes indésirables, soit parce que les résultats obtenus ne sont
pasinterprétablesparl’utilisateur,soitparcequ’ilsrisquentdecorromprelabasededonnées.
Néanmoins, accepterdevivreaveccertainesimperfections peut améliorerla performancedu
système en améliorant la concurrence. Nous nous intéressons à la lecture de copies de don-
nées qui ne sont pas nécessairementmutuellement cohérentes,pour accélérerl’exécution des
requêtes.
Ilexistedenombreusesstratégiesderéplication.Toutd’abord,concernantleplacementdes
donnéees,nousoptonspouruneréplicationtotaledesdonnéessurtouslesnœuds.Répliquer
latotalitédesdonnéesapouravantagedepréserverl’autonomiedesdonnéesdel’application,
àl’opposéd’uneréplicationpartiellequinécessited’effectuerunepartitiondesdonnéesetde
modifier le schéma de la base en ce sens. En contrepartie, une modification effectuée sur un
nœuddoitàtermeêtrepropagéesurlatotalitédesautresnœuds.Lesstratégiesderéplication
peuvent êtreclassées en deux familles : la réplication synchrone et la réplication asynchrone.
Laréplicationsynchroneisoletouteslescopiesd’unedonnéesavantdevaliderunemodifica-
tion.Elleoffredesdonnéesmutuellementcohérentes,maisauprixdeleurdisponibilitéetdes
performancescarlemaintiendelacohérencemutuellenécessited’unefaçonoud’uneautrede
retarderlesopérationsdemiseàjourjusqu’àcequetouteslescopiessoientsemblables[CP92],
cequiprovoqueunsurcoûtdetempsderéponse.Laréplicationasynchroneoffreplusdeflexi-
bilitécarelledistinguelaphasedemiseàjourd’unedonnéedelaphasedepropagationdela
miseàjour.C’estlaraisonpourlaquellenousavonschoisiuneapprocheparréplicationasyn-
chrone. La difficulté des approches asynchrones est de contrôler la cohérence mutuelle des
données. Contrairementauxapprochesoptimistes qui nécessitent des mécanismes derésolu-
tiondeconflitencasdeproblèmedemisesàjoursimultanéessurdifférentsnœuds,nousnous
intéressonsàdesapplicationspourlesquelleslesconflitsnesontpasnécessairementrares.Par6 Introduction
exemple,uneactivitédeback-officeinterrogedesdonnéesmodifiéesquotidiennementparles
activitésdefront-office.Danscecontexte,larésolutiondesconflitspeutdevenirtrèscouteuse,
car très fréquente. C’est pourquoi nous choisissons une solution de prévention des conflits.
Nous assurons la sérialisation des transactions au niveau de l’intergiciel soit en reproduisant
lemêmeordresurtouslesnœuds,soitengarantissantquel’ordred’exécutiondestransactions
surchaquenœudestcompatibleavecunordrederéférenceglobaldéfiniapriori.
L’équilibragedecharge
En sus de la réplication des données, l’équilibrage de charge entre les différents nœuds
permet d’améliorer l’utilisation des ressources. Les temps de réponse des accès aux données
bénéficientdeladiminutiondelachargedechaquenœud.Néanmoins,équilibrerlachargeest
un problème complexe qui dépendde nombreuxparamètres,à la fois statiques (parexemple
les capacités individuelles des machines) et dynamiques (par exemple l’état de la mémoire,
du processeur, les pages chargées ou non). Dans un contexte base de données, une tâche est
une demande d’accès aux données. Cela signifie que l’équilibrage doit en particulier tenir
compte de l’état des données sur les nœuds, car dans le cadre d’une réplication asynchrone,
les copies des données sur des nœuds différents peuvent être dans des états différents (par
exemple ne pas refléterla même version de la donnée). Un autreaspect du problème est que
la durée d’exécution d’une tâche est non déterministe car c’est le SGBD qui gère lui-même la
concurrence.Danscettethèse,nousproposonsunenouvelleméthoded’équilibragedecharge
qui étend les travaux classiques de routage des accès en tirant profit de la qualité demandée
parl’application.
Contrôledelaqualitédesdonnées
La notion de qualité recouvre traditionnellement beaucoup de dimensions, telles que la
complétude,lavalidité,lacohérence,lapertinence,laprécision,etc.[SLW97].Danscettethèse
nousnousintéressonsàlanotiondequalitécommelecontrôledeladivergencedescopiesd’une
donnée.End’autrestermes,laqualitéestlamesured’uneerreursurlacopielue.Notreobjectif
estdecontrôlerladivergencedescopiespouraméliorerlestempsderéponsedel’application.
Contrôledelaqualitéperçueparl’application
Chaqueapplicationadesbesoinsspécifiquesconcernantlaqualitédesdonnéesauxquelles
elleaccède.Nombreusessont lesapplicationsqui tolèrentun certainrelâchementdela diver-
gencedesdonnées.Lesentrepôtsdedonnéessupportentdesrequêtesstatistiqueslourdesqui
acceptentdesrésultatsraisonnablement imprécis(parexemplelesventes dujour nesont pas
nécessaires pour faire le bilan trimestriel). Les applications scientifiques manipulent en toute
connaissance de cause des données imprécises. Les miroirs de serveurs web peuvent conte-
nir des documents légèrement obsolètes tant que les mises à jour sur le site maître n’ont pas
été propagées. Néanmoins, la divergence tolérée par ces applications doit être contrôlée de
façon à garantir qu’elle ne dépasse pas les limites acceptables par l’application. Intégrer les
besoinsspécifiquesdecesapplicationsdanslesystèmedegestiondesdonnéespermetd’offrir
un service qui coïncide avec les besoins applicatifs donc améliore la satisfaction de l’utilisa-
teur.Deplus,leserviceestplusperformantcarlesystèmeaplusdeflexibilitépourlagestion
desdonnéesetdesdemandesd’accès.Ilpeutparexemplerouterlesdemandesd’accèssurles
nœudsselonlaqualitédemandéeouretarderlapropagationdesmisesàjoursurlesnœudsen

Soyez le premier à déposer un commentaire !

17/1000 caractères maximum.