Fiche descriptive

_____________________________ Fiche descriptive _____________________________
Proposition de projet M1 SAR 2005-2006
Encadrant(s): Cécile Le Pape et Stéphane Gançarski
Email(s) :[email protected], [email protected]
Nombre d'étudiants concernés : 1 binôme.
Sujet du projet : Evaluation du contrôle de fraîcheur de données relationnelles répliquées dans
une configuration multimaître.
Objectifs et approche : Le cadre général de ce projet est celui d’une base de données
relationnelle sur lesquelles sont exécutées des transactions. La base de données est répliquée
sur une grappe de PCs. La réplication est asynchrone, c’est-à-dire qu’une mise à jour est
effectuée d’abord sur un nœud, puis propagée plus tard sur les autres nœuds. Un intergiciel
s’intercale entre le client qui envoie les transactions et les nœuds. Dans une configuration
multimaître, l’intergiciel peut choisir n’importe quel PC (ou nœud) pour exécuter une
transaction envoyée par un client. Le choix du nœud d’exécution doit permettre d’améliorer
l’équilibrage de charge et donc les performances. L’intergiciel gère la cohérence des nœuds,
de façon à ce que les mises à jour touchant la même donnée soient propagées à terme sur tous
les nœuds et y soient exécutées sans conflit, dans le même ordre. En revanche, deux
transactions qui ne touchent pas les mêmes données peuvent être exécutées en parallèle dans
n’importe quel ordre. De plus, les requêtes en lecture seule peuvent accepter des données
raisonnablement obsolètes, en garantissant que leur fraîcheur satisfait un contrat spécifié par
l’application. Par exemple, une requête pour calculer le chiffre d’affaires annuel d’une
entreprise peut tolérer de ne pas prendre en compte les ventes effectuées dans la journée.Le
premier objectif de ce projet est d’implémenter un algorithme de contrôle de la fraîcheur. Cet
algorithme a été décrit dans [WDIDDR]. L’implémentation devra étendre le prototype
REFRESCO fonctionnant actuellement pour une configuration monomaître, c’est-à-dire pour
laquelle un seul nœud (appelé nœud maître) exécutent les mises à jour qui sont ensuite
propagées sur les autres nœuds (appelés nœuds esclaves).
De plus, différentes stratégies de propagation des mises à jour devront être testées. Une
stratégie simple consiste par exemple à propager une mise à jour dès que possible, de façon à
maintenir tous les nœuds les plus frais possible. Une autre possibilité est de propager les
mises à jour au dernier moment (« à la demande »). Différentes stratégies ont été proposées
dans [WDIDDR]. Le deuxième objectif de ce projet est de tester les performances du système
(temps moyen de réponse des transactions) en fonction de la charge applicative (fréquence des
mises à jour, fraîcheur demandée, etc.).
Langages de spécification, de programmation : SQL, Java, UML, notions de bash.
Environnement de développement : Linux, j2sdk1.4.2, postgresql-7.3.4
Bibliographie : [WDIDDR] "Fined-grain Refresh Strategies for Managing Replication in
Database Clusters", Stephane Gancarski, Hubert Naacke and Cécile Le Pape, VLDB
Workshop on Design, Implementation and Deployement of Database Replication, pg. 47-54,
august 2005, Trondheim (Norway) .