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

Dimension: px
Commencer à balayer dès la page:

Download "L élasticité des bases de données sur le cloud computing"

Transcription

1 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

2 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.

3 Table des matières 1 Introduction Contexte et objectifs du mémoire Structure du mémoire Contributions du mémoire Le cloud computing et ses services Contexte Origine et modèles Caractéristiques spécifiques et capacités Amazon Définition du cloud Propriétés fondamentales des services La haute disponibilité Passer à l échelle Le théorème CAP Etude comparative de différents systèmes de gestion des bases de données Classification des systèmes Le modèle de données Les choix CAP et PACELC La réplication synchrone ou asynchrone Le modèle de consistance Le modèle de requêtes Les bases de données relationnelles distribuées Le modèle de données relationnel Les propriétés ACID MySQL Cluster Autres solutions SQL Les solutions SQL-MR Le mouvement NoSQL Les modèles de données BASE en réponse à ACID MongoDB Modèle de données Choix CAP et PACELC Vue d ensemble de l architecture

4 i Réplication des données Modèle de consistance Modèle de requête Cassandra Modèle de données Le choix CAP et PACELC Vue d ensemble de l architecture Réplication des données Modèle de consistance Modèle de requêtes HBase The Hadoop Distributed Filesystem Modèle de données Choix CAP et PAELC Vue d ensemble de l architecture Réplication des données Consistance des données Modèle de requêtes Voldemort Comparaison des différents systèmes Bases de données et élasticité Etat de l art Problèmes liés à la mesure de l élasticité Notre solution Scénario de tests Paramètres Application Expériences Considérations complémentaires Montée à l échelle Descente à l échelle Analyse des résultats Les travaux de Thibault Dory Méthodologie Définitions Résultats Analyse Conclusion - Comparaison Critiques de l approche comparative Vers une nouvelle approche Influence des choix techniques sur l élasticité Modèle de données Modèle de consistance Finalement ou fortement consistant Le verrouillage d entrée et la consistance transactionnelle

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

6 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 vu 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

7 2 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.

8 3 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é.

9 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 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

10 5 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

11 6 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 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é 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,

12 7 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.

13 8 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.

14 9 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

15 10 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 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 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.

16 11 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.

17 12 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 Remarquons que S. Gilbert et N. Lynch démontrent en 2002 cette conjecture pour un modèle asynchrone de systèmes distribués [26].

18 13 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 You can have at most two of these properties for any shared-data system Tolerance to network Partitions 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

19 14 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. traduit de [26] Discussion 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]

20 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 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

21 on-oltp applications that ured and unstructured data ciency than RDBMs and continuing to operate) failures cause the system to fail) stem ncing, garbage collection ypertable) ystem Node Tablet Server n FS n 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 to achieve plus abstraite, éloignée des composants physiques horizontal et plus scalability. procheit Tip Hot de attains l application this by reducing en verra ses performances réduites mais une utilisationtransactional bien plus aisée. semantics and referential integrity. Node 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. Topology (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. Consistency Availability RDBMs (Oracle, MySQL), Aster Data, Green Plum, Vertica C mongodb, Terrastore, Datastore, Hypertable, Hbase, Redis, Berkeley DB, MemcacheDB, Scalaris Relational Key-Value Column-Oriented Document-Oriented Pick Any Two P Partition tolerance A 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. 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 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).

22 17 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 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) 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.

23 18 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 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 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 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.

24 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 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

25 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.

26 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.

27 22 Figure 3.3 BD orientées documents [30] Figure 3.4 BD orientées colonne [30] Le modèle en graphe 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. Figure 3.5 BD orientées graphe [30] BASE en réponse à ACID 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-

28 23 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é 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 }

29 24 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 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 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.

30 25 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 (2- phase 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 200M B. 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 shard 1 users nom : Skhiri nom : Zimányi shard 4 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 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.

31 26 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.

32 27 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]

33 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) 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 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

34 29 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] 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

35 30 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 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 à

36 31 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 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 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

37 32 é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 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.

38 33 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) 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 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

39 34 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 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.

40 35 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 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 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.

41 36 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 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.

42 37 On voit donc un nouveau modèle asynchrone, où la transmission de données se fait en cascade 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]) 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.

43 38 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

44 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

45 40 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.

46 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 n i, le nombre initial d instances d un service, n f le nombre d instances du service après un passage à l échelle, son apport terme de ressources se définit comme n = n f n i n i 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.

47 Scénario de tests Considérons un SGBD de n i instances préalablement chargé de données.a l instant t 0, 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 t 0, 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 t m, une modification (ajout ou retrait de n f n i instances) est effectuée sur le système. Arbitrairement, nous effectuons cette modification après 20 minutes. Le système se compose alors de n f 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 ([t i, t m ]), une phase d adaptation à la modification ([t m, t m + t]) et une phase de stabilisation du système suite à la modification ([t m + t, t f ]) temps de latence l n i phase d'attaque phase d'adaptation phase de stabilisation l n f Δt t i t m 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

48 43 temps de latence l n f phase d'attaque phase d'adaptation phase de stabilisation l ni Δt t i t m t f temps Figure 4.4 Résultat supposé du scénario pour le retrait d instances Phase d attaque Le système étant stable à l instant t i, 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 [t i, t m ]. Cette moyenne l ni reflétera le comportement du système composé de n i instances. Définition 11 (l ni ). l ni = 1 tm m i t=ti l(t) Phase d adaptation A l instant t m, 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.

49 44 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 t m + 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 l nf représentative du comportement du système composé de m instances. Définition 12 (l nf ). l nf = 1 tf m i t=t l(t) m+ t Paramètres 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 l ni et l nf l ni est la moyenne arithmétique des temps de latence du système composé de n i instances (avant modification - voir définition 11). l nf, elle, est la moyenne arithmétique des temps de latence du système composé de n f 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 n i à n f instances. Définissons la variation des temps de latence l = l nf l ni, le coefficient d adaptation µ se définit comme suit :

50 45 temps de latence α 2 α 1 l i lambda l n i mu Δt l n f t m t impact temps Figure 4.5 Période d adaptation théorique supposée Définition 13 (Le coefficient d adaptation µ). µ = l ln i n Par exemple, imaginons un SGBD parfaitement élastique (sans considérer le temps d adaptation) tel que lorsqu on double son nombre d instances (n f = 2 n i ), les temps de latence soient réduits de moitié (l nf = ln i 2 ) et dès lors µ i,j = 0.5. A contrario, un système dont les performances ne seraient modifiées (l nf = l ni ) 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

51 46 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 t m et finit lorsque les temps de réponse du système composé de n f 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 (l i ) et le temps de latence moyen du système initial l ni. Définition 14 (L impact maximal λ). λ = l i l ni 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 (t m, l ni ) et (t impact, l i ). La droite de descente des temps de latence, elle, est définie par les deux points (t impact, l i ) et (t m + t, l nf ). Nous définissons α 1 et α 2 comme suit : Définition 15 (α 1 ). α 1 = t impact t m l i l ni Définition 16 (α 2 ). α 2 = (tm+ t) t impact l nf l i

52 47 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 alpha 1 et alpha 2. 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

53 48 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 l(t) dt tm 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 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

54 Symbole Noms Unité Formule µ Coefficient d adaptation Sans unité µ = t Temps d adaptation Secondes Déterminé à l œil nu après l expérience λ Impact maximal Sans unité λ = l i l ni α 1 Montée des temps de latence Sans unité α 1 = t impact t m l i l ni α 2 Descente des temps de latence Sans unité α 2 = (tm+ t) t impact π Perturbation d adaptation Sans unité π = l ln i n l nf l i R tm+ t l(t) dt tm l t 2 Table 4.1 Tableau récapitulatif des paramètres définissant l élasticité 49 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

55 50 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 à user 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 F m et F M (données en paramètres). Chaque champ est nommé field0, field1, etc.. La taille des champs L sera, elle aussi, comprise entre 2 valeurs L m et L M (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 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).

56 51 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 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 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 Nous analyserons ensuite ces paramètres et leurs valeurs 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.)

57 52 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 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].

58 Le premier nœud est intégré li temps de réponse (millisecondes) Montée des temps de latence Les noeuds sont actifs Ajout de 2 nouveaux noeuds descente des temps de latence Les 2 nœuds sont intégrés Le système a assimilé la modification l ni l nf Δt 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 % 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.

59 54 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 % B % 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.

60 li temps de reponse (millisecondes) Ajout de 2 nouveaux noeuds Le système a assimilé la modification l ni l nf Δt temps (secondes) 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)

61 56 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 li temps de reponse (millisecondes) Ajout de 2 nouveaux noeuds Le système a assimilé la modification l ni l nf Δt 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 % C % , 38 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.

62 57 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 li temps de reponse (millisecondes) 16.1 Ajout de 2 nouveaux noeuds Le système a assimilé la modification l ni l nf Δt temps (secondes) 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 % C % , 38 D % Table 4.5 Paramètres des expériences A, C et D

63 58 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 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 % 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).

64 li temps de reponse (millisecondes) Retrait d'un noeud Le système a assimilé la modification l ni l nf Δt temps (secondes) 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 µ t(sec) λ α 1 α 2 π E % F % Table 4.7 Paramètres des expériences E et F Expérience G 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.

65 li temps de reponse (millisecondes) Retrait d'un noeud Le système a assimilé la modification l ni l nf Δt temps (secondes) 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 µ t(sec) λ α 1 α 2 π E % G % Table 4.8 Paramètres des expériences E et G Expérience H 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.

66 li temps de reponse (millisecondes) Retrait d'un noeud Le système a assimilé la modification l ni l nf Δt 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 % G % H % Table 4.9 Paramètres des expériences E, G et H Analyse des résultats Dans cette section, nous analyserons les résultats de nos expériences. Ces résultats sont repris dans la table 4.10.

67 li temps de reponse (millisecondes) Retrait d'un noeud Le système a assimilé la modification l ni l nf Δt temps (secondes) 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

68 63 Expérience µ t(sec) λ α 1 α 2 π A % B % C % , 38 D % E % F % G % H % 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 X ,1 Ghz Mémoire RAM 8 Gb 8 Gb OS Ubuntu LTS Ubuntu 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 (l ni ) et après modification (l nf ) : Premièrement, (l ni ) et (l nf ) 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, l nf est la moyenne arithmétique des temps de latences de sur l intervalle [t m + t, t f ]. Or t est sujet à interprétation humaine, ceci peut donc discréditer l nf 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 l ni et l nf, la médiane a été considérée mais dans nos expériences, médianes et moyennes restent fort proches.

69 64 La forme de l adaptation (α 1, l i, α 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 ). Considérant l ajout d instances, ceci peut s expliquer assez facilement. Les nouveaux nœuds ne peuvent être accédés que lorsque les transferts internes de données sont terminés. Durant ce temps, on ne tire aucun bénéfice des nouveaux et perdons en performance (à cause du trafic interne) tandis que dès que ces données sont assimilées, on peut prendre pleinement profit de ces nouvelles instances. La même logique peut s appliquer au retrait d une instance. Pour la charge de travail forte en lecture, la tendance semble s inverser ( α 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.

70 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 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 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]

71 66 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. Figure 4.17 Surfaces utilisées pour caractériser l élasticité[41] La montée à l échelle 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. Scalability N = Average 2N Average N Average N 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). Average N (resp. Average 2N ) 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.

72 67 Figure 4.18 T. Dory - Scénario de tests [41] Résultats Considérations supplémentaires 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 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.

73 68 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.

74 69 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

75 70 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-

76 71 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 Hbase , 3 MongoDB à 24 nœuds Cassandra 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

77 72 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 et 4.5.4

78 73 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 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.

79 74 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 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 n i et n f les nombres initial et final d instances, Li et L f 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.

80 75 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 t m à 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).

81 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 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 SQL Complexité du modèle de données Voldemort MongoDB Cassandra Hbase 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

82 77 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 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) 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

83 78 (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.

84 79 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.

85 80 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.

86 81 - 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é

87 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

88 83 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

89 é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

90 Bibliographie [1] Amazon Elastic Compute Cloud, page d accueil. consulté le 8 avril [2] Amazon Mechanical Turk, page d accueil. https://www.mturk.com/mturk/welcome, consulté le 3 mai [3] Apache Cassandra - Operations. Operations,consulté le 2 mai [4] Apache Cassandra - Wiki. le 25 avril [5] Apache Cassandra, page d accueil. consulté le 2 mai [6] Apache HBase, page d accueil. consulté le 2 mai [7] Cassandra Mailing List - How to Decommission Two Slow Nodes? how-to-decommission-two-slow-nodes-td html, consulté le 28 mai [8] Introduction à MySQL Cluster. ndbcluster.html, consulté le 21 août [9] MongoDB Documentation, MapReduce. MapReduce, consulté le 5 mai [10] MongoDB, page d accueil. consulté le 2 mai [11] ScaleDB, page d accueil. consulté le 24 septembre [12] Voldemort, page d accueil. consulté le 4 mai [13] VoltDB, page d accueil. consulté le 24 septembre [14] HBase, ACID Semantics, 6 mai html, consulté le 12 mai [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, [16] D. Abadi. Problems with CAP, and Yahoo s Little Known NoSQL System, 23 décembre problems-with-cap-and-yahoos-little.html, consulté le 24 février [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,

91 86 [18] E. Brewer. Towards Robust Distributed Systems. In PODC 00 : Proceedings of the Nineteenth Annual ACM Symposium on Principles of Distributed Computing. ACM, [19] J. Browne. Brewer s CAP Theorem, 11 janvier article/viewer/brewers-cap-theorem, consulté le 24 février [20] R. Cattell. Scalable SQL and NoSQL Data Stores. page 1 à 16, Décembre [21] K. Chodorow. Scaling MongoDB. O Reilly Media, [22] E. Ciurana. Getting Started with NoSQL and Data Scalability. 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 consulté le 8 mars [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, [25] K. Chodorow et M. Dirolf. MongoDB, The Definitive Guide. O Reilly Media, Septembre [26] S Gilbert et N. Lynch. Brewer s Conjecture and the Feasibility of Consistent Available Partition-Tolerant Web Services. In ACM SIGACT News, [27] A. Lakshman et P. Malik. Cassandra - A Decentralized Structured Storage System. SIGOPS Oper. Syst. Rev., 44 :de 35 à 40, avril [28] J. Dean et S. Ghemawat. MapReduce : Simplified Data Processing on Large Clusters. Commun. ACM, 51(1) :de 107 à 113, [29] P. Mell et T. Grance. The NIST Definition of Cloud Computing. National Institute of Standards and Technology, 53(6) :de 1 à 50, juillet [30] M. Figuière. NoSQL Europe : Tour d horizon des bases de données NoSQL, 21 avril nosql-europe-tour-dhorizon-des-bases-de-donnees-nosql/, consulté le 12 août [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 [32] P. Grange. Le livre blanc du cloud computing. Syntec informatique, page de 1 à 19, [33] E. Hewitt. Cassandra : The Definitive Guide. O Reilly, First Edition edition, [34] T. Hoff. VoltDB Decapites Six SQL Urban Myths And Delivers Internet Scale OLTP In The Process, le 25 juin /28/voltdb-decapitates-six-sql-urban-myths-and-delivers-internet.html, consulté le 12 août [35] D. Kushal. MongoDB Strategies for the Disk-averse. com/2011/02/09/mongodb-strategies-for-the-disk-averse, consulté le 18 février [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.

92 87 [37] S. Lutz. The Future of Cloud Computing Opportunities. European Cloud Computing Beyond 2010, page de 1 à 67, [38] D. Merriman. MongoDB : Sharding Introduction. DOCS/Sharding+Introduction, consulté le 28 février [39] D. Merriman. On Distributed Consistency, mars consulté le 05 mars [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 [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 consulté le 19 février [43] T. White. Hadoop : The Definitive Guide. O Reilly, Second Edition edition, october 2010.

93 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

94 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

95 90 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 B.4.1 Cette section regroupe les différents documents relatifs à ce stage. 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.

96 Bancs d essais pour nouvelles bases de données sur cloud Nicolas Degroodt Faculté des sciences, Université libre de Bruxelles Belgique En partenariat avec Euranova Abstract 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 reproductibilité 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)

97 base 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 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. 2

98 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. 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. 3

99 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. 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 4

100 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. 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. 5

101 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. 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 , et 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, 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

102 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. 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. com, consulté le 12 décembre [2] Apache Cassandra - page d accueil. http: //cassandra.apache.org, consulté le 12 décembre

NoSQL : hype ou innovation? Grégory Ogonowski / Recherches Octobre 2011

NoSQL : hype ou innovation? Grégory Ogonowski / Recherches Octobre 2011 NoSQL : hype ou innovation? Grégory Ogonowski / Recherches Octobre 2011 Sommaire Introduction Théorème CAP NoSQL (principes, mécanismes, démos,...) Ce que nous avons constaté Recommandations Conclusion

Plus en détail

Introduction aux bases de données NoSQL

Introduction aux bases de données NoSQL Introduction aux bases de données NoSQL Khaled Tannir ets@khaledtannir.net Montréal - 23 Juillet 2015 Qui suis-je? Khaled TANNIR Big Data Architect Lead 20 ans d expérience ets@khaledtannir.net @khaled_tannir

Plus en détail

Groupe de Discussion Big Data Aperçu des technologies et applications. Stéphane MOUTON stephane.mouton@cetic.be

Groupe de Discussion Big Data Aperçu des technologies et applications. Stéphane MOUTON stephane.mouton@cetic.be Groupe de Discussion Big Data Aperçu des technologies et applications Stéphane MOUTON stephane.mouton@cetic.be Recherche appliquée et transfert technologique q Agréé «Centre Collectif de Recherche» par

Plus en détail

NoSQL. Introduction 1/23. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur)

NoSQL. Introduction 1/23. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur) 1/23 2/23 Anne-Cécile Caron Master MIAGE - BDA 1er trimestre 2013-2014 I : Not Only SQL, ce n est pas du relationnel, et le contexte d utilisation n est donc pas celui des SGBDR. I Origine : recherche

Plus en détail

Bases de données documentaires et distribuées Cours NFE04

Bases de données documentaires et distribuées Cours NFE04 Bases de données documentaires et distribuées Cours NFE04 Cloud et scalabilité Auteurs : Raphaël Fournier-S niehotta, Philippe Rigaux, Nicolas Travers prénom.nom@cnam.fr Département d informatique Conservatoire

Plus en détail

AVRIL 2014. Au delà de Hadoop. Panorama des solutions NoSQL

AVRIL 2014. Au delà de Hadoop. Panorama des solutions NoSQL AVRIL 2014 Panorama des solutions NoSQL QUI SOMMES NOUS? Avril 2014 2 SMILE, EN QUELQUES CHIFFRES 1er INTÉGRATEUR EUROPÉEN DE SOLUTIONS OPEN SOURCE 3 4 NOS EXPERTISES ET NOS CONVICTIONS DANS NOS LIVRES

Plus en détail

Les activités de recherche sont associées à des voies technologiques et à des opportunités concrètes sur le court, moyen et long terme.

Les activités de recherche sont associées à des voies technologiques et à des opportunités concrètes sur le court, moyen et long terme. Mémoires 2010-2011 www.euranova.eu EURANOVA R&D Euranova est une société Belge constituée depuis le 1er Septembre 2008. Sa vision est simple : «Être un incubateur technologique focalisé sur l utilisation

Plus en détail

Cartographie des solutions BigData

Cartographie des solutions BigData Cartographie des solutions BigData Panorama du marché et prospective 1 1 Solutions BigData Défi(s) pour les fournisseurs Quel marché Architectures Acteurs commerciaux Solutions alternatives 2 2 Quels Défis?

Plus en détail

Le Cloud Computing avec Amazon Web Services

Le Cloud Computing avec Amazon Web Services Le Cloud Computing avec Amazon Web Services Jeff Barr Traduit par Isabelle Hurbain-Palatin, avec la contribution technique de Dominique Colombani Pearson Education France a apporté le plus grand soin à

Plus en détail

NoSQL Faut-il franchir le pas?

NoSQL Faut-il franchir le pas? NoSQL Faut-il franchir le pas? Guillaume HARRY Journées rbdd Octobre 2015 Sommaire 1. Evolution des bases de données 2. Le mouvement NoSQL 3. Les grandes familles du NoSQL 4. Aller ou non vers le NoSQL?

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBLITÉ CONTINUE ET MOBILITÉ DES DONNÉES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

Les participants repartiront de cette formation en ayant une vision claire de la stratégie et de l éventuelle mise en œuvre d un Big Data.

Les participants repartiront de cette formation en ayant une vision claire de la stratégie et de l éventuelle mise en œuvre d un Big Data. Big Data De la stratégie à la mise en oeuvre Description : La formation a pour objet de brosser sans concession le tableau du Big Data. Les participants repartiront de cette formation en ayant une vision

Plus en détail

Systèmes Répartis. Pr. Slimane Bah, ing. PhD. Ecole Mohammadia d Ingénieurs. G. Informatique. Semaine 24.2. Slimane.bah@emi.ac.ma

Systèmes Répartis. Pr. Slimane Bah, ing. PhD. Ecole Mohammadia d Ingénieurs. G. Informatique. Semaine 24.2. Slimane.bah@emi.ac.ma Ecole Mohammadia d Ingénieurs Systèmes Répartis Pr. Slimane Bah, ing. PhD G. Informatique Semaine 24.2 1 Semestre 4 : Fev. 2015 Grid : exemple SETI@home 2 Semestre 4 : Fev. 2015 Grid : exemple SETI@home

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBILITE CONTINUE ET MOBILITE DES DONNEES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

Programmation parallèle et distribuée

Programmation parallèle et distribuée Programmation parallèle et distribuée (GIF-4104/7104) 5a - (hiver 2015) Marc Parizeau, Département de génie électrique et de génie informatique Plan Données massives («big data») Architecture Hadoop distribution

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

Architectures informatiques dans les nuages

Architectures informatiques dans les nuages Architectures informatiques dans les nuages Cloud Computing : ressources informatiques «as a service» François Goldgewicht Consultant, directeur technique CCT CNES 18 mars 2010 Avant-propos Le Cloud Computing,

Plus en détail

Sauvegarde et restauration en environnement VMware avec Avamar 6.0

Sauvegarde et restauration en environnement VMware avec Avamar 6.0 Livre blanc Sauvegarde et restauration en environnement VMware avec Avamar 6.0 Analyse détaillée Résumé Dans les entreprises, les environnements virtuels sont de plus en plus déployés dans le cloud. La

Plus en détail

CNAM 2010-2011. Déploiement d une application avec EC2 ( Cloud Amazon ) Auteur : Thierry Kauffmann Paris, Décembre 2010

CNAM 2010-2011. Déploiement d une application avec EC2 ( Cloud Amazon ) Auteur : Thierry Kauffmann Paris, Décembre 2010 CNAM 2010-2011 Déploiement d une application avec EC2 ( Cloud Amazon ) Auteur : Thierry Kauffmann Paris, Décembre 2010 Déploiement d une application dans le cloud. 1. Cloud Computing en 2010 2. Offre EC2

Plus en détail

NoSQL. Introduction 1/30. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur)

NoSQL. Introduction 1/30. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur) 1/30 2/30 Anne-Cécile Caron Master MIAGE - SGBD 1er trimestre 2014-2015 I : Not Only SQL, ce n est pas du relationnel, et le contexte d utilisation n est donc pas celui des SGBDR. I Origine : recherche

Plus en détail

Hibernate vs. le Cloud Computing

Hibernate vs. le Cloud Computing Hibernate vs. le Cloud Computing Qui suis-je? Julien Dubois Co-auteur de «Spring par la pratique» Ancien de SpringSource Directeur du consulting chez Ippon Technologies Suivez-moi sur Twitter : @juliendubois

Plus en détail

NoSQL : en Quête de Performances Extrêmes

NoSQL : en Quête de Performances Extrêmes NoSQL : en Quête de Performances Extrêmes Alors que l audience du web croît sans cesse, les applications Internet à succès ont été confrontées aux mêmes problèmes de base de données : si les serveurs web

Plus en détail

e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France

e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France Sommaire Cloud Computing Retours sur quelques notions Quelques chiffres Offre e need e need Services e need Store

Plus en détail

Programmation parallèle et distribuée

Programmation parallèle et distribuée Programmation parallèle et distribuée (GIF-4104/7104) 5a - (hiver 2014) Marc Parizeau, Département de génie électrique et de génie informatique Plan Mégadonnées («big data») Architecture Hadoop distribution

Plus en détail

AVIS COMMUN DE LA CHAMBRE DE COMMERCE ET DE LA CHAMBRE DES METIERS

AVIS COMMUN DE LA CHAMBRE DE COMMERCE ET DE LA CHAMBRE DES METIERS Luxembourg, le 17 décembre 2012. CHAMBRE DE COMMERCE CHAMBRE DES METIERS Objet : Projet de loi portant modification de l article 567 du Code de commerce. (4037SBE) Saisine : Ministre de la Justice (8 octobre

Plus en détail

La virtualisation par Stéphane Dutot, Chef de produit de Internet Fr

La virtualisation par Stéphane Dutot, Chef de produit de Internet Fr Communiqué de Presse Massy, le 31 Mars 2009 La virtualisation par Stéphane Dutot, Chef de produit de Internet Fr Depuis quelques années, une nouvelle technologie révolutionne l informatique : la virtualisation.

Plus en détail

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE

ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Mémoires 2010-2011 www.euranova.eu MÉMOIRES ETUDE ET IMPLÉMENTATION D UNE CACHE L2 POUR MOBICENTS JSLEE Contexte : Aujourd hui la plupart des serveurs d application JEE utilise des niveaux de cache L1

Plus en détail

SAP HANA: note de synthèse

SAP HANA: note de synthèse Préface: Au cœur des nombreux défis que doivent relever les entreprises, l informatique se doit de soutenir les évolutions, d aider au développement de nouveaux avantages concurrentiels tout en traitant

Plus en détail

NoSql. Principes. Google (Map Reduce, Big Table) et Amazone (Dynamo) pour faire face à la monté en charge liée au BigData

NoSql. Principes. Google (Map Reduce, Big Table) et Amazone (Dynamo) pour faire face à la monté en charge liée au BigData NoSql Principes Google (Map Reduce, Big Table) et Amazone (Dynamo) pour faire face à la monté en charge liée au BigData Les SGBD NoSql partagés ne peuvent satisfaire que 2 critères au plus NoSql Les transactions

Plus en détail

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 MapReduce Malo Jaffré, Pablo Rauzy ENS 16 avril 2010 Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 Qu est ce que c est? Conceptuellement Données MapReduce est un framework de calcul distribué

Plus en détail

Cloud Computing : Utiliser Stratos comme PaaS privé sur un cloud Eucalyptus

Cloud Computing : Utiliser Stratos comme PaaS privé sur un cloud Eucalyptus Cloud Computing : Utiliser Stratos comme PaaS privé sur un cloud Eucalyptus Mr Romaric SAGBO Ministère de l'economie et des Finances (MEF), Bénin SWD Technologies Email : rask9@yahoo.fr Tél : +229 97217745

Plus en détail

Introduction aux SGBDR

Introduction aux SGBDR 1 Introduction aux SGBDR Pour optimiser une base Oracle, il est important d avoir une idée de la manière dont elle fonctionne. La connaissance des éléments sous-jacents à son fonctionnement permet de mieux

Plus en détail

Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives

Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives Module 7 : Familles de bases de données NoSQL Les bases de données relationnelles mises au point dans les

Plus en détail

SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID

SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID GUIDE DE CONCEPTION SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID VMware Horizon View 5.2 et VMware vsphere 5.1 - Jusqu à 2 000 bureaux virtuels EMC VSPEX Résumé Le présent guide décrit les composants

Plus en détail

Hébergement MMI SEMESTRE 4

Hébergement MMI SEMESTRE 4 Hébergement MMI SEMESTRE 4 24/03/2015 Hébergement pour le Web Serveurs Mutualités Serveurs Dédiés Serveurs VPS Auto-Hébergement Cloud Serveurs Mutualités Chaque Serveur héberge plusieurs sites Les ressources

Plus en détail

Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives

Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives Module 6 : Changement d échelle et cohérence Les bases de données relationnelles sont mûres : elles ont bientôt

Plus en détail

Tirez plus vite profit du cloud computing avec IBM

Tirez plus vite profit du cloud computing avec IBM Tirez plus vite profit du cloud computing avec IBM Trouvez des solutions de type cloud éprouvées qui répondent à vos priorités principales Points clés Découvrez les avantages de quatre déploiements en

Plus en détail

Qu est ce que le Cloud Computing?

Qu est ce que le Cloud Computing? Qu est ce que le Cloud Computing? Makhlouf Hadji Ingénieur de Recherche Qu est ce que le Cloud Computing? Agenda: Virtualisation des Ressources Introduction au Cloud Computing Caractéristiques du Cloud

Plus en détail

NoSQL. Etat de l art et benchmark

NoSQL. Etat de l art et benchmark NoSQL Etat de l art et benchmark Travail de Bachelor réalisé en vue de l obtention du Bachelor HES par : Adriano Girolamo PIAZZA Conseiller au travail de Bachelor : David BILLARD, Professeur HES Genève,

Plus en détail

Cloud Computing Concepts de base Année académique 2014/15

Cloud Computing Concepts de base Année académique 2014/15 Concepts de base Année académique 2014/15 Qu'est que le? online 2 Qu'est que le? Cela s'est-il produit auparavant? Innovation Produit Service 3 Qu'est que le? Considérons-le comme-ça... Crée ta propre

Plus en détail

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales Ecole des Hautes Etudes Commerciales HEC Alger Évolution des SGBDs par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Evolution des SGBDs Pour toute remarque, question, commentaire

Plus en détail

Département informatique de l IUT (de l université) de Bordeaux Cours de Bases de Données : NoSQL 19 août 2015 Olivier Guibert. NoSQL.

Département informatique de l IUT (de l université) de Bordeaux Cours de Bases de Données : NoSQL 19 août 2015 Olivier Guibert. NoSQL. Département informatique de l IUT (de l université) de Bordeaux Cours de Bases de Données : NoSQL 19 août 2015 Olivier Guibert NoSQL Not only non relational Plan Généralités SGBD Relationnel Théorème CAP

Plus en détail

Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud. Grid and Cloud Computing

Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud. Grid and Cloud Computing Chapitre 1. Infrastructures distribuées : cluster, grilles et cloud Grid and Cloud Computing Problématique Besoins de calcul croissants Simulations d'expériences coûteuses ou dangereuses Résolution de

Plus en détail

L informatique des entrepôts de données

L informatique des entrepôts de données L informatique des entrepôts de données Daniel Lemire SEMAINE 14 NoSQL 14.1. Présentation de la semaine On construit souvent les entrepôts de données en utilisant des systèmes de bases de données relationnels

Plus en détail

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES

Plus en détail

10/04/2011. Serveur de données. Serveur de données. Client. Programme d'application Logiciel intermédiaire Pilote de télécommunication.

10/04/2011. Serveur de données. Serveur de données. Client. Programme d'application Logiciel intermédiaire Pilote de télécommunication. 1 BD locale BD locale Programme d'application Logiciel intermédiaire Client SGBD réparti Logiciel intermédiaire données SGBD réparti Logiciel intermédiaire données 2 Bénéfices potentiels Performance Fiabilité

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

ENVIRONNEMENTS ORACLE CRITIQUES AVEC VMAX 3

ENVIRONNEMENTS ORACLE CRITIQUES AVEC VMAX 3 ENVIRONNEMENTS ORACLE CRITIQUES AVEC VMAX 3 AVANTAGES CLES CRITIQUES Puissance Stockage hybride avec des niveaux de service performants optimisés pour le Flash à grande échelle, pour les charges applicatives

Plus en détail

FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE. Database as a Service (DBaaS)

FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE. Database as a Service (DBaaS) FOURNIR UN SERVICE DE BASE DE DONNÉES FLEXIBLE Database as a Service (DBaaS) 1 The following is intended to outline our general product direction. It is intended for information purposes only, and may

Plus en détail

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles

Plus en détail

«Scale-to-fit» Storage

«Scale-to-fit» Storage LIVRE BLANC «Scale-to-fit» Storage Faites évoluer votre stockage de façon totalement transparente grâce au «Scale-to-Fit» de Nimble Storage. Ce livre blanc explique comment les solutions Nimble Storage

Plus en détail

Les technologies du Big Data

Les technologies du Big Data Les technologies du Big Data PRÉSENTÉ AU 40 E CONGRÈS DE L ASSOCIATION DES ÉCONOMISTES QUÉBÉCOIS PAR TOM LANDRY, CONSEILLER SENIOR LE 20 MAI 2015 WWW.CRIM.CA TECHNOLOGIES: DES DONNÉES JUSQU'À L UTILISATEUR

Plus en détail

Technologies du Web. Ludovic DENOYER - ludovic.denoyer@lip6.fr. Février 2014 UPMC

Technologies du Web. Ludovic DENOYER - ludovic.denoyer@lip6.fr. Février 2014 UPMC Technologies du Web Ludovic DENOYER - ludovic.denoyer@lip6.fr UPMC Février 2014 Ludovic DENOYER - ludovic.denoyer@lip6.fr Technologies du Web Plan Retour sur les BDs Le service Search Un peu plus sur les

Plus en détail

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer Bases de Données Réparties Définition Architectures Outils d interface SGBD Réplication SGBD répartis hétérogènes BD réparties Principe : BD locales, accès locaux rapides accès aux autres SGBD du réseau

Plus en détail

Bases de données documentaires et distribuées Cours NFE04

Bases de données documentaires et distribuées Cours NFE04 Bases de données documentaires et distribuées Cours NFE04 Introduction du cours Auteurs : Raphaël Fournier-S niehotta, Philippe Rigaux, Nicolas Travers prénom.nom@cnam.fr Département d informatique Conservatoire

Plus en détail

Enseignant: Lamouchi Bassem Cours : Système à large échelle et Cloud Computing

Enseignant: Lamouchi Bassem Cours : Système à large échelle et Cloud Computing Enseignant: Lamouchi Bassem Cours : Système à large échelle et Cloud Computing Les Clusters Les Mainframes Les Terminal Services Server La virtualisation De point de vue naturelle, c est le fait de regrouper

Plus en détail

Rapport de projet : Interrogation de données hétérogènes.

Rapport de projet : Interrogation de données hétérogènes. Université Montpellier II Sciences et Techniques GMIN332 Gestion de Données Complexes, Master 2 Informatique 2013-2014 Rapport de projet : Interrogation de données hétérogènes. Otmane Nkaira Étudiant en

Plus en détail

PRESENTATION DE LA VIRTUALISATION DE SERVEURS

PRESENTATION DE LA VIRTUALISATION DE SERVEURS PRESENTATION DE LA VIRTUALISATION DE SERVEURS SOMMAIRE QU EST-CE QUE LA VIRTUALISATION? POURQUOI VIRTUALISER? LES AVANTAGES DE LA VIRTUALISATION NOTION DE CONSOLIDATION, RATIONALISATION ET CONCENTRATION

Plus en détail

Etude des outils du Cloud Computing

Etude des outils du Cloud Computing Etude des outils du Cloud Computing Sommaire : Présentation générale.. 2 Définitions. 2 Avantage.. 2 Inconvénients. 3 Types d offres de service Cloud.. 3 Comparaison des services Cloud 4 Conclusion 5 Présentation

Plus en détail

Présentation SERVEUR EN CLUSTER. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13

Présentation SERVEUR EN CLUSTER. Clinkast 4 Avenue du Général de Gaulle F 92360 Meudon (+33) 6 20 44 86 95 (+33) 1 46 30 24 13 Présentation SERVEUR D APPLICATIONS EN CLUSTER Description Un cluster est un ensemble d instances de serveurs d applications combinant haute disponibilité et forte évolutivité. Contrairement à un système

Plus en détail

Cloud et SOA La présence du Cloud révolutionne-t-elle l approche SOA?

Cloud et SOA La présence du Cloud révolutionne-t-elle l approche SOA? Cloud et SOA La présence du Cloud révolutionne-t-elle l approche SOA? Jean-Marc Pierson pierson@irit.fr IRIT, Université de Toulouse Agenda! Le Cloud! Le SOA! Quelle différence!?! Cloud et SOA! Mise en

Plus en détail

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl Dynamic Computing Services solution de backup White Paper Stefan Ruckstuhl Résumé pour les décideurs Contenu de ce White Paper Description de solutions de backup faciles à réaliser pour des serveurs virtuels

Plus en détail

Université de Liège Faculté des Sciences Appliquées Institut Montefiore ETUDE DES FRAMEWORK DISTRIBUÉS DE GRILLES DE DONNÉES

Université de Liège Faculté des Sciences Appliquées Institut Montefiore ETUDE DES FRAMEWORK DISTRIBUÉS DE GRILLES DE DONNÉES Université de Liège Faculté des Sciences Appliquées Institut Montefiore ETUDE DES FRAMEWORK DISTRIBUÉS DE GRILLES DE DONNÉES EN VUED UNE SOLUTION DE STOCKAGE ÉLASTIQUE DANS LE CLOUD En collaboration avec

Plus en détail

Vers une standardisation des accords de niveau de service

Vers une standardisation des accords de niveau de service Vers une standardisation des accords de niveau de service Analyse du référentiel publié par la Commission européenne le 24 juin 2014 «Cloud Service Level Agreement standardisation guidelines» Eléonore

Plus en détail

Cloud Computing : Généralités & Concepts de base

Cloud Computing : Généralités & Concepts de base Cloud Computing : Généralités & Concepts de base Les 24èmes journées de l UR-SETIT 22 Février 2015 Cette oeuvre, création, site ou texte est sous licence Creative Commons Attribution - Pas d Utilisation

Plus en détail

Datomic. La base qui détonne (aka database as a value)

Datomic. La base qui détonne (aka database as a value) Datomic La base qui détonne (aka database as a value) Identité Base de données NoSQL Distribuée ("cloud"!) ACID Annoncée début 2012 Version 0.8.XXXX Rich Hickey et Relevance (Clojure!) Licence privative

Plus en détail

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc

CONNECTIVITÉ. Options de connectivité de Microsoft Dynamics AX. Microsoft Dynamics AX. Livre blanc CONNECTIVITÉ Microsoft Dynamics AX Options de connectivité de Microsoft Dynamics AX Livre blanc Ce document décrit les possibilités offertes par Microsoft Dynamics AX en terme de connectivité et de montée

Plus en détail

Unitt www.unitt.com. Zero Data Loss Service (ZDLS) La meilleure arme contre la perte de données

Unitt www.unitt.com. Zero Data Loss Service (ZDLS) La meilleure arme contre la perte de données Zero Data Loss Service (ZDLS) La meilleure arme contre la perte de données La meilleure protection pour les données vitales de votre entreprise Autrefois, protéger ses données de manière optimale coûtait

Plus en détail

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source Jérôme Petit, Serge Petit & Serli Informatique, ITMatic Jérôme Petit, Serge Petit & SERLI & ITMatic Serli : SSII

Plus en détail

Cloud Computing. Introduction. ! Explosion du nombre et du volume de données

Cloud Computing. Introduction. ! Explosion du nombre et du volume de données Cloud Computing Frédéric Desprez LIP ENS Lyon/INRIA Grenoble Rhône-Alpes EPI GRAAL 25/03/2010! Introduction La transparence d utilisation des grandes plates-formes distribuées est primordiale Il est moins

Plus en détail

Cloud Computing : forces et faiblesses

Cloud Computing : forces et faiblesses Chapitre 7 Cloud Computing : forces et faiblesses 1. Présentation Cloud Computing : forces et faiblesses Le monde informatique a connu une véritable révolution ces dernières années avec l'apparition d'un

Plus en détail

Gestion de données complexes

Gestion de données complexes Master 2 Informatique Spécialité AIGLE Gestion de données complexes Amayas ABBOUTE Gilles ENTRINGER SOMMAIRE Sommaire i 1 - Introduction 1 2 - Technologies utilisées 2 2.1 API Jena........................................

Plus en détail

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

Plus en détail

Optimisations des SGBDR. Étude de cas : MySQL

Optimisations des SGBDR. Étude de cas : MySQL Optimisations des SGBDR Étude de cas : MySQL Introduction Pourquoi optimiser son application? Introduction Pourquoi optimiser son application? 1. Gestion de gros volumes de données 2. Application critique

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi

ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES. Cours Administration des Bases de données M Salhi ARCHITECTURES DES SYSTÈME DE BASE DE DONNÉES Cours Administration des Bases de données M Salhi Architectures des Système de base de données Systèmes centralisés et client-serveur Server System Architectures

Plus en détail

Conception d une infrastructure «Cloud» pertinente

Conception d une infrastructure «Cloud» pertinente Conception d une infrastructure «Cloud» pertinente Livre blanc d ENTERPRISE MANAGEMENT ASSOCIATES (EMA ) préparé pour Avocent Juillet 2010 RECHERCHE EN GESTION INFORMATIQUE, Sommaire Résumé........................................................

Plus en détail

+ = OpenStack Presentation. Raphaël Ferreira - CoFounder. @ enovance. Credits : Thanks to the OpenStack Guys 1

+ = OpenStack Presentation. Raphaël Ferreira - CoFounder. @ enovance. Credits : Thanks to the OpenStack Guys 1 + = OpenStack Presentation Raphaël Ferreira - CoFounder @ enovance Credits : Thanks to the OpenStack Guys 1 INTRODUCTION 2 Les entreprises déploient des clouds pour... Répondre aux besoins de ressources

Plus en détail

Nacira Salvan. Responsable Pôle Architecture Sécurité Direction Infrastructure IT SAFRAN. CRiP Thématique Sécurité de l informatique de demain

Nacira Salvan. Responsable Pôle Architecture Sécurité Direction Infrastructure IT SAFRAN. CRiP Thématique Sécurité de l informatique de demain Nacira Salvan Responsable Pôle Architecture Sécurité Direction Infrastructure IT SAFRAN Nacira.salvan@safran.fr CRiP Thématique Sécurité de l informatique de demain 03/12/14 Agenda Quelques définitions

Plus en détail

Big data et données géospatiales : Enjeux et défis pour la géomatique. Thierry Badard, PhD, ing. jr Centre de Recherche en Géomatique

Big data et données géospatiales : Enjeux et défis pour la géomatique. Thierry Badard, PhD, ing. jr Centre de Recherche en Géomatique Big data et données géospatiales : Enjeux et défis pour la géomatique Thierry Badard, PhD, ing. jr Centre de Recherche en Géomatique Événement 25e anniversaire du CRG Université Laval, Qc, Canada 08 mai

Plus en détail

Un concept multi-centre de données traditionnel basé sur le DNS

Un concept multi-centre de données traditionnel basé sur le DNS Confiez vos activités critiques à un expert S il est crucial pour vos activités commerciales que vos serveurs soient disponibles en continu, vous devez demander à votre hébergeur de vous fournir une solution

Plus en détail

La situation du Cloud Computing se clarifie.

La situation du Cloud Computing se clarifie. Résumé La situation du Cloud Computing se clarifie. Depuis peu, le Cloud Computing est devenu un sujet brûlant, et à juste titre. Il permet aux entreprises de bénéficier d avantages compétitifs qui leur

Plus en détail

Les bases de données relationnelles

Les bases de données relationnelles Bases de données NO SQL et SIG : d un existant restreint à un avenir prometteur CHRISTIAN CAROLIN, AXES CONSEIL CAROLIN@AXES.FR - HTTP://WWW.AXES.FR Les bases de données relationnelles constituent désormais

Plus en détail

Rappel sur les bases de données

Rappel sur les bases de données Rappel sur les bases de données 1) Généralités 1.1 Base de données et système de gestion de base de donnés: définitions Une base de données est un ensemble de données stockées de manière structurée permettant

Plus en détail

Cloud Computing et SaaS

Cloud Computing et SaaS Cloud Computing et SaaS On a vu fleurir ces derniers temps un grands nombre de sigles. L un des premiers est SaaS, Software as a Service, sur lequel nous aurons l occasion de revenir. Mais il y en a beaucoup

Plus en détail

Fiche technique RDS 2012

Fiche technique RDS 2012 Le 20/11/2013 OBJECTIF VIRTUALISATION mathieuc@exakis.com EXAKIS NANTES Identification du document Titre Projet Date de création Date de modification Fiche technique RDS Objectif 02/04/2013 20/11/2013

Plus en détail

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l Siège social : 5 Speen Street Framingham, MA 01701, É.-U. T.508.872.8200 F.508.935.4015 www.idc.com L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i

Plus en détail

Business & High Technology

Business & High Technology UNIVERSITE DE TUNIS INSTITUT SUPERIEUR DE GESTION DE TUNIS Département : Informatique Business & High Technology Chapitre 09 : CC : Cloud Computing Sommaire Introduction... 2 Définition... 2 Les différentes

Plus en détail

Généralités sur les bases de données

Généralités sur les bases de données Généralités sur les bases de données Qu est-ce donc qu une base de données? Que peut-on attendre d un système de gestion de bases de données? Que peut-on faire avec une base de données? 1 Des données?

Plus en détail

Atteindre la flexibilité métier grâce au data center agile

Atteindre la flexibilité métier grâce au data center agile Atteindre la flexibilité métier grâce au data center agile Aperçu : Permettre l agilité du data-center La flexibilité métier est votre objectif primordial Dans le monde d aujourd hui, les clients attendent

Plus en détail

Cloud Computing Maîtrisez la plate-forme AWS - Amazon Web Services

Cloud Computing Maîtrisez la plate-forme AWS - Amazon Web Services Avant-propos 1. Amazon Web Services 11 2. Public concerné et pré-requis 13 3. Périmètre de l'ouvrage 14 4. Objectifs à atteindre 15 Le cloud computing 1. Présentation 17 1.1 Définition 17 1.2 Points forts

Plus en détail

CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise

CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise Alors que les plates-formes PaaS (Platform as a Service) commencent à s imposer comme le modèle privilégié auprès des entreprises

Plus en détail

L UNIVERS INSTANTANÉ:

L UNIVERS INSTANTANÉ: L UNIVERS INSTANTANÉ: Samy Benzekry Speaker Name Title 2011 Hewlett-Packard Development Company, 2010 L.P. Hewlett-Packard Development Company, L.P. The information contained herein is subject to change

Plus en détail

MIF18 - Les SGBD Non-Relationnels

MIF18 - Les SGBD Non-Relationnels MIF18 - Les SGBD Non-Relationnels Fabien Duchateau fabien.duchateau [at] univ-lyon1.fr Université Claude Bernard Lyon 1 2013-2014 Transparents disponibles sur http://liris.cnrs.fr/~ecoquery/dokuwiki/doku.php?id=

Plus en détail

Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long,

Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long, Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long, en fait ça me faisait penser au nom d un certain projet gouvernemental je me suis

Plus en détail

Cloud computing Votre informatique à la demande

Cloud computing Votre informatique à la demande Cloud computing Votre informatique à la demande Thomas RULMONT Définition du Cloud Computing L'informatique dans le nuage (en anglais, cloud computing) est un concept ( ) faisant référence à l'utilisation

Plus en détail

Bases de données réparties

Bases de données réparties Bases de données réparties J. Akoka - I. Wattiau 1 Contexte Technologique : des solutions de communication efficace entre les machines des SGBD assurent la transparence des données réparties standardisation

Plus en détail

Cours 6. Sécurisation d un SGBD. DBA - M1ASR - Université Evry 1

Cours 6. Sécurisation d un SGBD. DBA - M1ASR - Université Evry 1 Cours 6 Sécurisation d un SGBD DBA - M1ASR - Université Evry 1 Sécurisation? Recette d une application Vérification des fonctionnalités Vérification de l impact sur le SI existant Gestion du changement

Plus en détail

CONSOTEL : Leader de l édition TEM grâce aux performances des solutions Oracle

CONSOTEL : Leader de l édition TEM grâce aux performances des solutions Oracle CONSOTEL : Leader de l édition TEM grâce aux performances des solutions Oracle Interview «CONSOTEL» du 11 Octobre 2011, postée sur : http://www.itplace.tv Christian COR, Directeur Associé Brice Miramont,

Plus en détail