L'élasticité des bases de données sur le cloud computing - CoDE

Chapitre 4
Bases de données et élasticité
Dans ce chapitre, après un passage par l’état de l’art (section 4.1) qui est assez pauvre,
nous débattrons de l’élasticité des BDs sur cloud : nous listerons les problèmes liés à son
étude et aux moyens pouvant être mis en place pour l’étudier (section 4.2). Nous proposerons
ensuite des scénarios de test et une série de paramètres pouvant caractériser cette élasticité
d’une BD pour cloud (section 4.3). A la section 4.4, nous soumettrons ensuite Cassandra à ses
scénarios afin de mieux comprendre comment ses choix techniques influencent son élasticité.
Enfin, nous résumerons les travaux de T. Dory [41] qui apportent une autre méthodologie
pour tester et comparer l’élasticité des BDs sur cloud (section 4.5). Cette méthodologie
est très intéressante mais possède, toute comme notre méthode, des points faibles. A la section
4.6, nous tenterons de tirer parti des points forts et faibles des deux approches pour
mieux appréhender l’élasticité des BDs.
4.1 Etat de l’art
Il n’existe à l’heure actuelle et à notre connaissance aucune étude similaire à notre approche.
Néanmoins, nous nous devons de souligner les travaux de B. Cooper qui peuvent
servir de première approche : Yahoo ! Cloud Serving Benchmark (YCSB) [17] qui propose un
framework et une étude installant les bases pour une nouvelle méthodologie de bancs d’essais
(benchmark en anglais) pour les BDs sur cloud.
YCSB utilise le terme elastic speedup pour parler de l’élasticité qu’ils définissent comme la
capacité d’ajouter de nouvelles instances à un système en cours d’exécution. Cette définition
est fort similaire à la nôtre mais ne considère que l’ajout de nouvelles instances (et ne considère
pas leur retrait).
Le scénario proposé par YCSB est le suivant : soit un système composé de 2 serveurs (chargés
de 120GB de données) soumis à une charge de travail (Workload en anglais) constante.
Une fois, les temps de réponse du système stabilisés 1 , une nouvelle instance est ajoutée au
système. Cette opération est répétée jusqu’à atteindre un système de 6 instances. Durant l’entièreté
du test, la charge est constante et estimée à 80% de la charge maximale que supporte
le système (composé de 6 instances).
Par exemple, observons les résultats d’une telle expérience sur Cassandra (figure 4.1).
Dans cette figure, les 10 premières minutes représentent les temps de réponses d’un système
de 5 instances. Après ces 10 minutes le système est stable et un sixième serveur est ajouté au
1. Ils supervisent l’opération pour voir si ses temps de réponses sont plus ou moins constants
39