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

Faculté de Sciences
Département Informatique
L’élasticité des bases de données
sur le cloud computing
Nicolas Degroodt
Directeur : Prof. Esteban Zimányi
En collaboration avec
Mémoire présenté en vue de
l’obtention du grade de
Master en Sciences Informatiques
Année académique 2010–2011

Remerciements
Je tiens à remercier le professeur Esteban Zimányi, mon directeur de mémoire, pour ses
nombreux conseils tant de direction et de rédaction que scientifiques, qui m’ont permis de
fournir un travail que j’espère pertinent et intéressant.
La collaboration avec la société Euranova fut aussi très agréable et instructive. Je tiens à
remercier tous ses membres pour leur accueil et plus particulièrement Sabri Skhiri dit Gabouje
et Nam-Luc Tran pour leurs conseils et nos discussions qui ont soulevé des problèmes fort
intéressants et y ont souvent trouvé des solutions. Je tiens également à souligner les précieuses
informations et recommandations que m’ont apporté Hervé Bath, Eric Delacroix et Ivan Frain.
Je leur en suis très reconnaissant.
Enfin, je souhaite remercier Peter Van Roy, Boris Mejias et Thibault Dory, membres du
département d’ingénierie informatique (INGI) de l’Université catholique de Louvain (UCL)
qui m’ont accueilli dans leur groupe de discussion autour du cloud computing, leurs remarques
furent très instructives.

Table des matières
1 Introduction 1
1.1 Contexte et objectifs du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Structure du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contributions du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Le cloud computing et ses services 4
2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Origine et modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Caractéristiques spécifiques et capacités . . . . . . . . . . . . . . . . . . 6
2.1.3 Amazon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Définition du cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Propriétés fondamentales des services . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 La haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Passer à l’échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Le théorème CAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Etude comparative de différents systèmes de gestion des bases de données 15
3.1 Classification des systèmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Le modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Les choix CAP et PACELC . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 La réplication synchrone ou asynchrone . . . . . . . . . . . . . . . . . . 16
3.1.4 Le modèle de consistance . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.5 Le modèle de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Les bases de données relationnelles distribuées . . . . . . . . . . . . . . . . . . . 18
3.2.1 Le modèle de données relationnel . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Les propriétés ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 MySQL Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.4 Autres solutions SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.5 Les solutions SQL-MR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Le mouvement NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Les modèles de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.2 BASE en réponse à ACID . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Choix CAP et PACELC . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4.3 Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . 24

3.4.4 Réplication des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.5 Modèle de consistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.6 Modèle de requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5 Cassandra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2 Le choix CAP et PACELC . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.3 Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . 30
3.5.4 Réplication des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.5 Modèle de consistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.6 Modèle de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.1 The Hadoop Distributed Filesystem . . . . . . . . . . . . . . . . . . . . 33
3.6.2 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.3 Choix CAP et PAELC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.4 Vue d’ensemble de l’architecture . . . . . . . . . . . . . . . . . . . . . . 35
3.6.5 Réplication des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.6 Consistance des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.7 Modèle de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7 Voldemort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Comparaison des différents systèmes . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Bases de données et élasticité 39
4.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Problèmes liés à la mesure de l’élasticité . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Notre solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Scénario de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2 Paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Expériences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1 Considérations complémentaires . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2 Montée à l’échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.3 Descente à l’échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.4 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Les travaux de Thibault Dory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.6 Conclusion - Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6.1 Critiques de l’approche comparative . . . . . . . . . . . . . . . . . . . . 73
4.6.2 Vers une nouvelle approche . . . . . . . . . . . . . . . . . . . . . . . . . 74
5 Influence des choix techniques sur l’élasticité 76
5.1 Modèle de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Modèle de consistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.1 Finalement ou fortement consistant . . . . . . . . . . . . . . . . . . . . 77
5.2.2 Le verrouillage d’entrée et la consistance transactionnelle . . . . . . . . 77
i

5.3 Réplication de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.4 Modèle de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5 Ajout d’instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.7 Tableau récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6 Conclusion 82
Bibliographie 84
A Liste d’accronymes 88
B Rapport de stage 89
B.1 Cadre du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.2 Chronologie du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.3 Bilan du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.4 Autres documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.4.1 Article . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B.4.2 L’entrée dans le blog d’ Euranova . . . . . . . . . . . . . . . . . . . . . . 99
ii

Chapitre 1
Introduction
1.1 Contexte et objectifs du mémoire
“Cloud computing emerges as a new computing paradigm which aims to provide
reliable, customized and Quality of Service guaranteed computing dynamic environments
for end-users” [36]
Le cloud computing (CC, cloud) est un nouveau paradigme émergent très à la mode. Il
s’agit d’un domaine d’étude hautement compétitif et emprunté par de grands acteurs tels
que la Nasa, Amazon, etc. Les solutions sur le marché, déjà très convaincantes, offrent à
leurs utilisateurs des services hautement disponibles, capables de passer à l’échelle et ceci de
manière dynamique. Mais qu’en est-il des bases de données sur cloud ? Peuvent-elles jouir des
fonctionnalités offertes par le cloud ou, au contraire, sont-elles un frein à l’évolution d’une
application sur le cloud ?
Ces dernières années, nous avons apparaître de nouvelles applications sur internet (telles
que Facebook et Twitter) connaissant un succès fou et par conséquent des charges énormes.
Ces systèmes font face, en autre, à deux gros défis ; le premier est le volume de données qu’ils
doivent gérer et le second est la croissance exponentielle de ce volume. Les bases de données de
ces applications doivent donc être capables de gérer un énorme volume de données mais aussi
être capable de passer à l’échelle de manière dynamique, c’est-à-dire sans devoir interrompre
leur service (pour pouvoir gérer l’évolution de ce volume de données).
Dans ce mémoire, nous nous intéresserons à l’élasticité des bases de données sur cloud,
c’est-à-dire la capacité à passer à l’échelle de manière dynamique. Cette propriété est, à
l’heure actuelle, très peu étudiée dans le domaine académique. Il s’agira dès lors de la définir
de manière rigoureuse et de proposer un scénario et des paramètres permettant de l’étudier.
Le domaine du cloud est emprunté par énormément d’acteurs, chacun utilisant ses propres
termes pour des propriétés qui ne sont pas définies rigoureusement dans un langage scientifique.
Le terme cloud peut donc malheureusement se définir tel un terme à la mode, très
aguicheur, ce qui entraîne une incompréhension sur le domaine. Nous devrons donc avant tout
ramener ce paradigme dans le domaine scientifique. Nous le définirons de manière concise ainsi
que les propriétés fondamentales des services qu’il propose.
Ces nouvelles applications n’ont pas trouvé dans les bases de données traditionnelles de
solutions à leur problème de gestion de données et ont dès lors opté pour créer de nouveaux
systèmes de gestion de bases de données (SGBDs). Ceux-ci sont fort différents les uns des
autres. Nous proposerons une étude comparative de différentes bases de données adaptables
1

au cloud (les systèmes NoSQL, SQL-MR, etc.). Nous proposerons des dimensions permettant
des les démarquer et de comprendre quelles directions, choix techniques elles prennent. Cette
étude nous permettra aussi de comprendre les fonctionnement (modèle de réplication, de
distribution des données, etc.) de ces systèmes.
Il n’existe, à l’heure actuelle et à notre connaissance, aucun standard, définition, paramètre
permettant de définir l’élasticité. Dans ce mémoire, nous lui apporterons une définition
et proposerons une étude analytique de l’élasticité d’un SGBD. Nous appliquerons cette étude
à Cassandra que nous ferons monter et descendre à l’échelle de manière dynamique. Nous proposerons
une série de paramètres permettant de décrire intuitivement et de manière complète
ce phénomène. Ces paramètres nous permettront de quantifier l’élasticité d’une transition
d’un système passant de n à m instances.
Etre en mesure de quantifier l’élasticité permettra de comprendre l’influence des paramètres
de configuration d’un système sur son comportement et également de prédire le comportement
du système en cas de modification. L’administrateur d’une base de données pourra,
sur bases des paramètres de cette étude, déterminer s’il est judicieux de modifier son système
ou non.
Enfin sur base des études comparative et analytique, nous dresserons un portrait de la
manière dont les différents choix techniques pris par les bases de données influencent sur leur
élasticité. Ce portrait permettra à l’utilisateur de choisir, en fonction de ses exigences, une
base de données et ses choix techniques en connaissant l’impact qu’ils auront sur l’élasticité
du service.
1.2 Structure du mémoire
Afin de mieux comprendre le contexte de ce mémoire, nous ferons d’abord un détour,
au chapitre 2, par le domaine du cloud computing. Nous examinerons le domaine socioéconomique
dans lequel il se place et expliquerons les évolutions technologiques qui ont mené
à son développement. Nous analyserons aussi la solution la plus connue sur le marché : Amazon
Elastic Compute Cloud. Ceci nous permettra de définir le cloud et les propriétés de ses
services.
Les notions de base revues, nous décortiquerons (au chapitre 3) MongoDB, Cassandra et
Hbase pour mettre en évidence les différentes technologies et techniques qu’ils mettent en
place. Nous proposerons une étude comparative de ces systèmes ainsi que d’autres SGBDs.
Dans le chapitre 4, nous étudierons l’élasticité des bases de données (BDs) et ses caractéristiques.
Nous mettrons en place une méthode analytique d’évaluation de l’élasticité et
soumettrons Cassandra à cette méthode.
Enfin, dans le chapitre 5, nous analyserons les différentes caractéristiques et technologies
de ces nouveaux SGBDs et déterminerons les différents impacts sur l’élasticité des BDs sur
cloud.
1.3 Contributions du mémoire
Les contributions de ce mémoire sont les suivantes :
1. Nous apportons des définitions concises et scientifiques du cloud et des propriétés de ses
services.
2

2. Nous apportons une étude détaillée de trois systèmes NoSQL différents : MongoDB ,
Cassandra et Hbase.
3. Nous proposons une étude comparative de différents SGBDs ainsi que des dimensions
permettant des les distinguer et les comprendre dans leur globalité
4. La contribution principale de ce mémoire est l’étude analytique de l’élasticité d’une
base de données. Nous proposons des scénarios de tests et des paramètres nécessaires et
suffisants pour analyser, décrire et quantifier l’élasticité d’un système en transition.
5. Nous proposons une liste des influences de choix techniques pris par les bases de données
sur leur élasticité.
3

Chapitre 2
Le cloud computing et ses services
Le cloud est très à la mode et utilisé par des nombreux acteurs pour décrire des concepts
qui peuvent être très différents. Il en perd souvent sa pertinence. Dans ce rapport, il est donc
nécessaire de le replacer dans un contexte scientifique.
Dans ce chapitre, nous ferons un rapide tour d’horizon des évolutions qui ont mené au
cloud. Nous proposerons ensuite un tour d’horizon de la solution cloud la plus réputée sur le
marché : Amazon EC2. Ce tour d’horizon nous permettra de mieux comprendre le cloud et
le concepts de service qu’il met en avant.
Dans un contexte scientifique, nous apporterons ensuite une définition du cloud et énoncerons
les propriétés fondamentales des services qu’il propose. Nous décrirons ensuite le théorème
CAP, central à ce mémoire, qui énonce l’impossibilité pour le service base de données
de maintenir simultanément consistance, tolérance à la partition et haute disponibilité.
2.1 Contexte
2.1.1 Origine et modèles
Les 20 années précédentes ont vu la démocratisation de l’informatique, d’internet et des
réseaux de hauts débits. Le cloud suit cette chute des prix et l’émergence de virtualisation des
serveurs d’applications : il consiste en la coopération de ressources informatiques, situées ou
non dans le même parc informatique. Cette coopération sous-entend que ces machines vont
travailler ensemble dans un but commun via des protocoles et des standards de communication
qui sont basés sur ceux d’internet [32].
Le cloud se veut capable de s’auto-gérer, de fournir un certain degré d’automatisme. Tous
ces mécanismes sont transparents pour l’utilisateur final qui pense le cloud tel une série de
services et fait donc totalement abstraction de tout autre composant. L’utilisateur final voit
la solution cloud comme étant dynamique, capable de s’adapter à la charge à laquelle il est
soumis, comme une solution qu’il peut payer à la demande.
“Pour les entreprises utilisatrices (du grand compte multinational à la PME locale),
le Cloud Computing peut se définir comme une approche leur permettant
de disposer d’applications, de puissance de calcul, de moyens de stockage, etc.
comme autant de « services ». Ceux-ci seront mutualisés, dématérialisés (donc
indépendants de toutes contingences matérielles, logicielles et de communication),
4

contractualisés (en termes de performances, niveau de sécurité, coûts. . . ), évolutifs
(en volume, fonction, caractéristiques. . . ) et en libre-service.” [32]
Il existe trois modèles de cloud :
– Le cloud privé : les ressources physiques sont entièrement prises en charge par l’entreprise.
– Le cloud public : il est externe à l’organisation, géré par un prestataire externe et
accessible via internet (telle la solution proposée par Amazon). Les services peuvent
donc être hébergés physiquement sur la même machine qu’un autre service extérieur.
– Le cloud hybride : il s’agit d’un mélange des deux précédents. Typiquement, lorsqu’une
société vient à manquer de ressources physiques, elle peut louer des services à un prestataires
de cloud public. Les deux solutions seront alors amenées à partager applications
et données via des canaux de communication sécurisés.
L’abstraction faite via la virtualisation peut être extrapolée. On voit ainsi naître le paradigme
de service. Traditionnellement, on décrivait le cloud tel une architecture comportant 3
couches de services (figure 2.1) :
– Infrastructure as a Service (IaaS) : dans ce modèle, le client dispose d’une infrastructure
informatique hébergée sur laquelle il a un accès complet (sans restriction).A la différence
des services traditionnels, l’infrastructure mise au service du client n’est plus une
infrastructure physique (un parc de serveur) mais une infrastructure virtualisée.
– Platform as a Service (PaaS) : le fournisseur met à disposition un environnement fonctionnel
et performant. Le client ne doit plus qu’y déployer son application.
– Software as a Service (SaaS) : ce modèle permet de déporter l’application chez un tiers.
Figure 2.1 – Les 3 modèles de cloud[32]
En fait, l’expansion du cloud fait naître le modèle de “XaaS” signifiant “Tout comme un
service” (everything-as-a-service en anglais). On voit par exemple apparaitre la notion de
Human as a Service(HuaaS) [15] qui caractérise une couche supérieure à SaaS correspondant
à une ressource humaine élastique. Cette intelligence “artificiellement artificielle” peut, par
exemple, servir pour des décisions arbitraires comme choisir les vidéos les plus intéressantes à
afficher (pour un système comme Youtube). Le service Amazon Mechanical Turk [2] s’inscrit
5

dans cette couche. Cette classification en couches de services quitte le domaine de ce mémoire
mais reste un domaine d’étude fort intéressant.
2.1.2 Caractéristiques spécifiques et capacités
Outre les caractéristiques techniques (sur lesquelles nous reviendrons plus tard), distinguons,
parmi les différentes caractéristiques essentielles et relevantes, les non-fonctionnelles et
les économiques [37].
Les aspects non-fonctionnels décrivent les propriétés intrinsèques du cloud. Parmi ces
aspects nous listons :
– L’élasticité : il s’agit d’une des caractéristiques les plus essentielles dans notre vision
du cloud. Elle définit la capacité d’une infrastructure donnée à s’adapter de manière
dynamique au changement. L’élasticité fait intervenir la capacité à passer à l’échelle
mais aussi l’agilité.
– La capacité à s’adapter : le cloud doit fournir un ensemble d’automatismes lui permettant
de s’auto-gérer. Son administration devra nécessiter le minimum possible d’interventions
humaines.
– La qualité de service : est un autre aspect essentiel du cloud ; à l’aide de métriques telles
que le temps de réponse, le nombre d’opérations à la seconde, le service fournit des
garanties à ses utilisateurs. Il n’appartient plus à l’utilisateur de devoir décider quelles
ressources déployer mais plutôt de définir des bornes que le service doit satisfaire. Le
cloud s’adaptera de manière à assurer ses bornes.
– La haute disponibilité : en jouant sur des données répliquées dans des centres de données
différents, le cloud doit fournir un service fiable, non sensible à la défaillance d’une
instance voire d’un centre de données.
Les aspects économiques du cloud séduisent de plus en plus les sociétés. Parmi ces aspects,
nous listons :
– la réduction des coûts : son modèle de paiement à l’utilisation (Pay Per Use en anglais)
signifie que l’utilisateur paie uniquement le service en fonction de son taux d’utilisation
(alors qu’il payait par forfait auparavant).
– Un retour sur l’investissement : Le paiement à l’utilisation est particulièrement intéressant
pour les entreprises de petite taille qui peuvent à présent profiter des avantages
d’un service fonctionnel dès le départ. L’idée sous-jacente est donc la suivante : le service
deviendra coûteux pour une société dans la mesure où il est fort utilisé, c’est-à-dire à la
condition qu’il lui rapporte de l’argent. On passe dès lors de dépenses d’investissement
en capital (l’achat de serveurs d’application) aux dépenses d’exploitation (l’achat de
ressources consommables).
– Une démarche écologique : l’allocation de ressources à la stricte nécessité permet de
réduire la consommation énergique des parcs informatiques. Outre l’aspect économique,
ces réductions énergétiques permettent de diminuer l’empreinte écologique de la société.
2.1.3 Amazon
Après avoir introduit le cloud, son contexte et ses caractéristiques, faisons un rapide détour
par la description d’une solution cloud reconnue pour sa stabilité et le nombre considérable
d’applications qu’elle héberge : Amazon. Disposant d’une architecture cloud très aboutie,
Amazon fournit à ses clients une liste de services ; le plus basique, l’elastic compute cloud,
6

peut être vu de manière abstraite comme une instance dont les ressources pourraient être
ajustées à la demande.
Ce n’est qu’en combinant ce service basique à d’autres services (tels que le CloudWatch, l’
Auto Scaling) que le client commencera à disposer d’une architecture qu’il exploitera tel son
propre cloud. Afin de mieux comprendre le concept de services et l’interaction existant entre
eux, reprenons ci-dessous quelques services proposé par Amazon. Ces services sont de type
SaaS ; le client a accès à un service dont l’infrastructure sous-jacente lui est abstraite.
“Amazon Elastic Compute Cloud (Amazon EC2) is a web service that provides
resizable compute capacity in the cloud. It is designed to make web-scale computing
easier for developers.” [1]
Amazon Elastic Compute Cloud propose un service dont la capacité de calcul est redimensionnable.
Le terme “service” met en évidence la volonté de faire abstraction des composants
physiques tandis que “redimensionnable” fait référence à la possibilité d’adapter la capacité
de calcul de cette instance virtuelle à la demande du client. L’utilisateur du service profitera
dès lors pleinement des avantages cloud sans avoir même à considérer l’environnement cloud.
CloudWatch est un service qui fournit une surveillance pour les autres services Amazon.
Il fournit une visibilité des ressources (usage CPU, mémoire) utilisées et des performances de
ces services. Cette visibilité permettra (lorsqu’on couple CloudWatch à un autre service) de
déclencher certains triggers forts utiles.
Auto Scaling, couplé au service EC2 et CloudWatch, est un service qui permet d’ajuster
la capacité de EC2 en fonction de la demande. Ce service définit des conditions et des actions
à effectuer lorsqu’elles sont atteintes ; par exemple, on peut décider d’ajouter 3 nouvelles
instances EC2 au parc lorsque l’utilisation moyenne de l’unité centrale atteint 70 %. Auto
Scaling permet aussi de s’assurer d’avoir un parc d’instances saines de taille fixe en décidant
donc de remplacer toute instance défaillante par une nouvelle saine.
Elastic Load Balancing (traduit par Equilibreur de charge élastique) distribue automatiquement
le trafic entrant à travers de multiples instances EC2 appartenant, ou non, à la
même zone de disponibilité. Elastic Load Balancing détecte aussi les défaillances d’instances
(appartenant à son domaine) et redirige le trafic qui leur était destiné (vers d’autres instances
saines) jusqu’à ce que les instances défaillantes soient assainies. On peut dès lors créer une
tolérance à la défaillance 1 : en plaçant des instances EC2 dans différentes zones de disponibilité,
le service Elastic Load Balancing peut automatiquement gérer le trafic (le diriger vers
des instances saines). Couplé à Auto Scaling, on peut s’assurer que le nombre d’instances sous
Elastic Load Balancing ne soit jamais inférieur à un nombre voulu ou bien s’assurer que le
temps de latence d’une application n’excède jamais un seuil fixé par l’administrateur.
Simple Queue Service (SQS) est une file d’attente fiable et capable de monter à l’échelle.
Utilisée pour transmettre des messages entre différents services, elle facilite la création d’un
flux de travail automatisé.
2.2 Définition du cloud
Dans cette section, nous tenterons une approche plus théorique des concepts énoncés
précédemment.
1. Nous définirons le terme de tolérance à la défaillance dans la section 2.2.
7

Le cloud dans la littérature
“A cloud (...) is an “elastic execution environment of resources involving multiple
stakeholders and providing a metered service at multiple granularities for a specified
level of quality (of service)”
EU Expert Group [37]
“Cloud computing is a model for enabling convenient, on-demand network access
to a shared pool of configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with
minimal management effort or service provider interaction.”
National Institute of Standards and Technology [29]
Ces deux définitions ont retenu notre attention. Chacune propose des paradigmes fort
intéressants même si réellement différents. Essayons de les souligner :
Les experts de l’Union Européenne mettent en avant la notion d’élasticité inhérente à
notre mémoire. Ils soulignent aussi la nature hétérogène de ses acteurs (fournisseurs et clients)
et enfin la notion de qualité des services fournis. Soulignons que cette notion de qualité de
services est un modèle essentiel du cloud qui, malheureusement, quitte le cadre de ce mémoire.
L’institut national des standards et de la technologie met en avant les caractéristiques
d’adaptabilité et, sans la nommer comme telle, l’élasticité du cloud qu’il définit comme la
capacité de passer rapidement à l’échelle en nécessitant un minimum d’effort humain.
On remarque que les deux définitions proposent une certaine abstraction en parlant de
ressources informatiques (définissant un large panel de composants). Un second point commun
entre ces deux définitions, leur haut degré d’abstraction, nous pousse à proposer notre propre
définition du cloud (dans la suite de cette section) que nous voudrons plus précise.
Cluster et cloud
Définition 1.
Un cluster d’ordinateur est un parc d’ordinateurs interconnectés (on parle souvent
de grappe) afin de partager leurs ressources dans un but commun.
Définition 2.
Un cloud est un modèle d’architecture qui fournit un parc d’instances virtuelles
capable de s’auto-gérer et d’adapter ses capacités (modulo son support physique) de
manière dynamique et automatique à la charge à laquelle il est soumis.
8

Le cluster est donc de manière assez basique l’architecture matérielle nécessaire au déploiement
d’une solution cloud. La définition du cloud nécessite quant à elle quelques éclaircissements
:
– Les ressources que propose le cloud sont virtuelles. On parle donc de ressources logiques
(par opposition aux ressources physiques).
– L’architecture est capable de s’auto-gérer. Est comprise dans l’architecture toute la
couche de gestion des instances, des défaillances, etc.
– Le cloud est capable de s’adapter à la charge en changeant le nombre de ses instances,
ou en modifiant leurs caractéristiques.
– Il est capable de s’adapter de manière dynamique et automatique ; le cloud est capable
de détecter lui-même ses propres défaillances et de ré-instancier les modules nécessaires
à son bon fonctionnement.
– Il est aussi capable de relever les métriques relevantes, de déterminer s’il procure un
service satisfaisant et, s’il ne le fait pas, d’augmenter ses capacités (de s’adapter à la
charge).
Il existe naturellement une limite à sa capacité de s’adapter à la charge ; le cloud reposant
sur un cluster, il ne pourra excéder les ressources dont il dispose. Remarquons néanmoins qu’un
modèle public ou hybride semble dès lors assumer des variations de charge plus importantes.
Mais cette capacité est toujours limitée par les ressources physiques.
Cloud et grille de calcul
La définition précédente peut provoquer une confusion entre le cloud et la grille de calcul
(grid en anglais). Effectivement, leurs architectures sont assez similaires mais ils sont destinés
à des fonctions bien différentes. Le cloud, comme nous l’avons vu, est destiné à être capable
de monter en charge c’est-à-dire traiter un nombre important de requêtes concurrentes.
La grille de calcul est plutôt destinée à traiter un nombre plus réduit de requêtes. Ces
requêtes sont, en règle générale, bien plus complexes et peuvent facilement être divisées en
sous-requêtes qui seront adressées à d’autres nœuds. La figure 2.2 nous donne un aperçu visuel
de cette différence.
nombre de tâches
Cloud
Grille de calcul
complexité de la tâche
Figure 2.2 – Cloud Vs Grille de calcul
9

Cette différence de vocation fait que le cloud et la grille de calcul se pensent différemment.
Néanmoins, on constate que certaines approches pensées pour l’un peuvent se décliner pour
l’autre. Récemment, le concept de distribution-réduction (Map-Reduce en anglais), pensé
à l’origine pour la grille de calcul, semble particulièrement bien s’adapter au cloud.
2.3 Propriétés fondamentales des services
Après ce tour d’horizon du cloud, décrivons à présent les propriétés fondamentales des
services sur cloud. Notons que le SGBD est un service du cloud. A ce titre, toutes les définitions
suivantes sont immédiatement applicables aux bases de données. Nous conseillons donc au
lecteur de les lire en pensant au service de base de données.
2.3.1 La haute disponibilité
Définition 3.
Un service est dit hautement disponible (High available en anglais) si toute requête
reçu par un nœud n’étant victime d’aucune défaillance retourne un résultat.
traduit de [26]
La haute disponibilité d’un service caractérise sa capacité à assurer son effective accessibilité
durant une période donnée. Le service devra donc pouvoir détecter les points de
défaillances et réduire l’impact de leur potentielle défaillance grâce à la mise en place de
techniques de redondance et/ou réplication.
2.3.2 Passer à l’échelle
Un des principaux atouts d’une solution cloud est sa capacité à passer à l’échelle que
nous décrirons plus loin. Définissons d’abord sa capacité à monter à l’échelle :
Définition 4.
La capacité à monter à l’échelle d’un service est sa capacité à pouvoir assumer
une production constante lorsque le nombre de requêtes augmente.
Cette définition ne fait intervenir aucune notion de dynamisme ; quel que soit le moyen
d’étendre ses capacités, un cloud est capable de monter à l’échelle s’il peut monter en charge
jusqu’à sa limite (celle de ses composants physiques). Plus précisément, on distingue deux
types de montée à l’échelle : verticale et horizontale.
10

Définition 5.
Considérant un service, sa capacité à monter à l’échelle verticalement est
la propriété qui décrit l’évolution apportée à sa capacité de traitement lorsqu’on
augmente ses ressources (CPU, mémoire, etc.).
On dira donc, par exemple, qu’un service est capable de monter à l’échelle de manière
verticale en terme d’usage de mémoire RAM s’il est capable d’augmenter ses performances
lorsqu’on augmente sa mémoire RAM.
Définition 6.
Considérant un service, sa capacité à monter en charge horizontalement est
la propriété qui décrit l’évolution apportée à sa capacité de traitement lorsqu’on
augmente le nombre d’instances.
On dira donc qu’un service est capable de monter en charge (horizontalement) de manière
linéaire 2 si une augmentation de X% de ses ressources augmente ses performances de X%.
On remarque dès à présent que décrire l’augmentation du nombre d’instances en terme de
pourcentage est sujet à discussion, nous le discutons à la section 4.2. Supposons, à ce stade,
que chaque instance est identique et que le pourcentage se résume donc au rapport du nombre
d’instances futur sur le précédent.
La plupart des solutions cloud mettent en avant leurs capacités à monter à l’échelle pour
des raisons commerciales. La capacité à descendre à l’échelle est souvent négligée mais n’en
est pas moins intéressante : pour des enjeux économiques et écologiques, il est très intéressant
de pouvoir diminuer ses ressources lorsqu’elles sont sous-exploitées.
Le cloud doit être capable de s’adapter et ceci ne peut se résumer à la capacité à monter
à l’échelle. Il faut aussi considérer sa capacité à descendre à l’échelle. L’union de ses deux
propriétés est sa capacité à passer à l’échelle que nous définissons comme suit :
Définition 7.
La capacité à passer à l’échelle d’un service (( Scalability en anglais), est sa
capacité à pouvoir assumer la variation (descente ou montée) de la charge à laquelle
il est soumis.
2. Dans la suite de ce mémoire, nous nous intéressons particulièrement aux adaptations horizontales, qui
sont particulières au cloud. Nous omettrons le terme horizontal et ne préciserons que lorsqu’il s’agira des
propriétés verticales.
11

Par “assumer”, on entend fournir des performances constantes. De manière assez intuitive,
on peut comprendre qu’un facteur pouvant caractériser cette capacité à passer à l’échelle
pourrait être le rapport entre le gain en performance et l’augmentation des ressources du
service nécessaire à ce gain de performance.
L’élasticité
Dans cette section, nous proposerons notre définition de l’élasticité du cloud à titre d’introduction.
Le chapitre 4 étudie de façon plus poussée l’élasticité.
Définition 8.
L’élasticité d’un service est sa capacité à passer à l’échelle de manière dynamique
(c’est-à-dire sans nécessiter sa réinitialisation et sans entraîner des effets collatéraux
trop importants).
Par “collatéraux”, on entent des pertes en performance inacceptables. L’élasticité d’un
service est une caractérisation de sa capacité à passer à l’échelle ; elle requiert son dynamisme.
Le terme “dynamisme” signifie que le système sous-jacent au service doit être assez agile
que pour garantir la continuité et la stabilité de ce dernier. Listons les conséquence de ces
exigences :
– Le service doit être continu ; son passage à l’échelle ne doit pas nécessiter sa réinitialisation.
– Le service doit être continu et stable ; les modifications internes nécessaires à son passage
à l’échelle ne doivent pas entrainer son inaccessibilité (ou des temps de réaction trop
lents).
Les paramètres nécessaires à caractériser tout passage à l’échelle ne suffisent plus. Il s’agit
aussi de pouvoir caractériser ses “effets collatéraux” ainsi que leurs impacts. Nous discutons de
ce sujet en section 4.3. Un service ne peut entrer dans le mouvement cloud qu’à la condition
qu’il soit élastique : si son passage à l’échelle n’est pas dynamique, ce dernier ne pourra pas
être hautement disponible.
2.4 Le théorème CAP
La spécificité du service base de données est qu’il stocke des données dont on doit pouvoir
garantir une certaine intégrité. Cette contrainte est assez bloquante lorsqu’on pense les bases
de données comme un service cloud c’est-à-dire capable de monter à l’échelle. Ce problème
peut être résumé par une conjecture connue sous le nom de théorème CAP 3 ou sous le nom
de théorème de Brewer 4 .
Cette conjecture est énoncée comme suit :
3. Dans la suite de ce mémoire, nous parlerons de “CAP” pour signifier “le théorème CAP”.
4. E. Brewer énonce cette conjecture en 2009. Remarquons que S. Gilbert et N. Lynch démontrent en 2002
cette conjecture pour un modèle asynchrone de systèmes distribués [26].
12

Conjecture 1.
Parmi les trois propriétés suivantes : consistance, haute disponibilité et tolérance à
la partition, tout système de données distribué ne peut respecter, au plus, que deux
d’entre elles.
Consistency Availability
Tolerance to network
Partitions
You can have at most two
of these properties for any
shared-data system
Figure 2.3 – CAP (reproduction de [18])
CAP (représenté par la figure 2.3) introduit deux propriétés relatives aux systèmes distribués
qui nous sont inconnues. Nous allons maintenant les décrire.
La consistance des données 5 est un concept qui décrit les modes d’accès aux données,
leur intégrité et validée. Nous le verrons à la section 3.1.4, il existe plusieurs modèles de
consistance des données. La consistance des données, telle que CAP l’entend, décrit le fait
que les données auxquelles on accèdera seront toujours à jour.
Pour des raisons de performance (passage à l’échelle) et de sécurité (réplication des données),
les systèmes distribués tirent profit du fait de pouvoir s’étirer sur plusieurs instances.
Répartir un service sur de nombreuses instances augmente le risque de défaillance d’une partie
du service et causer ainsi une partition du service en plusieurs sous-ensembles. Pour expliquer
le phénomène de partition, imaginons notre service distribué sur deux boites noires ; un phénomène
de partition arrive lorsque le câble reliant ces deux boites noires est débranché ; les deux
sous-systèmes ne sont plus capables de communiquer. Un service distribué tolérant à la partition
est un système tel qu’un phénomène de partition n’altère pas son bon fonctionnement.
Ou de manière plus pragmatique :
5. Il faudrait parler de la cohérence des données (data consistency en anglais) mais par abus de langage,
nous parlons de la consistance des données
13

Définition 9.
Dans un service tolérant à la partition, aucun ensemble de défaillance autre que la
défaillance de la totalité du réseau ne peut causer des réponses incorrectes du service.
Discussion
traduit de [26]
CAP est un problème inhérent au cloud puisqu’on veut un service base de données hautement
disponible (en passant notamment par la bonne gestion du phénomène de partition)
capable de stocker de manière cohérente nos données. CAP retient dès lors l’attention d’un
bon nombre d’acteurs. A titre d’exemple, citons [42] et [19] qui l’illustrent par des exemples
et discutent les défis et enjeux de cette conjecture. Afin de mieux appréhender le phénomène
introduit par CAP, nous tenons à résumer l’approche de D. Abadi [16] qui tend à critiquer
CAP et en donner une approche plus pragmatique et une compréhension, à nos yeux, plus
pertinente.
Soulignons deux problèmes à CAP vus par Abadi [16] :
– Suivant CAP, nous aurons soit des systèmes dits CA (consistants et hautement disponibles),
CP (consistants et tolérants à la partition) ou AP (hautement disponibles et
tolérants à la partition). Il existe une asymétrie entre la valeur de la disponibilité et de
la consistance : un système CP acceptera de sacrifier sa disponibilité mais seulement en
cas de partition, tandis qu’un système AP décidera de sacrifier sa consistance tout le
temps.
– Le second problème souligné est que, en pratique, la différence entre les systèmes CA et
CP est difficile à discerner. En effet, que veut dire “non tolérant à la partition”? Dans la
pratique, toujours selon Adabi, cela signifie que, en cas de partition, le système perdra
en disponibilité. Il n’existe donc en pratique que deux types de systèmes : CP/CA et
AP.
Il s’agit donc de remplacer CAP par PACELC :
“if there is a partition (P) how does the system tradeoff between availability and
consistency (A and C) ; else (E) when the system is running as normal in the
absence of partitions, how does the system tradeoff between latency (L) and consistency
(C) ?”
Dans la pratique, les systèmes AP – qui ont tendance à relâcher la consistance en cas
de partition – tireront aussi profit de ce relâchement pour une améliorer leurs performances
lorsqu’il n’y a pas de partition du système. Ces systèmes sont donc, dans la théorie d’Abadi
des systèmes PA/EL.
Nous tenterons dans la suite de ce mémoire, de classifier les différents SGBDs non seulement
en fonction de CAP mais aussi en fonction de PACELC.
[16]
14

Chapitre 3
Etude comparative de différents
systèmes de gestion des bases de
données
Dans ce chapitre, nous proposerons une analyse des différentes dimensions caractérisant un
SGBD sur cloud. Nous ferons un tour d’horizon du courant SQL et de ses systèmes distribués
(section 3.2). Nous introduirons également le nouveau courant dit NoSQL et ses concepts
(section 3.3).
Nous analyserons ensuite, de manière plus approfondie, trois différentes solutions NoSQL :
MongoDB [10], Cassandra [5] et Hbase [6] et étudierons de manière plus abstraite Voldemort
[12].
Nous résumerons finalement ces analyses et comparerons ces différents systèmes grâce aux
dimensions préalablement établies.
3.1 Classification des systèmes
Examinons tout d’abord les différentes décisions architecturales caractérisant un SGBD,
à savoir :
– Le modèle de données
– Le choix CAP
– Le choix PACELC
– La réplication synchrone ou asynchrone
– Le modèle de consistance
– Le modèle de requêtes
Remarquons que les quelques autres études comparatives de SGDBs ([20], [17], [40]) nous
servant de référence, s’attardent sur leurs licences, leur langages de programmations, etc. Dans
le cadre de notre analyse, nous ne pensons pas que ces dimensions apporteraient une valeur
ajoutée.
3.1.1 Le modèle de données
Le modèle de données caractérise l’architecture, le schéma logique respecté pour décrire
les données stockées ; allant d’un modèle simpliste clé-valeur jusqu’au modèle complexe re-
15

on-OLTP applications that
ured and unstructured data
ciency than RDBMs and
stem
ncing, garbage collection
ypertable)
ystem
Node Node
Topology
Tablet
Server n
FS n
(a commit doesn’t occur
n to at least two separate
s are optimized for writes
are formatted to handle
The NoSQL database
rocessing (mapReduce,
nterpart to the data grid
feeds the computational
he NoSQL database.
continuing to operate)
failures cause the system to fail)
Since only two of these characteristics are guaranteed for any
given scalable system, use your functional specification and
16
business SLA (service level agreement) to determine what your
lationnel. Cette dimension aura des répercussions sur les performances et la réputation des
your requirements, and proceed to implement the appropriate
SGBDs.
technology.
De manière intuitive, on peut comprendre que le modèle le plus basique atteindra de
meilleures performances vu qu’il est plus proche des mécanismes de la machine physique.
Tandis, qu’un modèle de plus Rule haut of Thumb: niveau, NoSQL’s permettant primary une goal modélisation is to achieve plus abstraite, éloi-
Hot
gnée des composants physiques horizontal et plus scalability. procheIt Tip
de attains l’application this by reducing en verra ses performances
réduites mais une utilisationtransactional bien plus aisée. semantics and referential integrity.
3.1.2 Les choix CAP et PACELC
Comme décrit en section 2.4, chaque système s’inscrit parmi les trois systèmes CA, CP et
NoSQL systems listed.
AP décrit par CAP ou peut se catégoriser via la proposition PACELC d’Abadi.
Consistency Availability
RDBMs (Oracle, MySQL), Aster Data, Green Plum, Vertica
C A
mongoDB, Terrastore, Datastore, Hypertable, Hbase,
Redis, Berkeley DB, MemcacheDB, Scalaris
Relational
Key-Value
Column-Oriented
Document-Oriented
Pick Any Two
P
Partition tolerance
Dynamo, Voldemort, Tokyo Cabinet, KAI, Cassandra,
SimpleDB, CouchDB, Riak
Figure 3 - CAP Selection Chart
(source: Nathan Hurst's Blog)
Figure 3.1 – Classification des systèmes grâce à CAP [22]
DZone, La catégorisation Inc. | www.dzone.com via CAP est fort utile ; elle permet en seulement deux lettres de comprendre
la politique voulue par un système (voir figure 3.1). Toutefois, nous estimons que
PACELC semble bien plus descriptif et dès lors mérite d’être repris lors de notre analyse
comparative. Remarquons que la classification des systèmes via PACELC ne va pas du tout
à l’encontre de CAP mais permet une meilleure compréhension.
3.1.3 La réplication synchrone ou asynchrone
La réplication de données est le processus consistant à maintenir R copies d’un ensemble
de données sur d’autres instances de stockage. Ce nombre de copies (R) est appelé facteur de
réplication. La réplication peut servir à rendre le système plus disponible (en redirigeant le
trafic d’une instance défaillante vers sa réplique), à éviter la perte de données et à améliorer
les performances (en divisant et redirigeant la charge d’une instance vers ses répliques).

Plusieurs approches sont possibles pour la réplication : la réplication synchrone et la
réplication asynchrone.
– La réplication synchrone s’assure que toutes les copies soient à jour, ce qui peut potentiellement
entrainer des temps de réponses plus lents lors des mises-à-jour. Remarquons
que le mode de réplication synchrone peut être bloquant pour la disponibilité : si une
réplique connaît une défaillance, le système pourrait rester bloqué.
– Dans une réplication asynchrone, une instance mère stocke les données actualisées et
transmet les données modifiées aux répliques de manière différée. Il existe donc très
certainement un gain à l’écriture des données (on doit s’assurer que la modification n’ait
eu lieu que sur une seule copie) mais celui-ci implique le risque de perdre des données
si l’instance mère connait une défaillance avant d’avoir pu transmettre l’information
aux répliques. Ce mode de réplication peut aussi impliquer la nécessité de mécanismes
d’assemblage de versions pour assembler différentes versions d’une donnée en une seule
valeur mise-à-jour.
Comme nous l’avons déjà mentionné, le mode de réplication a une forte influence sur le
comportement du système. Il est donc nécessaire d’entendre le mode de réplication comme
une dimension de notre étude comparative.
3.1.4 Le modèle de consistance
En réponse à la montée en charge exceptionnelle à laquelle de nombreux acteurs ont dû
faire face, ceux-ci ont créé des systèmes relâchant la consistance transactionnelle pour passer
à un autre modèle de consistance. Ces nouveaux modèles ont une influence théorique très
importante sur les performances, la disponibilité et la tolérance à la partition (cf. CAP). Mais
ce niveau de relâchement ne peut être accepté par toute application (on imagine mal une
application bancaire accepter de perdre des transactions faites par ses clients).
Les modèles de consistance proposés par les SGBDs sont donc une caractéristique très
significative et importante. Nous pouvons distinguer, en fonction de leur degré de consistance,
quatre sous-ensembles de modèles (du plus faible au plus fort) :
– Finalement consistant : garantit que si aucune modification n’est faite sur la donnée,
les accès en lecture sur la donnée retournent finalement sa valeur actualisée [42]. Ceci
peut notamment se faire par des systèmes de réparation à la lecture (nous verrons dans
ce chapitre les techniques mises en place par les différentes SGBDs).
– Consistance forte : s’assure que chaque lecture d’une valeur retourne la valeur actuelle
de la valeur (c’est-à-dire la valeur de la dernière écriture réussie et finie).
– Le verrouillage d’entrée signifie que l’on va pouvoir verrouiller une entrée et donc garantir
son intégrité.
– Transactionnel : S’assure qu’une transaction respecte les propriétés ACID (voir section
3.2.2)
3.1.5 Le modèle de requêtes
Le modèle de requêtes comprend le langage de communication et les requêtes qu’il est
possible de faire sur la BD. Celui des SGBDs relationnels (SGBDRs) traditionnels était riche
et plus ou moins similaire pour chaque système. Ceux des nouveaux systèmes sont, en règle
générale, bien plus pauvres et diffèrent fortement d’un système à l’autre.
17

Or la richesse du modèle de requêtes sera un argument prépondérant lors du choix du
SGBD. De plus, elle peut aussi avoir son impact sur les performances de celui-ci. Par exemple,
un modèle permettant l’utilisation de fonctions Map-Reduce (MR) permettra, en répartissant
une charge en sous-charges, de traiter plus aisément des requêtes complexes.
3.2 Les bases de données relationnelles distribuées
Des “bases de données relationnelles extensibles” tel est le terme utilisé par Catell pour
décrire les SGBDRs adaptés aux clusters. Les SGBDRs traditionnels ont été développés durant
les dernières décennies et sont généralement la meilleure solution sur le marché pour les
services ne devant pas passer à l’échelle : ils sont pensés pour tenir sur une seule instance.
Dans cette section, nous décrirons leurs adaptations au cluster ainsi que les mécanismes mis
en place pour permettre de les distribuer sur plusieurs instances.
3.2.1 Le modèle de données relationnel
Un schéma relationnel est essentiellement un groupe de tables représentant des objets et
des relations entre ceux-ci. Ces tables, faites de lignes et colonnes, peuvent être interrogées à
l’aide d’un langage d’interrogation structuré (SQL).
Dans un schéma relationnel, les tables sont normalisées dans le but d’éviter les doublons et
de consolider les données. Chaque entité ou relation possède une représentation minimaliste
qui peut s’étendre grâce à des jointures des tables.
3.2.2 Les propriétés ACID
Les SGBDRs traditionnels reposent sur la notion de transaction et la propriété ACID. La
notion de transaction dans les BD décrit une interaction qui fait passer une BD d’un état A
à un état B tout en satisfaisant les propriétés d’atomicité, de consistance, d’isolation et de
durabilité (ACID) :
– Atomicité : l’ensemble des opérations est une suite indissociable c’est-à-dire qu’en cas
d’échec d’une opération, tout l’ensemble sera annulé (y compris les opérations précédentes).
– Consistance : le résultat de l’ensemble des opérations doit être cohérent. Les règles de
cohérence varient en fonction de la sémantique des données.
– Isolation : lorsque deux transactions ont lieu en même temps, les modifications effectuées
par la première ne sont visibles par la seconde que lorsque la première est terminée et
validée.
– Durabilité : une transaction terminée ne peut être annulée ou recouverte.
3.2.3 MySQL Cluster
Comme premier élément de tour d’horizon, nous nous attardons sur MySQL Cluster [8]
car c’est la solution SQL la plus mature. Il s’agit une version de MySQL sortie en 2004 qui
remplace le moteur InnoDB par une nouvelle couche distribuée NDB [20]. MySQL Cluster
respecte le modèle “ne partageant rien” (shared nothing en anglais) et distribue les données
sur des nœuds multiples.
18

Choix CAP et PACELC Les systèmes respectant la propriété ACID sont des systèmes CA
(point de vue CAP), c’est-à-dire que pour préserver l’intégrité de leurs données, ils sont prêts
à sacrifier la tolérance à la partition. MySQL Cluster a choisi de préserver la consistance au
détriment des performances et de la tolérance à la partition. Ces systèmes sont donc PC/LC.
En cas de partition, vu son modèle de réplication synchrone, MySQL cluster empêchera les
opérations de mises-à-jour.
Réplication Pour éviter de propager la faille d’une instance, les données sont répliquées de
façon synchrone[8] c’est-à-dire que lors de l’écriture (insertion ou mise-à-jour) d’une entrée,
l’information est propagée sur toutes les répliques et l’opération n’est validée que lorsque
toutes les répliques l’ont validée.
Dans le cas où toutes les répliques d’une donnée sont à jour, si une instance subit une défaillance,
on peut alors rediriger son trafic sur une réplique et éviter ainsi que cette défaillance
soit fatale pour tout le système.
Modèle de consistance MySQL Cluster, vu son respect des propriétés ACID, opte pour
une consistance transactionnelle. En pratique, MySQL Cluster ne propose pas de consistance
transactionnelle complète mais une consistance transactionnelle Read Committed [8]. Lors
d’une lecture, la requête voit les données telles qu’elles sont avant que la requêtes ait été
effectuée : les modifications validées par les transactions concurrentes sont retournées par la
lecture.
Le modèle de requêtes MySQL Cluster garde toute la richesse des versions non distribuées
de MySQL. On peut effectuer toutes les requêtes SQL comme si la BD n’était pas distribuée
et tous les mécanismes internes sont transparents pour l’utilisateur.
3.2.4 Autres solutions SQL
Dans cette section, nous passerons en revue quelques initiatives SQL entreprises. Nous
ne nous attarderons pas sur celles-ci car, même si leurs concepts sont très intéressants, ces
solutions ne sont pas encore matures. Il est donc fort difficile de juger de leur efficacité.
De manière théorique, nous suivons l’avis de Catell pour dire que les SGBDRs devraient
être capables de passer à l’échelle tant que les applications évitent les opérations traversant
plusieurs nœuds et des transactions de grande ampleur [20]. On remarque que cette concession
n’affecte pas leur capacité à concurrencer les solutions NoSQL (étudiées en section 3.3) qui
traitent aussi difficilement (voire ne sont pas du tout capables de traiter) de telles opérations.
ScaleDB [11] se veut la version MySQL de Oracle RAC. Tout comme MySQL Cluster, il
se place sur une version de MySQL en remplaçant InnoDB. Son principe est de se reposer sur
une architecture à mémoire partagée (shared memory en anglais) : tout nœud a accès à tout
disque. La distribution des données est automatique au travers des serveurs. ScaleDB n’utilise
pas de réplication mais des sauvegardes sont faites sur disque (pour récupérer les données en
cas de défaillances).
19

3.2.5 Les solutions SQL-MR
Map-Reduce
MapReduce est un modèle de programmation (initié par Google) pour manipuler et gérer
un large ensemble de données. Le principe est relativement simple ; l’utilisateur définit un
schéma de redirection et une fonction de réduction [28]. Un nœud peut alors, en suivant le
schéma de redirection (Map), diviser une charge en plusieurs sous-charges qu’il soumettra
à ses nœuds fils (l’opération peut être récursive). Les nœuds sous-traitants remontent leurs
résultats au nœud parent qui combine ces résultats via la fonction de réduction.
SQL-MR
SQL-MR unit un système SQL épuré au concept de MapReduce. Les fonctions de réduction
se chargent de toutes les tâches non relationnelles et optimisations liées au domaine [24].
Ces fonctions (qui peuvent être écrites dans de nombreux langages de programmation)
sont, par défaut, parallèles. Les requêtes sont donc prises en charge par ces fonctions et
distribuées en parallèle sur les nœuds du cluster, ce qui assure au système de supporter la
montée en charge. Les fonctions reçoivent des relations (tables) en entrée et retournent des
relations. Elles sont adaptatives c’est-à-dire qu’en fonction du contexte, elles déterminent
quelles relations retourner.
Les systèmes SQL-MR
Les systèmes SQL-MR les plus reconnus sont AsterData, VoltDB et Greenplum.
VoltDB [13] est une nouvelle solution open-source qui est pensée pour être performante
sur chaque nœud et capable de passer à l’échelle (notamment grâce au fait qu’il est orienté
colonnes). Les tables sont partitionnées et distribuées sur les différents nœuds de manière
automatique (mais l’utilisateur peut en définir les paramètres). Les données peuvent être
répliquées (réplication synchrone) et l’application peut distribuer ses requêtes de lecture sur
les répliques pour améliorer ses performances.
VoltDB propose des solutions intéressantes (même si elles ne sont pas encore mises en
place) : les indexes et la structure des données sont pensées pour s’adapter à une BD qui
tiendrait entièrement en mémoire. Cette solution optimise nettement les écritures. VoltDB
serait 100 fois plus rapide que MySQL et 13 fois plus rapide que Cassandra [34].
3.3 Le mouvement NoSQL
Les systèmes NoSQL (Not Only SQL) proposent de surprenantes architectures quittant
le chemin relationnel. Le message transmis est que, si on veut une BD capable de passer à
l’échelle, on ne peut plus utiliser un SGBDR. Nous examinons dans cette partie les concepts
variés qu’ils mettent en place.
Dans cette section, nous donnerons un aperçu des différents modèles de données du mouvement
NoSQL (section 3.3.1) et du paradigme BASE (section 3.3.2) qu’il propose en réponse
aux propriétés ACID des solutions SQL.
Les sections 3.4, 3.5 et 3.6 décrivent de manière approfondie les moyens mis en place par
MongoDB, Cassandra et HBase. La section 3.7 donne un aperçu de Voldemort.
20

3.3.1 Les modèles de données
Les différents systèmes NoSQL utilisent des terminologies fort différentes. Cattell [20]
différencie comme suit les modèles de structure qu’ils adoptent :
– Un n-uplet est un ensemble de paires clé-valeur telles que les noms d’attributs sont
définis dans le schéma et les valeurs sont basiques. On parle souvent de modèle clévaleur
– un document est un ensemble de paires clé-valeur telles que les valeurs peuvent être
composées (d’autres paires clé-valeur) et que les noms d’attributs sont définis dynamiquement
pour chaque document.
– Une entrée extensible est un hybride entre un n-uplet et un document où des familles
d’attributs sont définies dans le schéma tout en permettant de définir de nouveaux
attributs à la volée. On parle souvent de modèles orientés colonnes voire orientés familles
de colonnes.
– Un graphe qui représente l’information sous forme de graphe. Selon la mise en oeuvre,
le graphe peut représenter le schéma et l’architecture de la BD ou peut servir à encoder
toute la DB.
Le modèle clé-valeur
Le modèle clé-valeur (figure 3.2) est d’une grande simplicité : il peut être vu comme une
large table de hachage persistante. Il est, par conséquent, adapté aux caches et offre, dès lors,
de hautes performances en terme d’accès aux informations.
Figure 3.2 – BD clé-valeur [30]
Cette modélisation la plus simpliste est justifiée par le constat qu’un bon nombre d’accès
aux bases de données se résume à de simples lectures ou écritures à partir d’un index.
Le modèle orienté document
La représentation orientée documents est une extension du modèle clé-valeur.A l’instar de
celui-ci, elle associe à chaque clé un document qui contient des données organisées de manière
hiérarchique à l’image d’un document XML (figure 3.3).
Le modèle d’entrées extensibles
Aussi connu sur le nom de représentation orientée colonnes (figure 3.4), ce modèle est une
deuxième évolution, multidimensionnelle, du stockage clé-valeur. Les données y sont représentées
comme des groupes de colonnes.
21

Le modèle en graphe
Figure 3.3 – BD orientées documents [30]
Figure 3.4 – BD orientées colonne [30]
Ce modèle (figure 3.5) permet une modélisation plus aisée d’objets et de leurs interactions.
Un exemple typique serait les interactions entre acteurs, réalisateurs, producteurs et films.
3.3.2 BASE en réponse à ACID
Figure 3.5 – BD orientées graphe [30]
Si les solutions SQL avaient tendance à être des systèmes CA, le NoSQL lui s’oriente plutôt
vers un modèle AP (voire CP). Le courant veut redéfinir de nouvelles formes de consistance en
fournissant, en réponse à la propriété ACID, le paradigme BASE : essentiellement disponible
(Basically Available en anglais), à état variable dans le temps (Soft State en anglais) et fina-
22

lement consistant (Eventually Consistant en anglais). Le principe est d’oublier le ’C’ et le ’I’
d’ACID pour une dégradation avantageuse de consistance et pour une amélioration des performances.
Pour plus de détails, nous dirigeons le lecteur vers la présentation de Brewer [18].
Pour le lecteur surpris de cet affaiblissement de la consistance, nous proposons la lecture de
l’article de Volgels [42] qui explique pourquoi ces concessions et comment elles peuvent être
vues du point de vue client et serveur.
3.4 MongoDB
MongoDB est un SGBD NoSQL de type document, open source, proposé par la société
10gen. Sa popularité est grandissante, il est notament utilisé par FourSquare [35], SourceForge
ou GitHub qui, à eux seuls, lui garantissent sa notoriété.
3.4.1 Modèle de données
Le modèle de données de MongoDB est orienté documents. Etudions ce modèle via une
approche bottom-up.
Documents
Un document, l’unité basique de MongoDB , est un ensemble ordonné de paires clé-valeur.
Il est identifié par son nom. Pour faire une analogie à SQL, un document peut être vu comme
une entrée. A la différence d’une entrée SQL, le nombre de champs d’un document n’est pas
défini préalablement. Un exemple d’un simple document est le suivant :
Exemple 1 (MongoDB - Document).
{”nom” : “Degroodt”, “prenom” : “Nicolas”, “age” : 25}
Les clés sont des strings alors que les valeurs sont typées : dans notre exemple, Degroodt
et Nicolas sont des strings et 25 est un entier.
Collections
Une collection est un ensemble de documents (et peut donc être vu comme une table SQL).
Les documents d’une collection peuvent avoir des formes très différentes comme l’illustre
l’exemple suivant
Exemple 2 (MongoDB - Collection).
{”nom” : “Degroodt”, “prenom” : “Nicolas”, “age” : 25}
{”marque” : “apple”, “nom” : “MacBook Pro”}
23

MongoDB ne pose aucune restriction quant aux documents contenus dans une même
collection. Pourtant, pour des raisons pratiques, il est intéressant de distinguer des documents
différents en les plaçant dans différentes collections (et donc ne pas procéder comme nous
l’avons fait dans l’exemple précédent).
A la différence d’une table SQL, le nombre de champs des documents d’une même collection
peut varier d’un document à l’autre.
Bases de données
Une base de données est un conteneur pour les collections (tout comme une base de
données SQL contient des tables) avec ses propres permissions.
3.4.2 Choix CAP et PACELC
MongoDB a fait le choix CP favorisant la consistance à toute autre considération. MongoDB
prévoit des mécanismes fort intéressants pour pallier à un bon nombre de défaillances
(c’est-à-dire de manière à préserver consistance, disponibilité et tolérance à la partition).
Néanmoins, lorsque ces mécanismes ne suffisent plus, le choix est fait de ne pas garantir la
disponibilité et de rester tolérant à la partition.
La politique de MongoDB est d’être consistant avant tout. Il s’inscrit donc dans un choix
PC/EC. Néanmoins, si l’utilisateur désire augmenter les performances du système, il serait
possible de libérer la consistance pour une amélioration des temps de réponse.
3.4.3 Vue d’ensemble de l’architecture
Figure 3.6 – L’architecture de MongoDB [38]
Comme illustré par l’image 3.6, MongoDB se décompose en 3 services différents mais
dépendants les uns des autres.
24

Un shard se compose d’un ou plusieurs serveurs. Via son processus mongod, il est en
charge de stocker les données.
Les serveurs de configurations stockent les méta-données du système c’est-à-dire les
informations basiques relative à chaque shard et des indications quant aux données stockées
par ceux-ci.
Ce service est indispensable, il est donc nécessaire de l’assurer en lui consacrant deux voire
trois instances. L’écriture sur ces services utilise le protocole de validation en deux phases (2phase
commit en anglais) pour assurer un stockage fiable [38]. En cas de défaillance d’un
service, tous les autres serveurs passent en mode de lecture unique (read only en anglais).
Le processus Mongos redirige les requêtes des applications clientes vers les shards
adéquats et regroupe les résultats avant de les transmettre à l’application cliente. Il n’a pas
d’état persistant : son premier état provient des serveurs de configuration. Toute modification
dans les serveurs de configuration est propagée immédiatement aux processus mongos. Etant
donné que ce service n’a pas d’état persistant, en cas de défaillance de ce service, seules les
applications s’y connectant seront affectées, aucun autre service ne sera affecté. Pour répondre
à une telle défaillance, il suffit de relancer le service.
MongoDB distribue les données en fonction de ses collections c’est-à-dire que chaque
collection peut définir sa propre politique de partionnement de données. Un morceau (chunk
en anglais) est un ensemble continu de documents d’une collection. Un morceau, défini via
un triplet (collection A, minKey, maxKey), contient les données de la collection A dont la clé
est comprise entre les bornes minkey et maxKey.
Les serveurs de configuration ont connaissance de chaque morceau et de leur localisation
(comme décrit en figure 3.1). La taille d’un morceau ne peut dépasser 200MB. Lorsqu’il
atteint cette limite, il est divisé en deux nouveaux morceaux. Lorsque la limite de stockage
d’un shard est atteinte, des morceaux lui appartenant émigreront vers un autre shard.
Collection mink maxkey location
users nom : “Degroodt” nom : “Skhiri” shard1
users nom : “Skhiri” nom : “Zimányi” shard4
Table 3.1 – MongoDB - Configuration Morceaux, Shard
Actuellement, l’algorithme de répartition des données est très simple et est appliqué de
manière automatique ; on ne sait pas le configurer (cette faiblesse est connue et est en cours
d’amélioration [21]). L’algorithme déplace les morceaux en fonction de la taille des différents
shards. Le but est de maintenir les données distribuées de manière uniforme mais aussi de
réduire au minimum les transferts de données. Pour qu’un déplacement ait lieu, il faut qu’un
shard ait au minimum 9 morceaux de plus que le plus impopulaire des shards. A partir de ce
point, les morceaux vont être répartis de manière uniforme sur les différents shards.
3.4.4 Réplication des données
Le premier modèle de réplication proposé par MongoDB est le modèle maître-esclave.
Récemment, MongoDB propose une nouvelle approche, la réplication par pairs (Replicat set
en anglais), qui voit tous les serveurs d’un shard comme des pairs qui éliront un maître
temporaire. Dans les deux modèles, la réplication est asynchrone.
25

Réplication maître-esclave
Ce modèle (voir figure 3.7) est le plus répandu, il peut être utilisé comme outil de sauvegarde,
de basculement (failover en anglais) et peut servir à la montée en charge horizontale
(pour des opérations de lecture).
Figure 3.7 – Réplication maître-exclave[25]
Les données sont, dans un premier temps, écrites sur le serveur maître, l’information est
ensuite transmise de manière asynchrone aux serveurs esclaves.
Si un serveur esclave subit une défaillance, il suffit de relancer l’instance et il synchronisera
ses données avec le serveur maître via un fichier log (pour ne pas surcharger le réseau avec
une migration de données depuis le début). Si un serveur maître subit une défaillance, le
système passe en mode lecture unique jusqu’à ce que le serveur maître soit relancé. On voit
donc ici que ce système de réplication permet un service de basculement en cas de défaillance.
Ces serveurs esclaves possèdent donc une version plus ou moins actualisée des données et
peuvent donc être utilisés en lecture par l’application si celle-ci concède un relâchement de
la consistance. Les esclaves allègent alors la charge subie par le serveur maître (le système
devient alors PA/EL). Une telle utilisation favoriserait fortement les applications à lectures
fréquentes.
Réplication par pairs
La réplication par pairs (Replicat Set en anglais) est une version améliorée du modèle
maître-esclave. Elle offre un balancement automatique.
Comme l’indique son nom, chaque serveur est identique et a un rôle : primaire ou secondaire.
Il n’y a qu’un serveur primaire par ensemble de répliques. En cas de défaillance de
celui-ci, les membres de l’ensemble procèdent à l’élection d’un nouveau serveur primaire (en
fonction de celui qui détient les informations les plus récentes) 1 . Les figures 3.8, 3.9 et 3.10
nous montrent un scénario d’élection.
Ce modèle de réplication donne à MongoDB la capacité de s’auto-gérer ; il ne nécessite
plus d’intervention humaine pour continuer son bon fonctionnement en cas de défaillance
d’une instance de stockage.
1. D’autres arguments peuvent être définis manuellement par l’utilisateur. Ces arguments donnent des
valeurs à chaque nœud qui seront prises en compte lors de l’élection du nouveau primaire.
26

Figure 3.8 – Un ensemble de réplicats[25]
Figure 3.9 – Défaillance du serveur primaire, procédure d’élection[25]
Figure 3.10 – Défaillance du serveur primaire, un nouveau serveur est élu[25]
27

3.4.5 Modèle de consistance
Par défaut, les requêtes sont donc consistantes mais il est possible de modéliser d’autres
degrés de consistance [39], notamment via l’utilisation des instances de stockages secondaires
(ou esclaves selon le mode de réplication) (voir section 3.4.4).
3.4.6 Modèle de requête
Grâce à son modèle de données en documents, MongoDB propose une interface de programmation
assez riche (sans doute parmi les plus riches du mouvement NoSQL). A titre
d’exemple, nous proposons deux listes non-exhaustives de ses fonctions.
La première liste illustre les différents opérateurs pour filtrer une sélection :
– les opérateurs , ≥
– l’opération exists : utilisée pour filtrer les entrées telles qu’il existe ou non un certain
attribut
– l’opérateur in : qui vérifie qu’une valeur doit être présente dans l’entrée retournée
– des expressions régulières qui peuvent être appliquées aux champs retournés
La seconde liste reprend quelques méthodes proposées par MongoDB :
– COUNT qui retourne le nombre de documents correspondant aux critères de recherche
– LIMIT qui limite le nombre de documents retournés
– SORT qui trie les documents retournés
– SKIP qui permet de ne pas retourner les n premiers documents
De plus, Mongo propose une mise en oeuvre de MR. Les fonctions doivent être écrites en
JavaScript [9].
3.5 Cassandra
Cassandra est un SGBD NoSQL orienté colonnes développé à l’origine par la société
Facebook et repris par la suite sous licence Apache. Le but du projet est de faire tourner un
système sur des milliers de serveurs [27]. A cette taille, les défaillances (grandes et petites) sont
courantes. Cassandra propose une nouvelle façon de gérer l’état persistant de ses instances
pour pallier à ces problèmes. Cassandra a été développé dans l’optique de diminuer les coûts
hardware et de gérer des données avec des fréquentes écritures.
3.5.1 Modèle de données
Cassandra propose un modèle de données orienté colonnes. Nous décrivons ce modèle de
données via une approche top-down.
Keyspace
Un Keyspace est le point de départ de stockage, l’équivalent d’une base de données dans
les SGBDR. Il est conseillé d’avoir un et un seul Keyspace par application [33].
Famille de colonnes
Une famille de colonnes est un conteneur pour un ensemble ordonné de colonnes (super
ou simples colonnes). Les familles de colonnes étaient statiques et définies manuellement dans
28

le fichier de configuration dans les versions antérieures à 0.7. Depuis Cassandra 0.7, on peut
ajouter/modifier/supprimer une famille de colonnes à la volée.
Une famille de colonnes a deux attributs : son nom et son comparateur qui définit le critère
permettant d’ordonner ses colonnes (par exemple un critère basé sur l’encodage UTF8).
Les différentes familles de colonnes sont stockées sur différents fichiers. Ce fait est important
lors de la modélisation du schéma de données. Pour former une famille de colonnes, on ne
pensera plus qu’à la sémantique des données mais aussi à la manière et à la fréquence dont on
y a accès. Si deux colonnes ont tendance à être lues ou modifiées en même temps, les mettre
dans un même fichier permettra de limiter cette opération en un seul accès fichier.
Colonnes
Une (simple) colonne est l’unité la plus basique du modèle. Une colonne est un triplet :
la clé (le nom), la valeur et l’heure (un timestamp) (figure 3.11) de la dernière modification.
Ces colonnes ne sont pas définies au départ et peuvent être ajoutées/retirées à la volée, ce qui
permet une certaine flexibilité.
Figure 3.11 – Cassandra - La structure d’une colonne [33]
Une super colonne (figure 3.12) est une colonne spéciale ; sa valeur est un ensemble de
colonnes simples. L’idée est donc de donner un degré de hiérarchie en plus au modèle. (Ce
concept de super-colonne est un des principaux aspects qui différencie le modèle de données
de Cassandra à celui de Dynamo).
Figure 3.12 – Cassandra - La structure d’une super colonne [33]
Remarquons que lorsqu’une famille de colonnes contient des super-colonnes, cette famille
devient une famille de super-colonnes et ne pourra plus stocker que des super-colonnes.
Résumé
Ce modèle peut donc être vu comme une architecture à 5 niveaux (figure 3.13 ) :
[keyspace][famille de colonne][clé][super colonne][colonne].
3.5.2 Le choix CAP et PACELC
Cassandra a très clairement été développé tel un système AP. Mais notons que ce système
donne l’option de pouvoir établir un niveau de consistance différent pour chaque requête :
(notamment en utilisant la technique de quorum 2 ). Toutefois, on remarque que, s’il est possible
2. Cette technique sera décrite à la section 3.5.5
29

Figure 3.13 – Cassandra - Un modèle de données à 5 niveaux
grâce à cette méthode d’avoir la dernière version d’une colonne, avoir la dernière version de
toute une entrée reste impossible. Ce choix est fait par Cassandra pour garantir la disponibilité
et la tolérance à la partition.
Cassandra a été pensé pour favoriser la disponibilité et la tolérance à la partition (système
PA/EL). Grâce à son modèle de consistance, à ses lectures réparatrices, Cassandra peut laisser
le système disponible en cas de partition (les données seront réparées plus tard) ; sans partition,
le système utilisera ce modèle pour améliorer les performances.
3.5.3 Vue d’ensemble de l’architecture
Cassandra propose une architecture décentralisée basée sur les solutions Dynamo et Big-
Table. Inspiration de Dynamo, chaque nœud de Cassandra est égal. Leur gestion des nœuds
se base sur le protocole peer-to-peer Gossip [33]. Cette décentralisation, par opposition à
l’architecture maître-esclave, permet d’éviter les points de défaillances isolés et les goulots
d’étranglement.
Le Gossiper est en charge de s’assurer que chaque information importante concernant
l’état des nœuds du cluster est transmise à tous les nœuds du cluster (et aussi aux futurs
nœuds et ceux ayant subi une défaillance). Le service Gossip est aussi en charge de répartir
les clés sur les différents nœuds.
Une des principales fonctionnalités voulues pour Cassandra est la capacité de passer à
30

l’échelle de manière linéaire, ce qui nécessite la capacité de distribuer les données de manière
dynamique sur les différentes instances du cloud. Pour distribuer les données au travers des
instances du système, Cassandra utilise une méthode de hachage cohérent (Constitent Hashing
en anglais) à l’aide d’une fonction de hachage préservant l’ordre [27]. Dans le hachage cohérent,
l’ensemble des instances est considéré comme un anneau (c’est-à-dire que le nœud d’indice
(token en anglais) d’ordre le plus grand est suivi par le nœud d’indice le plus faible). Lorsqu’un
nœud se rajoute à l’anneau, on lui assigne un indice. Cet indice déterminera sa position dans
l’anneau.
Chaque donnée est identifiée par des clés. Pour déterminer la position de la donnée dans
l’anneau 3 , sa clé est donnée en entrée à la fonction de hachage qui détermine alors sa position
dans l’anneau. Cette position déterminée, la donnée parcourt alors l’anneau jusqu’à trouver
le premier nœud dont l’indice sera supérieur à sa position. Ce nœud sera alors responsable de
cette donnée.
Chaque nœud est dès lors responsable de toutes les données dont la position est supérieure
à l’indice de son prédécesseur et inférieur au sien. On parle de nœud coordinateur. Le
principal avantage de cette technique est que l’ajout/retrait d’une instance n’influence que
ses prédécesseur et successeur directs.
Pour assigner les indices aux nœuds, Cassandra propose différents outils de partitions. En
voici une liste non-exhaustive :
– Le RandomPartitioner va assigner un indice compris entre 0 et 2 127 . C’est l’outil de
partition par défaut de Cassandra . Néanmoins, cet aspect aléatoire peut vite conduire
à une répartition non-uniforme des charges et des données.
– Le OrderPreservingPartitioner va utiliser les clés des données pour les répartir dans
l’anneau. C’est donc aux développeurs de l’application de bien choisir ses clés.
3.5.4 Réplication des données
Cassandra utilise la réplication de données dans le but de proposer la haute disponibilité et
durabilité de ses données. Le facteur de réplication N définit le nombre de copies des données.
Chaque Keyspace a son facteur de réplication.
Chaque nœud est donc chargé de stocker les données dont il est le coordinateur mais
aussi de s’assurer que ses données soient répliquées N-1 fois au travers l’anneau. Cassandra
propose plusieurs options de réplication. Dans la première, Rack Unaware, les N − 1 copies
sont répliquées dans les nœuds successeurs directs du coordinateur. Dans les suivantes, Rack
Aware et Datacenter Aware, en utilisant le système Zookeeper 4 , un nœud leader est élu. Le
leader dit à chaque nœud du système quel ensemble de données (toujours en fonction de leur
clé) il est chargé de répliquer. Le leader fait en sorte (dans la mesure du possible) que chaque
nœud ne soit jamais responsable de plus de N − 1 jeux de données tout en s’assurant que les
données aient des copies dans différents centres de calcul ou racks.
Le modèle de réplication entre ces différents nœuds est différent de tout ce que nous
avons déjà vu. Il n’est ni synchrone, ni asynchrone. Cassandra permet de définir un degré
de consistance pour chacune des opérations l’attaquant, définissant ainsi (nous le verrons à
la section 3.5.5) le nombre de serveurs devant répondre pour que l’opération soit validée.
Résumons le concept : l’application envoie une requête à chaque nœud stockant la donnée
concernée et attend un certain nombre de réponses pour valider l’opération. Si ce nombre est
3. Un cluster Cassandra peut être vu comme un anneau d’instance ayant un rôle similaire.
4. Le service Zookeeper est décrit de manière plus précise en section 3.6.4
31

égal au facteur de réplication, alors le modèle pourra être considéré comme synchrone ; dans le
cas contraire, la réplication sera asynchrone et un phénomène de réparation aura lieu durant
les lectures.
3.5.5 Modèle de consistance
S’inspirant de Dynamo [31], Cassandra met en place le concept de “finalement consistant”
(Eventually consistent en anglais) mais ne se limite pas à celui-ci. Son modèle de consistance
est configurable au quorum et permet dès lors une large gamme de consistance.
Modèle au quorum
Définissons les trois variables suivantes :
– N : le nombre de répliques
– R : le quorum en lecture (le nombre de réponses de lectures à attendre lors d’une requête
de lecture)
– W : le quorum en écriture (le nombre de confirmations d’écriture à attendre lors d’une
requête d’écriture)
– si W + R > N, la consistance sera dite forte
– si W + R ≤ N, on dira le système finalement consistant. Il se peut que les opérations
d’écriture et de lecture ne se recouvrent pas. Des conflits de versions peuvent alors
apparaitre. Ces conflits peuvent être résolus à l’aide de vector clocks et un système de
gestion de versions.
Niveaux de consistance
Il y a quelques niveaux typiques de consistance que l’on peut décider. Ces niveaux peuvent
être différents en fonction de l’opération (écriture ou lecture) [4].
Ecriture : Voyons une liste non-exhaustive de ces différents niveaux (par consistance croissante)
pour l’écriture :
– ONE : s’assure que l’opération a été écrite sur au moins un nœud. Si un seul nœud
répond, l’opération sera considérée comme réussie.
– QUORUM : le quorum en écriture est assigné à nombre de répliques/2 +1. Par exemple,
pour un facteur de réplication de 8, Cassandra écrira l’information dans 5 nœuds (4+1)
– ALL : tous les nœuds (leur nombre est spécifié par le facteur de réplication) doivent
retourner une réponse positive. Si un seul nœud signale une erreur, l’écriture est un
échec.
On le comprend, plus la consistance sera forte, plus les performances seront faibles.
Lecture Voyons une liste non-exhaustive de ces différents niveaux (par consistance croissante)
pour la lecture :
– ONE : retourne la valeur donnée par le premier nœud.
– QUORUM : le quorum de lecture a la même valeur que celui de l’écriture : nombre
de répliques/2 +1. Via la gestion des conflits de versions des différentes réponses, on
construit la donnée et, considérant le quorum de lecture et d’écriture, on a la garantie
d’avoir une réponse consistante.
32

– ALL : interroge tous les nœuds. Si un seul ne répond pas la requête est considérée comme
non validée. Dans le cas contraire, on reconstruit la donnée avec toutes les réponses.
On le comprend, tous les mécanismes de réparation ont lieu à la lecture, ce qui peut
entrainer des pertes de performances à la lecture. Cassandra a donc été modélisée pour des
écritures performantes (aux dépens de la performance en lecture).
3.5.6 Modèle de requêtes
Le modèle de requêtes de Cassandra peut être considéré comme assez riche (même si il est
moins riche que celui de Mongo). A titre d’exemple, nous proposons une liste non-exhaustive
des différentes requêtes possibles[4] 5 :
– GET retourne une (super) colonne d’une entrée spécifiée par sa clé.
– GET SLICE retourne un ensemble de (super) colonnes (spécifiées par un SlidePredicate
6 ) d’une entrée spécifiée par sa clé.
– MULTIGET SLICE retourne un ensemble de (super) colonnes (spécifiées par un Slice-
Predicate) de plusieurs entrées (spécifiées par leurs clés).
– GET COUNT retourne le nombre de colonnes présentes dans une entrée et respectant
un SlicePredicate.
Si Cassandra est couplée à un cluster Hadoop (voir section 3.6.1), des fonctions MR
peuvent être écrites pour faciliter l’exécution de tâches complexes.
3.6 HBase
HBase est un projet open-source écrit en JAVA Apache dont le but est de fournir un produit
similaire au produit propriétaire Big Table de Google. Tout comme BigTable se déployait
au dessus du système de fichiers distribué Google File System, Hbase se déploie sur un système
de fichiers distribué open-source : The Hadoop Distributed Filesystem (HDFS) (un projet de
la fondation Apache) qui se charge des opérations de réplication 7 .
3.6.1 The Hadoop Distributed Filesystem
HDFS est conçu autour de l’idée que le mode de traitement de données le plus efficace
consiste en une et une seule écriture et plusieurs lectures pour chaque donnée. [43]. Un ensemble
de données est donc copié ou généré une fois et analysé à de nombreuses reprises. Il est
conçu pour pouvoir se déployer sur des nœuds différents les uns des autres (pouvant appartenir
à des clusters différents). Dans ce contexte, les défaillances ne sont pas exceptionnelles. Il
est conçu de manière à gérer ces défaillances sans entrainer de trop longs temps d’interruption
chez l’utilisateur [43].
L’architectre HDFS repose sur deux composants : le nœud de noms (namenode en anglais)
et les nœuds de données (datanodes en anglais) (figure 3.14) et suit le pattern maître-esclave :
.
5. Rappelons que la consistance de la plupart des requêtes peut être définie individuellement pour la plupart
des requêtes
6. Un SlicePredicate est l’équivalent d’un prédicat en logique mathématique.
7. HBase peut se déployer sur d’autres systèmes de fichiers distribués mais il est d’usage courant de la
coupler à HDFS
33

Figure 3.14 – Architecture HDFS
Les nœuds de données sont les esclaves. Ils stockent et retrouvent les blocks. Ils signifient
périodiquement au nœud de noms la liste des blocks qu’ils stockent. Tout comme les systèmes
de fichiers sur un simple disque, HDFS coupe les fichiers en block (64 MB par défaut), ce
qui permet d’avoir des fichiers de grande taille, voire plus grands qu’un disque ; effectivement
ces blocks composant un même fichier ne doivent pas nécessairement être contenus sur le
même disque. Le second avantage d’une telle approche est qu’elle simplifie la gestion des soussystèmes,
ce qui est particulièrement utile et nécessaire dans la gestion de systèmes distribués.
Ces blocks ayant des tailles fixes, il est facile de calculer combien chaque disque peut en
contenir. Les méta-données (telles que les permissions, etc.) ne doivent pas nécessairement
être stockées avec les blocks, un autre service (le nœud de noms) peut les prendre en charge.
Le nœud des noms, le maître, prend en charge l’espace de noms (namespace en anglais)
et maintient l’arbre de gestion de fichiers ainsi que les méta-données relatives à tous ces
fichiers. Cette information est stockée de manière permanente sous forme de deux fichiers :
l’image de l’espace de noms et un fichier de log. Le nœud des noms sait aussi quels nœuds de
données sont en charge de quelles données. Il tient un rôle central dans l’administration du
système : vu qu’il gère toutes les méta-données des fichiers, sa défaillance pourrait entrainer
une incapacité à reconstruire les fichiers et donc une perte de l’information. Il s’agira donc
d’assurer un mécanisme très puissant de résistance à la défaillance pour ce service.
3.6.2 Modèle de données
Les données sont stockées en tables faites de colonnes et d’entrées. Chaque cellule composant
les tables est versionnée (HBase détermine le timestamp à chaque insertion) et interprétée
comme un tableau d’octets. La clé de chaque entrée est elle aussi un tableau d’octets ce qui
fait que théoriquement toute donnée peut servir de clé. Les tables trient les entrées en fonction
de leurs clés.
Les colonnes sont regroupées en familles de colonnes (column families en anglais). Toutes
les colonnes d’une famille de colonnes ont un préfixe commun. Par exemple, les colonnes
nosql :cassandra et nosql :MongoDB appartiennent à la même famille de colonnes nosql tandis
que sql :MySQL appartient à la famille de colonne sql.
34

Les différentes tables et familles de colonnes doivent être définies au démarrage du système
car elles ne peuvent pas être modifiées de manière dynamique tandis qu’à tout instant, des
colonnes peuvent être ajoutées à une famille de colonnes. Les différentes familles de colonnes
sont stockées ensemble sur HDFS, ce qui fait de Hbase un système orienté famille de colonnes.
3.6.3 Choix CAP et PAELC
Hbase est un système CP : vu qu’il ne possède pas de système propre de réplication,
lorsqu’un nœud connait une défaillance, les données dont il était responsable ne vont plus
être accessibles (il n’y pas de possibilité de joindre une réplique). L’avantage le plus certain
est que le système est tolérant à la partition : en cas de défaillance, seules quelques régions
(voir section 3.6.4) seront inaccessibles. Hbase s’inscrit donc dans un modèle PC/EC.
3.6.4 Vue d’ensemble de l’architecture
Figure 3.15 – Architecture Hbase [43]
Un système Hbase repose donc sur deux clusters travaillant ensemble, un cluster HDFS
et un cluster Hbase . Comme l’illustre la figure 3.15, le cluster Hbase a 3 composants :
– Le maître qui assigne les régions aux serveurs de régions enregistrés. Il est aussi chargé
de les surveiller. Si un serveur de région n’est plus joignable, le maître va réassigner les
régions qu’il gérait. Le maître est aussi en charge de tâches administratives telles que les
changements du schéma de données, etc. Il sert de point d’entrée pour toute application
se connectant au système ; il communiquera quelle serveur de région stocke les données
qui l’intéressent.
35

– Les Serveurs de régions prennent en charge les requêtes d’écriture et de lecture
du client. Ils communiquent avec le maître qui lui transmet la liste des régions qu’ils
géreront et pour lui faire savoir qu’ils sont toujours joignables. Ils communiqueront aussi
avec le maître pour lui signifier qu’une nouvelle région doit être créée.
– Hbase dépend du service ZooKeeper qui se charge de maintenir les informations du
parc en cas de défaillance. Le maître et les serveurs de région sont tous enregistrés
auprès du Zookeeper et si l’un d’eux subit une défaillance, Zookeeper se chargera de le
faire réparer ou de le remplacer.
Les tables sont automatiquement partitionnées horizontalement en régions que l’on peut
résumer en un triplet :
– la table à laquelle elle se reporte
– la première entrée qu’il stocke
– la première entrée qu’il ne stockera pas
Initialement, une table contient une simple région mais au fur et à mesure que la taille de
cette région augmente, celle-ci se divise en deux régions de tailles approximativement égales
que Hbase répartira sur différents nœuds du cluster. Le maître est responsable d’assigner les
régions aux serveurs de régions (comportement similaire aux nœuds de noms et nœuds de
données de HDFS). On a donc affaire à une répartition des données centralisées autour de ces
deux points d’entrée (le maître Hbase et le nœud de données HDFS).
Le nœud de noms d’HDFS distribue, de manière presque uniforme, les nouvelles données
dans les nœuds de données composant le cluster HDFS. Les données sont donc réparties de
manière équitable. Mais, lorsque des nouveaux nœuds sont ajoutés au cluster, les données
existantes ne vont pas être réparties sur ceux-ci ce qui entraîne un cluster non balancé (c’està-dire
où les données ne sont pas réparties équitablement). Notons que les nouvelles entrées
seront envoyées sur les nouveaux nœuds. Dans le cas d’une application à écritures fréquentes,
le cluster retrouvera donc rapidement un état plus balancé. HDFS fournit aussi un outil qui
obligera les données à se répartir de manière équitable sur les nœuds.
Le maître Hbase se comporte différemment : il va toujours faire en sorte que les serveurs
de régions s’occupent d’un nombre similaire de régions.
3.6.5 Réplication des données
Hbase ne propose pas de système de réplication et repose sur le système répliqué de
HDFS. Le concept de block est la base du modèle de réplication chez HDFS. La taille des
blocks et le facteur de réplication peuvent être configurés par fichier. La réplication des blocks
est assurée par le nœud de noms. Celui-ci reçoit périodiquement des “battements de coeur”
(trad.Heartbeat) de chaque nœud de données (qui signifient leur bon fonctionnement) et des
rapports sur les blocks (qui contiennent une liste de tous les blocks qu’il stocke).
La requête d’écriture d’un client n’est pas directement transmise au nœud de noms, le
client stocke d’abord le fichier localement et temporairement. Le client ne contacte le nœud
de noms que lorsque le fichier a atteint la taille d’un block. Le nœud de noms insère le nom
du fichier dans le système de fichiers et lui alloue des blocks. Le client transmet alors la
donnée par petits morceaux (4KB) au premier nœud de données qui écrit ces morceaux et
les transmet au deuxième nœud de données (supposons un facteur de réplication égal à 3).
Celui-ci effectue le même processus.
36

On voit donc un nouveau modèle asynchrone, où la transmission de données se fait en
cascade.
3.6.6 Consistance des données
Le modèle est assez simple : les entrées sont atomiques quels que soient leurs nombres de
colonnes ([43] et [14]).
3.6.7 Modèle de requêtes
Le modèle proposé par Hbase est un petit peu plus faible que Cassandra . Ceci peut se
justifier par son approche Map-Reduce : Hbase /HDFS sont pensés pour s’adapter de manière
optimale à ce concept : les tables Hbase peuvent directement servir d’entrée et de sortie de
fonctions MR qui seront distribuées au travers des régions. Les requêtes proposées par Hbase
se limitent donc aux opérations basiques telles que get, put, scan, etc.
3.7 Voldemort
Le projet Voldemort est un SGBD avancé clé-valeur. C’est un projet open-source dont les
contributions de LinkedIn font une valeur sure.
Son modèle de données est le “n-uplet” qui propose de diviser l’ensemble des clés en
magasins (stores en anglais). C’est le seul niveau de subdivision de Voldemort.
A l’instar de Cassandra , l’ensemble des clés est vu comme un anneau divisé en Q sousensembles
de données. Chacun des S serveurs est dès lors responsable de Q/S sous-ensembles
de données. Les données sont répliquées de manières asynchrone sur les R nœuds suivants
(où R est le facteur de réplication). La répartition des données est assurée du côté du client :
celui-ci se connecte à l’anneau pour connaitre sa topologie et sait dès lors à quels nœuds
envoyer quelles données.
Des nœuds peuvent être ajoutés et retirés du système lorsque celui-ci est en fonctionnement.
Voldemort est capable de détecter et recouvrer les défaillances.
Le modèle est finalement consistant : Voldemort garantit une version à jour de la donnée
via la lecture d’une majorité des répliques et un système de contrôle de versions concurrentielles
(multi-version concurrency control en anglais) pour gérer les différentes versions des
répliques.
Voldemort est donc un système AP, en cas de partition, le système continuera à fonctionner
au détriment de la consistance et, si aucun problème ne survient Voldemort et son modèle
finalement consistant favorisent les performances à la consistance. Il est donc un système
PA/EL.
Son modèle de requêtes est voulu le plus pauvre ; il ne propose que les trois opérations
basiques : trouver (GET en anglais), insérer (put en anglais) et supprimer (delete en anglais).
3.8 Comparaison des différents systèmes
Le tableau 3.2 résume cette comparaison.
37

Système Modèle de données choix CAP choix PAEELC consistance réplication API
SQL
MySQL cluster Relationnel CP PC/EC transactionnelle 8 Synchrone SQL
VoltDB Relationnel CP PC/EC transactionnelle Asynchrone SQL + MR
NoSQL
Cassandra Familles de colonnes AP PA/EL Adaptable Adaptable Moyen + MR
Hbase Familles de colonnes CP PC/EC Verrouillage par entrée Asynchrone faible + MR
MongoDB Documents CP PC/EC consistance forte Asynchrone haut niveau + MR
Voldemort Clé-valeur AP PA/EL Finalement consistant Asynchrone Bas niveau
Table 3.2 – Tableau récapitulatif de l’étude comparative des SGBDs
38

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

Figure 4.1 – YCSB - Cassandra - Passage de 5 instances à 6 instances[23]
système. La figure 4.2 montre l’ajout d’une sixième instance à un système Hbase stable de 5
instances (après les 10 premières minutes).
Figure 4.2 – YCSB - Hbase - Passage de 5 instances à 6 instances[23]
Même si cette proposition d’expérience peut proposer des résultats parlants, nous en
voyons très vite les limitations. Dans un premier temps, revenons sur sa reproductibilité :
le scénario proposé par YCSB nécessité l’intervention d’un acteur humain pour définir si le
système s’est stabilisé. Cette notion de système stable est arbitraire et est un frein à la reproductibilité
de l’expérience. Il s’agit donc de définir ces instants (où l’on modifie le système, où
l’on considère le système comme stabilisé) de manière plus concrète, plus scientifique.
Comme le montrent les figures 4.1 et 4.2, ces résultats restent difficiles à analyser même si,
de manière intuitive, on peut analyser la figure 4.2. Il s’agit donc de déterminer des paramètres
qui définiront de manière plus rigoureuse l’élasticité du système. En se basant sur la figure 4.1,
nous remarquons que les résultats peuvent sembler brouillons (par exemple, la figure 4.1
ressemble plus à un nuage de points qu’à des temps de latence stabilisés). Il s’agira donc de
penser un scénario permettant de dégager des valeurs statistiques pouvant être étudiées.
40

4.2 Problèmes liés à la mesure de l’élasticité
Avant de décrire de manière détaillée une nouvelle méthodologie, prenons le temps d’analyser
les problèmes intrinsèques à une telle démarche : le premier est la difficulté de chiffrer,
d’apposer une métrique sur l’ajout d’une instance. Jugera-t-on l’apport en CPU, en RAM ou
en mémoire disque ? Effectivement ceci dépendra du type de SGBD : un SGBD stockant les
données en mémoire tirera nettement plus profit de l’ajout d’une instance avec une grande
capacité en RAM qu’un système les stockant en mémoire disque.
Pour ne pas être confrontés à de telles considérations, nous proposons que toutes les
instances composant notre cloud soient similaires 2 . Chiffrer, fixer une métrique devient donc
assez simple 3 :
Définition 10.
Soit ni, le nombre initial d’instances d’un service, nf le nombre d’instances du service
après un passage à l’échelle, son apport terme de ressources se définit comme
∆n = nf −ni
ni
Le second problème est de prendre en considération le rôle de l’instance. Une instance
de calcul est dite sans état (stateless en anglais) lorsqu’elle traite chaque requête indépendamment
(sans relation avec la précédente). Les instances de BDs stocke des données dont
la persistance doit être assurée. On voit ici assez vite arriver le problème de la descente à
l’échelle : lorsqu’on désire diminuer le nombre d’instances de stockage d’un service, il va falloir
déplacer les données qu’il stockait vers d’autres instances. Ceci va nécessiter un certain
temps d’adaptation qui se reflétera sur une augmentation certaine des temps de latence du
service de stockage. On le comprend donc, le rôle d’une instance détermine son influence sur
l’élasticité.
Comme nous l’avons vu au chapitre 3, un nœud peut se voir attribuer un ensemble de
fonctions bien différentes. Par exemple, dans le cas de MongoDB , l’ajout un processus mongos
aura un effet, théoriquement, très différent de l’ajout d’un shard. Lorsqu’on parle d’ajouter
un nœud sur un cluster Hbase/HDFS, ajout-t-on ce nœud au cluster Hbase ou au cluster
HDFS. Traiter ces rôles comme une dimension de notre étude semble très complexe (voire
impossible). Toutefois, il ne serait pas judicieux de faire abstraction de ces rôles. Il s’agit donc
de les considérer lors de l’analyse des résultats.
4.3 Notre solution
Si on peut comprendre facilement l’élasticité, définir des paramètres qui permettront de
la mesurer est une tâche moins aisée. Dans cette section, nous étudierons le comportement
théorique d’un système face à l’ajout ou au retrait d’instances et proposerons un scénario de
test permettant de son élasticité.
2. Cette abstraction peut facilement se justifier par l’aspect virtuel des instances composant le cloud : vu
qu’elle font abstraction de la couche physique, il n’y a pas de raison de vouloir s’en tenir à des instances émulant
des composantes physiques différentes
3. Notons toutefois que, même si nous en faisons abstraction (pour des raisons de clarté), étudier ces aspects
“physiques” de l’instance garde tout son intérêt.
41

4.3.1 Scénario de tests
Considérons un SGBD de ni instances préalablement chargé de données.A l’instant t0, le
système est stable, c’est-à-dire qu’il n’y a plus de transferts internes de données entre-eux, et
n’est soumis à aucune charge.
A partir de l’instant t0, un nombre conséquent et constant d’utilisateurs (effectuant euxmême
un nombre constant d’opérations par seconde sur le système) 4 attaquent un SGDB
pendant 60 minutes. Toutes les 10 secondes, une moyenne des temps de latence est reportée.
A l’instant tm, une modification (ajout ou retrait de nf − ni instances) est effectuée sur
le système. Arbitrairement, nous effectuons cette modification après 20 minutes. Le système
se compose alors de nf instances.
Les figures 4.3 et 4.4 représentent le comportement théorique d’un tel scénario, cette
modification sous-entend une découpe du scénario en trois phases : une phase d’attaque du
système ([ti, tm]), une phase d’adaptation à la modification ([tm, tm + ∆t]) et une phase de
stabilisation du système suite à la modification ([tm + ∆t, tf ])
temps de
latence
ln
i
ln
f
t i
phase d'attaque phase d'adaptation
tm
Δt
phase de stabilisation
t f temps
Figure 4.3 – Résultat supposé du scénario pour l’ajout d’instances
Il faut préciser à ce niveau que notre étude ne considère pas de système rigoureusement
stable. Notre étude étudie le comportement du système en transition, le scénario de tests ne
dure donc que 60 minutes.
4. Des tests seront préalablement effectués pour déterminer les capacités du système
42

temps de
latence
ln f
ln i
t i
Phase d’ attaque
phase d'attaque phase d'adaptation
tm
Δt
phase de stabilisation
t f
temps
Figure 4.4 – Résultat supposé du scénario pour le retrait d’ instances
Le système étant stable à l’instant ti, il devrait très vite répondre de manière constante à
l’attaque. Nous serons dès lors en mesure d’effectuer une moyenne arithmétique 5 des temps
de latence sur l’intervalle [ti, tm]. Cette moyenne lni reflétera le comportement du système
composé de ni instances.
Définition 11 (lni ).
Phase d’adaptation
lni
1 tm = m−i t=ti l(t)
A l’instant tm, le système subit une modification. Il doit alors réagir à cette modification,
propager l’information de sa modification. En fonction du système étudié, cette modification
et cette propagation peuvent avoir des formes très différentes et produire des effets collatéraux
fort différents.
Certains systèmes devront avoir recours à un nombre élevé de modifications (et donc
de communications) internes et accuseront dès lors des temps de réponse beaucoup plus
5. La médiane des temps de latence a aussi été considérée mais, pratiquement, les résultats restent similaires.
43

importants que voulus durant une certaine période que nous définissons comme la phase
d’adaptation, ∆t.
Ce temps d’adaptation ∆t sera défini ultérieurement au test grâce à une supervision
humaine. L’observateur humain sera en charge, en fonction du graphique généré par le test,
de déterminer ce temps d’adaptation.
Phase de stabilisation
A l’instant tm + ∆t, le système a assimilé la modification et tend à se stabiliser. Il en
résulte des temps de latence plus ou moins similaires dont on peut tirer une moyenne lnf
représentative du comportement du système composé de m instances.
Définition 12 (lnf ).
4.3.2 Paramètres
lnf
tf 1 = m−i t=tm+∆t l(t)
D’un tel scénario, nous pouvons relever les six paramètres suivants qui caractériseront
l’élasticité :
1. le coefficient d’adaptation µ
2. le temps d’adaptation ∆t
3. l’impact maximal λ
4. la pente de la montée des temps de latence α1
5. la pente de la descente des temps de latence α2
6. la perturbation d’adaptation π
Les cinq premiers paramètres sont résumés à la figure 4.5. La perturbation π est plus
difficile à appréhender, nous la décrirons plus loin dans cette section.
Les temps de latence lni
et lnf
lni est la moyenne arithmétique des temps de latence du système composé de ni instances
(avant modification - voir définition 11). lnf , elle, est la moyenne arithmétique des temps de
latence du système composé de nf instances (après modification - voir définition 12).
Le coefficient d’adaptation µ
Ce paramètre est central dans notre approche, il quantifiera le gain (ou la perte) en performance
survenant immédiatement après la modification. De manière abstraite, il s’entend donc
comme le rapport entre la performance et le coût engendré par la modification du système.
Il s’agit donc de considérer la modification des temps de latence ainsi que la modification du
nombre d’instances.
Le coefficient d’adaptation µi,f est sans dimension et détermine l’adaptation d’un système
passant de ni à nf instances. Définissons la variation des temps de latence ∆l = lnf − lni , le
coefficient d’adaptation µ se définit comme suit :
44

temps de
latence
l i
ln i
ln f
α 2
tm
timpact
Δt
α 1
lambda
mu
Figure 4.5 – Période d’adaptation théorique supposée
Définition 13 (Le coefficient d’adaptation µ).
µ =
∆l
ln i
∆n
temps
Par exemple, imaginons un SGBD parfaitement élastique (sans considérer le temps d’adaptation)
tel que lorsqu’on double son nombre d’instances (nf = 2 ∗ ni), les temps de latence
soient réduits de moitié (lnf = ln i
2 ) et dès lors µi,j = 0.5. A contrario, un système dont les
performances ne seraient modifiées (lnf = lni ) par n’importe quelle modification verrait son
coefficient d’adaptation à 0.
Une première approche serait de voir µ comme caractérisant le passage à l’échelle. Cette
approche serait naïve : pour mesurer le passage à l’échelle, il faudra considérer des systèmes
stables. Notre approche considère le système en transition, µ se réfère donc au gain immédiat
en performance (mesuré par rapport aux moyennes des temps de latence précédant et
succédant directement la modification) par rapport au coût.
Le temps d’adaptation ∆t
Correspondant à la durée de la phase d’adaptation, ce temps est la durée nécessaire au
système pour assimiler la modification (répartition des données et autres). Un système sera
45

d’autant plus élastique que ce temps sera réduit.
De manière plus descriptive, cette durée commence à l’instant où l’on modifie le système tm
et finit lorsque les temps de réponse du système composé de nf nœuds ne sont plus influencés
par la modification. Ce temps d’adaptation est donc déterminé ultérieurement aux tests et
sujet à l’interprétation d’un observateur humain. Ceci est critiquable mais nous soulignons
que cet acteur humain n’influence pas sur le déroulement des tests, il n’intervient que sur
l’interprétation des résultats.
La forme de l’adaptation
Le système sera donc perturbé durant toute la période d’adaptation. Il est intéressant de
connaitre le temps nécessaire au système pour se stabiliser mais aussi de pouvoir décrire la
forme de cette adaptation. En faisant un zoom sur la phase d’adaptation (figure 4.5), nous
déterminons 4 nouveaux paramètres : l’impact maximal λ, les pentes de montée et descentes
des temps de latence (α1 et α2) et la perturbation d’adaptation π.
L’impact maximal λ est le rapport entre le pic de perte de performance (li) et le temps
de latence moyen du système initial lni .
Définition 14 (L’impact maximal λ).
λ = li
ln i
Un impact plus grand préviendra du risque d’une très forte perte en performance (par
rapport aux performances précédentes), momentanée ou non. Nous connaissons à présent ce
temps d’adaptation (∆t), l’impact maximal de cette adaptation (π en %), on peut dès lors se
demander quand aura lieu cet impact maximal, quelles seront les pentes de la montée et de
la descente des temps de latence du système.
Les pentes α1 et α2 sont les coefficients angulaires de la montée (α1) et de la descente
(α2) des temps de latence (figure 4.5). Considérant les valeurs décrites à la figure 4.5, la droite
de montée des temps de latence est la droite joignant les deux points (tm, lni ) et (timpact, li).
La droite de descente des temps de latence, elle, est définie par les deux points (timpact, li) et
(tm + ∆t, lnf ). Nous définissons α1 et α2 comme suit :
Définition 15 (α1).
Définition 16 (α2).
α1 = timpact−tm
li−ln i
α2 = (tm+∆t)−timpact
ln f −li
46

Ces deux nouveaux paramètres (α1 et α2), couplés à l’impact maximal, sont une première
approche dans la façon de définir la forme de l’adaptation. Cette description peut sembler
simpliste mais elle se justifie par la simplicité même des faits : le système subit une modification,
ce qui implique des modifications et des trafics internes qui diminuent ses performances
(pente croissante α1 des temps de latence). Lorsque le système a effectué le nombre maximal
de modifications (et donc, quand ses performances sont minimales), trafics et modifications
vont diminuer jusqu’à ne plus être significatifs dans les performances du système. (pente décroissante
α2 des temps de latence). Toutefois, même si cette approche simpliste semble se
justifier, on s’aperçoit en pratique que la forme de cette adaptation ne va pas toujours être
proche de la forme triangulaire formée par alpha1 et alpha2.
Nous pouvons à présent déterminer la variation en performance résultant de la modification
du système et le temps nécessaire à son adaptation mais aussi le pic maximal de perte
en performance et la tendance du système à atteindre ce pic (l’atteindra-t-il rapidement ou
non). Mais cette représentation est trop simpliste, il faut aussi savoir comment le système va
se comporter durant l’adaptation. Pour connaître ce comportement, nous considérons l’aire
de la surface sous la courbe des temps de latence durant l’adaptation (la surface N à la
figure 4.7).
Figure 4.6 – Perturbation de la période d’adaptation théorique - Surface N
N suffit à compléter les 5 premiers paramètres (que nous avons décrits précédemment)
pour fournir une analyse de l’élasticité d’un système. Plus il sera grand, plus le système présentera
de mauvaises performances durant toute l’adaptation (et réciproquement). Néanmoins,
ce paramètre est aussi dépendant du temps d’adaptation et de la variation des temps de latence
∆l ; plus ceux-ci seront grands, plus pi sera susceptible d’être grand. On ne peut dès
lors pas interpréter π indépendamment des autres paramètres. Ceci est assez déplaisant.
Dans la figure 4.6, M est la surface sous la courbe des temps de latence d’un système
47

Figure 4.7 – Perturbation de la période d’adaptation théorique - Surface M
adaptant ses temps de réponses de manière linéaire durant la période d’adaptation. M est
définie par le temps d’adaptation et la variation des temps de latence ∆l. Nous proposons dès
lors d’utiliser cette surface pour former un paramètre indépendant de la perturbation.
La perturbation d’adaptation π décrit le comportement, la perturbation du système
par rapport à un système s’adaptant de manière linéaire à la modification. Nous la définissons
comme suit :
Définition 17 (Perturbation d’adaptation π).
π =
R tm+∆t
tm
l(t) dt
∆l∗∆t
2
Ce paramètre est donc sans dimension. Plus sa valeur sera proche de 1, plus le comportement
du système sera linéaire durant l’adaptation. Une valeur comprise entre O et 1, nous
informera que le système a un comportement globalement meilleur qu’un système s’adaptant
linéaire à l’adaptation, tandis qu’un grand score nous informera que le comportement du
système s’éloigne d’un comportement linéaire.
Le tableau 4.1 donne une idée récapitulative des différents paramètres.
4.3.3 Application
Dans cette section, nous décrirons comment nous mettons en œuvre un tel scénario. Nous
y décrirons le framework YCSB que nous utilisons ainsi que les adaptations que nous lui avons
48

Symbole Noms Unité Formule
µ Coefficient d’adaptation Sans unité µ = ∆l
∆t Temps d’adaptation Secondes
∆n
Déterminé à l’œil nu après l’expérience
λ Impact maximal Sans unité π = li
α1 Montée des temps de latence Sans unité
lni α1 = timpact−tm
α2 Descente des temps de latence Sans unité
li−lni α2 = (tm+∆t)−timpact
ln −li
R f
tm+∆t
l(t) dt
π Perturbation d’adaptation Sans unité π =
tm
∆l∗∆t
2
Table 4.1 – Tableau récapitulatif des paramètres définissant l’élasticité
apportées. Nous décrirons le jeu de données de nos tests ainsi que deux charges de travail que
nous appliquerons dans ces tests.
Le framework de YCSB
Figure 4.8 – Architecture de YCSB[17]
Pour appliquer ce scénario, nous utilisons une version adaptée YCSB (le framework).
L’architecture de YCSB (figure 4.8) est composée de quatre modules : le workload executor
va lancer plusieurs clients qui exécutent une série d’opérations (module client-threads) en
faisant appel au module d’interface de BD (DB Interface Layout en anglais). Le module
statistique récupérera les temps de latence de chaque opération et les analysera.
Un fichier de configuration de la charge de travail (workload en anglais) définit entre
autres :
– le nombre de clients
– le nombre d’opérations
– les pourcentages d’opérations de lecture-écriture
49

– la distribution de génération des données
– ...
Les paramètres suivants caractérisent plus spécifiquement notre scénario :
– l’interface de BD
– les adresses de BDs à contacter
– le fichier de configuration de la charge de travail
Pour générer de manière aléatoire, YCSB déploie 3 types de distribution :
– Uniforme : choisit un objet aléatoirement. Dans le cas d’une lecture, toutes les entrées
de la BD ont la même probabilité d’être lues.
– Zipfian : choisit un objet suivant la distribution ZipFian : quelques objets seront plus
populaires (et donc auront plus de chance d’être choisis) que d’autres.
– Dernière : les derniers objets récemment insérés sont plus populaires.
Les Modifications que nous avons apportées à YCSB ne sont pas considérables :
– Nous avons modifié le module statistique pour qu’il retourne en sortie la moyenne des
temps de latence toutes les 10 secondes.
– Nous avons aussi modifié le générateur de données pour qu’il puisse produire des entrées
de taille variable (alors que YCSB les destinait à être de taille fixe).
Jeux de données
Le jeu de données de nos tests est le suivant : chaque entrée est identifiée par une clé
primaire similaire à “user234123”. Chaque entrée est caractérisée par un nombre F de champs
qui sont des strings eux-mêmes caractérisés par une taille L. Afin de générer des données de
taille variable, le nombre de champs F est compris entre 2 valeurs Fm et FM (données en
paramètres). Chaque champ est nommé field0, field1, etc.. La taille des champs L sera, elle
aussi, comprise entre 2 valeurs Lm et LM (données en paramètres). Chaque champ est une
chaîne aléatoire de caractères.
Nous avons choisi de faire varier la taille de ces données car une des caractéristiques des
solutions NoSQL est que leur schéma de données n’est pas fixe et qu’ils peuvent donc stocker
des données très hétérogènes dans la même entité. Dans cette expérience, nous aurons des
entrées de taille variable comportant entre 80 et 100 champs dont la taille varie de 80 à 1000
bytes). Stockant 100.000 entrées, notre jeu de données aura une taille minimale de environ
6GB et maximale de environ 9,3 GB.
Charge de travail 1 : lectures fréquentes
Cette configuration proposée par YCSB est proche d’une application de tags de photos.
Chaque mise à jour correspond à un tag et certaines photos ont plus de succès que d’autres.
Nous simulons 100 clients attaquant la BD à un rythme de 50 opérations par seconde.
Paramètres :
– 95% de lectures
– 5% de mises-à-jour
– Distribution Zipfian
Charge de travail 2 : écritures fréquentes
Nous simulons une application basique comportant plus de deux fois plus d’écritures que
de lectures. Certaines informations sont plus populaires que d’autres (distribution Zipfian).
50

Nous simulons la charge de 100 clients à raison de 50 opérations par seconde.
Paramètres :
– 30% de lectures
– 70% d’insertions
– Distribution Zipfian
4.4 Expériences
Nous allons à présent tester notre méthodologie sur un cluster Cassandra de 6 nœuds.
Nous simulerons les deux charges de travail (décrites à la section 4.3.3 et 4.3.3) et ferons
varier la consistance des opérations.
Dans la première section (4.4.1), nous apporterons quelques informations supplémentaires
relatives à Cassandra nécessaires pour bien appréhender nos expériences. Dans les sections
4.4.2 et 4.4.3, nous simulerons des montées à l’échelle (de 4 à 6 nœuds) et des descentes à
l’échelle (de 5 à 4 nœuds).
Ces expériences nous permettront de relever les valeurs des paramètres décrits à la section
4.3.2. Nous analyserons ensuite ces paramètres et leurs valeurs.
4.4.1 Considérations complémentaires
Ajout d’une nouvelle instance
Pour ajouter une instance au cluster Cassandra, il suffit de lancer un nouveau nœud
Cassandra en lui notifiant un membre de l’anneau à contacter. Une fois que le nœud a signifié
son envie d’entrer dans l’anneau, le cluster commence à murmurer (90 secondes [3]) pour
connaitre le volume de données que chaque instance stocke et s’assurer de l’exactitude de ces
informations, le nouveau nœud se voit alors assigner son indice de façon à ce qu’il décharge de
moitié le nœud le plus chargé. Le nouveau nœud attend 30 sec avant de recevoir les données
de son successeur.
L’opération totale prendrait donc, théoriquement, au total deux minutes [3] 6 . Passé ce
délai, le nœud reçoit les données de son successeur mais peut déjà être interrogé par l’application
cliente. Il sera uniquement responsable de données une fois qu’il a reçu toutes ses
données.
Retrait d’une instance
Pour gérer son cluster, Cassandra fournit un outil nodetool. L’option decommission permet
à un nœud de se retirer de l’anneau, de se mettre hors service. Cette méthode est sans doute la
plus propre : les données et répliques de données dont il était responsable vont être réassignées
aux autres nœuds de l’anneau et transmises à d’autres nœuds du cluster. Aucune version de
ces données n’est perdue.
On remarquera que, considérant la gestion du retrait d’une instance, Cassandra n’est pas
tellement élastique. Les expériences nous ont montré deux aspects s’opposant à sa capacité à
descendre à l’échelle de manière dynamique :
– La première est qu’il est impossible de libérer un nœud sur lequel il existe un trafic
intérieur. Or, lorsqu’on détache un nœud de l’anneau, ceci génère un trafic important
6. Lors de nos expériences, nous avons surveillé cette opération et confirmons ce délai.)
51

pour répartir les données. Dans un petit cluster (5 nœuds pour nos expériences), ce
trafic atteint les autres nœuds du cluster et les empêche donc de pouvoir se retirer
de manière simultanée 7 . Pour l’administration de larges clusters, il est possible que le
trafic engendré n’atteigne pas tous les nœuds et il est possible aussi de savoir quelles
instances seront atteintes (les méthodes de distribution et de réplication de données les
définissent), mais cette administration serait fort difficile.
– La solution au premier problème serait d’effectuer ces mises hors service en cascade.
Mais nos expériences montrent que cinq minutes environ sont nécessaires pour libérer
un nœud d’environ 6GB. On peut estimer qu’un serveur de production sera bien plus
chargé et donc bien plus long à se vider de ses données. Ce temps n’est donc pas
négligeable et il est donc bien plus intéressant de pouvoir retirer plusieurs instances de
l’anneau de manière parallèle 8 .
4.4.2 Montée à l’échelle
Maintenant que nous avons éclairci ces quelques points, nous allons analyser comment
Cassandra se comporte en cas d’ajout de nœuds. Nous avons testé l’ajout de 2 nœuds à un
cluster de 4 nœuds.
Après 20 minutes de charge constante (100 clients effectuant 50 requêtes à la seconde) sur
le cluster de 4 nœuds, nous lui ajoutons 2 nouvelles instances tout en continuant la charge sur
les 4 premiers nœuds. Lorsque les nouvelles instances sont devenues actives (nous le vérifions
à l’aide de l’outil de supervision de Cassandra), nous arrêtons la charge pour immédiatement
la relancer mais en la répartissant cette fois-ci sur les 6 nœuds. Notons que durant toutes nos
expériences, le facteur de réplication est de 3.
Nous effectuons 4 fois ces expériences (expériences A, B, C et D) en faisant varier le
modèle de consistance et la charge de travail.
Expérience A
Le modèle de consistance de cette expérience est fort. Il est assuré par des écritures ONE
(c’est-à-dire que le système ne s’assure que de la réponse d’un seul nœud) et des écritures
réparatrices ALL (c’est-à-dire que les écritures recevront les informations de toutes les répliques
et reconstruiront la donnée). Cette configuration s’adaptera donc mal (en termes de
performance) à la charge de travail forte en lecture de cette expérience.
Configuration de l’expérience :
– Charge de travail : lectures fréquentes (section 4.3.3)
– Taille initiale du cluster : 4 nœuds
– Taille finale du cluster : 6 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : ALL
7. Nous avons rencontré ce problème lors des tests pratiques. Nous pouvons aussi confirmer, grâce à des
tests, que Cassandra est capable de gérer le retrait de plusieurs nœuds simultanément tant qu’il n’existe pas
de trafic intérieur vers ceux-ci.
8. Ce problème a été reporté plusieurs fois sur la mailing liste de Cassandra [7].
52

36.43
temps de réponse (millisecondes)
16.59
16.27
10
Le premier nœud
est intégré
Montée des temps
de latence
Les noeuds sont
actifs
Ajout de 2 nouveaux
noeuds
Δt
descente des temps
de latence
li
Les 2 nœuds sont
intégrés
Le système a assimilé
la modification
1200 1490
3600
temps (secondes)
Figure 4.9 – Elasticité observée sur Cassandra passant de 4 à 6 nœuds - Expérience A
Expérience µ ∆t(sec) λ α1 α2 π
A 0.039 300 220% 99 −336 138.7
Table 4.2 – Paramètres de l’expérience A
La figure 4.9 illustre l’expérience A et le tableau 4.2 la résume. Dans un premier temps,
nous observons l’expérience et la manière dont nos paramètres la décrivent et, dans un second
temps, nous déterminerons si cette transition tend à être élastique ou non.
On voit très clairement les 120 premières secondes durant lesquelles les performances ne
semblent pas s’altérer. Rappelons que l’anneau murmure durant ces 120 secondes, les nouveaux
nœuds ne sont pas encore intégrés et les anciens vérifient les informations du cluster (par
exemple, quel volume de donnée est stocké par chaque instance). Dès que les 2 nouveaux
nœuds sont intégrés, des données leur sont transférées et les temps de latence augmentent
donc. Durant la montée de temps de latence, on voit qu’il y a un premier pic (avant le pic
maximal) correspondant à l’intégration du premier nœud.
La montée des temps de latence est le résultat du trafic intérieur généré par le transfert
des données vers les nouveaux nœuds. Dès que les données sont transférées, le système jouit
des nouvelles instances et les temps de latence chutent immédiatement. Le fait que α1 est
près de 4 fois plus petit que α2 (en valeur absolue) exprime ce phénomène.
l ni
l nf
53

Rappelons que µ = 0.5 pour système parfaitement élastique µ = 0 pour un système
inélastique. Le constat de cette expérience n’est pas à la faveur de l’élasticité du système : on
remarque de le coefficient d’adaptation est plus proche de celui d’un système inélastique que
celui d’un élastique. En augmentant les ressources de ∆n = 50%, nous obtenons un gain en
performance de seulement 2%.
Le gain (µ) est donc très réduit et l’impact maximal est important 220%. Le facteur
de perturbation π nous indique que, durant la période d’adaptation, les temps de réponses
seront d’ordre général 139 fois supérieurs à ceux d’un système d’adaptant linéairement sur
cette période.
Ces derniers arguments nous indiquent que l’élasticité de cette transition n’est pas réelle.
En production, il ne serait pas intéressant d’effectuer une telle transition.
Expérience B
La charge de travail de cette expérience est différente de l’expérience A et composée principalement
d’écritures. Le modèle de consistance de cette configuration (écriture :ONE/lecture :ALL)
semble donc plus adapté à cette charge de travail vu que les écritures sont source de perte de
temps (elles doivent réparer les données pour assurer une consistance forte).
Configuration de l’expérience :
– Charge de travail : écritures fréquentes (section 4.3.3)
– Taille initiale du cluster : 4 nœuds
– Taille finale du cluster : 6 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : ALL
La figure 4.10 représente l’expérience B et le tableau 4.3 résume les paramètres des deux
expériences précédentes. Dans un premier temps, nous observons l’expérience et la manière
dont nos paramètres la décrivent et, dans un second temps, nous déterminerons si cette
transition tend à être élastique ou non.
Expérience µ ∆t(sec) λ α1 α2 π
A 0.039 300 220% 99 −336 138.7
B 0.34 1000 184% 24.4 −9.91 56.1
Table 4.3 – Paramètres des expériences A et B
Les variations de temps de latence sont plus grandes que celle de l’expérience A. Ce phénomène
s’explique par la méthode de stockage de Cassandra : les données sont consécutivement
placées en mémoire sur des fichiers de log, inscrites dans une memtable (in memory table) et
écrites sur disque dans uneSSTable (Sorted String Table). Lorsque 4 SSTables sont présentes
sur disque un nouvel index est créé [4]. On parle de phénomène de compactage. Ce mécanisme
à plusieurs étapes explique les variations plus grandes de ces temps de réponse.
On s’aperçoit que 40 minutes ne sont pas suffisantes au système pour connaitre une stabilisation
: on voit que, lors de la phase de stabilisation, les temps de réponse du système
continuent à diminuer pour se stabiliser plus tard. Nous avons choisi de limiter le temps
d’exécution pour étudier la transition. Il faut donc déterminer un temps de réponse moyen
sur cette stabilisation.
54

13.34
temps de reponse (millisecondes)
7.24
6.01
10
Ajout de 2 nouveaux
noeuds
Le système a assimilé
la modification
1200 2190
temps (secondes)
3600
Figure 4.10 – Elasticité observée sur Cassandra passant de 4 à 6 nœuds - Expérience B
On remarque aussi une adaptation beaucoup plus lente que celle de l’expérience A ; les 3
paramètres ∆t, α1 et α2 sont plus importants. Malgré tout, cette transition est plus élastique
que la précédente. Son coefficient d’adaptation (π = 0.34) se rapproche de celui d’un système
purement élastique (π = 0.5) et nous remarquons que les temps de latence après modification
tendaient à diminuer et donc à encore augmenter le score de π. Le pic de perte en performance
est plus petit que celui de l’expérience A et le paramètre de perturbation π nous indique que
les temps de latences sont globalement “seulement” 56 fois supérieurs à ceux qu’un système
s’adaptant de manière linéaire.
Dans un espace de production, cette transition sera intéressante à faire dans la mesure
où les gains sont importants et, même si le temps d’adaptation est long, les perturbations ne
semblent pas trop dérangeantes.
Expérience C
Cette expérience est similaire à l’expérience A. La différence se situe au niveau de leur
modèle de consistance. Même si la consistance est toujours forte, celle-ci est obtenue grâce à
des écritures et lectures au QUORUM.
Configuration de tests :
– Charge de travail : lectures fréquentes (section 4.3.3)
Δt
li
l ni
l nf
55

– Taille initiale du cluster : 4 nœuds
– Taille finale du cluster : 6 nœuds
– Facteur de réplication : 3
– Consistance en écriture : QUORUM
– Consistance en lecture : QUORUM
La figure 4.11 représente l’expérience B et le tableau 4.4 résume les paramètres des cette
expérience et ceux de l’expérience A. Dans un premier temps, nous observons l’expérience et
la manière dont nos paramètres la décrivent et, dans un second temps, nous déterminerons si
cette transition tend à être élastique ou non.
temps de reponse (millisecondes)
31.81
16.31
15.73
10
Ajout de 2 nouveaux
noeuds
Δt
Le système a assimilé
la modification
1200 1400
3600
temps (secondes)
Figure 4.11 – Elasticité observée sur Cassandra passant de 4 à 6 nœuds - Expérience C
Expérience µ ∆t(sec) λ α1 α2 π
A 0.039 300 220% 99 −336 138.7
C 0.071 200 195% 96.9 −536 130
Table 4.4 – Paramètres des expériences A et C
Cette expérience effectue des lectures au QUORUM. Le système ne doit donc attendre
que 2 réponses avant de retourner une entrée alors que dans l’expérience A, il devait attendre
les 3 répliques. La charge de travail de ces expérience est forte en lecture et l’expérience C
est donc plus performantes que l’expérience C. les paramètres µ, ∆t, λ et π présentent des
meilleurs résultats.
De manière similaire à l’expérience C, cette transition n’est pas élastique.
li
l nf
l ni
56

Expérience D
Cette expérience est similaire à l’expérience 1 à la différence que la consistance est cette
fois dite finalement consistante.
Configuration de tests :
– Charge de travail : lectures fréquentes (section 4.3.3)
– Taille initiale du cluster : 4 nœuds
– Taille finale du cluster : 6 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : QUORUM
temps de reponse (millisecondes)
18.69
16.1
15.31
10
Ajout de 2 nouveaux
noeuds
Δt
Le système a assimilé
la modification
1200 1580
temps (secondes)
3600
Figure 4.12 – Elasticité observée sur Cassandra passant de 4 à 6 nœuds - Expérience D
La figure 4.11 représente l’expérience B et le tableau 4.4 résume les paramètres de cette
expérience et ceux de des expériences A et C.
Expérience µ ∆t(sec) λ α1 α2 π
A 0.039 300 220% 99 −336 138.7
C 0.071 200 195% 96.9 −536 130
D 0.098 380 116% 129 −9.64 109
Table 4.5 – Paramètres des expériences A, C et D
li
l ni
l nf
57

De manière générale, on remarque que le relâchement de la consistance fait à cette expérience
favorise µ, λ et π (par rapport aux expériences A et C). Par contre, on remarque le
temps d’adaptation est plus important pour l’expérience C.
4.4.3 Descente à l’échelle
Analysons à présent comment Cassandra réagit au retrait d’une instance. Les expériences
E, F, G et G décrivent la transition d’un cluster Cassandra passant de 5 à 4 nœuds.
Le scénario est assez simple : nous attaquons le cluster de cinq nœuds durant vingt minutes.
Après ces vingt minutes, un nœud signale qu’il veut se retirer de l’anneau. Simultanément,
nous relançons la charge sur le cluster mais en ne ciblant plus que les quatre composantes
restantes de l’anneau.
Expérience E
Cette expérience est notre première expérience de descente à l’échelle. Elle simule une
charge forte en lecture et un modèle de consistance forte (lecture :ALL/écriture :ONE).
Configuration de tests :
– Charge de travail : lectures fréquentes (section 4.3.3)
– Taille initiale du cluster : 5 nœuds
– Taille finale du cluster : 4 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : ALL
La figure 4.13 représente l’expérience E et le tableau 4.6 résume ses paramètres.
Expérience µ ∆t(sec) λ α1 α2 π
E 0.556 290 264% 115 −472 147.6
Table 4.6 – Paramètres de l’expériences E
On remarque que les temps de latences grimpent lentement et puis chutent brusquement.
Nous avons surveillé cette opération et nous avons observé que cette chute des temps de
latence avait lieu immédiatement après que le nœud se soit retirer de l’anneau c’est-à-dire
lorsqu’il a transféré toutes ses données aux autres nœuds. Ceci explique donc que α1 est 4 fois
plus grand que α2 en valeur absolue.
λ vaut 264%. Cette forte perte en performance se justifie par le fait que le nœud se retirant
transfère ses données à 3 autres instances. Il n’y a donc plus qu’une seule instance qui n’est
pas perturbée par le trafic intérieur.
Expérience F
Cette expérience est similaire à l’expérience E. La différence est que celle-ci exécute la
charge de travail 2 (c’est-à-dire lourde en écritures).
58

temps de reponse (millisecondes)
40.76
17.15
15.43
10
Retrait d'un noeud
Δt
Le système a assimilé
la modification
1200 1480
temps (secondes)
3600
Figure 4.13 – Elasticité observée sur Cassandra passant de 5 à 4 nœuds - expérience E
Configuration de tests :
– Charge de travail : écritures fréquentes (section 4.3.3)
– Taille initiale du cluster : 5 nœuds
– Taille finale du cluster : 4 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : ALL
La figure 4.14 représente l’expérience F et le tableau 4.7 résume ses paramètres et ceux
de l’expérience E.
Expérience G
Expérience µ ∆t(sec) λ α1 α2 π
E 0.556 290 264% 115 −472 147.6
F 1.36 900 674% 64.8 −55.1 87.7
Table 4.7 – Paramètres des expériences E et F
Cette expérience est similaire à l’expérience E. La différence est son modèle de consistance
(écriture et lecture au quorum). La consistance reste forte.
li
l ni
l nf
59

31.93
temps de reponse (millisecondes)
6.03
4.74
10
Retrait d'un noeud
Δt
1200 2090
3600
temps (secondes)
Le système a assimilé
la modification
Figure 4.14 – Elasticité observée sur Cassandra passant de 5 à 4 nœuds -expérience F
Configuration de tests :
– Charge de travail : lectures fréquentes (section 4.3.3)
– Taille initiale du cluster : 5 nœuds
– Taille finale du cluster : 4 nœuds
– Facteur de réplication : 3
– Consistance en écriture : QUORUM
– Consistance en lecture : QUORUM
La figure 4.15 représente l’expérience F et le tableau 4.8 résume ses paramètres et ceux
de l’expérience E.
Expérience H
Expérience µ ∆t(sec) λ α1 α2 π
E 0.556 290 264% 115 −472 147.6
G 1.38 270 254% 136 −210 153
Table 4.8 – Paramètres des expériences E et G
Cette expérience est similaire à l’expérience E. La différence est qu’elle modélise une
consistance forte via le modèle de consistante écriture :ONE/lecture :QUORUM.
li
l ni
l nf
60

temps de reponse (millisecondes)
38.04
19.14
15
10
Retrait d'un noeud
1200
Δt
Le système a assimilé
la modification
1470
temps (secondes)
Figure 4.15 – Elasticité observée sur Cassandra passant de 5 à 4 nœuds - Expérience G
Configuration de tests :
– Charge de travail : lectures fréquentes (section 4.3.3)
– Taille initiale du cluster : 5 nœuds
– Taille finale du cluster : 4 nœuds
– Facteur de réplication : 3
– Consistance en écriture : ONE
– Consistance en lecture : QUORUM
Expérience µ ∆t(sec) λ α1 α2 π
E 0.556 290 264% 115 −472 147.6
G 1.38 270 254% 136 −210 153
H 1.18 170 369% 452 −530 150
4.4.4 Analyse des résultats
Table 4.9 – Paramètres des expériences E, G et H
Dans cette section, nous analyserons les résultats de nos expériences. Ces résultats sont
repris dans la table 4.10.
li
l ni
l nf
3600
61

temps de reponse (millisecondes)
55.85
18.73
15.15
10
Retrait d'un noeud
Δt
1200 1370
3600
temps (secondes)
Le système a assimilé
la modification
Figure 4.16 – Elasticité observée sur Cassandra passant de 5 à 4 nœuds - Expérience H
Le cluster de test
La première remarque que nous tenons à faire est que le cluster de test n’est pas purement
homogène. Il est composé de quatre nœuds de type A et de deux nœuds de type B. Dans notre
cas d’étude, nos différents paramètres ne sont pas utilisés pour afficher des performances d’un
système mais pour servir de critères de comparaison sur l’impact du choix d’architecture sur
nos différents paramètres.
Dans ce contexte, vu que les scénarios sont reproduits de manière analogue sur chaque
test, ces différences entre les nœuds et leurs caractéristiques ne sont pas significatives dans
notre étude. Le tableau 4.11 résume toutefois, les configurations des deux types de serveurs.
Le coefficient d’adaptation µ
Une première constatation est que µ est plus grand pour les systèmes descendants que pour
les systèmes montants à l’échelle. Ceci peut s’observer en regardant les couples d’expériences
(A,E), (B,F), (C,G) et (D,H) qui partagent exactement les mêmes charges de travail. Cette
constatation peut être résumée simplement de la façon suivante : la perte en performance
due au retrait d’une instance d’un cluster de cinq nœuds est plus importante que le gain en
performance d’une augmentation de deux nœuds d’un cluster composé initialement de quatre
instances. Ceci est assez sévère mais n’est pas étonnant ; il y a deux raisons à cela :
– Lors de l’ajout de nœuds, Cassandra décharge les plus remplis en donnant la moitié de
li
l ni
l nf
62

Expérience µ ∆t(sec) λ α1 α2 π
A 0.039 300 220% 99 −336 138.7
B 0.34 1000 184% 24.4 −9.91 56.1
C 0.071 200 195% 96.9 −536 130
D 0.098 380 116% 129 −9.64 109
E 0.556 290 264% 115 −472 147.6
F 1.36 900 674% 64.8 −55.1 87.7
G 1.38 270 254% 136 −210 153
H 1.18 170 369% 452 −530 150
Table 4.10 – Résumé des paramètres des expériences A-H
type A type B
Processeur AMD Opteron Dual Core -2,2 Ghz AMD Athlon II X2 255 - 3,1 Ghz
Mémoire RAM 8 Gb 8 Gb
OS Ubuntu 10.04.2 LTS Ubuntu 10.04.2 LTS
Connection Gigabit ethernet interconnect
Table 4.11 – Configuration du cluster de test
leurs données aux nouvelles instances de l’anneau. Le retrait ne respecte pas du tout
le même schéma, le nœud qui se retire de l’anneau est choisi par un acteur humain
(aléatoirement). Il peut en résulter un nouvel anneau moins équilibré et donc moins
performant.
– Nous ajoutons deux instances qui, lorsque que l’anneau décide qu’elles sont joignables,
responsables de données, ne sont pas forcement stabilisées. Elles n’ont pas forcément
encore bien mis les données en cache et sont peut-être encore victimes de phénomènes
de compactage et de mise en mémoire.
La valeur de µ est critiquable. Ceci vient des temps de latence moyens avant (lni ) et après
modification (lnf ) :
– Premièrement, (lni ) et (lnf ) les temps de latence moyens sont pris sur une durée de temps
très réduite. On ne se repose pas sur une notion forte de système stabilisé pour tirer la
moyenne. On peut donc observer à l’expérience 3 (figure 4.11) que sur des systèmes non
stables, ces moyennes sont sujettes à controverse 9 .
– Secondement, lnf est la moyenne arithmétique des temps de latences de sur l’intervalle
[tm + ∆t, tf ]. Or ∆t est sujet à interprétation humaine, ceci peut donc discréditer lnf
vu que déterminer ∆t est assez difficile.
Cette critique est inhérente à notre approche : notre but était de déterminer les effets
immédiats de la modification sur le système en transition. Remarquons aussi que µ peut
sembler faible (resp. fort) pour l’ajout (resp. retrait) d’instance. Ceci est dû au fait que lors
de la phase d’attaque, le système est stable tandis que lors de la phase de stabilisation, le
système n’est pas encore stabilisé et présente donc des performances plus faibles.
9. Pour calculer ln i et ln f , la médiane a été considérée mais dans nos expériences, médianes et moyennes
restent fort proches.
63

La forme de l’adaptation (α1, li, α2)
Notre approche intuitive de caractériser le comportement du système via l’impact maximal
λ et les angles α1 et α2 semble proche du comportement de la majorité des transitions.
Pour la charge de travail forte en lecture, le système met le double de temps pour atteindre
le pic (de perte de performance) que pour que ses temps de réponse ne soient plus affectés
par la modification (|α1| > |α2|).
Lorsque le cluster murmure l’arrivée ou le retrait de nœuds, il calcule le volume de données
que les instances vont devoir transférer puis commence le transfert. Or l’application continue à
effectuer des écritures. Une fois le volume initial transféré, les nœuds devront encore échanger
les données écrites durant ce premier transfert.
Le temps d’adaptation ∆t
On remarque que globalement, ∆T est plus petit pour le retrait des instances. Ceci s’explique
par le nombre de nœuds dérangés par les opérations. Dans un premier temps, durant la
montée des temps de latence, le nœud qui se retire va rediriger ses données vers 3 instances (3
étant le facteur de réplication). Ensuite, une fois que l’instance s’est retirée, les trois instances
doivent se stabiliser. Lors de l’ajout de 2 nœuds, ceux-ci perturbent 2 autres nœuds durant
toute la période d’adaptation. Il y a donc 4 nœuds qui sont dérangés. Ce qui explique que le
systèmes est dérangé plus longtemps. Remarquons que les coefficients de descentes α2 sont
globalement plus grands (en valeur absolue) pour les retraits que pour les ajouts (exception
faite du couple d’expériences (C,G)).
La perturbation d’adaptation π
L’idée de ce facteur de perturbation π était de fournir une valeur sans dimension caractérisant
les perturbations liées à la modification du système. La surface qu’il représente est
la variation des performances du système par rapport à un système qui passerait à l’échelle
de manière linéaire durant le temps d’adaptation. Plus précisément, un système passant à
l’échelle de manière linéaire durant la période d’adaptation aura une perturbation de 1. Un
système s’adaptant plus vite à la modification qu’un système linéaire (ceci est considération
purement théorique) aurait une perturbation comprise entre 0 et 1.
L’explication intuitive de ce facteur est que plus grand il sera, plus la perturbation d’adaptation
aura un effet négatif sur les performances durant la période d’adaptation. Rappelons
que la perturbation d’adaptation est indépendante du temps d’adaptation. Il est donc tout
à fait possible d’avoir une modification entrainant un temps d’adaptation très faible et une
perturbation très forte (l’expérience 8 en est un exemple).
Ce paramètre représente bien l’impact de la perturbation, on le remarque dans toutes
nos expériences, plus la perturbation est importante, plus π sera grand. Malheureusement,
nous ne disposons pas d’assez de valeurs pour essayer de donner des ordres de grandeurs qui
démarqueraient les scores acceptables des scores inacceptables.
64

4.5 Les travaux de Thibault Dory
Thibault Dory, étudiant à l’Université Catholique de Louvain, a aussi étudié durant cette
année l’élasticité des BDs sur cloud. Il propose, dans ce contexte, une étude comparative
de HBase, Cassandra et MongoDB [41]. Cette étude apporte des résultats intéressants. Nous
expliquerons dans cette section sa méthodologie dans le but de pouvoir rendre compréhensible
et d’exploiter ses résultats et réflexions. Nous pensons que l’analyse poussée de ses travaux
couplée avec les nôtres apporte des aspects plus techniques et pratiques qui compléteront
notre approche.
4.5.1 Méthodologie
La méthodologie utilisée est une simplification de Wikipedia : un ensemble d’articles est
chargé depuis Wikipédia. Cet ensemble servira ensuite de jeu de données. L’idée générale
est d’insérer ces articles (identifiés à l’aide d’une clé unique) dans un SGBD et d’ensuite
soumettre le système à un nombre de requêtes en parallèle qui effectuent de manière aléatoire
des opérations de mises à jour et de lectures.
Contrairement à notre approche, cette étude a choisi comme métrique le temps nécessaire à
effectuer l’ensemble des opérations (elle effectue 10 fois l’ensemble des opérations et considère
la moyenne de ces temps). Pour un cluster composé initialement de N nœuds, le système sera
attaqué parallèlement par N ensembles d’opérations.
Durant ces expériences, le facteur de réplication sera fixé à 3 et la consistance sera forte.
Les systèmes seront déployés sur des instances RackSpace 4GB. Le volume de données est
voulu assez large pour ne pas pouvoir être contenu en mémoire RAM 10 .
4.5.2 Définitions
L’élasticité
L’élasticité est vue comme la caractérisation de la réaction du cluster lorsqu’on ajoute/retire
des nœuds. Elle est décrite par deux propriétés : le temps que prend le cluster à se stabiliser
et l’impact en performance.
Selon T. Dory [41], un système peut être défini comme stable lorsque les variations des
temps de traitement de plusieurs ensembles de requêtes sont équivalentes aux variations d’un
système reconnu comme stable (c’est-à-dire tel qu’il n’y a plus de transfert de données entre les
différents nœuds du cluster). En pratique, un système stable lorsque les 5 derniers ensembles
de requêtes ont des variations inférieures à la variation de l’ensemble précédent.
Dans le but de pouvoir comparer l’élasticité de systèmes fort différents, cette approche
propose une formule définissant l’élasticité tel un unique paramètre sans dimension. Voici sa
définition :
Définition 18.
Elasticity =
A+B
(Rt1+RT 2)∗(Av1+Av2)
10. Pour plus de détails sur les spécifications des SGBDs déployés, nous vous invitons à la lecture de [41]
65

Comme illustré en figure 4.17, la surface A décrit l’augmentation du temps résultant de la
modification tandis que la surface B décrit les déviations standard des ensembles de requêtes.
Rt1 et Rt2 sont les temps moyens de réponse pour d’une requête sur le système stable avant
et après la modification. Av1 et Av2 sont eux les temps moyens de traitement du système
stable d’un ensemble de requêtes avant et après sa modification. Si cet ensemble est composé
de 1000 requêtes et le cluster d’un nombre initial de six nœuds, Av1 = 1000/6 ∗ Rt1. Notons
que ces ensembles de requêtes sont toujours composés de 80% de lectures. Nous discuterons
de la pertinence de cette définition dans les sections suivantes.
La montée à l’échelle
Figure 4.17 – Surfaces utilisées pour caractériser l’élasticité[41]
Dans cette approche, la capacité de monter à l’échelle (scalabilty en anglais) est définie
comme le changement de performance lorsque le système résultant de la modification est
stabilisé. Il la caractérise grâce à un paramètre sans dimension suivant la définition suivante :
Définition 19.
ScalabilityN = Average2N −AverageN
AverageN
Plusieurs informations doivent être apportées à ce niveau : cette approche n’étudie que la
montée à l’échelle des systèmes qu’elle limite, pour différentes raisons techniques, à doubler
la taille du cloud. Ces études nous montrent des systèmes passant de 6 à 12, de 12 à 24 et de
24 à 48 nœuds. Le scénario est le suivant : charger un système de N nœuds avec N ensembles
de requêtes, attendre la stabilisation, doubler le nombre de nœuds et attendre la stabilisation
(avec la même charge en continu). Lorsque le système est stable, doubler la taille des données
et charger avec 2N ensembles de requêtes (voir figure 4.18).
AverageN (resp. Average2N) correspond au temps moyen de réponses pour une BD de N
(resp. 2N) nœuds attaquée par N (resp. 2N) ensembles de requêtes. Un système qui monterait
parfaitement à l’échelle devrait avoir une montée à l’échelle égale à 0. Ce facteur sert donc
à mesurer la capacité à monter à l’échelle et n’est donc pas comparable à notre coefficient
d’adaptation.
66

4.5.3 Résultats
Considérations supplémentaires
Figure 4.18 – T. Dory - Scénario de tests [41]
Les trois systèmes MongoDB , Cassandra et Hbase proposent des architectures fort différentes.
Or, nous l’avons souligné précédemment, le rôle des instances ajoutées va influer
fortement sur l’effet de cette modification. Dans cette section, nous décrirons les choix faits
lors de ces tests.
– Cassandra est le plus simple à décrire : vu que chaque nœud est similaire, il n’y a qu’un
type de nœud possible comme ajout. Soulignons que dans ces tests, contrairement aux
nôtres, ne répartissent pas la charge sur les nœuds fraîchement ajoutés à l’anneau.
– MongoDB réplique les données au sein de ses shards. Dans la configuration de ses
tests, T. Dory regroupe les nœuds par 3 pour former des shards respectant le modèle de
réplication par pairs (et avoir un facteur de réplication de 3). Il faut donc considérer que
les nœuds recevant les requêtes ne représentent qu’un tiers des nœuds du cluster. Les
serveurs de configuration seront aussi hébergés par les trois premiers nœuds du cluster.
– Hbase est plus complexe que les deux premiers systèmes d’un point de vue architectural.
Dans ces tests-ci, un même nœud est chargé du service maître Hbase, du service serveur
de nom de Hadoop et de Zookeeper. Toutes les autres instances auront la configuration
suivante : 2GB de mémoire sont alloués au serveur de région de Hbase et 1GB est alloué
au serveur de données de Hadoop.
Descriptions
La figure 4.19 représente le comportement de Cassandra passant de 12 à 24 nœuds. Elle
représente une série temporelle des temps moyens pour traiter des séries d’ensembles de requêtes.
Les segments verticaux représentent les déviations standards de ces séries.
4.5.4 Analyse
Les apports de cette étude sont nombreux et de qualité. Dans cette section, nous reprendrons
quelques analyses fortes intéressantes qui ne seront pas reprises dans le prochain
chapitre.
67

Figure 4.19 – Elasticité observée sur Cassandra passant de 24 à 48 nœuds[41]
Phénomène de compactage
Les différents systèmes présentés au chapitre 3 présentent des politiques différentes quant
à la gestion de la mémoire :
– Chez Cassandra, toutes les écritures sont inscrites dans un fichier de log, puis l’information
est inscrite dans une memtable. Lorsque celui-ci est plein, les données sont écrites
dans une SSTable. Chaque fois, que 4 SSTable sont présentes sur disque, un compactage
a lieu : les données sont reconstruites et un nouvel index est créé [4]. C’est à ces moments
de compactage qu’ont lieu les grosses écritures sur disque. Le comportement de Hbase
est plus ou moins similaire (ce système de gestion de mémoire est repris à BigTable qui
est à l’origine de Cassandra et Hbase ).
– Chez MongoDB, la politique est différente. MongoDB opte pour la pré-allocation d’espace.
La mise en disque est une décision laissée au système d’exploitation. Par défaut,
la mise en disque est périodique (toutes les 60 secondes) Mongo pré-alloue des grands
fichiers lorsqu’il a besoin de grands espaces c’est-à-dire lorsqu’il doit écrire beaucoup
de données, ce qui est typiquement le cas lorsqu’une nouvelle instance doit stocker un
grand nombre d’entrées [41].
Ces phénomènes de compactage ne sont pas négligeables. Sur les figures 4.20 et 4.21, on
voit que les variations en performance sur un cluster de 6 nœuds sont plus significatives que
ceux de la variation due au dédoublement du cluster.
Il ne s’agit pas d’occulter ces phénomènes de compactage car ils sont inhérents aux BDs.
Remarquons que la différence de variation de performance (les déviations standards) entre
les figures 4.20 et 4.21 est due à la taille des memtable : 256MB pour Hbase et 64MB pour
Cassandra. Chez Cassandra, ces phénomènes de compactage ont donc lieu plus souvent, ce
qui entraine cette variation de performance.
68

Figure 4.20 – Elasticité observée sur Cassandra passant de 6 à 12 nœuds[41]
Figure 4.21 – Elasticité observée sur Hbase passant de 6 à 12 nœuds[41]
Dans ces tests, il y a 80% de lecture, ce qui fait que MongoDB ne doit donc pas pré-allouer
souvent des nouveaux espaces. Sa mise en disque périodique suffit. MongoDB reste donc plus
stable que les deux autres systèmes (voir figure 4.22).
Taille du cluster
Ces tests mettent en évidence que la taille du cluster a une forte influence sur son élasticité.
Premièrement, on se rend compte que plus le cluster est grand, moins l’impact du phénomène
69

Figure 4.22 – Elasticité observée sur MongoDB passant de 6 à 12 nœuds[41]
Figure 4.23 – Elasticité observée sur Hbase passant de 12 à 24 nœuds[41]
de compactage est significatif comparé aux perturbations dues à la modification (comme le
montrent les figures 4.19 et 4.23).
Néanmoins, avec un système centralisé comme MongoDB, la taille du cluster peut influer
sur son temps de stabilisation. La figure 4.24 montre une augmentation de 92% du temps
de nécessaire à stabilisation d’un cluster MongoDB passant de 12 à 24 nœuds par rapport
au temps requis par un cluster passant de 6 à 12 nœuds). Ceci est du à deux facteurs : le
premier est que les nouvelles instances traitent les requêtes des clients immédiatement après la
réception du premier morceau (or la taille de ces morceaux est seulement de 200MB). Les nou-
70

Figure 4.24 – Elasticité observée sur MongoDB passant de 12 à 24 nœuds[41]
velles instances sont donc responsables de gérer les requêtes clientes alors même qu’elles sont
surchargées de trafic intérieur. Ce qui entraine une perte en performance (le trafic intérieur
nécessitant de nouvelle pré-allocation d’espace). Le second facteur est que la redistribution
des données est gérée par un seul processus qui doit donc gérer les morceaux de chaque nœud
et devient donc vite un goulot d’étranglement.
La gestion des nouvelles instances
Les résultats de ces expériences nous montrent aussi l’influence certaine de la gestion
d’ajout d’instances du système sur son élasticité (la table 4.12 résume les différents paramètres
de ces expériences).
Modification Système Montée à l’échelle Temps de stabilisation (min)
6 à 12 nœuds Cassandra −0.06 141
Hbase 0.05 12, 3
MongoDB 0.78 183
12 à 24 nœuds Cassandra −0.28 201
Hbase 1, 68 17, 2
MonogDB inconnu 352
Table 4.12 – Influence de la politique d’ajout d’instance sur l’élasticité [41]
Hbase tire profit de la non-redistribution des données à la couche HDFS pour diminuer
ton temps de stabilisation. Mais il y a un prix en performance. On voit que Cassandra tire
plus profit des nouvelles instances (ses paramètres de montée à l’échelle sont meilleurs). Les
figures 4.25 et 4.23 nous montrent ces différences.
La politique de MongoDB (utiliser directement les ressources) est la source de son mauvais
comportement élastique. Celui-ci résulte du fait que les nouveaux nœuds surchargés de trafic
71

Figure 4.25 – Elasticité observée sur Cassandra passant de 12 à 24 nœuds[41]
interne sont utilisés pour les requêtes clientes 11 . Cet effet collatéral se révèle important :
MongoDB présente des résultats nettement inférieurs et à Cassandra et à HBase.
4.6 Conclusion - Comparaison
Dans cette section, nous tentons une critique comparative des deux expérience présentées
précédemment. Le but de cette section est de pouvoir identifier les différences entre ces deux
approches, identifier leurs points forts et faibles pour proposer une nouvelle solution de test
mettant en avant les avantages des deux propositions.
L’approche de T. Dory tente de fournir un facteur de comparaison de l’élasticité de différentes
BDs pour cloud. Il l’a donc voulu indépendant de leurs performances (qui était les
différencie à l’origine). Notre approche est plus analytique : son but est d’appréhender, de
comprendre le principe d’élasticité du SGBD. A ce titre, elle ne nécessite pas de critères
rigoureux pour définir ces paramètres. En effet, c’est leur interprétation au regard de l’expérience
qui est importante. Le scénario de test est, lui, défini de manière rigoureuse, ce qui le
rend reproductible et automatique.
La principale différence entre notre étude et celle de T. Dory est donc leur approche :
lorsque la première étudie le système en transition, la seconde décrit le système en régime.
Les deux approches avancent des points de vue très intéressants :
– l’approche en transition a pensé l’élasticité comme une propriété dynamique et donc
a voulu la réduire dans le temps. L’idée sous-jacente était que, placé dans un environnement
de production, les répercussions immédiates de la modification du système ne
sont pas négligeables et doivent être prises en compte.
11. Ce problème a déjà été discuté aux sections 4.5.4 et 4.5.4
72

– L’approche en régime prend en compte que les temps de réponse de ces systèmes peuvent
varier fortement d’un instant à l’autre (par exemple du au phénomène de compactage).
Dans un environnement de production, il est donc important de savoir comment le
système se comportera de manière générale (à long terme) et il est aussi important de
savoir le temps nécessaire à ces systèmes pour se stabiliser.
4.6.1 Critiques de l’approche comparative
L’idée d’une étude comparative est de fournir un unique point de comparaison pour tous
les différents systèmes. Ceci va en opposition avec l’étude analytique qui va tenter de dégager
un nombre plus important de paramètres pour avoir une meilleure vue de son comportement.
Néanmoins, l’étude de T. Dory nous fournit une liste de paramètres qui peuvent aussi être
intéressants (moyennant quelques modifications) pour étendre notre étude analytique : l’élasticité,
la montée à l’échelle et le temps de stabilisation. Ce dernier est le temps nécessaire au
système pour passer d’un état initial stable à un état final stable.
On remarque directement l’analogie avec nos trois paramètres : la perturbation, le coefficient
et le temps d’adaptation. Avant d’ identifier leurs différences, notons que de manière
globale, la tendance sera à parler de stabilisation pour le scénario en régime et d’adaptation
pour le scénario de transition.
Le temps de stabilisation
Tel que défini dans [41], ce facteur est directement analysable. Il ne faut donc lui apporter
aucune modification. Néanmoins, nous soulignons le fait que la définition d’un système stable
proposée dans [41] ne semble pas être suffisante pour assumer des tests sans intervention
humaine. En effet, les SGBDs qui ne sont pas encore stables fournissent déjà des temps de
réponses similaires (comme le montrent nos expériences). La méthodologie proposée par T.
Dory nécessite l’intervention d’un acteur humain pour déterminer si le système est stable et
si on peut lancer une nouvelle charge.
Le passage à l’échelle
Tel que défini dans [41], le passage à l’échelle diffère de notre coefficient d’adaptation dans
3 aspects différents :
1. le fait qu’il est lié à des systèmes stables.
2. le fait qu’il ne considère pas le coût de la modification en terme de structure (∆n défini
en section 4.2).
3. le fait que les moyennes sont celles des temps de latence de systèmes dont la charge de
travail et le volume de données sont proportionnels à la taille du cluster.
La première différence est voulue ; elle provient de la différence entre adaptation et stabilisation.A
nos yeux, le coût en terme de ressources doit être considéré, nous proposons donc de
le rajouter à un nouveau facteur : le coefficient de stabilisation. La troisième différence provient
du fait que le passage à l’échelle, tel que défini dans [41], n’est pas pensé dans l’optique
d’être un facteur décrivant l’élasticité. Dans une optique en transition, il s’agira de ne plus
varier la charge de travail et le volume de données.
73

L’élasticité
Tel que défini dans [41], ce facteur prend en considération le temps de stabilisation, il sera
d’autant plus grand que ce temps de stabilisation sera long. Or, dans une nouvelle approche
comparative, où l’on prendrait en compte les deux facteurs précédents (temps et coefficient
de stabilisation) pour caractériser l’élasticité, ce facteur peut être repensé vers un nouvelle
définition décrivant les perturbations du système jusqu’à sa stabilisation : les perturbations
de stabilisation.
4.6.2 Vers une nouvelle approche
Nous proposons dans cette section une nouvelle approche analytique combinant les approches
en transition et en régime.
Etude de la stabilisation
La première étape de cette nouvelle méthodologie consiste à étudier l’élasticité du système
passant d’un état stable à un autre état stable via le scénario de T. Dory (temps de
traitement moyens sur des jeux d’ensembles de requêtes et charge constante). De ce scénario,
nous pourrons mesurer les 3 paramètres suivants : le temps, le coefficient et la perturbation
de stabilisation.
Définition 20 (Temps de stabilisation ∆T ).
Le temps de stabilisation est le temps nécessaire à un système stable pour se stabiliser
après à une modification de son nombre d’instances.
Soit ni et nf les nombres initial et final d’instances, Li et Lf les temps de traitement
moyens du système de taille i et f, nous pouvons définir le coefficient de stabilisation comme :
Définition 21 (Coefficient de stabilisation Θ).
Θ =
L f −L i
L i
∆n
Soit N et M, les surfaces décrites à la figure 4.26, la perturbation de stabilisation se définit
comme :
Définition 22 (Perturbation de stabilisation Π).
Π = N
M
Cette première étape de l’expérience permettra de faire ressortir les caractéristiques de
la modification du système en régime. L’utilisateur en retirera l’information sur le gain, sur
le temps nécessaire pour atteindre ce gain et sur l’importance des perturbations durant ce
temps de stabilisation.
74

Figure 4.26 – Perturbation de la période de stabilisation - Surfaces N & M
Etude de l’adaptation
Les paramètres proposés dans notre première approche sont parlants : le temps d’adaptation
nous prévient durée pendant laquelle le système va être totalement perturbé par la
modification. L’impact maximal nous prévient du pic de pertes en performance durant cette
adaptation et les coefficients α1 et α2 nous indiquent quelle sera la tendance de cette adaptation
(les performances diminueront-elles vite pour croître ensuite lentement ou mettront-elles
du temps à décroitre pour augmenter très vite). La perturbation d’adaptation nous indiquera
si la perturbation sera importante en comparaison avec les temps de latence moyens (et ce
durant tout le temps d’adaptation).
Soit τ la durée totale de cette seconde étape de l’expérience, le coefficient d’adaptation
donnera à l’utilisateur une idée du gain fait par la modification durant cette période τ. Sur un
cluster de 5 nœuds, τ était fixé à 60 minutes sur base de tests préliminaires. La première étape
de cette nouvelle méthodologie servira à établir τ pour chaque cluster différent. τ pourra par
exemple être défini comme 150% de ∆T et dès lors fixer le début de la modification tm à 33%
de τ.
Cette deuxième étape permettra d’étudier le comportement de la modification du système
en transition(de manière similaire à notre première approche).
75

Chapitre 5
Influence des choix techniques sur
l’élasticité
Dans ce chapitre, nous tentons de cerner l’influence des différents composants, choix techniques
empruntés par les SGBDs sur leur élasticité. Ceci permettra de mettre en avant les
concessions qu’il faut faire par rapport à l’élasticité lorsqu’on choisit son SGBD. Commençons
ces considérations avec les dimensions décrites dans l’étude comparative du chapitre 3.
5.1 Modèle de données
Les différents modèles de données peuvent être classés en fonction de leur complexité :
la figure 5.1 les ordonne par complexité croissante. Cette complexité représente à la fois les
mécanismes internes nécessaires à stocker un tel modèle mais aussi la complexité du point
vue utilisateur pour modéliser l’architecture des données. On remarquera que plus un modèle
est complexe, plus son utilisation ultérieure sera facile.
clé-valeur
document
entrées extensibles
Voldemort MongoDB Cassandra
Hbase
SQL
Complexité du modèle de données
MySQL Cluster
VoltDB
Figure 5.1 – Complexité des modèles de données
Les modèles clé-valeur, orientés documents et entrées extensibles ont été pensés pour que
les données puissent être partitionnées (sur base de leur clés) et distribuées de la manière la
plus simple possible. Cette facilité diminuera théoriquement le temps d’adaptation. Remarquons
aussi que les entrées sont indépendantes entre-elles. Chaque nœud est responsable de
76

ses données et n’a pas à se soucier des autres instances. On peut dès lors exploiter pleinement
les performances de chaque nœud individuellement, le coefficient d’adaptation est donc
meilleur pour un modèle plus simple.
Les modèles SQL eux restent plus durs à partitionner et leur distribution est moins efficiente
: sa richesse (index secondaires, clés voisines) entraine de lourds mécanismes internes
pour gérer les données. Ces mécanismes entrainent donc un temps d’adaptation plus long.
Cette modélisation est aussi un frein au passage à l’échelle : premièrement, les différentes
données sont liées (par exemple via des clés voisines) ce qui empêche une redistribution efficace
des requêtes ; secondement, chaque entrée d’une table a une taille pré-définie et peut donc
contenir des champs vides qui devront être stockés et traités. Toute la puissance de chaque
instance ne peut donc être dédiée exclusivement au traitement des données (effectives) qu’elle
stocke.
Des systèmes tels que les SQL-MR et les SQL orientés colonnes (Vertica, MonetDB)
confirment cette concession à faire entre la complexité du modèle de données et le passage à
l’échelle : toutes ses solutions se basent sur un modèle SQL épuré.
5.2 Modèle de consistance
5.2.1 Finalement ou fortement consistant
Dans un système décentralisé, comme Cassandra, le modèle finalement consistant favorise
nettement le temps d’adaptation pour tout type d’application (forte en lectures ou écritures).
Dans ce modèle, la donnée sera finalement consistante (c’est-à-dire que finalement après plusieurs
opérations de lecture, la donnée sera à jour). Les temps de réponses du système vus par
l’application seront en fait les temps de ses instances les plus performantes. Les nœuds qui
subissent les modifications et qui connaissent donc un fort trafic seront moins performants et
pourront peut-être éviter les requêtes de l’application cliente. Ils pourront dès lors se stabiliser
et agir normalement plus vite.
Le coefficient d’adaptation est avantagé par une telle politique : qui dit ajouter des nœuds,
dit soulager certains membres d’une partie de leur charge. Ces instances moins chargées
auront donc des temps de performances meilleurs. Cette nouvelle répartition des données
peut entrainer la libération de nœuds plus performants que ceux que l’application contactait
précédemment. Dans un modèle finalement consistant, ceci aura donc un effet positif sur les
temps moyens de réponse du système et entrainera donc un coefficient d’adaptation meilleur
que pour une consistance forte.
Dans un système, comme MongoDB, la consistance pourrait être relâchée grâce à une
redirection des lectures sur les nœuds esclaves. Ceci n’aurait pas d’effet sur le temps d’adaptation
vu que ça n’a pas d’effet sur l’architecture même du cluster. Par contre, ceci aura très
certainement un effet positif sur le coefficient d’adaptation vu que le système tirera avantage
de toutes les nouvelles instances tandis que dans une consistance forte le système ne tirera
profit que de 1/R% des nouvelles instances (où R est le facteur de réplication).
5.2.2 Le verrouillage d’entrée et la consistance transactionnelle
Ces deux modèles sont bien plus stricts que les premiers, ils permettent de bloquer une ou
plusieurs entrées durant la modification de celles-ci. Bloquer une entrée ou une série d’entrées
77

(pour les déplacer ou pour les modifier) la rend inaccessible et donc rend le temps d’adaptation
plus long. Du point de vue du coefficient d’adaptation, le modèle de verrouillage d’entrée
n’est pas problématique, il atteint de la même façon les performances avant et après la modification.
Par contre, la consistance transactionnelle qui bloquera un ensemble d’entrées dans
potentiellement plusieurs nœuds est une perte de performance. Plus le cluster est grand, plus
les risques de transactions agissant sur plusieurs nœuds sont importants et donc on peut dire
que la consistance transactionnelle est un point négatif vis-à-vis du coefficient d’adaptation.
5.3 Réplication de données
Dans cette section, nous traitons l’influence du mode de réplication sur l’élasticité du
système. Nous tenons à souligner le fait que nous étudions l’influence du mode de réplication
sur l’élasticité du cloud et pas sur les performances du système. Nous faisons l’hypothèse
que la modification n’influence pas le mode de réplication (pas de changement de facteur de
réplication par exemple).
La réplication synchrone est bloquante : pour valider la modification d’une entrée, le système
devra s’assurer que toutes les répliques aient bien effectué la modification. Si cette modification
fait intervenir un nœud en cours de modification, celle-ci le ralentira. La réplication
synchrone a donc un effet négatif sur le temps d’adaptation.
Si l’influence de la réplication synchrone est certaine sur les performances du système (positive
pour les lectures, négative pour les lectures), son influence sur le coefficient d’adaptation
est plus difficile à décrire. Il ne semble pas y en avoir.
5.4 Modèle de requêtes
Le modèle de requêtes est un argument de vente très important, plus riche il sera, plus
intéressant il sera, plus l’utilisateur pourra profiter largement de sa richesse. Néanmoins, de
riches modèles de requêtes se basent sur de riches modèles de données qui entrainent avec
eux les problèmes décrits plus haut (section 5.1). De plus, les modèles riches ont tendance
à proposer des requêtes similaires à GROUP BY de SQL. Ces requêtes d’agrégation sont
extrêmement complexes et ne peuvent être optimales pour tout cas d’utilisation. Si elles
joignent plusieurs nœuds du cluster, le risque de contacter des nœuds en cours de modification
est plus grand. Ceci entraine un temps d’adaptation plus grand.
D’autre part, plus le modèle de requête est poussé, plus les mécanismes internes devront
l’être aussi (index secondaires, etc.). Il sera dès lors plus dur de tirer parti de la pleine puissance
de chaque composant du cluster indépendamment. De manière similaire aux critiques faites
aux langages de haut niveau, on peut critiquer ces fonctions en leur prétextant qu’elles doivent
être générales et des fonctions plus spécifiques, faites au cas par cas seraient capables de tirer
avantage des différents composants. De telles fonctions peuvent être source de perte en profit
vu que l’utilisateur les utilisera de manière transparente et risquera d’appeler des requêtes
utilisant de nombreuses instances (le coefficient d’adaptation sera donc moins bon).
La réponse à la considération précédente est la possibilité de déployer des fonctions MR
sur le système. Cette possibilité est donc un facteur positif sur le coefficient d’adaptation. Par
contre, l’effet peut être négatif sur le temps d’adaptation ; l’utilisateur utilisant ces fonctions
en tirera profit pour utiliser un maximum de nœuds, ce qui augmente le risque de joindre une
instance subissant une modification.
78

Quelques autres dimensions doivent être prises en compte lorsqu’on parle d’élasticité.
5.5 Ajout d’instances
La façon dont le SGBD va gérer l’ajout des nœuds dans le cluster va être un facteur très
important dans son élasticité. Parmi les différents scénarios possibles, nous distinguons quatre
modèles différents :
– Le premier (celui deMongoDB consiste à directement assimiler la nouvelle instance et
d’en faire usage “immédiatement”. Nous le qualifierons d’actif.
– Le deuxième (celui de Hadoop), consiste à ne rien faire à l’ajout d’instances ; c’est-à-dire
considérer l’instance comme faisant partie du cluster et continuer à agir comme avant.
Nous qualifierons ce modèle de passif.
– Le troisième, emprunté par Cassandra, tire directement profit de la nouvelle instance
mais attend que celle-ci contienne toutes les données qui lui sont assignées. Nous le
qualifierons d’pesudo-actif.
– Le dernier est celui de Hbase/Hadoop. Il est un mixte entre les deux premières solutions.
Nous le qualifierons de pseudo-actif.
Nous ne disposons pas d’études sur des systèmes passifs mais pouvons aisément faire
une étude théorique. Le temps d’adaptation ou de stabilisation sera le plus réduit possible (il
suffira au cluster de prendre connaissance de la modification mais aucun trafic supplémentaire
ne perturbera le système). La montée à l’échelle elle ne sera pas significative (exception faite
d’une application où les écritures sont en grande majorité).
Comme expliqué à la section 4.5.4, plus le système va être passif (comme HBase), plus son
temps de stabilisation va être court (ce constat peut être extrapolé au temps d’adaptation).
A l’inverse, plus il va être passif, plus son coefficient de stabilisation être faible (ce constat
peut être extrapolé au coefficient d’adaptation). On remarque que Cassandra a des scores
meilleurs que Hbase.
5.6 Architecture
Nous avons vu au chapitre 3 deux types d’architecture : la première, centralisée, est un
mode primaire-secondaire (MongoDB, Hbase), la seconde, décentralisée, est un anneau de
pairs (Cassandra).
L’architecture de pairs est totalement décentralisée ; chaque nœud a le même rôle. Dans le
cas de Cassandra, ceci permet de diminuer nettement les temps d’adaptation et de stabilisation
vu que l’ajout ou le retrait d’un nœud n’inquiète qu’un seul autre nœud. De plus, le fait que
les nœuds soient des pairs permet d’éviter le rôle central d’une seule instance qui pourrait
dès lors devenir un goulot d’étranglement et donc augmenter les temps de stabilisation et
d’adaptation. Ce effet d’étranglement a été expérimenté avec le passage à l’échelle dynamique
de MongoDB dans les expériences de T. Dory.
L’effet sur le coefficient d’adaptation n’est pas évident à décrire en ne se basant que sur
la distinction centralisé-décentralisé. Le fait qu’un système soit décentralisé peut permettre
un meilleur coefficient d’adaptation : sur des clusters de grandes tailles, les nœuds primaires
pourraient être aussi un goulot d’étranglement pour l’application en terme de performance.
Augmenter les nœuds secondaires ne peut être positif que si le primaire est capable de gérer
l’entièreté du nouveau cluster.
79

Remarquons que le fait de la distinction maître-esclave entraine que chaque nœud n’a pas
le même rôle. Il y a donc des nœuds dont le service n’est pas immédiatement de stocker des
données. Ceux-ci comptent dans le nombre de serveurs initial et peuvent diminuer l’apport en
ressource ∆n, ce qui aura pour effet d’augmenter faussement le coefficient d’adaptation (∆n
plus petit). On remarque que pour des clusters de grande taille, ce dommage est négligeable.
5.7 Tableau récapitulatif
Le tableau 5.1 résume la manière dont ces différentes dimensions agissent sur le temps et
le coefficient d’adaptation.
80

- Temps d’adaptation + - Coefficient d’adaptation +
Modèle de données Simple -> Complexe Complexe -> Simple
Modèle de consistance Faible -> Forte Forte -> Faible
Mode de réplication Asynchrone Synchrone Non déterminé
Modèle de requête Pauvre -> Riche Riche -> Pauvre
MapReduce Non Oui Non Oui
Ajout d’instance Passif -> Actif Actif -> Passif
Architecture Décentralisée Centralisée Centralisée Décentralisée
Table 5.1 – Tableau récapitulatif des liens entre choix techniques et l’élasiticté
81

Chapitre 6
Conclusion
Dans ce travail, nous avons défini la propriété d’élasticité des BDs sur cloud. Plus spécifiquement,
nous l’avons définie et défini des scénarios de test et paramètres permettant de la
caractériser et enfin nous avons décrit la manière dont les spécificités techniques de certains
SGBDs peuvent influencer cette propriété.
Ce travail est divisé en 4 parties : dans la première partie, en partant du contexte actuel
qui entoure le cloud, nous avons défini le cloud et ses propriétés essentielles. Dans la
deuxième partie, nous avons proposé une étude comparative de différents SGBDs adaptés
au cloud. Dans la troisième partie, nous avons apporté une approche analytique dynamique
pour décrire le comportement élastique d’un SGBD. Nous y avons aussi analysé une approche
comparative (moins dynamique) tentant de fournir un paramètre unique pouvant servir de
point de comparaison des élasticités de différents systèmes. Nous avons ensuite comparé les
deux approches pour tenter une nouvelle proposition d’approche combinant les qualités des
deux premières. Enfin, dans la quatrième partie, nous avons déterminé la manière dont les
choix techniques d’un SGBD peuvent influer sur son élasticité.
Les nouveaux SGBDs développés dans le but de pouvoir passer à l’échelle le plus rapidement
possible sont très différents les uns des autres et il est donc difficile d’avoir une vue
d’ensemble sur leurs caractéristiques et différences. Nous avons dès lors proposé 5 dimensions
permettant de les caractériser et de les différencier. Ces cinq dimensions sont le modèle de
données, les choix CAP et PACELC 1 , le modèle de consistance, le modèle de réplication et le
modèle de requêtes. D’autres dimensions auraient pu être choisies mais nous avons décidé de
restreindre leur nombre dans le but de fournir un récapitulatif concis mais suffisant des choix
les plus importants.
Ces deux chapitres (les définitions au cloud et l’étude comparative de différents SGBDs)
nous ont servi de base pour décrire notre sujet d’étude : l’élasticité des bases de données
sur cloud que nous définissons comme étant leur capacité à passer (monter et descendre) à
l’échelle de manière dynamique (en étant toujours disponible). Nous en avons proposé une
étude analytique basée sur des tests de charge sur Cassandra lorsque ce système passe à
l’échelle (montée et descente).
Pour analyser le phénomène de passage à l’échelle dynamique (sur une période de temps
donnée), nous proposons 5 paramètres : le coefficient, le temps et la perturbation d’adaptation,
l’impact maximal en perte en performance et les coefficients angulaires des montée et descente
1. L’acronyme PACELC est très nettement moins populaire que CAP mais nous le trouvons bien plus
parlant que ce dernier.
82

des temps de réponses. Le temps d’adaptation caractérise le temps nécessaire au système
pour assimiler la modification de son nombre d’instances, pour que ses temps de réponses
n’en soient plus influencés. Le coefficient d’adaptation représente le gain de cette modification
(en regardant le nombre d’instances et les temps de réponse avant et après modification).
Durant cette phase d’adaptation, le système retourne des temps de latence plus importants.
Pour qualifier cette perte en performance, l’impact maximal va signifier cette augmentation
par rapport aux temps de latences initiaux et les coefficients de montée et descente nous
informent, eux, sur la tendance du système, sa rapidité à perdre et à gagner en performance.
Enfin, la perturbation d’adaptation caractérise la manière dont le système est perturbé durant
cette phase d’adaptation.
Enfin, sur base des études et des résultats précédents et à partir de réflexions théoriques,
nous tentons de définir quels sont les choix techniques faits par les SGBDs sur leur élasticité.
Sur base de considérations théoriques et pratiques, nous constatons que plus un système
propose des modèles de données et requêtes complexes, moins il sera élastique. Une corrélation
négative peut aussi être faite entre la consistance des données et l’élasticité du système.
Nous remarquons aussi que le temps d’adaptation d’un système sera plus court si le système
envisage une politique de réplication de données asynchrones. Outre ces choix techniques
déjà décrits dans l’étude comparative, nous mettons en avant deux autres choix : centraliser
ou décentraliser le système. La décentralisation est un point positif pour l’élasticité et agir
passivement ou activement à l’ajout d’instances ; une politique active ralentit l’adaptation
mais optimise le gain en performance.
Travaux futurs
Ce travail pose donc des dimensions qui caractérisent un SGBD et influent sur son élasticité.
De plus, il propose un scénario et des paramètres pour analyser l’élasticité du système
en transition. Ce travail ouvre un certain nombre de portes et de questions qui seraient très
intéressantes à étudier.
La première est relative au cloud computing et au manque de définitions, de standards
pour le régir. Dans ce mémoire, nous avons ramené des définitions commerciales, attractives
à des notions scientifiques. Ces notions ont été voulues les plus rigoureuses possible mais il
serait prétentieux d’affirmer qu’elles pourraient servir de références hors de ce travail tant
standardiser le cloud computing est une tâche complexe sur laquelle butent de nombreux
organismes. Nous espérons néanmoins que nos définitions puissent servir de bases à un tel
procédé de standardisation.
L’étude concurrente de T. Dory ([41]) s’oriente vers la comparaison de l’élasticité de différents
systèmes. Elle décrit l’élasticité en termes de systèmes stables, en régime. Sur base de
celle-ci et de notre étude, nous avons décrit une nouvelle approche (combinant les deux premières)
pour tester les élasticités du système en régime et en transition (voir section 4.6.2).
Pour mener à bien une telle approche, un certains nombre de critères doivent encore être
établis. Il s’agira de pouvoir définir à définir de manière rigoureuse un système stable : une
définition permettant de pouvoir le déterminer de manière automatique.
Nous pensons nos paramètres en nombre suffisant et assez globaux pour permettre d’analyser
toute adaptation du système en transition mais ceci n’a pas pu être vérifié pour tout
système. Si Cassandra se comporte comme nous l’avions envisagé de manière théorique, il
serait intéressant de voir le comportement d’autres systèmes lors de leur transition.
De manière générale, nous déplorons le manque d’études expérimentales soutenant notre
83

étude (plus théorique que pratique) de l’influence des choix techniques d’un système sur son
élasticité. Il serait donc intéressant de déployer les tests définis précédemment sur de plus
nombreux systèmes en faisant varier leurs paramètres pour mettre en évidence ces relations
entre choix techniques et élasticité et valider ainsi ou contredire nos approches théoriques.
Dans une autre étude (voir rapport de stage en section B.4.1), nous avons souligné l’inadéquation
des bancs d’essais traditionnels pour les nouveaux SGBDs. YCSB propose en solution
un banc d’essais le plus simpliste possible de manière à s’adapter à tous ces systèmes. Or,
nous l’avons souligné dans ce mémoire, les modèles de données et de requêtes (notamment la
possibilité d’écrire ses fonctions MR) influencent nettement sur le SGBD et son élasticité. Il
existe donc une grande nécessité de définir un nouveau banc d’essais plus complexe pouvant
servir de standard pour tester ces nouveaux systèmes.
84

Bibliographie
[1] Amazon Elastic Compute Cloud, page d’accueil. http://aws.amazon.com/ec2/,
consulté le 8 avril 2011.
[2] Amazon Mechanical Turk, page d’accueil. https://www.mturk.com/mturk/welcome,
consulté le 3 mai 2011.
[3] Apache Cassandra - Operations. http://wiki.apache.org/cassandra/
Operations,consulté le 2 mai 2010.
[4] Apache Cassandra - Wiki. http://wiki.apache.org/cassandra/,consulté le 25 avril
2010.
[5] Apache Cassandra, page d’accueil. http://cassandra.apache.org, consulté le 2 mai
2011.
[6] Apache HBase, page d’accueil. http://hbase.apache.org, consulté le 2 mai 2011.
[7] Cassandra Mailing List - How to Decommission Two Slow Nodes ?
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/
how-to-decommission-two-slow-nodes-td5078455.html, consulté le 28 mai 2011.
[8] Introduction à MySQL Cluster. http://dev.mysql.com/doc/refman/5.0/fr/
ndbcluster.html, consulté le 21 août 2010.
[9] MongoDB Documentation, MapReduce. http://www.mongodb.org/display/DOCS/
MapReduce, consulté le 5 mai 2011.
[10] MongoDB, page d’accueil. http://www.mongodb.org, consulté le 2 mai 2011.
[11] ScaleDB, page d’accueil. http://www.scaledb.com/, consulté le 24 septembre 2010.
[12] Voldemort, page d’accueil. http://project-voldemort.com/, consulté le 4 mai 2011.
[13] VoltDB, page d’accueil. http://voltdb.com/, consulté le 24 septembre 2010.
[14] HBase, ACID Semantics, 6 mai 2011. http://hbase.apache.org/acid-semantics.
html, consulté le 12 mai 2011.
[15] J. Nimis S. Tai et T. Sandholm A. Lenk, M. Klems. What’s Inside the Cloud ? An
Architectural Map of the Cloud Landscape. In Proceedings of the 2009 ICSE Workshop on
Software Engineering Challenges of Cloud Computing, page de 23 à 31. IEEE Computer
Society, 2009.
[16] D. Abadi. Problems with CAP, and Yahoo’s Little Known NoSQL System,
23 décembre 2010. http://dbmsmusings.blogspot.com/2010/04/
problems-with-cap-and-yahoos-little.html, consulté le 24 février 2011.
[17] E. Tam R. Ramakrishnan et R. Sears B.F. Cooper, A. Silberstein. Benchmarking Cloud
Serving Systems with YCSB. In SoCC ’10 : Proceedings of the First ACM Symposium
on Cloud Computing, page de 143 à 154. ACM, 2010.
85

[18] E. Brewer. Towards Robust Distributed Systems. In PODC ’00 : Proceedings of the Nineteenth
Annual ACM Symposium on Principles of Distributed Computing. ACM, 2000.
[19] J. Browne. Brewer’s CAP Theorem, 11 janvier 2009. http://www.julianbrowne.com/
article/viewer/brewers-cap-theorem, consulté le 24 février 2011.
[20] R. Cattell. Scalable SQL and NoSQL Data Stores. page 1 à 16, Décembre 2010.
[21] K. Chodorow. Scaling MongoDB. O’Reilly Media, 2011.
[22] E. Ciurana. Getting Started with NoSQL and Data Scalability. http://refcardz.
dzone.com/refcardz/getting-started-nosql-and-data, consulté le 25 août 201°.
[23] B. F. Cooper. Yahoo ! Cloud Serving Benchmark, Overview and Results, Mars 2010.
http://www.brianfrankcooper.net/pubs/ycsb-v4.pdf, consulté le 8 mars 2011.
[24] P. Pawlowski et J. Cieslewicz E. Friedman. SQL/MapReduce : a Practical Approach
to Self-describing, Polymorphic, and Parallelizable User-defined Functions. Proc. VLDB
Endow., 2(2) :de 1402 à 1413, 2009.
[25] K. Chodorow et M. Dirolf. MongoDB, The Definitive Guide. O’Reilly Media, Septembre
2010.
[26] S Gilbert et N. Lynch. Brewer’s Conjecture and the Feasibility of Consistent Available
Partition-Tolerant Web Services. In ACM SIGACT News, 2002.
[27] A. Lakshman et P. Malik. Cassandra - A Decentralized Structured Storage System.
SIGOPS Oper. Syst. Rev., 44 :de 35 à 40, avril 2009.
[28] J. Dean et S. Ghemawat. MapReduce : Simplified Data Processing on Large Clusters.
Commun. ACM, 51(1) :de 107 à 113, 2008.
[29] P. Mell et T. Grance. The NIST Definition of Cloud Computing. National Institute of
Standards and Technology, 53(6) :de 1 à 50, juillet 2009.
[30] M. Figuière. NoSQL Europe : Tour d’horizon des bases de données
NoSQL, 21 avril 2010. http://blog.xebia.fr/2010/04/21/
nosql-europe-tour-dhorizon-des-bases-de-donnees-nosql/, consulté le 12
août 2010.
[31] M. Jampani G. Kakulapati A.Lakshman A. Pilchin S. Sivasubramanian P. Vosshall et
W. Vogels G. DeCandia, D. Hastorun. Dynamo : Amazon’s Highly Available Key-value
Store. SIGOPS Oper. Syst. Rev., 41 :de 205 à 220, Octobre 2007.
[32] P. Grange. Le livre blanc du cloud computing. Syntec informatique, page de 1 à 19, 2010.
[33] E. Hewitt. Cassandra : The Definitive Guide. O’Reilly, First Edition edition, 2010.
[34] T. Hoff. VoltDB Decapites Six SQL Urban Myths And Delivers Internet Scale
OLTP In The Process, le 25 juin 2010. http://highscalability.com/blog/2010/
6/28/voltdb-decapitates-six-sql-urban-myths-and-delivers-internet.html,
consulté le 12 août 2010.
[35] D. Kushal. MongoDB Strategies for the Disk-averse. http://engineering.foursquare.
com/2011/02/09/mongodb-strategies-for-the-disk-averse, consulté le 18 février
2011.
[36] M. Kunze A. Canales Castellanos D. Kramer et W. Karl L. Wang, J. Tao. Scientific
Cloud Computing : Early Definition and Experience. High Performance Computing and
Communications, 10th IEEE International Conference, page de 825 à 830, 2008.
86

[37] S. Lutz. The Future of Cloud Computing Opportunities. European Cloud Computing
Beyond 2010, page de 1 à 67, 2010.
[38] D. Merriman. MongoDB : Sharding Introduction. http://www.mongodb.org/display/
DOCS/Sharding+Introduction, consulté le 28 février 2011.
[39] D. Merriman. On Distributed Consistency, mars 2010. http://blog.mongodb.org/,
consulté le 05 mars 2011.
[40] D. M. Batista et M. Alomari S. Sakr, A. Liu. A Survey of Large Scale Data Management
Approaches in Cloud Environments. Communications Surveys Tutorials, IEEE, 12(4) :1
à 26, avril 2010.
[41] P. Van Roy N.-L. Tran T. Dory, B. Mejias. Measuring Elasticity for cloud databases
[DRAFT]. mai.
[42] W. Vogels. Eventually Consistent - Revisited, 23 décembre 2008 2007. http://
www.allthingsdistributed.com/2008/12/eventually_consistent.html, consulté le
19 février 2011.
[43] T. White. Hadoop : The Definitive Guide. O’Reilly, Second Edition edition, october
2010.
87

Annexe A
Liste d’accronymes
– API : Interface de programmation
– BD : Bases de données
– CAP : “théorème CAP” voir (voir section 2.4)
– CC : Cloud Computing
– Cloud : Cloud Computing
– HDFS : Hadoop distributed Filesystem
– HuaaS : Human as a Service
– IaaS : Infrastructure as a Service
– MR : Map Reduce
– MV : Machine Virtuelle
– NIST : National Institute of Standards and Technology
– PaaS : Platform as a Service
– PACELC : CAP revu par D. Abadi (voir section 2.4)
– SaaS : Software as a Service
– SGBD : Système de gestion de bases de données
– SGBDR : Système de gestion de bases de données relationnelles
– SQL-MR : SQL - Map Reduce
– YCSB : Yahoo ! Cloud Serving Benchmark
88

Annexe B
Rapport de stage
B.1 Cadre du stage
Le stage avait pour but d’acquérir de l’expérience dans le domaine du cloud et d’étudier
récentes BDs pour cloud. Dans ce but, Euranova m’a proposé, initialement, d’effectuer des
tests de comparaisons en performances sur différents SBGDs. Après avoir effectué les premières
recherches dans le domaine et après discussions entre les ingénieurs d’ Euranova et le professeur
E. Zimanyi, la finalité du stage fut redéfinie vers l’établissement d’une stratégie de banc
d’essais pour nouvelles BDs sur cloud (une adpation de TPC-C).
Le stage a duré 6 semaines et a été effectué dans les bureaux d’Euranova. Ce fut pour moi
l’occasion d’avoir accès à leur infrastructure (un cluster de 4 puis 8 serveurs) mais surtout de
profiter des nombreux conseils de H. Bath, E. Delacroix, N-L. Tran (qui étaient aux bureaux
d’Euranova) et de S. Skhiri (lors de réunions presque hebdomadaires).
B.2 Chronologie du stage
Le stage avait pour but, dans un premier temps, d’acquérir de l’expérience dans le domaine
du cloud et des récentes bases de données. Dans cette optique, la première démarche était de
faire de faire un tour d’horizon des différentes solutions existantes, pour le cloud : Eucalyptus,
OpenNebula, Amazon et pour les bases de données : les bases de données traditionnelles
adaptées au cloud, le mouvement NoSQL et les nouvelles bases de données relationnelles : les
SQL-MR.
La deuxième étape était de choisir deux BDs parmi les solutions explorées, de les étudier
plus en détail dans le but final de pouvoir effectuer des tests de comparaisons en performances.
Les deux choix se dirigèrent vers Cassandra (NoSQL) et AsterData (SQL-MR). L’outils choisi
pour exécuter les tests était le framework YCSB.
Les systèmes choisis, il fallait décrire une scénario de test : le schéma de données, les
dimensions à faire varier et les métriques à relever. Le schéma des données choisi fût celui de
l’application Twitter. Ce choix fait, le schéma de l’application fut modélisé et l’application
YCSB fut modifiée de manière à générer ces données. Une modélisation d’ensembles ordonnés
d’opérations typiques de Twitter furent aussi modélisés et implémentés.
Seulement, après discussion avec le professeur E. Zimányi, le choix fut fait de se ramener
à des bancs d’essais de référence tels que TPC. Après une étude des différentes solutions de
références, le choix fût porté sur TPC-C. L’adaptation de TPC-C à des nouveaux SGBDs tels
89

Cassandra n’est pas évidente. Ce fut la première tâche à réaliser. Pour résumer la démarche
(qui est expliquée dans l’article en section B.4.1), il s’agit de repenser les bans d’essais non
plus comme décrivant de manière rigoureuse les données et les transactions à effectuer mais
le décrivant de manière fonctionnelle.
Cette modélisation fut transposée sur une nouvelle version de YCSB adaptée et, à titre
d’exemple, ce nouveau banc d’essais fut appliqué sur un cluster Cassandra de 4 nœuds. Vous
trouverez en section B.4 deux articles décrivant ces travaux.
B.3 Bilan du stage
Les premières semaines de stage m’ont permis de me familiariser avec la blogospshère
relative au cloud, à leurs BDs et tous les concepts les entourant. J’ai ainsi découvert, entre
autre, YCSB qui nous a servi dans ce mémoire. Les semaines suivantes m’ont permis de
découvrir les méthodes de banc d’essais, leurs standards et normes. De manière générale ceci
m’a permis de découvrir que lire un article scientifique ne nous apprend pas seulement que
le contenu de cet article. Lire un article scientifique peut aussi nous apprendre comment
formaliser des idées, des concepts et des résultats, apprendre de sa structure.
Ce stage a aussi été pour moi l’occasion de découvrir chez les ingénieurs d’Euranova des
personnes de grandes qualités scientifiques. J’ai appris un nouveau mode d’apprentissage basé
sur des discussions et réunions brèves ou longues. Je fus aussi invité à participer à des réunions,
à l’université catholique de Louvain (UCL), d’un groupe d’étudiants ayant un sujet relatif au
cloud. Durant ces réunions, périodiquement, chacun exposait ses recherches et ses avancées.
Ce mode de partage de savoir fut aussi très instructif.
Cette période fut aussi l’occasion de parler avec des ingénieurs de leur travail. Travailler
à Euranova m’a permis de rencontrer des consultants travaillant dans des branches très différentes
et donc m’a ouvert les yeux sur un monde très vaste. Grâce à ces nombreuses discussions,
je peux, à présent, mieux appréhender mon futur .
B.4 Autres documents
Cette section regroupe les différents documents relatifs à ce stage.
B.4.1 Article
Ci-dessous, vous trouverez l’article que j’ai écrit sur la modélisation d’un banc d’essais du
type TPC-C adapté au solution cloud.
90

Abstract
Bancs d’essais pour nouvelles bases de données sur cloud
Récemment un nombre conséquent de nouvelle bases
de données adaptées au cloud computing ont vu le jour
pour répondre à des besoins spécifiques d’applications y
accédant de manière très fréquente. Ces nouvelles bases
de données (dont le mouvement NoSQL) se distinguent
fortement des bases de données traditionnelles, il s’agit
donc de créer ou d’adapter les bancs d’essais traditionnels
à leurs particularités afin de pouvoir comparer leurs
performances. Dans ce travail, nous proposons un banc
d’essais similaire à TPC-C adapté aux nouvelles bases de
données. Nous définissons les nouveaux critères de comparaison,
de performance et proposons une approche de
modélisation pour ces nouvelles bases de données.
1 Introduction
Le cloud computing est une architecture d’instances
virtuelles auto-adaptative à la charge à laquelle elle est
soumise. Cette structure est donc capable de régler dynamiquement
son nombre d’instances pour correspondre
de manière optimale à la charge c’est-à-dire un nombre
minimal d’instances (pour réduire les coûts) qui satisfait
les conditions de performance désirée.
Lorsqu’on désire déployer un tel système, il s’agit
de voir si il est réellement capable de fournir les performances
requises et de s’adapter à la charge. Parmi
les différents composants d’un cloud, la base de données
se révèle être un point faible qui peut vite limiter
l’expansion, la capacité d’adaptation de l’architecture. Il
s’agit dès lors de bien choisir son système de gestion de
base de données (SGBD) pour être sûr qu’il satisfait aux
critères de notre application.
Pour s’assurer qu’un SGBD satisfait des critères de
sélection, nous soumettons celui-ci à un banc d’essais
(benchmark). Le domaine du benchmarking est un domaine
fort rigoureux et normalisé favorisant ainsi la re-
Nicolas Degroodt
Faculté des sciences,
Université libre de Bruxelles
Belgique
En partenariat avec
Euranova
nicolas.degroodt@ulb.ac.be
productibilité et la confiance en les résultats précédents.
TPC (Transaction Processing Performance Council), par
exemple, est un organisme renommé qui propose une série
de bancs d’essais standardisés pour SGBDs relationnels
(SGBDR) en modélisant des applications concrètes de la
vie courante. Ces séries de tests servent de référence pour
juger, comparer les performances de différents SGBDRs.
Le cloud amène avec lui l’avènement de nouveaux
SGBDs (dont les systèmes NoSQL (not-only-SQL)) et
leurs critères de performance tels que les temps de latence,
l’usage CPU et l’élasticité. Ces nouveaux SGBDs quittent
totalement le mouvement relationnel pour proposer des
solutions adaptées aux besoins spécifiques d’une application
particulière. Il est dès lors impossible d’appliquer les
bancs d’essais standards (tels que ceux proposés par TPC)
sur ces systèmes. Il s’agit dès lors de fixer des nouveaux
standards, critères et une nouvelle méthodologie de tests
qui permettra d’évaluer de manière uniforme et comparable
les différents SGBDs.
Une première solution, proposée dans [3], consiste
à soumettre tous ces systèmes à un même scénario qui
ne testera que leurs fonctionnalités les plus basiques
présentes dans tout SGBD (à savoir des opérations de
CRUD 1 ). Cette approche a le mérite de permettre une
comparaison effective (pomme-pomme) des SGBDs mais
présente le défaut de ne pas considérer des opérations
complexes (présentes dans la vie de tous les jours) et
de ne pas tirer profit des différentes qualités des SGBD.
Un SGBDR traditionnel (tel que MySQL), par exemple,
est un système fort complexe (et donc vraisemblablement
moins performant) mais possédant des propriétés et structures
bien plus élaborées qu’un système clé-valeur d’une
solution NoSQL (tel que voldemort).
Une seconde approche, présentée dans cet article, se
1 Create, Read, Update, Delete c’est-à-dire (Créer, lire, mettre-à-jour
et supprimer)

ase sur le constat que, même si ils sont fort différents,
ces systèmes ont la même vocation: celle de stocker
de manière performante les données et à ce titre, il est
nécessaire de pouvoir les comparer en tenant compte de
leurs avantages et défauts. Dans cette optique, nous
conservons l’approche TPC (qui est de tester le SGBD
avec des données et opérations de la vie courante) tout
en adaptant la modélisation des données et requêtes au
SGBD testé.
Dans ce travail, nous proposons d’établir les nouveaux
critères de comparaisons pour différents modèles
de SGBDs placés dans un contexte de cloud et de définir
l’action de benchmarking non comme l’implémentation
de standard mais plus comme la modélisation d’un standard
fonctionnel de bancs d’essais. A ce titre, un banc
d’essais ne doit plus proposer une architecture stricte pour
ses données mais plutôt un schéma et une sémantique
fonctionnels.
Nous proposons ensuite, à titre illustratif, cette
démarche via l’application d’un banc d’essais similaire à
TPC-C sur un Cassandra[4], un système NoSQL avancé
propulsé par l’équipe de développement de Facebook.
2 Related Work
2.1 TPC
TPC-C est un banc d’essais de processus de transactions
en ligne qui met en avant 5 différentes transactions;
principales activités d’un environnement gérant
des commandes d’objets. Ces transactions modélisent
les opérations de livraisons et entrées de commandes, les
payements, les vérifications des statuts des commandes et
le monitoring des stocks des magasins.
TPC-C propose une définition des données via un
schéma entités-relations et une définition rigoureusement
de tous les attributs de chaque entité. Une fois qu’un tel
schéma est déployé dans le SGBDR, que les données y
sont chargées, un banc de tests simulant les cinq transactions
courantes (décrites aussi rigoureusement par TPC-
C) peut être lancé. Le but étant d’assumer un nombre
maximum de transactions à la minute.
Nous avons choisi TPC-C de part la simplicité de
son schéma et ses apparentes similitudes avec un magasin
en ligne (type Amazon[2]), une application qui pourrait
facilement être tentée d’utiliser pour certaines de leur
données un SGBD NoSQL.
2.2 Yahoo! Cloud Serving Benchmark
Yahoo! cloud Serving Benchmark (YCSB) propose
un nouveau standard de bancs d’essais et un framework
pour faciliter la comparaison les performances des
différentes bases données dans un contexte cloud.
YCSB considère que les benchmarks traditionnels,
tels que TPC-C, ne sont plus représentatifs des nouvelles
2
applications utilisant le cloud et propose de faire une
comparaison pomme-pomme des ces nouveaux SGBDs
et focalise son attention sur les systèmes fournissant des
opérations de lecture et d’écriture en ligne (typiquement
les services web en opposition aux systèmes analytiques
et relationnels OLAP).
Yahoo se propose d’étudier les performances
d’opérations basiques (CRUD) sur une seule entité du
système (quelle que soit sa représentation) définissant de
nouveaux compromis à considérer avant d’installer de tels
systèmes sur cloud. Parmi ceux-ci, citons le compromis
entre les performances en lecture et celles en écriture. En
effet, ces nouveaux systèmes, pour la plupart, considèrent
que l’application focalise son activité sur des écritures ou
sur des lectures et qu’il est donc intéressant de favoriser
les performances d’une seule opération au détriment de
l’autre.
Enfin, ils définissent quatre déploiements de tests typiques:
• Le premier est axé performances. Le but est de
mesurer, pour une architecture cloud donnée, le
temps de latence en fonction du nombre de requêtes
sur le système. Typiquement, ce test permet à
l’administrateur de connaître le comportement du
système de voir jusque quand le système sera satisfaisant.
• Le deuxième consiste à faire varier le nombre
d’instances; au démarrage pour étudier la montée
à l’échelle du système ou durant l’exécution pour
étudier l’élasticité.
• Le troisième étudie la haute disponibilité du système.
L’expérience consiste à supprimer une instance et à
en analyser les conséquences. Ce procédé ne permet
que de définir une seule panne. Néanmoins, ces
systèmes étant forts différents, ils ne sont donc pas
souvent victimes du même type de panne.
• Enfin le dernier test consiste à étudier l’influence du
nombre de réplicas sur le comportement du système.
Quels sont les résultats sur les performances, sur
la haute disponibilité, sur la consistance de ces
réplicats (leur fraicheur) lorsque les différents centres
de données sont dispersés dans le monde.
3 De nouveaux SGBDDs
Les nouveaux SGBDs se basent sur des fondements
fort différents. Ce qui entraine la nécessité de reconsidérer
les benchmarks. Cette section traite de ces considérations
supplémentaires.

3.1 Architecture des données
Les standards de benchmark proposent un schéma relationnel
décrit par des entités liées entres elles. Chaque
attribut, chaque relation, les clés primaires et index des
entités y sont définis rigoureusement. La même logique
est respectée pour les transactions.
Les systèmes NoSQL ne proposent pas de modéliser
ces entités et relations de la même façon que le faisaient
les SGBDRs. Le schéma proposé ne peut être déployé tel
quel dans le système. Il faut donc le penser tel un modèle
définissant les données de manière sémantique et fonctionnelle
et le transposer en une structure optimisée pour
le système de stockage à tester.
Les transactions quant à elles, seront aussi à voir
telles que des modèles décrivant le fonctionnement, le
déroulement d’opérations standard sur les données. Elles
devront, elles aussi, être transposées dans le contexte du
système concerné.
3.2 Schema Less
La majorité de ces systèmes sont dits schema-less
c’est-à-dire que les données ne sont plus décrites par un
schéma structuré et fixe mais plutôt par un schéma minimaliste
(souvent un schéma clé-valeur).
L’avantage certain d’une structure relationnelle est
qu’elle représente un objet de la vie réelle. La phase
de modélisation peut dès lors se faire de manière intuitive,
naturelle. Dans les systèmes dits schema-less,
la modélisation est moins naturelle. Une entrée ne
représente plus un objet. La modélisation des donnée
y est pensée de manière opérationnelle, impérative.
L’opération de modélisation doit donc être bien réfléchie
et a des implications importantes sur les performances de
l’application.
La phase de modélisation pour un benchmark peut
prendre deux chemins:
1. Modéliser l’application en considérant le schéma relationnel
et la sémantique des données; c’est-à-dire
penser l’application dans l’optique qu’elle soit la
plus adaptée aux données et à leurs relations. Le
schéma résultant d’une telle logique présentera des
performances moyennes avantageuses durant toutes
l’existence de l’application.
2. Modéliser l’application en considérant les transactions
du benchmark; c’est-à-dire limiter la
sémantique des données à l’unique utilisation qu’on
en fait dans ces transactions. Cette logique
présente l’avantage certain que le SGBDs présentera
des performances optimales sur les transactions.
Néanmoins, la modélisation en résultant présenterait
de forts risques d’être vite dépassée et nonperformante
déployée dans une application réelle.
3
Alors qu’une requête relationnelle retournait un objet
prêt à l’emploi, la majorité des nouveaux SGBDs
ne propose généralement qu’un mécanisme de requêtes
simplistes (un bon nombre se limite à un API
read/insert/delete). L’opération de réunir les informations
sous forme d’objet utilisable par l’application cliente est
donc déléguée à une couche intermédiaire. Ce travail n’est
pas négligeable, il peut même se révéler fort couteûx en
terme de ressources. Placé d’un contexte de cloud computing
où l’on désire se limiter à des ressources minimales,
il convient d’analyser ce coût (en mesurant, par
exemple, l’usage CPU d’une instance dédiée à ces transformations).
3.3 BASE au lieu de ACID
Alors que les traditionnels SGBDRs proposent le concept
de transactions via les propriétés ACID, les nouveaux
SGBDs ont pris le parti de relâcher le degré consistance
pour une plus haute disponibilité en cas de partitionement
du réseau et pour des temps de latence plus faibles en cas
normal [1].
La première considération se fait niveaux de
l’abandon de la notion de transaction. Cette option
doit être implémentée par le SGBD, nous ne pouvons
pas l’émuler via l’application cliente. Si celui-ci ne
propose pas de transactions, il est donc impossible
d’appliquer cette notion. Il s’agit dès lors d’accepter ce
manque lorsqu’on décide de déployer ou d’étudier de tels
SGBDs 2 .
La seconde considération est autour du rabaissement
de la consistance globale de ces systèmes. Même si la plupart
de ces systèmes ne sont pas limités à une consistance
faible et que l’on peut dès lors les tester en leur soumettant
une consistance parfaite pour chaque opération, se limiter
à tel tests seraient dénaturer ces systèmes (qui tirent
un gain en performance certains de ce relâchement de la
consistance). Il peut donc être intéressant de proposer
lors de futurs essais quelques transactions permettant une
réduction de la consistance.
3.4 Des systèmes non uniformes
Une dernière réflexion est faite autour du fait que
ces systèmes sont tous fort différents. Chacun apporte
son lot de défauts et d’avantages par rapport aux autres.
A la différence de YCSB, nous ne nous rattachons pas
à l’idée de faire une comparaison pomme-pomme via
l’implémentation d’un banc d’essais testant les fonctionnalités
les plus basiques des systèmes. Il s’agit de profiter
de chaque avantage proposé par les différents systèmes,
d’adapter la structure des données au SGBD dans le but
2 Dans la suite de cet article, nous utiliserons le terme de transaction
pour faire référence aux transactions décrites par le benchmark que nous
voyons plus comme une suite d’opérations basiques ne satisfaisant pas
nécessairement aux propriétés ACID.

de tirer profit de toutes ses qualités, d’opter pour une
modélisation (adapté à la sémantique des données ou aux
transactions) et de l’adapter au système étudié.
4 Vue d’ensemble du cloud computing
Dans cette section, nous discutons les aspects
spécifiques au cloud devant être pris en compte lorsqu’on
y décrit un banc d’essais.
De nouvelles dimensions
• Mise à l’échelle: les clouds ont tendance à gérer un
nombre important de données en ajustant le nombre
de leurs instances en fonction de cette charge. La
capacité d’un SGBD à utiliser de manière effective
ce nombre de ressources est ce que l’on appelle sa
capacité à monter à l’échelle.
• Elasticité: la capacité de monter à l’échelle caractérise
le comportement d’un système en fonction
du nombre d’instances qui le composent. L’élasticité
caractérise la réaction du système à la variation de ce
nombre d’instances lorsque le système est en cours
d’exécution.
• Haute disponibilité: le cloud doit fournir un haut
niveau de disponibilité, étant donnée qu’ils sont
hautement utilisés. La défaillance d’un nœud peut
avoir des répercussions multiples. Le cloud doit donc
gérer les défaillances et il est donc intéressant de
mesurer la réaction du cloud à une défaillance.
De nouvelles mesures Même si le nombre de transactions
par seconde a le mérite d’être une mesure
représentative de la qualité d’un SGBDD, il apparait que
les nouveaux systèmes ne peuvent être uniquement jugés
que sur ce critère. Il s’agit d’étudier aussi le temps de latence
des transactions. En effet ce point est fort important
étant donnée que l’utilisateur humain est de nature impatiente
et que les moindres temps d’attente peuvent faire
perdre un nombre important de clients.
Typiquement, l’administrateur d’un cloud fixera une
limite acceptable de temps de latence et augmentera le
nombre d’instances du cloud pour pouvoir supporter le
nombre de transactions de l’application cliente sans que
le temps de la latence n’excède la limite fixée. Il est donc
intéressant de pouvoir extraire le temps de latence lors du
déploiement des tests.
Le principe même du cloud est d’allouer le minimum
de ressources nécessaires au bon fonctionnement de
l’environnement. Dans cette optique, il s’agit de proposer
un SGBDD qui soit le plus économe et en espace mémoire
et en usage CPU. Une nouvelle mesure intéressante se
situe donc au niveau de l’usage CPU des instances stockantes
et de l’instance chargée de diviser les requêtes et de
les réunir.
4
5 Notre solution
Dans cette section, nous proposons de nouvelles dimensions,
mesures et tests à considérer pour de nouveaux
benchmarks adaptés aux services de stockage de données
dédiés au cloud.
5.1 Les mesures
L’outil chargé de relever les mesures devra être capable
de monitorer les temps de latence des réponses
du système, le nombre de transactions moyen qu’il
est capable d’effectuer par seconde, l’usage CPU des
différentes instances et l’espace mémoire qu’occupent les
données (cet espace pouvant fortement varier en fonction
de la politique de réplication et de stockage des données).
5.2 Les dimensions
Les différents paramètres à faire varier lors du
scénario de tests sont les suivants:
• la taille des données
Cette dimension permet de tester la capacité du système
à monter en charge en terme de données stockées. Nous
proposons de lancer un banc d’essais sur une architecture
donnée et un système préalablement chargé de données.
Ensuite, il s’agira de réinitialiser l’architecture en augmentant
son nombre d’instances, de charger le système
de données dont le volume serait augmenté de manière
proportionnelle au nombre d’instance et de ré-exécuter le
banc d’essais. Si le système est résistant à une montée en
charge en terme de volume, les temps de latence résultant
des tests devraient être constants. Il convient néanmoins
de faire attention au facteur de réplication des données lors
qu’on augmente la taille des données de manière proportionnelle.
• le nombre d’utilisateurs
Le premier test permet de tester la capacité du système
à monter en charge en terme d’utilisateurs attaquant la
base de données. Son fonctionnement est similaire au test
précédant: augmenter de manière proportionnelle le nombre
d’utilisateurs et le nombre d’instances. Les temps de
latence résultant devraient être constant.
Le deuxième consiste à tester la performance d’un
système; pour une architecture et un volume de données
donnés, il s’agit de lancer une série de tests en faisant
varier le nombre d’utilisateurs attaquant le système. Il
devrait en résulter une série de temps de latence croissante
en fonction du nombre d’utilisateurs. Ces mesures
permettront à l’administrateur système de savoir combien
d’utilisateurs son architecture est capable de traiter en
deçà la borne qu’il se fixe (en terme de temps de latence).
Le troisième consiste à tester l’élasticité du système.
De manière similaire au test de montée en charge en

terme d’utilisateurs, ce banc d’essais consiste à faire
varier le nombre d’instances et d’utilisateurs de manière
dynamique. Les résultats devraient rapporter un temps
de latence constant en fonction du nombre d’instancesutilisateurs.
Cet aspect dynamique implique des considérations
supplémentaires. En effet, un cloud composé
de N instances risque de se comporter différemment en
fonction de son état précédant N − 1 ou N + 1 instances.
Il s’agit dès lors de considérer une architecture dont on
augmenterait le nombre d’instances puis le diminuerait.
Cette diminution d’instances représente le cas concret où
l’administrateur désirerait diminuer le nombre d’instances
de son cloud pour faire des économies.
Il faut aussi considérer le timing; quand faut-il ajouter
ou soustraire une instance? Il n’y a pas de réponses
établies à cette question. L’approche proposée par YCSB
est de laisser le système se stabiliser (c’est-à-dire attendre
que les temps de latence du système soient constants) et
seulement après ajouter une instance. Deux critiques peuvent
être apportées sur une telle approche. La première
est la notion subjective de ce ”temps de stabilisation” qui
est propre à chaque couple (SGBD et cluster) et ne peut
donc former un standard ré-applicable.
La seconde critique se base sur les résultats de [3] qui
reporte un ”temps de stabilisation” allant autour des 20
min pour quelques systèmes dits élastiques (tels que cassandra
par exemple). Ce temps semble assez long pour
pouvoir être considéré comme une réponse dynamique du
système.
• Le facteur de réplication
Faire varier le facteur de réplication peut influer tant
sur le niveau de performance que sur celui de consistance.
Nous proposons une solution pour étudier son influence
sur le niveau de performance. Il s’agit d’effectuer, sur
une architecture de cloud et un volume de données fixés,
un test de montée en charge en terme d’utilisateurs et de
réitérer ce test en faisant varier le facteur réplication de
chaque configuration de test. Ce facteur devant être à
l’initialisation du SGBD, il s’agit donc d’un test statique.
Les résultats pourront être affichés sous forme de courbes
(temps de latence en fonction des utilisateurs). Il s’agira
ensuite pour l’administrateur de déterminer quel facteur
lui convient le mieux. En conservant à l’esprit que ce facteur
devrait être supérieur à 3 pour préserver l’intégrité
des données [6].
5.3 Architecture
Cette section décrit le schéma, l’architecture typique
d’un client 3 favorisant la mise en place d’un banc d’essais
décrit par des aspects sémantiques et fonctionnels.
3 Nous utilisons le terme de client pour définir l’application chargée
d’effectuer les tests et de récolter les mesures de ces tests.
5
La figure 1 représente une telle architecture. Elle est
composée de 6 éléments: un générateur de paramètres
aléatoires, un module représentant les requêtes liées au
standard de banc d’essais (ici TPC-C), un interpréteur de
requêtes chargé de lier les paramètres aux requêtes et de
les distribuer sur la couche suivante: la couche base de
données qui sert d’interface entre le client et le SGBD, un
module chargé de définir les paramètres qui définiront les
tests (nombre d’utilisateurs, taille de la base de données,
etc.) et le module statistique chargé de récolter les statistiques
sur les tests (temps de latence, nombre de transactions
par seconde).
Génération des paramètres Lors de la génération de
test, afin de pouvoir reproduire les tests, il s’agit de pouvoir
générer les données et des paramètres des transactions
de manière reproductible. Notre architecture contient
donc une couche génératrice de paramètres qui
produira des valeurs pseudo-aléatoires (c’est-à-dire des
valeurs aléatoires pouvant être reproduites aisément). Le
travail de cette couche n’est soumis à aucune mesure de
performance.
Générateur de requêtes Ce module connait la
sémantique des données et les requêtes décrites par le
standard de test. Par exemple, pour TPC-C, ce module
aura connaissance des définitions de chaque attribut
formant les entités et des 5 différentes requêtes et les
communiquera à l’interpréteur de requêtes. Ce module
n’a pas une fonction très élaborée toute fois nous l’isolons
de manière symbolique. Il représente le standard de banc
d’essais que l’on désire déployer. Ce module ne sera pas
monitoré, aucune mesure n’en sera tirée.
Interpréteur de requêtes Qu’elles soient des requêtes
de chargement de données ou des requêtes formant les
transactions, les requêtes décrites par le benchmark (typiquement
en langage SQL) doivent être interprétées et
transformées en requêtes spécifiques. Cette couche est
la première à avoir connaissance de l’architecture de la
BDD. L’interprétation se fait en deux phases:
Figure 1: Architecture du client.

• la couche insère les paramètres dans la requêtes SQL.
• la couche analyse la requête et la distribue en
requêtes interprétables par la couche inférieure. La
couche d’interprétation est la première à avoir conscience
de l’architecture des données sur le SGBDD.
A ce titre, elle sait quelle entité stockante elle doit atteindre
4 . Une simple requête pourra être distribuée
sur plusieurs sous-requêtes.
Les requêtes faisant intervenir des jointures en SQL ne
sont pas possibles via une interface CRUD. Pour effectuer
de telles requêtes l’interpréteur de données devra
être capable de recevoir des données de la couche
inférieure (la couche base de données), les interpréter pour
les réinjecter dans de nouvelles requêtes. Toute opération
de Map/Reduce sera effectuée par ce module. Le travail
de ce module est à estimer; Si elle n’influence aucunement
les temps de latence, la phase de redirection des transactions
et de réduction des différents résultats pourrait se
révéler couteuse en terme de calcul. Il s’agit donc de monitorer
l’usage CPU d’un tel module.
Le module paramètres Ce module récoltera les
différentes dimensions voulues par l’utilisateur et les
répercutera sur les tests. Ces différentes dimensions
sont par exemple, le nombre d’utilisateurs attaquant le
SGBDD, le nombre de transactions à la seconde effectuées
par ces clients, la taille de la base de données
à charger et la fréquence de chaque transaction 5 . Ce module
est un module symbolique, il permet de bien distinguer
les différents tests formant le banc d’essai. Il n’y a donc
aucune mesure à récolter de ce module.
la couche base de données Le client se compose d’une
interface capable de communiquer avec le SGBD. Il est en
charge de l’ interroger et de récolter les mesures définies
plus haut. C’est à ce niveau qu’il s’agira de prendre les
mesures correspondant aux temps de latence du SGBD et
du nombre de transactions qu’il est capable d’effectuer par
seconde.
La module statistique Ce module est en charge de
récolter les mesures sur les tests c’est-à-dire le nombre de
transactions par seconde, les temps de latence pour chaque
transaction et l’usage CPU de chaque instance composant
le cloud.
6 Nos tests
Cette section illustre les essais que nous avons effectués
dans le but d’étudier la mise en place d’un tel banc
4 Quelle table elle doit atteindre si le SGDB est un système SQL,
quelle columnFamily si il sagit de cassandra
5 La fréquence de chaque transaction est une chose fixée par des
standards tels que TPC-C et peut dès lors être remontée à la couche
Générateur de requêtes pour de tels standards.
6
d’essais. À ce titre, nous concédons que les résultats exposés
peuvent sembler faibles mais le but de ce travail
consiste plus à la proposition d’adaptation de standards
et la mise en place d’un outil facilitant le déploiement de
bancs d’essais qu’à étudier un système particulier.
6.1 Mise en situation
Sur un cluster composé de 4 nœuds, nous déployons
Cassandra[4]. Sur une architecture fixe 6 , nous chargeons
trois différents volumes de données (répondant aux
normes de TPC-C). Pour chacun de ces volumes, nous effectuons
3 tests simulant les cinq transactions TPC-C qui
différent en considérant le nombre d’utilisateurs attaquant
le SGBD.
Pour simuler une charge des utilisateurs, nous simulons
trois différents nombres d’utilisateurs attaquant de
manière concurrentielle le système sur 1000 transactions.
Aucune borne n’est donnée pour les utilisateurs, ils effectuent
autant de transactions que le SGBD le permet à
la seconde. En faisant varier le nombre d’attaquants 50,
100 et 200, on obtient donc 50.000, 10.000 et 200.000
transactions effectuées.
6.2 Modélisation
Modélisation des données Les données simulent 5 entrepôts
(tels que définis par TPC-C) entraînant environ
2, 610 6
entrées (soit 4GB de données réplicats compris).
Nous modélisons les données en fonction du schéma
relationnel et de la sémantique décrite dans TPC-C
(première modélisation décrite dans la section 3.2).
6.3 Prise de mesure
La principale application chargée de prendre les
mesures est une extension de YCSB. YCSB assume
les modules paramètres, statistiques et db client. Le
générateur de paramètres est un simple objet java capable
de générer les paramètres de manière pseudo-aléatoire
et correspondant aux critères définis par TPC-C.
Les modules TPC-C requêtes et Interpréteur de
requêtes ne se distinguent pas. En effet, l’interpréteur de
requêtes est non seulement dépendant du benchmark mais
aussi de l’architecture de la structure stockant les données;
ceci entrainant une grande difficulté, voire l’impossibilité
de formaliser cet interpréteur. Dans ce travail, nous avons
donc regroupé les deux composants en un seul. Ce composant
appelle le générateur de paramètres et les introduit
dans les requêtes TPC-C traduites No-SQL et interroge le
DB client.
Le DB client est une interface Java utilisant l’API
thrift de Cassandra [5] et implémentant les fonction
CRUD.
6 La configuration de Cassandra est la configuration de base proposée
dans [6] à l’exception que le dossiers de log sont sur des disques dédiés

6.4 Résultats et analyse
La figure 2 illustre les temps de latence du SGBD
supportant une montée en charge en terme d’utilisateurs.
Un tel graphe permet à l’administrateur du système
de connaître les limites de son application en terme
d’utilisateurs et de savoir à partir de quelle charge, il sera
nécessaire de repenser l’architecture (comme rajouter une
nouvelle instance).
Figure 2: Montée en charge en terme d’utilisateurs
7 Conclusion
Dans ce travail, nous avons donc proposé une
méthodologie pour exporter les standards de benchmark
à toute solution de SGBD. A la lecture de cet article, on
se rend compte que la démarche n’est pas dénouée de sens
mais reste très sensible et difficile à mettre en place.
Une démarche qui a du sens. Oui, tout SGBD
stocke des données auxquelles on peut accéder moyennant
quelque temps de latence. A ce titre, on peut effectivement
les comparer.
Un démarche sensible à la critique! Les récents
SGBD (notamment les NoSQL) ouvrent de nouveaux
chantiers qui ne sont pas explorés par les benchmark (et
en ferment certains). On voit par exemple qu’une idée
populaire dans les systèmes NoSQL est de laisser la consistance
des données se dégrader pour une amélioration
de la disponibilité. Or les standards de benchmark ne proposent
pas de tels relâchements de la consistance et ne
permettent donc pas de profiter des avantages certains de
ces démarches.
Une démarche difficile à mettre en place. Mettre en
place un benchmark qui serait adapté à tout SGBD est une
tâche trop complexe voire impossible:
• Les adeptes des SGBDRs traditionnels n’acceptent
pas l’abandon de la notion de transactions or cette
fonction bien souvent omise dans les nouveaux
SGBDs ne peut être mise en place par l’ application
de benchmark.
7
• Tous les SGBDRs traditionnels sont fort similaires.
Pour être les plus performants à un benchmark, les
responsables du SGBD peuvent adapter quelques
paramètres divers, mais la nature, la sémantique des
données et transactions restent communes pour tous
les systèmes. Cette règle ne peut être respectée
pour les nouveaux systèmes plus exotiques. De par
cette subjectivité, on ne peut donc plus assurer qu’un
benchmark représente effectivement une application
de la vie réelle.
Nous remarquons aussi que la démarche voulue par
les nouveaux SGBDs est d’être la plus simple possible
(leur performance s’en trouvant augmentée) et de
déléguer toute opération sur les données à des couches
supérieures. Á ce titre, de manière similaire à [3],
nous pensons qu’il est intéressant de connaître les performances
pures du SGBD c’est-à-dire les opérations
CRUD. La démarche suivante, indépendante de celle-ci,
est d’étudier les systèmes (de Map/Reduce) par exemple)
permettant de traiter de manière plus complexe les
données.
Enfin, une dernière critique reste à faire sur la manière
dont un benchmark peut traiter le problème de l’élasticité
d’un SGBD. Cette question reste ouverte. En effet, il
s’agit de considérer deux aspects:
• le temps de stabilisation, c’est-à-dire le temps que
prend le système à se stabiliser lorsqu’on rajoute ou
retire une instance à la volée.
• Le second aspect est d’analyser la manière dont le
système réagit une fois le système stabilisé.
Á notre connaissance, aucune étude ne distingue ces
deux aspects. Certaines tendent à oublier le temps de stabilisation
à l’aide d’outils statistiques, d’autres tendent le
négliger tout simplement.
Dans des travaux futurs, nous tenterons d’ isoler ces
deux composants et les étudier indépendamment. En
réduisant nos tests aux opérations CRUD, nous espérons
pouvoir détacher les nouveaux concepts introduits par les
nouveaux SGBDs tels que le degré de consistance, la
méthode de stockage et de réplication sur l’élasticité (en
isolant chaque paramètre).
References
[1] Amazon - page d’accueil. http://www.amazon.
com, consulté le 12 décembre 2010.
[2] Apache Cassandra - page d’accueil. http:
//cassandra.apache.org, consulté le 12
décembre 2010.

[3] Apache Cassandra - Wiki, API. http://wiki.
apache.org/cassandra/API, consulté le 15
décembre 2010.
[4] Apache Cassandra - Wiki, Getting Started.
http://wiki.apache.org/cassandra/
GettingStarted, consulté le 15 décembre 2010.
[5] D. Abadi. Problems with CAP, and Yahoo’s
Little Known NoSQL System. http:
//www.massivedatanews.com/content/
problems-cap-and-yahoos-little-known-nosql-system,
consulté le 15 décembre 2010.
[6] E. Tam R. Ramakrishnan et R. Sears B F Cooper,
A. Silberstein. Benchmarking Cloud Serving systems
with ycsb. In SoCC ’10: Proceedings of the 1st ACM
Symposium on Cloud Computing, page de 143 à 154,
2010.
8

B.4.2 L’entrée dans le blog d’ Euranova
Ci dessous, vous trouverez une retranscription d’un entrée dans le blog du département
Recherche et Développement d’ Euranova. C’est une entrée que j’ai écrite lors de mon stage
et qui a été relue et publiée par le directeur du département : Sabri Skhiri :
99

The R&D director’s blog
Euranova R&D blog
Data storage elasticity – quick view on master thesis
work (part 2)
April 18, 2011, 1:10 pm
In this second part I welcome Nicolas Degroodt who explains how he has extended
the YCSB for implementing TPC-C benchmark for NoSQL. In this post we call DBMS
a storage framework whether it is RDBMS or a NoSQL.
When dealing with new DBMS in a cloud environment, traditional benchmarks (like
TPC-C [1]) need to be re-designed. First of all, the semantic of their queries is too
rigid and cannot fit, as they are defined, with a NoSQL system. For example, a keyvalue
store cannot execute immediately a GROUP BY SQL statement. These queries
need to be translated regarding to the tested storage.
Secondly, their data-schemas are oriented and designed for relational databases.
Storing data, as they are described by TPC, in a non-relational databases would be
weak in terms of performance. The data-schema needs to be modeled by taking
into account the underlying DBMS, its indexation schema, its data sharding policy,
etc.
We proposed to adapt the TPC-C to these new DBMS and to study the related
issues. We proposed to describe a new benchmark, TPC-C like, which defines data
and queries as functional values (instead of semantic fields).
On the other hand, Yahoo Cloud Serving Benchmark (YCSB) proposes a framework
[2] and a common set of workloads for evaluating the performance the performance
of different key-value and cloud serving stores. Their approach consists of testing
DBMS considering only their common basic functions (i.e. put, get, delete
operation).

The Yahoo! Cloud Serving Benchmark
The modular architecture of YCSB (see figure above from [3]) is very powerful and
easy to configure, for instance, scenari are defined by in-line parameters such as
number of clients, etc. We adapted this architecture to meet our requirements: (1)
we added a pseudo-random data generator module for producing not only data but
also parameters for TPC-C transactions, and (2) we added a queries generator
module which produces queries for putting data into the data base (according to
the data schema) and for attacking the DBMS (according to its syntax).
The adaptation to the TPC-C
benchmark.
We tested successfully this adapted framework in the Euranova lab on Cassandra
0.5 deployed on a 4-nodes cluster. For testing another DBMS, we need to adapt the
Queries Generator and the DB Interface Layer modules. In our next work, we will
continue to deal with YCSB and focusing on the elasticity aspects ( definition,
criteria and test scenario).
References:
[1] Transaction Processing Performance Council: http://www.tpc.org/
[2] YCSB Application, https://github.com/brianfrankcooper/YCSB
[3] YCSB Article, http://research.yahoo.com/files/ycsb.pdf
Category: NoSQL | Comment (RSS) | Trackback