Mémoire
Pour l’Obtention du Diplôme de
Post Graduation Spécialisée
PRÉSENTÉ PAR
ACEF MOHAMED
THEME
UTILISATION DU MODELE M...
Dédicaces
A mes parents,
A ma femme,
A ma fille Taghrid Ibtihal,
A mon fils Ahmed Yacine,
A mon fils Maemoun Abdelmounaim,...
Remerciements
Je remercie ALLAH le tout puissant, maître des cieux et de la terre, qui m’a éclairé le
chemin et permis de ...
SOMMAIRE
INTRODUCTION GENERALE ..............................................................................................
II-4 Conclusion..............................................................................................................
IV.3.3. Deuxième cas : Environnement distribué (Cloud).....................................................77
IV.4. Conclu...
INTRODUCTION
3
INTRODUCTION GENERALE
Nous sommes confrontés depuis quelques années à de nouvelles technologies qui
envahissent le monde...
4
Chapitre I
Le BIG DATA,
et le Cloud Computing
5
I.1. Le BIG DATA
I.1.1. Introduction
En quelques années, le volume des données exploité par les entreprises a
considérab...
6
l'étymologie du terme, Big Data voudrait dire « grosses données ». Or, la problématique des «
grosses données », ou donn...
7
Alex Popescu [2] ajoute à cela un quatrième “V”, celui de “variabilité” :
- Variabilité: le format et le sens des donnée...
8
Lucene/Solr,Hbase, Hive, Pig, Cassandra, Mahout, Zookeeper, S4, Storm, Kafka, Flume,
Hama, Giraph, etc.
Outre les sociét...
9
- Les Médias Numériques.
- Les Marchés Financiers.
Et dans la deuxième catégorie on trouve :
- Les Services Publics
- Le...
10
I.1.7. Le stockage
Les difficultés de présentation et stockage de données dans les Data Warhouses vu
leurs formes, type...
11
I.2.2. Les différents services
Le concept « Cloud Computing » est utilisé pour désigner des services, on distingue troi...
12
 Le Cloud privé
C'est un environnement déployé au sein d'une entreprise en utilisant les infrastructures
internes de l...
13
I.3. Conclusion
Nous avons tenté dans ce premier chapitre de comprendre les concepts de «Big Data »
et de « Cloud Compu...
14
Chapitre II.
Le NoSQL
15
II.1. Introduction
On ne peut pas parler de Big Data sans citer le NoSQL, Not Only SQL. Il est venu pour
solutionner le...
16
La manipulation répondue dans le monde de plusieurs types et formes de données et sur
plusieurs plateformes impose deux...
17
temps, les modifications effectuées par A ne sont ni visibles, ni modifiables par B tant que la
transaction A n’est pas...
18
 « Coherence » (Cohérence) :
Tous les clients du système voient les mêmes données au même instant.
 « Availibility » ...
19
Beaucoup d'organisations doivent stocker de grandes quantités de données, la plupart des
SGBD relationnel actuels ne pe...
20
II.2.5. Types de base NoSQL
Il existe une diversité d’approches NoSQL classées en quatre catégories. Ces différents
sys...
21
La structure de l’objet est libre et le plus souvent laissé à la charge du développeur de
l’application (par exemple XM...
22
- Value : c’est le contenu de la colonne. Cette valeur peut très bien être une colonne
elle-même.
Ce type de structure ...
23
L’avantage des bases de données documents est de pouvoir récupérer un ensemble
d’informations structurées hiérarchiquem...
24
II.2.6. Les propriétés de « BASE »
Dans la première partie de ce chapitre consacrée aux notions préliminaires, nous avo...
25
o Gros volume de données (Big Data)
NoSQL est plus évolutif. C’est en effet l’élasticité de ses bases de données NoSQL ...
26
II.3. MapReduce
II.3.1. Introduction
Le traitement des données par un SGBD NoSQL est caractérisé par son stockage dans
...
27
Figure II.5. Les étapes Map et Reduce
II.3.3. Le modèle de programmation
MapReduce consiste en deux fonctions map() et ...
28
À la fin du processus, le nœud d'origine peut recomposer une réponse au problème qui lui
avait été soumis :
reduce(key2...
29
II-4 Conclusion
Nous avons montré dans ce chapitre les différents types de bases de données NoSQL
avec leurs différents...
30
Chapitre III.
HADOOP, HBASE, MONGODB
ET YCSB.
31
III.1. Introduction
Nous nous intéresserons particulièrement dans ce chapitre aux technologies HBASE,
MongoDB, et Hadoo...
32
Hadoop fait partie des projets de la fondation de logiciel Apache depuis 2009. Il est destiné à
faciliter le développem...
33
Le nœud de données (Data Node) : Il permet le stockage des blocs de données. Il
communique périodiquement au « Name Nod...
34
Les points forts d’Hadoop se résument dans ses caractéristiques suivantes :
- évolutif, car pensé pour utiliser plus de...
35
III.2.3. HDFS
HDFS (Hadoop Distributed File System) est un système de fichiers distribué, inspiré
du système GFS dévelo...
36
via SSH au démarrage de HDFS. Par ailleurs, le NameNode est l’arbitre et le dépositaire de
toutes les métadonnées du HD...
37
De plus HDFS est avant tout conçu pour être utilisé avec Hadoop (Figure III.4). La
philosophie de l’implémentation d’Ha...
38
distribution de tâches est de tirer parti de la localité entre données et traitements sur le même
nœud de façon à minim...
39
III.3. HBASE
III.3. 1. Présentation de Hbase
HBase est un système de gestion de base de données NoSQL distribué, écrit ...
40
HBase est généralement utilisé sur un ensemble de machines, ou cluster, et utilise le système
de fichier HDFS. Les donn...
41
III.4. MONGODB
III.4.1. Présentation de MongoDB
MongoDB est une base de données orientée documents open-source qui four...
42
Une base de données MongoDB est un conteneur pour les collections (tout comme une base
dedonnées SQL contient des table...
43
- Sharding : Le Sharding est une surcouche qui est basée sur du Master / Slave ou du
Replica Sets.
 Les Shards : Ce so...
44
III.4.5. Réponse au CAP
MongoDB, de par son architecture dans un système distribué, et qui dans chaque mode utilise
tou...
45
III.6. Conclusion
Dans ce chapitre nous avons présenté les outils utilisés dans la partie implémentation et
expérimenta...
46
Chapitre IV.
IMPLEMENTATION ET
EXPERIMENTATION
47
IV.1. Introduction
Ce chapitre est consacré aux étapes d’installation des composants Hadoop, HBASE et
MongoDB, et se te...
48
 Système d’exploitation : Ubuntu 14.10
 Hadoop 1.0.4
 HBASE 0.94.8
 MongoDB 2.6.7
 YCSB 0.1.4
IV.2.1.2. Installati...
49
Création est installation des certificats SSH :
Hadoop nécessite un accès SSH pour gérer ses nœuds, c’est à dire les ma...
50
1. ~/.bashrc
2. /usr/local/hadoop/etc/hadoop/hadoop-env.sh
3. /usr/local/hadoop/etc/hadoop/core-site.xml
4. /usr/local/...
51
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
L’ajout de la déclaration ci-dessus dans le fichier hadoop-env.sh as...
52
<description>The host and port that the MapReduce job tracker runs
at. If "local", then jobs are run in-process as a si...
53
Pour vérifier le bon fonctionnement d’Hadoop :
On tape la commande : jps
7- Et pour arrêter Hadoop :
hduser@pcubuntu01:...
54
http://localhost:50070/ – Web UI pour le NameNode
55
http://localhost:50030/ – Web UI pour le JobTracker
http://localhost:50060/ – Web UI pour le TaskTracker
56
IV.2.1.3. Installation de HBASE
L’installation de HBASE est très facile à réaliser. Il faut choisir une version stable
...
57
Modifier l’adresse IP de 127.0.1.1 pcubuntu01 à : 127.0.0.1 pcubuntu01
6- Lancer Hadoop avec la commande :
$start-all.s...
58
L’interface WEB de HBASE est définit par l’adresse :
- http://localhost:60010
L’interface WEB offre toutes les informat...
59
IV.2.1.4. Installation de MongoDB
Les étapes d’installation figurent dans la page WEB :
http://docs.mongodb.org/manual/...
60
- http://localhost:28017
- La liste des bases de donnée est affichée en cliquant sur listDatabases.
61
IV.2.1.5. Comparaison des propriétés système
Tableau 1: HBASE vs MongoDB [W9]
Propriétés HBASE MongoDB
Description Orie...
62
IV.2.1.6. Installation de YCSB
1- Télécharger la source YCSB avec la commande :
~$ gitclone http://github.com/brianfran...
63
- Le temps d’exécution des opérations est affiché dans l’écran :
Loading workload...
Starting test.
0 sec: 0 operations...
64
- L’étape de l’exécution se lance après la commande :
hduser@pcubuntu01:~/ycsb-0.1.4$ bin/ycsb run mongodb -P
workloads...
65
Pour le deuxième cas, celui de l’expérimentation dans un environnement distribué, et à cause
de la difficulté d’impléme...
66
YCSB Client 0.1
Command line: -db com.yahoo.ycsb.db.HBaseClient -P
workloads/workloada -p columnfamily=f1 -p recordcoun...
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Utilisation du modele mapreduce dans les  differents systemes nosql etude comparative
Prochain SlideShare
Chargement dans…5
×

Utilisation du modele mapreduce dans les differents systemes nosql etude comparative

1 463 vues

Publié le

Le Big Data est un ensemble de technologies basées sur les bases de données NoSQL qui permettent de traiter de très grands volumes de données informatiques. Les bases NoSQL sont de nouvelles bases de données qui ont vu le jour pour la plupart il y a 5 ou 6 ans. Il sont vu par les grandes entreprises du domaine informatique comme de nouvelles solutions permettant de répondre à leurs besoins d'évolutivité.
Le but de ce travail est d'expliquer l'architecture des différentes bases NoSQL disponibles sur le marché. Et de voir d’une façon plus approfondi deux d’entre elles, HBASE et MongoDB, pour arriver à une analyse de performance utile en utilisant YCSB, un outil très connus pour sa puissance de test et utilisé dans plusieurs travaux d’évaluation des bases de données NoSQL. La finalité est de connaître les performances de chacun de deux bases de donnés et d’effectuer une comparaison à partir des résultats des tests générés par YCSB.

Publié dans : Données & analyses
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 463
Sur SlideShare
0
Issues des intégrations
0
Intégrations
137
Actions
Partages
0
Téléchargements
65
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Utilisation du modele mapreduce dans les differents systemes nosql etude comparative

  1. 1. Mémoire Pour l’Obtention du Diplôme de Post Graduation Spécialisée PRÉSENTÉ PAR ACEF MOHAMED THEME UTILISATION DU MODELE MAPREDUCE DANS LES DIFFERENTS SYSTEMES NOSQL: ETUDE COMPARATIVE Soutenu le : .. / .. / 2015 Devant le jury composé de : Président: B. Beldjilali Professeur, Université d’Oran 1, Ahmed Ben Bella Directeur de mémoire : G. Belalem Professeur, Université d’Oran 1, Ahmed Ben Bella Examinatrice: N. Taghezout MCA, Université d’Oran 1, Ahmed Ben Bella Code : …/… ‫قسم‬‫اآللي‬ ‫اإلعالم‬ Département d’Informatique
  2. 2. Dédicaces A mes parents, A ma femme, A ma fille Taghrid Ibtihal, A mon fils Ahmed Yacine, A mon fils Maemoun Abdelmounaim, A mes frères et mes sœurs, Je vous aime ! Mohamed.
  3. 3. Remerciements Je remercie ALLAH le tout puissant, maître des cieux et de la terre, qui m’a éclairé le chemin et permis de mener à bien ce travail. Je remercie mon encadreur Monsieur BELALEM Ghalem pour ces précieux conseils, sa disponibilité, la confiance qu’il m’a toujours témoigné, et ce tout au long de l’élaboration du présent travail. Je remercie les membres de jury d’avoir accepté de siéger et de juger mon travail. Je remercie également; mes enseignants de l’université d’Oran, le Directeur du CPE, Monsieur BOUHADDA Abdelkader, chef de département TSO, Monsieur BABA Ahmed Amine, chef de département TQI, mes collègues du département TSO, mes collègues du département TQI, mes collègues du CPE, Mr BEKKOUCHE Abdelmadjid, Mr SALHI Ali et sa famille, pour leurs aides et encouragements jusqu’à la finalisation de ce travail.
  4. 4. SOMMAIRE INTRODUCTION GENERALE ........................................................................................................3 Chapitre I. Le BIG DATA et le Cloud Computing ..........................................................................4 I.1. Le BIG DATA...........................................................................................................................5 I.1.1. Introduction.......................................................................................................................5 I.1.2. Définition...........................................................................................................................5 I.1.3. L’origine des données......................................................................................................7 I.1.4. Les principaux acteurs......................................................................................................7 I.1.5. Les enjeux technologiques................................................................................................8 I.1.6. Les secteurs d’activités......................................................................................................8 I.1.7. Le stockage.......................................................................................................................10 I.1.8. Le traitement et l’analyse................................................................................................10 I.2. LE CLOUD COMPUTING ....................................................................................................10 I.2.1.Définition..........................................................................................................................10 I.2.2. Les différents services.....................................................................................................11 I.2.3. Les formes de déploiement du Cloud Computing..........................................................11 I.3. Conclusion..............................................................................................................................13 Chapitre II. Le NoSQL.....................................................................................................................14 II.1. Introduction ..........................................................................................................................15 II.2. Notions préliminaires...........................................................................................................15 II.2.1. Les propriétés ACID......................................................................................................16 II.2.2. Scalabilité.......................................................................................................................17 II.2.3. Le Théorème CAP [5]................................................................................................17 II.2.4. L’émergence du NoSQL ................................................................................................18 II.2.5. Types de base NoSQL...............................................................................................20 II.2.6. Les propriétés de « BASE ».......................................................................................24 II.2.7. Les avantages et les inconvénients du NoSQL .......................................................24 II.3. MapReduce ..........................................................................................................................26 II.3.1. Introduction....................................................................................................................26 II.3.2. Principe de MapReduce.................................................................................................26 II.3.3. Le modèle de programmation.................................................................................27
  5. 5. II-4 Conclusion.............................................................................................................................29 Chapitre III. HADOOP, HBASE, MONGODB ET YCSB. ............................................................30 III.1. Introduction.........................................................................................................................31 III.2. HADOOP.............................................................................................................................31 III.2.1. Historique......................................................................................................................31 III.2.2. Présentation d’Hadoop ................................................................................................31 III.2.3. HDFS..............................................................................................................................35 III.2.4. Le composant MapReduce...........................................................................................37 III.3. HBASE..................................................................................................................................39 III.3. 1. Présentation de Hbase.................................................................................................39 III.3. 2. Architecture de HBASE...............................................................................................39 III.4. MONGODB .........................................................................................................................41 III.4.1. Présentation de MongoDB...........................................................................................41 III.4.2. Modèle de données.......................................................................................................41 III.4.3. Architecture...................................................................................................................42 III.4.4. Le composant Mapreduce............................................................................................43 III.4.5. Réponse au CAP ...........................................................................................................44 III.5. YCSB : Le Benchmark Yahoo..............................................................................................44 III.6. Conclusion ...........................................................................................................................45 Chapitre IV. IMPLEMENTATION ET EXPERIMENTATION....................................................46 IV.1. Introduction.........................................................................................................................47 IV.2. Première partie....................................................................................................................47 IV.2.1. Installation de Hadoop, HBASE, MongoDB et YCSB................................................47 IV.2.1.1.Configuration..............................................................................................................47 IV.2.1.2. Installation d’Hadoop en mode Single Node ..........................................................48 IV.2.1.3. Installation de HBASE...............................................................................................56 IV.2.1.4. Installation de MongoDB..........................................................................................59 IV.2.1.5. Comparaison des propriétés système ......................................................................61 IV.2.1.6. Installation de YCSB..................................................................................................62 IV.3. Deuxième partie : Analyse des tests ..................................................................................64 IV.3.1. Introduction ..................................................................................................................64 IV.3.2. Tests et analyse des résultats.......................................................................................65
  6. 6. IV.3.3. Deuxième cas : Environnement distribué (Cloud).....................................................77 IV.4. Conclusion :.........................................................................................................................88 CONCLUSION GENERALE...........................................................................................................89 Référence : ........................................................................................................................................91 Résumé .............................................................................................................................................93
  7. 7. INTRODUCTION
  8. 8. 3 INTRODUCTION GENERALE Nous sommes confrontés depuis quelques années à de nouvelles technologies qui envahissent le monde de l’information et l’internet. Cette situation nous oblige à prendre les défis, de connaitre et maîtriser ces « nouvelles sciences » afin de nous permettre de s’adapter aux changements forcés par cette « révolution scientifique » semblable à celle du XVII siècle. Beaucoup de concepts « inséparables » dominent actuellement le monde de l’IT. On entend souvent de « Cloud Computing » ; la « mode » technologique actuelle, hébergeant un « Big Data » sous forme de « NoSQL » et traité par un simple programme « MapReduce » dans des « clusters » distribués partout dans le monde. Ce manuscrit met le point sur ces concepts; et définie la relation qui les relient, en étudiant deux solutions caractérisées par l’implémentation dans leurs noyaux du même algorithme « MapReduce », il s’agit de HBASE et MongoDB. Nous essayerons de comparer entre ces deux solutions. L²’objectif est de donner une conclusion bénéfique aux acteurs intéressés. Nous commençons, dans les deux premiers chapitres, de donner les définitions et les descriptions des concepts considérés comme état de l’art pour cette étude. A savoir le « Big Data », le « Cloud Computing », « Le NoSQL », et l’Algorithme « MapReduce ». Le troisième chapitre est consacré à la présentation des outils : Hadoop, HBASE, MongoDB, et YCSB. Le quatrième chapitre montre la comparaison des résultats déduits à partir de l’évaluation des performances de chaque base de données, et nous terminerons notre manuscrit par une conclusion générale et quelques perspectives.
  9. 9. 4 Chapitre I Le BIG DATA, et le Cloud Computing
  10. 10. 5 I.1. Le BIG DATA I.1.1. Introduction En quelques années, le volume des données exploité par les entreprises a considérablement augmenté. Émanant de sources diverses (transactions, systèmes d’information automatisés, réseaux sociaux,...), elles sont souvent susceptibles de croître très rapidement. Lorsqu’on parle de manipulation de gros volume de données, on pense généralement à des problématiques sur le volume des données et sur la rapidité de traitement de ces données. L'idée derrière le "Big Data" est de pouvoir traiter ce grand volume de données. La première partie de ce chapitre consistera donc à expliquer ce sujet. D’une autre part, et depuis la création de la technologie de l'internet, une nouvelle tendance vient de dominer la technologie de l’IT, il s'agit du Cloud Computing . Et afin de mettre le point sur cette technologie, nous allons consacrer la deuxième partie de ce chapitre pour présenter ce nouveau marché. I.1.2. Définition Le terme «Big Data » est apparu il y’a quelques années pour expliquer un domaine issu d’une révolution dans la manière de traitement des données. Plusieurs définitions ont été données. On trouve principalement la définition donnée par Wikipédia, indiquant qu’il s’agit d’une “expression anglophone utilisée pour désigner des ensembles de données qui deviennent tellement gros qu’ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données”.[W1] On trouve d’autres définitions qui peuvent être considéré comme des critiques données à la définition de Wikipédia. En disant que « Le Big Data est avant tout un terme marketing. À dire vrai, il recouvre un ensemble de concepts et d'idées pas clairement définis. En se tenant à
  11. 11. 6 l'étymologie du terme, Big Data voudrait dire « grosses données ». Or, la problématique des « grosses données », ou données ayant un volume important, n'est pas nouvelle. [1] Depuis plus de 30 ans, nous sommes confrontés à des volumes importants de données. Cela fait presque dix ans que la problématique de gestion des gros volumes de données se pose dans les métiers de la finance, de l’indexation Web et de la recherche scientifique. Pour y répondre, l’approche historique a été celle des offres de DataWarehouse. … En somme, le Big Data, ce serait plutôt des besoins et des envies nouvelles émanant de l'idée de mieux utiliser ces données qui commencent à s'entasser dans nos DataWarehouse. ».[1] Le Big Data est défini ; donc ; par rapport à la manière avec laquelle les grandes masses de données peuvent être traitées et exploitées de façon optimale. Le concept de Big Data se caractérise par plusieurs aspects. De nombreux responsables informatiques et autorités du secteur tendent à définir le Big Data selon trois grandes caractéristiques : Volume, Vitesse et Variété, soit les trois « V ».[1] - Volume Le Big Data est associé à un volume de données vertigineux, se situant actuellement entre quelques dizaines de téraoctets (1 téraoctet=212 octets) et plusieurs péta-octets (1 péta-octets = 215 octets) en un seul jeu de données. Les entreprises, tous secteurs d’activité confondus, devront trouver des moyens pour gérer le volume de données en constante augmentation qui est créé quotidiennement. - Vitesse La vitesse décrit la fréquence à laquelle les données sont générées, capturées et partagées. Les entreprises doivent appréhender la vitesse non seulement en termes de création de données, mais aussi sur le plan de leur traitement, de leur analyse et de leur restitution à l'utilisateur en respectant les exigences des applications en temps réel. - Variété La croissance de la variété des données est largement la conséquence des nouvelles données multi structurelles et de l'expansion des types de données. Aujourd’hui, on trouve des capteurs d'informations aussi bien dans les trains, les automobiles ou les avions, ajoutant à cette variété.
  12. 12. 7 Alex Popescu [2] ajoute à cela un quatrième “V”, celui de “variabilité” : - Variabilité: le format et le sens des données peut varier au fil du temps. I.1.3. L’origine des données Les données traitées par le Big Data proviennent notamment [3]: o du Web: les textes, les images, les vidéos, et tous ce qui peut figurer sur les pages Web. o plus généralement, de l’internet et des objets communicants: réseaux de capteurs, journaux des appels en téléphonie; o des sciences: génomique, astronomie, physique subatomique, etc.; o données commerciales o données personnelles (ex: dossiers médicaux); o données publiques (open data). Ces données sont localisées généralement dans les Data Warehouses d’entreprises ou chez les fournisseurs du Cloud. Ce qui facilite leur traitement en utilisant des méthodes adaptées à ces architectures. On peut citer par exemple l’algorithme MapReduce. I.1.4. Les principaux acteurs Les acteurs sont les organismes qui « produisent » du Big Data, et dans la plupart des cas ce sont leurs fondateurs. « Les principales innovations du domaine trouvent leur origine chez les leaders du Web [3]: Google (MapReduce et BigTable), Amazon (Dynamo, S3), Yahoo! (Hadoop, S4), Facebook (Cassandra, Hive), Twitter (Storm, FlockDB), LinkedIn (Kafka, SenseiDB, Voldemort), LiveJournal (Memcached), etc. La Fondation Apache est ainsi particulièrement active dans ce domaine, en lançant ou en recueillant plus d’une dizaine de projets, matures ou en incubation: Hadoop,
  13. 13. 8 Lucene/Solr,Hbase, Hive, Pig, Cassandra, Mahout, Zookeeper, S4, Storm, Kafka, Flume, Hama, Giraph, etc. Outre les sociétés du Web, le secteur scientifique et plus récemment les promoteurs de l’Open Data (et de sa variante, l’Open Linked Data, issu du Web Sémantique), sont également historiquement très ouverts à l’Open Source, et ont logiquement effectué des contributions importantes dans le domaine du Big Data. I.1.5. Les enjeux technologiques Pour beaucoup d’entreprises, le Big Data représente de nouveaux enjeux qu’il faut envisager, mais il faut aussi étudier les risques induits. D’après Michael Stonebraker [3] « “Il y a beaucoup de bruit autour du Big Data. Ce concept a plusieurs significations en fonction du type de personnes. Nous pensons que la meilleure façon de considérer le Big Data est de penser au concept de trois V. Big Data peut être synonyme de gros volume, du teraoctet au petaoctet. Il peut également signifier la rapidité [Velocity, NDLR] de traitement de flux continus de données. Enfin, la troisième signification: vous avez à manipuler une grande variété de données, de sources hétérogènes. Vous avez à intégrer entre mille et deux mille sources de données différentes et l’opération est un calvaire. La vérité est que le Big Data a bien trois significations et que les éditeurs n’en abordent qu’une à la fois. Il est important de connaître leur positionnement pour leur poser les bonnes questions.” I.1.6. Les secteurs d’activités Actuellement, le Big Data est considéré souvent comme un chemin inévitable par les secteurs économiques, industriels et sociaux dans le monde. Plusieurs organismes et chercheurs s’intéressent à connaitre les impacts de ce nouveaux concept dans l’avenir. « Ces secteurs d’activité, qui ont été les premiers à s’intéresser au Big Data, peuvent être séparés en deux groupes : ceux pour qui le Big Data répond à des besoins historiques de leur activité, et ceux pour qui il ouvre de nouvelles opportunités. »[1] La première catégorie regroupe : - Les Banques. - La Télécommunication.
  14. 14. 9 - Les Médias Numériques. - Les Marchés Financiers. Et dans la deuxième catégorie on trouve : - Les Services Publics - Le Marketing : - La Santé : « …. mais d’autres commencent à s’y intéresser, notamment la Recherche, la Police ou encore les Transports. »[1] Afin de répondre à cette demande, de nombreux fournisseurs de technologie de Big Data sont apparus. Parmi les secteurs d’activités qui s’intéressent aux Big Data, les plus connus sont les entreprises d’informatiques. Qui sont les « créateurs » des technologies Big Data. Parmi elles : Microsoft, IBM, Microstrategy, Hurence et TeraData. Mais de nombreuses autres entreprises utilisent des solutions de Big Data proposées par les entreprises d’informatiques (figure I.1). Parmi elles, on retrouve différents secteurs d’activité tels que : - les télécoms : SFR ; - les réseaux sociaux : Facebook ; - des sociétés de services : Amazon Web Services ; - des sociétés d’analyses : HPCC Systems, 1010 Data, Quantivo, Opera solutions… Figure. I.1. Les différents secteurs d’activités du BIG DATA
  15. 15. 10 I.1.7. Le stockage Les difficultés de présentation et stockage de données dans les Data Warhouses vu leurs formes, types et tailles gênent leur exploitation adéquate. La technique utilisée est l’instauration des bases de données NoSQL. Les bases NoSQL visent à passer à l’échelle de manière horizontale en relâchant les conditions fortes de transactionnalité (ACID - atomiques, cohérentes, isolées et durables) attendues des bases traditionnelles, et en renonçant au modèle relationnel (voir Chapitre 2). I.1.8. Le traitement et l’analyse L’architecture distribuée implantée pour le stockage et le traitement des données Big Data présente un obstacle qui ralenti considérablement le temps espéré par les utilisateurs. Une technique dite « MapReduce », qui a été utilisée au début par Google, est actuellement intégrée dans plusieurs solutions Big Data. MapReduce est à l’origine une technique de programmation connue de longue date en programmation fonctionnelle, mais surtout un Framework développé par Google en 2004. La deuxième partie du chapitre 2 est consacré à la présentation de l’algorithme « MapReduce ». I.2. LE CLOUD COMPUTING Depuis sa création, la technologie de l'Internet se développe d’une manière exponentielle. Actuellement, une nouvelle « tendance » est dominante, il s'agit du Cloud Computing. Cette technologie, s'appuie sur le WEB 2.0, offre des occasions aux sociétés de réduire les coûts d'exploitation des logiciels par leurs utilisations directement en ligne.[4] Dans ce chapitre nous allons présenter les notions fondamentales du Cloud Computing, ses enjeux, ses évolutions et son utilité. I.2.1.Définition Le CloudComputing, « littéralement l'informatique dans les nuages » est un concept qui consiste à «rendre accessible et exploitable des données et des applications à travers un réseau. Ce terme désigne à la fois les applications en tant que services sur Internet et le matériel et logiciels qui permettent de fournir ces services ».[4]
  16. 16. 11 I.2.2. Les différents services Le concept « Cloud Computing » est utilisé pour désigner des services, on distingue trois "catégories" de services fournis :  Infrastructure as a service : IaaS  Platform as a service : PaaS  Software as a service : Saas IAAS Il s’agit de la mise à disposition, à la demande, de ressources d’infrastructures dont la plus grande partie est localisée à distance dans des Data Center. PAAS PAAS désigne les services visant à proposer un environnement complet permettant de développer et déployer des applications. SAAS Il s'agit des plateformes du nuage, regroupant principalement les serveurs mutualisés et leurs systèmes d'exploitation. En plus de pouvoir délivrer des logiciels. I.2.3. Les formes de déploiement du Cloud Computing Nous distinguons trois formes de Cloud Computing: Le Cloud publique, également le premier apparu, le Cloud privé et le Cloud hybride qui est en fait la combinaison des deux premiers.  Le Cloud publique Le principe est d'héberger des applications, en général des applications Web, sur un environnement partagé avec un nombre illimité d'utilisateurs. La mise en place de ce type de Cloud est gérée par des entreprises tierces (exemple Amazon, Google, etc.). Les fournisseurs du Cloud publique les plus connus sont Google et Amazon. Ce modèle est caractérisé par : - Demande de lourds investissements pour le fournisseur de services. - Offre un maximum de flexibilité. - N’est pas sécurisé.
  17. 17. 12  Le Cloud privé C'est un environnement déployé au sein d'une entreprise en utilisant les infrastructures internes de l’entreprise, et en utilisant des technologies telles que la virtualisation. Les ressources sont détenues et contrôlées par le département informatique de l’entreprise. Eucalyptus, OpenNebula et OpenStack sont des exemples de solution pour la mise en place du Cloud privé.  Le Cloud hybride En général, on entend par Cloud hybride la cohabitation et la communication entre un Cloud privé et un Cloud publique dans une organisation partageant des données et des applications.
  18. 18. 13 I.3. Conclusion Nous avons tenté dans ce premier chapitre de comprendre les concepts de «Big Data » et de « Cloud Computing ». Ces notions préliminaires aideront à mieux comprendre le contexte de traitement de nouveaux types données difficile à être classer dans les bases de données relationnel. Les systèmes de gestion de bases de données NoSQL appariaient ces dernières années pour solutionner ce problème. Nous avons présenté dans la deuxième partie de ce chapitre la technologie du Cloud Computing ainsi que les types de services Cloud connus jusqu'à présent. Nous allons présenter dans le chapitre suivant d’autres concepts qui ont une relation directe avec le Big Data et le Cloud Computing. Il s’agit du NoSQL et l’algorithme « MapReduce ».
  19. 19. 14 Chapitre II. Le NoSQL
  20. 20. 15 II.1. Introduction On ne peut pas parler de Big Data sans citer le NoSQL, Not Only SQL. Il est venu pour solutionner les difficultés rencontrées pendant la gestion des données classées « Big Data » avec les systèmes SGBD relationnels. Nous allons donner dans ce chapitre quelques notions préliminaires qui vont faciliter la comprenions et la présentation des bases de données NoSQL. En fin du chapitre, nous allons présenter l’algorithme « MapReduce » qui est devenu actuellement le noyau des procédures intégrés dans la plupart des systèmes de gestion de bases de données NoSQL. II.2. Notions préliminaires Une base de données (BDD) est un dispositif dans lequel il est possible de stocker des données de manière structurée ou semi-structurée et avec le moins de redondances possibles. Accessibles par des programmes employés par plusieurs utilisateurs. Une base de données peut être soit locale, soit répartie. Dans ce dernier cas, les informations sont stockées sur des machines distantes et accessibles par le réseau. L’accès aux données doit être géré par des droits accordés aux utilisateurs. L'avantage majeur des bases de données réparties est la possibilité de pouvoir être accédées simultanément par plusieurs utilisateurs. Les bases de données sont gérées par un système appelé « système de gestion de base de données », abrégé SGBD. C’est un logiciel dont les tâches sont principalement l’accès aux données, l’insertion de données, l’autorisation des accès aux informations simultanément à de multiples utilisateurs ainsi que la manipulation des données présentes dans la base. Suite aux limites du modèle hiérarchique et du modèle réseaux qui sont apparus au début pour implémenter la représentation physique des données ; le modèle relationnel est actuellement le SGBD le plus répandu. Dans ce modèle, les informations sont décomposées et organisées dans des matrices à deux dimensions (ligne-colonne) appelées relations ou tables. La manipulation de ces données se fait selon la théorie mathématique des opérations d’algèbre relationnelle telles que l’intersection, la jointure ou le produit cartésien.
  21. 21. 16 La manipulation répondue dans le monde de plusieurs types et formes de données et sur plusieurs plateformes impose deux « critères » de mesure de performances: Les propriétés ACID et la « Scalabilité». II.2.1. Les propriétés ACID Lorsque des transactions sont effectuées, les SGBD de type hiérarchique, réseau et relationnel fonctionnent selon les contraintes dites ACID. ACID est un acronyme qui veut dire « Atomicity », « Consistancy », « Isolation » et « Durability ». Une transaction est réalisée avec succès si elle respecte ces quatre contraintes. Voici une description détaillée de celles-ci [W2] :  « Atomicity » (Atomicité) : Lorsqu’une transaction est effectuée, toutes les opérations qu’elle comporte doivent être menées à bien : en effet, en cas d’échec d’une seule des opérations, toutes les opérations précédentes doivent être complètement annulées, peu importe le nombre d’opérations déjà réussies. En résumé, une transaction doit s’effectuer complètement ou pas du tout. Voici un exemple concret : une transaction qui comporte 3000 lignes qui doivent être modifiées ; si la modification d’une seule des lignes échoue, alors la transaction entière est annulée. L’annulation de la transaction est toute à fait normale, car chaque ligne ayant été modifiée peut dépendre du contexte de modification d’une autre, et toute rupture de ce contexte pourrait engendrer une incohérence des données de la base.  « Consistancy » (Cohérence) : Avant et après l’exécution d’une transaction, les données d’une base doivent toujours être dans un état cohérent. Si le contenu final d’une base de données contient des incohérences, cela entraînera l’échec et l’annulation de toutes les opérations de la dernière transaction. Le système revient au dernier état cohérent. La cohérence est établie par les règles fonctionnelles.  « Isolation » (Isolation) : La caractéristique d’isolation permet à une transaction de s’exécuter en un mode isolé. En mode isolé, seule la transaction peut voir les données qu’elle est en train de modifier, c’est le système qui garantit aux autres transactions exécutées en parallèle une visibilité sur les données antérieures. Ce fonctionnement est obtenu grâce aux verrous système posés par le SGBD. Prenons l’exemple de deux transactions A et B : lorsque celles-ci s’exécutent en même
  22. 22. 17 temps, les modifications effectuées par A ne sont ni visibles, ni modifiables par B tant que la transaction A n’est pas terminée et validée par un « commit ».  « Durability » (Durabilité) : Toutes les transactions sont lancées de manière définitive. Une base de données ne doit pas afficher le succès d’une transaction pour ensuite remettre les données modifiées dans leur état initial. Pour ce faire, toute transaction est sauvegardée dans un fichier journal afin que, dans le cas où un problème survient empêchant sa validation complète, elle puisse être correctement terminée lors de la disponibilité du système. II.2.2. Scalabilité La « scalabilité » est le terme utilisé pour définir l’aptitude d’un système à maintenir un même niveau de performance face à l’augmentation de charge ou de volumétrie de données, par augmentation des ressources matérielles. Il y a deux façons de rendre un système extensible :  La « scalabilité » horizontale Le principe de la « scalabilité » horizontale consiste à simplement rajouter des serveurs en parallèle.  La « scalabilité » verticale Elle consiste à augmenter les ressources d’un seul serveur, comme par exemple le remplacement du CPU par un modèle plus puissant ou par l’augmentation de la capacité de la mémoire RAM. Ces deux critères; ACID et scalabilité ; sont limités par le théorème CAP qui signifie «Coherence», «Availability» et «Partition tolerance», aussi connu sous le nom de théorème de Brewer [6]. II.2.3. Le Théorème CAP [5] Ce théorème, formulé par Eric Brewer en 2000 et démontré par Seth Gilbert et Nancy Lych en 2002, énonce une conjecture qui définit qu’il est impossible, sur un système informatique de calcul distribué, de garantir en même temps les trois contraintes suivantes :
  23. 23. 18  « Coherence » (Cohérence) : Tous les clients du système voient les mêmes données au même instant.  « Availibility » (Haute disponibilité) : Un système est dit disponible si toute requête reçue par un nœud retourne un résultat. Bien évidemment le nœud en question ne doit en aucun cas être victime de défaillance.  « Partition tolerance » (Tolérance à la partition) : Un système est dit tolérant à la partition s’il continue à répondre aux requêtes de manière correcte même en cas de panne autre qu’une panne totale du système. Seuls deux des trois contraintes peuvent être respectés en même temps Fig. II.1. Théorème de CAP II.2.4. L’émergence du NoSQL Le volume de données de certaines entreprises est augmenté considérablement durant ces dernières années. L’informatisation croissante de traitement en tout genre a eu pour conséquence une augmentation exponentielle de ce volume de données qui se compte désormais en pétaoctets, les anglo-saxon l’ont nommé le Big Data (Voir Chapitre 1). La gestion de ces volumes de données est donc devenue un problème que les bases de données relationnelles n’ont plus été en mesure de gérer ; la raison suite à laquelle est apparus le NoSQL comme solution plus performante par rapport aux systèmes de gestion des bases de données relationnels.
  24. 24. 19 Beaucoup d'organisations doivent stocker de grandes quantités de données, la plupart des SGBD relationnel actuels ne permettent plus de répondre aux besoins de stockage et de traitement de ces grandes quantités. Le besoin fondamental auquel répond le NoSQL est la performance. Afin de résoudre les problèmes liés au « Big Data », les développeurs de sociétés telles que Google et Amazone ont procédé à des compromis sur les propriétés ACID des SGBDR. Ces compromis sur la notion relationnelle ont permis aux SGBDR de se libérer de leurs freins à la scalabilité horizontale. Un autre aspect important du NoSQL est qu’il répond au théorème de CAP qui est plus adapté pour les systèmes distribués.[5] Ce sont les grands acteurs du Web tels que Google, Amazon, Linkedin et Facebook qui ont solutionné leurs problèmes en développant, en parallèle de leurs activités primaire, leurs propres SGBD NoSQL. A l’heure actuelle, la quasi-totalité des sites à fort trafic utilisent des SGBD NoSQL.[6] Un des premiers buts des systèmes NoSQL est de renforcer la « scalabilité » horizontale, il faut pour cela que le principe de tolérance au partitionnement soit respecté, ce qui exige l’abandon soit de la cohérence, soit de la haute disponibilité.[6] Le NoSQL ou « Not Only SQL » est un mouvement très récent (2009), qui concerne les bases de données. L’idée du mouvement est simple : proposer des alternatives aux bases de données relationnelles pour coller aux nouvelles tendances et architectures du moment, notamment le Cloud Computing.[7] Les axes principaux du NoSQL sont une haute disponibilité et un partitionnement horizontal des données, au détriment de la consistance. Alors que les bases de données relationnelles actuelles sont basées sur les propriétés ACID (Atomicité, Consistance, Isolation et Durabilité). Un SGBDR pour répondre aux exigences de performance face aux gros volumes de données, doit se retourner vers du matériel de plus en plus rapide et à l'ajout de mémoire. Le NoSQL, pour sa part, pour gérer la « montée en charge » se réfère à la répartition de la charge sur les systèmes de Cloud Computing. Il s'agit la de composant de NoSQL qui fait d'elle une solution peu coûteuse pour les grands ensembles de données.
  25. 25. 20 II.2.5. Types de base NoSQL Il existe une diversité d’approches NoSQL classées en quatre catégories. Ces différents systèmes NoSQL utilisent des technologies fortes distinctes spécifiques à différentes solutions [7. Voici quelques exemples]:  Orientées colonnes : HBase, Hyper table, Cassandra et BigTable  Orientées graphes (Euler) : Neo4J16  Orientées clé-valeur : Voldemort , Dynamite et Riak  Orientées document : MongoDB, CouchDB. Ces différents modèles de structure sont décrits comme suit :  Base de données Orientée Clé- valeur Cette structure est très adaptée à la gestion des caches ou pour fournir un accès rapide aux informations [W3]. La base de données de type clé-valeur est considérée comme la plus élémentaire. Son principe est très simple, chaque valeur stockée est associée à une clé unique. C’est uniquement par cette clé qu’il sera possible d’exécuter des requêtes sur la valeur. Souvent assimilé à une « hashmap » distribuée, le système de base de données de type clé/valeur est probablement le plus connu et le plus basique que comporte la mouvance NoSQL. [6] La structure de l’objet stocké est libre et donc à la charge du développeur de l’application. Un avantage considérable de ce type de base de données est qu’il est très facilement extensibles, on parle donc de scalabilité horizontale. Fig. II.2. Schéma d’une Base de données Orientée Clé-valeur
  26. 26. 21 La structure de l’objet est libre et le plus souvent laissé à la charge du développeur de l’application (par exemple XML, JSON, ...), la base ne gérant généralement que des chaînes d’octets. [7] La communication avec la base de données se résume aux opérations basiques que sont PUT, GET, UPDATE et DELETE. La plupart des bases de données de type clé/valeur disposent d’une interface HTTP REST qui permet de procéder très facilement à des requêtes depuis n’importe quel langage de développement. Ces systèmes sont donc principalement utilisés comme dépôt de données à condition que les types de requêtes nécessitées soient très simples. On les retrouve comme système de stockage de cache ou de sessions distribuées, particulièrement là où l’intégrité des données est non significative. Aujourd’hui, les solutions les plus connues ayant adoptées le système de couple clé-valeur sont Voldemort (LinkedIn), Redis et Riak. [5]  Les bases de données orientées colonnes Les bases de données orientées colonnes ont été conçues par les géants du web afin de faire face à la gestion et au traitement de gros volumes de données s’amplifiant rapidement de jours en jours. Ce modèle ressemble à première vue à une table dans un SGBDR à la différence qu’avec une BD NoSQL orientée colonne, le nombre de colonnes est dynamique. En effet, dans une table relationnelle, le nombre de colonnes est fixé dès la création du schéma de la table et ce nombre reste le même pour tous les enregistrements dans cette table. Par contre, avec ce modèle, le nombre de colonnes peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL. Le concept de base est décrit comme suit : - Column : c’est l’entité de base qui représente un champ de données. Toutes les colonnes sont définies par un couple clé/valeur - Super column : c’est une colonne qui contient d’autres colonnes - Column family : elle est considérée comme un conteneur de plusieurs colonnes ou super-colonnes - Row : c’est l’identifiant unique de chaque ligne de colonne
  27. 27. 22 - Value : c’est le contenu de la colonne. Cette valeur peut très bien être une colonne elle-même. Ce type de structure permet d’être plus évolutif et flexible ; cela vient du fait qu’on peut ajouter à tout moment une colonne ou une super-colonne à n’importe quelle famille de colonnes.  Les bases de données orientées documents Les bases de données documents sont une évolution des bases de données de type clé-valeur. Ici les clés ne sont plus associées à des valeurs sous forme de bloc binaire mais à un document dont le format n’est pas imposé. Les bases de données documentaires sont constituées de collections de documents (Figure II.3). Un document est composé de champs et des valeurs associées, ces dernières pouvant être requêtées. A ce titre, il n’est pas nécessaire de définir au préalable les champs utilisés dans un document. Les documents peuvent être très hétérogènes au sein de la base. Le stockage structuré des documents leur confère des fonctionnalités dont ne disposent pas les bases clés-valeurs simples dont la plus évidente est la capacité à effectuer des requêtes sur le contenu des objets. La valeur, dans ce cas, est un document de type JSON ou XML par exemple. [W3] CLE …Figure II.3. Schéma d’une base de données orientée documents
  28. 28. 23 L’avantage des bases de données documents est de pouvoir récupérer un ensemble d’informations structurées hiérarchiquement depuis une clé. Une opération similaire dans le monde relationnelle équivaudrait à plusieurs jointures de table.[5]  Les bases de données orientées graphe Bien que les bases de données de type clé-valeur, colonne, ou document tirent leur principal avantage de la performance du traitement de données, les bases de données orientées graphe permettent de résoudre des problèmes très complexes qu’une base de données relationnelle serait incapable de faire. [6] Ce modèle de représentation des données se base sur la théorie des graphes. Il s’appuie sur la notion de nœuds, de relations et de propriétés qui leur sont rattachées (Figure II.4). Ce modèle facilite la représentation du monde réel, ce qui le rend adapté au traitement des données des réseaux sociaux Ces bases permettent la modélisation, le stockage ainsi que le traitement de données complexes reliées par des relations. Ce modèle est composé d’un :  Moteur de stockage pour les objets : c’est une base documentaire où chaque entité de cette base est nommée nœud.  Mécanisme qui décrit les arcs : c’est les relations entre les objets, elles contiennent des propriétés de type simple (integer, string, date,...). Figure II.4. Schéma d’une base de données Orientées graphe.
  29. 29. 24 II.2.6. Les propriétés de « BASE » Dans la première partie de ce chapitre consacrée aux notions préliminaires, nous avons vu les propriétés ACID auxquelles doivent répondre les SGBD de type relationnel. Les SGBD NoSQL par contre doivent vérifier les propriétés dites propriétés de BASE. Le principe de BASE est le fruit d’une réflexion menée par Eric Brewer (Théorème de CAP). Les caractéristiques de BASE sont fondées sur les limites que montrent les SGBD relationnelles. Voici sa description[6] :  Basically Available (Disponibilité basique) : Même en cas de désynchronisation ou de panne d’un des nœuds du cluster, le système reste disponible selon le théorème CAP.  Soft-state (Cohérence légère) : Cela indique que l’état du système risque de changer au cours du temps, sans pour autant que des données soient entrées dans le système. Cela vient du fait que le modèle est cohérent à terme.  Eventual consistancy (Cohérence à terme) : Cela indique que le système devient cohérent dans le temps, pour autant que pendant ce laps de temps, le système ne reçoive pas d’autres données. II.2.7. Les avantages et les inconvénients du NoSQL Plusieurs avantages peuvent être associés aux systèmes NoSQL, nous pouvons citer par exemple : o La « scalabilité » horizontale : Aujourd’hui, la rapidité en lecture/écriture ainsi que la haute disponibilité sont devenues des critères indispensables. C’est pourquoi les bases de données NoSQL répondent entièrement à ce besoin. Elles ont été conçues pour répandre les données de manière transparente sur plusieurs nœuds et ainsi former un cluster. Les performances qu’offrent la «scalabilité » horizontale peuvent même être atteintes avec des serveurs bas de gamme, ce qui rend la structure plus économique. [6] La scalabilité horizontale offre d’autres avantages non négligeables, comme une grande tolérance aux pannes où les coûts réduits relatifs à l’achat du matériel (plus besoin d’acheter de serveurs extrêmement puissants).
  30. 30. 25 o Gros volume de données (Big Data) NoSQL est plus évolutif. C’est en effet l’élasticité de ses bases de données NoSQL qui le rend si bien adapté au traitement de gros volumes de données. o Economique Les bases de données NoSQL ont tendance à utiliser des serveurs bas de gammes dont le coût est moindre afin d’équiper les « clusters ». Les serveurs destinés aux bases de données NoSQL sont généralement bon marché et de faible qualité, contrairement à ceux qui sont utilisés par les bases relationnelles. De plus, la très grande majorité des solutions NoSQL sont Open– Source, ce qui reflète d’une part une économie importante sur le prix des licences. o Plus flexible N’étant pas enfermée dans un seul et unique modèle de données, une base de données NoSQL est beaucoup moins restreinte qu’une base SQL. Les applications NoSQL peuvent donc stocker des données sous n’importe quel format ou structure, et changer de format en production. o Le Cloud Computing NoSQL et le Cloud s’associent de façon naturelle. En effet, le Cloud Computing répond extrêmement bien aux besoins en matière de scalabilité horizontale que requièrent les bases de données NoSQL. En plus la pluparts des solutions Cloud sont basés sur le NoSQL. Néanmoins, l’inconvénient majeur est que les SGBD relationnel occupent actuellement la grande partie du marché mondial, ce qui implique une lenteur dans l’adoption des solutions NoSQL par les décideurs IT. Dans le monde NoSQL, presque tous les développeurs sont en apprentissage avec la technologie. Ces inconvénients vont disparaitre après quelques années vu la tendance mondiale vers les SGBD NoSQL.
  31. 31. 26 II.3. MapReduce II.3.1. Introduction Le traitement des données par un SGBD NoSQL est caractérisé par son stockage dans des supports distribués appelés «Clusters» d’une part, et d’autre part par la quantité gigantesque des données. Ce qui exige une fragmentation (décomposition) des données et leurs traitements simultanés (en parallèle), en plus, la finalité est de regrouper les résultats. Ce traitement de données de façon distribuée soulève certaines questions : Comment distribuer le travail entre les serveurs ? Comment synchroniser les différents résultats ? Comment gérer une panne d’une unité de traitement ? Une des solutions proposées est l’utilisation de l’algorithme « Map Reduce ». Il ne s’agit pas d’un élément de base de données, mais d’un modèle de programmation s’inspirant des langages fonctionnels et plus précisément du langage Lisp. Il permet de traiter une grande quantité de données de manière parallèle, en les distribuant sur divers nœuds d’un Cluster. Ce mécanisme a été mis en avant par Google en 2004 et a connu un très grand succès auprès des sociétés utilisant des DataCenter telles que Facebook ou Amazon. [5] MapReduce est un patron d'architecture de développement informatique, popularisé (et non inventé) par Google, dans lequel sont effectués des calculs parallèles, et souvent distribués, de données potentiellement très volumineuses, typiquement supérieures en taille à 1 téraoctet. [W4] II.3.2. Principe de MapReduce Le principe de MapReduce est simple (voir Figure II-5): il s’agit de découper une tâche manipulant un gros volume de données en plusieurs tâches traitant chacune un sous- ensemble de ces données. Dans la première étape (Map) les tâches sont donc dispatchées sur l’ensemble des nœuds. Chaque nœud traite un ensemble des données. Dans la deuxième étape, les résultats sont consolidés pour former le résultat final du traitement (Reduce).
  32. 32. 27 Figure II.5. Les étapes Map et Reduce II.3.3. Le modèle de programmation MapReduce consiste en deux fonctions map() et reduce().  Dans l'étape Map, le nœud analyse un problème, le découpe en sous-problèmes, et les délègue à d'autres nœuds (qui peuvent en faire de même récursivement). Les sous- problèmes sont ensuite traités par les différents nœuds à l'aide de la fonction Reduce qui à un couple (clé, valeur) associe un ensemble de nouveaux couples (clé, valeur) : map(clé1,valeur1) → list(clé2,valeur2) Fonction Map : //En pseudo code cela donnerait Map(void * document){ int cles = 1; for each mot m in document calculIntermediaire(m,cles); }  Vient ensuite l'étape Reduce, où les nœuds les plus bas font remonter leurs résultats au nœud parent qui les avait sollicités. Celui-ci calcule un résultat partiel à l'aide de la fonction Reduce (réduction) qui associe toutes les valeurs correspondantes à la même clé à une unique paire (clé, valeur). Puis il remonte l'information à son tour.
  33. 33. 28 À la fin du processus, le nœud d'origine peut recomposer une réponse au problème qui lui avait été soumis : reduce(key2,list(valeur2))→ list(valeur2) Fonction Reduce : //En pseudo code cela donnerait Reduce(entier cles, Iterator values){ int result = 0; for each v in values result += v; } MapReduce peut être utilisé pour un grand nombre d'applications, dont grep distribué, tri distribué, inversion du graphe des liens Web, vecteur de terme par hôte, statistiques d'accès au Web, construction d'index inversé, classification automatique de documents, apprentissage automatique. [W4] Le MapReduce a émergé en 2004 comme un important modèle de programmation pour les applications utilisant d’énormes quantités de données grâce à sa répartition efficace du travail sur différents nœuds de calcul. Il commence notamment à être utilisé dans le Cloud Computing, car son nombre de données stockées et manipulées ne cesse de croître. Il est donc nécessaire d'avoir un moyen d'améliorer le traitement des données au sein du Cloud. [W4]
  34. 34. 29 II-4 Conclusion Nous avons montré dans ce chapitre les différents types de bases de données NoSQL avec leurs différents domaines d’utilisation. Nous avons présenté en fin du chapitre l’algorithme MapReduce, et nous avons expliqué ses composants et son fonctionnement. Le chapitre suivant sera consacré à présenter deux solutions NoSQL. Le but est de comparer leur performance et d’arriver, en cas de besoin, à en choisir la bonne solution pour les circonstances liées au type de données choisies et au type de traitement exécuté sur ces données.
  35. 35. 30 Chapitre III. HADOOP, HBASE, MONGODB ET YCSB.
  36. 36. 31 III.1. Introduction Nous nous intéresserons particulièrement dans ce chapitre aux technologies HBASE, MongoDB, et Hadoop le framework Java destiné aux applications distribuées et à la gestion intensive des données. Ce sont des technologies récentes, encore relativement peu connues du grand public mais auxquelles nous associons déjà des grands noms parmi lesquels : Facebook, Yahoo ou encore Twitter. Nous présentons en fin de chapitre l’outil Yahoo ! Cloud Serving Benchmark (YCSB) qui un générateur de banque d'essais (benchmark en anglais) pour les bases de données NoSQL sur Cloud Computing. III.2. HADOOP III.2.1. Historique Doug Cutting l’un des fondateurs de Hadoop, travaillant à l’époque sur le développement de Apache Lucene, cherchait une solution quant à la distribution du traitement de Lucene afin de bâtir le moteur d’indexation web Nutch. Il décidait donc de s’inspirer de la publication de Google sur leur système de fichier distribué GFS (Google File System). Premièrement, renommer NDFS, il sera rebaptisé HDFS pour Hadoop Distributed File System [5]. III.2.2. Présentation d’Hadoop Hadoop est un ensemble de logiciels et d’outils qui permettent de créer des applications distribuées. C’est une plate-forme logicielle open-source, écrite en Java et fondée sur le modèle MapReduce de Google et les systèmes de fichiers distribués (HDFS). Elle permet de prendre en charge les applications distribuées en analysant de très grands ensembles de données. Hadoop est utilisé particulièrement dans l’indexation et le tri de grands ensembles de données, le data mining, l’analyse de logs, et le traitement d’images. Le succès de Google lui est en partie imputable. En 2001, alors qu’il n'en est encore qu'à ses balbutiements sur le marché des moteurs de recherche, le futur géant développe ce qui inspira les composants phares d'Hadoop: MapReduce, Google BigTable et Google BigFiles (futur Google File System). Ces deux points forment l’écosystème Hadoop, écosystème fortement convoité et qui se trouve au centre de l’univers du Big Data [10].
  37. 37. 32 Hadoop fait partie des projets de la fondation de logiciel Apache depuis 2009. Il est destiné à faciliter le développement d’applications distribuées et scalables, permettant la gestion de milliers de nœuds ainsi que des pétaoctets de données. En 2011, Yahoo! crée Horton works, sa filiale dédiée à Hadoop. L'entreprise se concentre sur le développement et le support d'Apache Hadoop. De la même manière, Cloudera, créé au début de l'année 2009, se place comme l'un des plus gros contributeurs au projet Hadoop, au côté de MapR (2009) et Hortonworks. Typologie d’un cluster Hadoop Hadoop repose sur un schéma dit « maître-esclave » et peut être décomposé en cinq éléments. (Fig III.1) : Le nom du noeud (Name Node) : Le « Name Node » est la pièce centrale dans le HDFS, il maintient une arborescence de tous les fichiers du système et gère l’espace de nommage. Il centralise la localisation des blocs de données répartis sur le système. Sans le « Name Node», les données peuvent être considérées comme perdues car il s’occupe de reconstituer un fichier à partir des différents blocs répartis dans les différents « Data Node ». Il n’y a qu’un «Name Node» par cluster HDFS. Le gestionnaire de tâches (Job Tracker) : Il s’occupe de la coordination des tâches sur les différents clusters. Il attribue les fonctions de MapReduce aux différents « TaskTrackers ». Le « Job Tracker » est un « Daemon » cohabitant avec le « Name Node » et ne possède donc qu’une instance par cluster. Le moniteur de tâches (Tasktracker) : Il permet l’exécution des ordres de mapReduce, ainsi que la lecture des blocs de données en accédant aux différents « Data Nodes ». Par ailleurs, le « TaskTracker » notifie de façon périodique au « Job Tracker » le niveau de progression des tâches qu’il exécute, ou alors d’éventuelles erreurs pour que celui-ci puisse reprogrammer et assigner une nouvelle tâche Un « TaskTracker est un « Deamon » cohabitant avec un « Data Node », il y a un donc un « TaskTracker » par « Data Node ». Le noeud secondaire (Secondarynode) : N’étant initialement pas présent dans l’architecture Hadoop, celui-ci a été ajouté par la suite afin de répondre au problème du point individuel de défaillance (SPOF- Single point of failure). Le « Secondary Node » va donc périodiquement faire une copie des données du « Name Node » afin de pouvoir prendre la relève en cas de panne de ce dernier.
  38. 38. 33 Le nœud de données (Data Node) : Il permet le stockage des blocs de données. Il communique périodiquement au « Name Node » une liste des blocs qu’il gère. Un HDFS contient plusieurs noeuds de données ainsi que des réplications d’entre eux. Ce sont les nœuds esclaves [5]. Figure III.1 Architecture d’un Cluster Hadoop Un Cluster Hadoop peut être constitué de machines hétérogènes, que ce soit au niveau du hardware comme au niveau software (système d’exploitation). Cependant il est bien plus simple d’administrer un cluster de type homogène [5]. Hadoop est aujourd’hui l’un des outils les plus pertinents pour répondre aux problèmes du Big Data [5]. C’est la première technologie qui vient à l’esprit lorsque l’on évoque aujourd’hui ce sujet [11].
  39. 39. 34 Les points forts d’Hadoop se résument dans ses caractéristiques suivantes : - évolutif, car pensé pour utiliser plus de ressources physiques, selon les besoins, et de manière transparente ; - rentable, car il optimise les coûts via une meilleure utilisation des ressources présentes; - souple, car il répond à la caractéristique de variété des données en étant capable de traiter différents types de données ; - et enfin, résilient, car pensé pour ne pas perdre d'information et être capable de poursuivre le traitement si un nœud du système tombe en panne [10]. Hadoop n’a pas été conçu pour traiter de grandes quantités de données structurées à grande vitesse. Cette mission reste largement l’apanage des grands systèmes de Datawarehouse et de Datamart reposant sur des SGBD traditionnelles et faisant usage de SQL comme langage de requête. La spécialité d’Hadoop, ce serait plutôt le traitement à très grande échelle de grands volumes de données non structurées tels que des documents textuels, des images, des fichiers audio,… même s’il est aussi possible de traiter des données semi-structurées ou structurées avec Hadoop [11]. Exemple d’usage Ce qui fait la spécificité de Hadoop est qu’il est conçu pour traiter un énorme volume de données en un temps record. A titre d’exemple, les Laboratoires de Yahoo! ont trié l’équivalent de 500 GB de données en 59 secondes sur un Cluster de 1400 nœuds (Avril 2009). Sa vocation première est donc d’implémenter des traitements batchs performants, particulièrement lorsqu’ils impliquent un volume de données très important. En dehors de Yahoo!, citons les cas d’utilisation de deux sociétés prestigieuses :  La plateforme musicale Last.fm met en œuvre Hadoop pour générer les statistiques hebdomadaires (Tops artistes et Top titres) ou mesurer les tendances musicales.  Facebook l’utilise pour la production de rapports à usage interne, comme la performance des campagnes publicitaires opérées par la plateforme sociale, ou des statistiques diverses (croissance du nombre des utilisateurs, consultation des pages, temps moyen de consultation du site, etc.) [W4].
  40. 40. 35 III.2.3. HDFS HDFS (Hadoop Distributed File System) est un système de fichiers distribué, inspiré du système GFS développé par Google. Il se démarque des autres systèmes de fichier distribués par sa grande tolérance aux fautes [8] et le fait qu’il soit conçu pour être déployé sur des machines à faible coût. HDFS fournit un haut débit d’accès aux données et est adapté pour les applications qui nécessitent de grands groupes de données. Il a été à l’origine conçu pour le projet de moteur de recherche web Apache Nutch [9]. HDFS a une architecture de type maître/esclave. Un Cluster HDFS est constitué d’un unique NameNode, un serveur maître qui gère le système de fichier et notamment les droits d’accès aux fichiers. A cela s’ajoute des DataNodes, en général un par nœud dans le Cluster, qui gère le stockage des données affectés au nœud sur lequel elle se trouve (Voir Figure III.2). HDFS est conçu pour tourner sur des machines simples sous GNU/linux, et est programmé en Java. Toute machine qui dispose de Java peut donc faire tourner un NameNode ou un DataNode. Les nœuds communiquent entre eux via SSH. Il faut donc entrer la clé publique de chaque DataNode dans le fichier authorized_keys du NameNode, afin qu’il puisse se connecter aux autres nœuds via SSH sans avoir besoin de taper un mot de passe à chaque fois [9]. Figure III.2. Schéma HDFS Le NameNode dispose d’un fichier de configuration dans lequel il entre l’adresse de chaque machine sur laquelle tourne un DataNode, et se connecte ensuite à chacune de ces machines
  41. 41. 36 via SSH au démarrage de HDFS. Par ailleurs, le NameNode est l’arbitre et le dépositaire de toutes les métadonnées du HDFS. HDFS est conçu de telle sorte qu’aucune donnée de l’utilisateur ne transite par le NameNode (voir Figure III.3). [9] Dans Hadoop, les différents types de données, qu’elles soient structurées ou non, sont stockées à l’aide du HDFS. Le HDFS va prendre les données en entrée et va ensuite les partitionner en plusieurs blocs de données. Afin de garantir une disponibilité des données en cas de panne d’un nœud, le système fera un réplica des données. Par défaut les données sont répliquées sur trois nœuds différents, deux sur le même support et un sur un support différent. Les différents nœuds de données peuvent communiquer entre eux pour rééquilibrer les données (Figure III.3) [5]. Figure III.3: Réplication des données à l’aide du HDFS HDFS est fait pour stocker de gros fichiers (chaque fichier est divisé en bloc de 64 MB par défaut). D’après la documentation officielle, un fichier typique dans HDFS fait une taille de l’ordre du GB voire du TB (1 TB = 1012 Octet = 1000 gigabytes) [W11]. HDFS est fait pour une très grande scalabilité et tourne déjà en production sur des très gros Clusters (plus de 1000 machines) dans des sociétés comme Facebook ou Yahoo [9].
  42. 42. 37 De plus HDFS est avant tout conçu pour être utilisé avec Hadoop (Figure III.4). La philosophie de l’implémentation d’Hadoop repose sur le principe qu’il est plus efficace de déplacer de la capacité de calcul que des donnés. HDFS fournit donc une interface pour pouvoir déplacer le traitement des données au plus près de celles-ci. Figure III.4. Hadoop Distributed File System (HDFS) III.2.4. Le composant MapReduce MapReduce est une technique qui permet d’effectuer des tâches sur de grandes quantités de données en utilisant un cluster de machines. Elle est implémentée au cœur du projet Hadoop. MapReduce est le second composant majeur d’Hadoop qui gère la répartition et l’exécution des requêtes sur les données stockées par le Cluster. Le Framework MapReduce est conçu pour traiter des problèmes parallèlisables à très grande échelle en s’appuyant sur un très grand nombre de nœuds. L’objectif de MapReduce et de son mécanisme avancé de
  43. 43. 38 distribution de tâches est de tirer parti de la localité entre données et traitements sur le même nœud de façon à minimiser l’impact des transferts de données entre les nœuds du Cluster sur la performance [11]. Le moteur MapReduce de Hadoop réceptionne les jobs de la part des applications puis les divise en une série de tâches, qu’il assigne ensuite aux différents nœuds de calcul [8]. Les jobs MapReduce se structurent toujours autour de trois parties : deux classes static «Mapper» et «Reduce», et une méthode main qui dirige l’application. L’exécution des jobs se fait à l’aide d’un JobTracker et de Tasktrackers : lors de son exécution le job est soumis au JobTracker qui s’occupe de le distribuer au Tasktracker qui tourne sur chaque noeud. Le JobTracker choisit toujours les TaskTracker qui sont les plus proches de l’emplacement de la donnée à traiter [9]. Une fois que la partie « Map » est terminée, c’est la partie Reduce qui commence à faire remonter les différents résultats et les consolider en un seul résultat final (voir 5.2.3 fonctionnement de MapReduce) pour répondre à la requête du client (Figure III.5) [5]. Figure III.5. Fonctionnement de MapReduce dans Hadoop
  44. 44. 39 III.3. HBASE III.3. 1. Présentation de Hbase HBase est un système de gestion de base de données NoSQL distribué, écrit en Java, disposant d'un stockage structuré pour les grandes tables. Il est sous LicenceApache. La société américaine Cloudera distribue une édition de Hadoop et HBase avec support nommée Cloudera Enterprise. HBase est utilisé par des acteurs comme Facebook pour stocker tous les messages de ce réseau social, ce qui représentait en 2009 plus de 150 téraoctets de nouvelles données par mois [W6]. HBase est inspirée des publications de Google sur BigTable, de type base de données orientée colonnes basées sur une architecture maître/esclave, et capable de gérer d'énormes quantités d'informations (plusieurs milliards de lignes par table). Il s'installe généralement sur le système de fichiers HDFS d'Hadoop pour faciliter la distribution. Il est utilisé lors d’un besoin à un accès aléatoire pour lecture- écriture en temps réel au Big Data. L'objectif de ce projet est l'hébergement de très Grandes tables des milliards de lignes et des millions de colonnes. HBase conserve un grand nombre de fichiers ouverts en même temps [12]. Mark Zuckerberg a annoncé le 15novembre2010 que Facebook allait désormais utiliser HBase en remplacement de Cassandra [W7]. Parmi les points forts de Hbase, nous trouvons ; son utilisation pour le Big Data, sa solidité de la conception et excellente tolérance au partitionnement. La propriété ACID est garantie sur une ligne (c'est-à-dire plusieurs familles de colonnes) depuis HBase 0.92 [W6]. III.3. 2. Architecture de HBASE Contrairement au SGBD orienté ligne (SGBD relationnel), les données sont stockées sous forme de colonne. On retrouve deux types de composants pour HBase : le composant maître appelé «HMaster», qui contient le schéma des tables de données, et les nœuds esclaves appelés «Region Server», qui gèrent des sous-ensembles de tables, appelés « Region ».
  45. 45. 40 HBase est généralement utilisé sur un ensemble de machines, ou cluster, et utilise le système de fichier HDFS. Les données des tables sont stockées sur les nœuds « DataNode» (HDFS) par les nœuds de type « Region Server »(HBASE). La Figure III.6 présente le fonctionnement général d'HBase. Les tables sont stockées en orientation par colonne. Chaque table est constituée d'un ensemble de familles de colonnes (regroupements logiques de colonnes). Sur chaque famille de colonnes il est possible d'ajouter des colonnes. Les lignes des tables sont partitionnées en plusieurs régions. Lors de la création d'une table, une seule région est créée, elle est ensuite automatiquement divisée en sous- parties lorsque sa taille atteint un seuil limite. Le rôle du master est la gestion des régions. Zookeeper est un outil permettant de coordonner des services distribués, c'est lui qui permettra de faire le lien entre le master et le système de fichier distribué HDFS. Figure III.6. Schéma de HBASE.
  46. 46. 41 III.4. MONGODB III.4.1. Présentation de MongoDB MongoDB est une base de données orientée documents open-source qui fournit de hautes performances, haute disponibilité, et une scalabilité automatique [15]. Développé depuis 2007 par 10gen (une société de logiciel), MongoDB est un système de gestion de base de données orientée document. Ecrit en C++ et distribué sous licence AGPL (licence libre), elle est très adaptée aux applications Web. MongoDB a été adoptée par plusieurs grands noms de l’informatique, tels que Foursquare, SAP, ou bien même GitHub [5]. MongoDB utilise des fichiers au format BSON, un dérivé du JSON. Comparé à ce dernier, le BSON a été pensé pour faciliter le scan des données. Un enregistrement dans MongoDB est un document, qui est une structure de données composée de paires de champs et de valeur. Les valeurs des champs peuvent inclure d'autres documents, des tableaux et des tableaux de documents [15]. Fonctionnant comme une architecture distribuée centralisée, il réplique les données sur plusieurs serveurs avec le principe de maître-esclave, permettant ainsi une plus grande tolérance aux pannes. La répartition et la duplication de document est faite de sorte que les documents les plus demandés soient sur le même serveur et que celui-ci soit dupliqué un nombre de fois suffisant [15]. Par sa simplicité d’utilisation du point de vue de développement client, ainsi que ces performances remarquables, MongoDB est l’une de base de données orientées document la plus utilisé [5]. III.4.2. Modèle de données Le modèle de données de MongoDB est de type orienté documents. Un document, l'unité basique de MongoDB, est un ensemble ordonné de paires clé-valeur. Il est identifié par son nom. Un ensemble de documents (et peut donc être vu comme une table SQL) forment ce que nous appelons une collection. Les documents d'une collection peuvent avoir des formes très différentes. MongoDB ne pose aucune restriction quant aux documents contenus dans une même collection. 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.
  47. 47. 42 Une base de données MongoDB est un conteneur pour les collections (tout comme une base dedonnées SQL contient des tables) avec ses propres permissions [13]. III.4.3. Architecture Il existe quatre différents modes de fonctionnement pour MongoDB [14]: - Single : Le mode Single sert à faire fonctionner une base de données sur un seul serveur. - Replication Master / Slave : Dans Le mode Master/Slave ; le serveur fonctionne en tant que maître et s'occupe des demandes des clients. En plus il s'occupe de répliquer les données sur le serveur esclave de façon asynchrone. L'esclave est présent pour prendre la place du maître si ce dernier se tombe en panne. L'avantage premier de cette structure permet de garantir une forte cohérence des données, car seul le maître s'occupe des clients. Aucune opération n'est faite sur l'esclave, hormis quand le maître envoie les mise à jours [14]. - Replica Set : (Voir Figure III.7) Le Replica Sets fonctionne avec plusieurs nœuds possédant chacun la totalité des données, de la même manière qu'un réplica. Ces différents nœuds vont alors élire un nœud primaire, qui peut s'apparenter à un maître. Il faut qu'un nœud obtienne la majorité absolue afin d'être élu. Dans le cas où un nœud n'obtiendrait pas la majorité, le processus de vote recommencerait à zéro. De plus, une priorité peut être donnée à chaque nœud afin de lui donner plus de poids lors de l'élection. Un serveur arbitre peut être inséré dans le système. Ce dernier n'aura aucune donnée mais participera aux élections afin de pouvoir garantir la majorité absolue [14].
  48. 48. 43 - Sharding : Le Sharding est une surcouche qui est basée sur du Master / Slave ou du Replica Sets.  Les Shards : Ce sont un groupe de serveurs en mode Master / Slave ou Réplica Sets.  Les mongos : Ce sont des serveurs qui savent quelles données se trouvent dans quel Shard et leur donnent des ordres (lecture, écriture).  Les Config Servers : Ils connaissent l'emplacement de chaque donnée et en informent les mongos. De plus, ils organisent la structure des données entre les Shards. Le Sharding sert à partager les données entre plusieurs Shard, chaque Shard devant stocker une partie des données [14]. III.4.4. Le composant Mapreduce Dans une opération de MapReduce, MongoDB applique la phase de map pour chaque document d'entrée (les documents de la collection qui correspondent à la condition de requête). La fonction map retourne des paires clé-valeur. Pour les clés qui ont plusieurs valeurs, MongoDB applique la phase Reduce, qui recueille et condense les données agrégées. MongoDB stocke ensuite les résultats dans une collection. En option, la sortie de la fonction reduce peut passer à travers une fonction de finalisation traitement des résultats. Toutes les fonctions de Mapreduce dans MongoDB sont des scripts Java qui sont exécutés dans le processus de MongoDB. Les opérations Mapreduce prennent les documents d'une unique collection comme entrée, et peuvent effectuer un tri arbitraire et de limitation avant de commencer l'étape map. Mapreduce peut retourner les résultats d'une opération sous forme d’un document, ou peut écrire les résultats dans des collections. Les collections d'entrée et de la sortie peuvent être fragmentées. En résumé, les opérations de MapReduce utilisent des fonctions JavaScript pour l’étape map, et associe les valeurs à une clé. Si une clé a de multiples valeurs mappées à elle, l'opération reduce réduit les valeurs de la clé à un seul objet. L'utilisation de fonctions JavaScript permet la flexibilité des opérations Mapreduce [W8].
  49. 49. 44 III.4.5. Réponse au CAP MongoDB, de par son architecture dans un système distribué, et qui dans chaque mode utilise toujours un nœud maître, a tendance à privilégier l'intégrité par rapport à la disponibilité [14]. MongoDB se différencie des bases de données relationnelles avec sa récupération automatique d'erreurs dans le cas où un serveur maître viendrait à être indisponible, via le système d'élection où les esclaves vont s'élire entre eux. Elle permet également de gérer des transactions en deux phases et permet de revenir en arrière en cas d'erreur afin de garantir l'isolation des données. De plus, de nombreux CMS (Content Management System) ont également fait des portages sur MongoDB, car cette dernière se prête bien aux applications Web [15]. III.5. YCSB : Le Benchmark Yahoo Yahoo propose un outil très puisant (YCSB : Yahoo ! Cloud Serving Benchmark) qui se présente comme une nouvelle méthodologie de bancs d'essais (benchmark en anglais) pour les bases de données NoSQL sur Cloud. YCSB est un excellent outil pour comparer les performances SGBD NoSQL. Il supporte l’exécution des tests de chargement en parallèle des variables (benchmark), pour évaluer l’insertion, la mise à jour, et la suppression des enregistrements. Dans chaque test on peut configurer le nombre d'enregistrements à charger, le nombre d’opérations à effectuer, et la proportion de lecture et d'écriture. Il est donc facile à utiliser pour tester différents scénarios de charge d’enregistrements et d’opérations. Les tests utilisent des charges de travail (Workload ) avec des paramètres de de référence différents pour chaque Workload. Par exemple : ● Workload A: 50% de lectures, 50% de mises à jour. ● Workload B: 95% de lectures, 5% des mises à jour. ● Workload C: 100% de lectures. ● Workload F: simule read-modify-write. ● Workload D: insère des enregistrements, avec des lectures des données récemment insérées. ● Workload E: insère des enregistrements, et interroge les plages d'enregistrements. Chaque Workload effectue généralement 1000 opérations et mesure la latence moyenne par type d'opération, ainsi que le débit total de toutes les opérations. Ces Workload peuvent être modifié et personnalisé suivant la nature des résultats attendues des tests.
  50. 50. 45 III.6. Conclusion Dans ce chapitre nous avons présenté les outils utilisés dans la partie implémentation et expérimentation citée dans le chapitre IV. En l’occurrence, Hadoop, HBASE, MongoDB, et YCSB. Nous avons présenté l’architecture, les caractéristiques techniques et les composants de chaque système. L’objectif était de donner aux lecteurs une idée sur ces outils, leur domaine d’utilisation, et leur mode de fonctionnent ; afin de leur permettre le suivi et la compréhension le fond de notre travail qui consiste à comparer les performances des systèmes SGBD NoSQL : HBASE et MongoDB. La comparaison de L’évaluation de performance l’analyse de résultat est présentée dans le chapitre IV.
  51. 51. 46 Chapitre IV. IMPLEMENTATION ET EXPERIMENTATION
  52. 52. 47 IV.1. Introduction Ce chapitre est consacré aux étapes d’installation des composants Hadoop, HBASE et MongoDB, et se termine avec une analyse des résultats obtenus à partir des tests, afin d’arriver à une évaluation globale de performances. Dans la première partie, vous trouverez les étapes d’installation de Hadoop, HBASE et MongoDB, et l’outil de Benchmarking YCSB. La deuxième partie est consacrée à l’analyse des résultats obtenus à partir de nos expérimentations dans le cas d’une architecture Single Node. Pour le second cas - l’architecture distribuée sur un Cloud Computing- nous avons fait une analyse à partir d’une étude publiée et réalisée sur la base de tests effectués dans cet environnement. L’évaluation des performances va se porter sur deux niveaux : 1- Niveau 1 : temps d’exécution : il consiste à mesurer le temps d’exécution des demandes lorsqu'une base de données est en charge (Workloads). La lenteur d’exécution des demandes est fortement liée au débit du système SGBD NoSQL et reste un obstacle pour augmenter la performance. 2- Niveau 2 : évolutivité: Le plus grand indice de vente chez les fournisseurs Cloud est leur capacité à ajouter de nouveaux serveurs (nœuds) en cas de besoin. Le but est de savoir l’impact d’évolutivité sur les performances des SGBD NoSQL. IV.2. Première partie IV.2.1. Installation de Hadoop, HBASE, MongoDB et YCSB IV.2.1.1.Configuration  PC portable, HP Probook 4740s ;  Processeur : Intel Core i5-2450M CPU@2.50GHzx4  Type OS : 64 Bits  RAM : 6 Go  Disque : 732 Go
  53. 53. 48  Système d’exploitation : Ubuntu 14.10  Hadoop 1.0.4  HBASE 0.94.8  MongoDB 2.6.7  YCSB 0.1.4 IV.2.1.2. Installation d’Hadoop en mode Single Node Dans ce chapitre, nous allons montrer l’installation d’un cluster Hadoop Single-Node version 1.0.4 sur Ubuntu 14.10 LTS. L’installation de Hadoop-1.0.4 est réalisé à en suivant les étapes suivantes : 1- Installation de JAVA. Le composant java est un outil indispensable pour l’exécution des jobs Hadoop écrits sous forme de javascript. Nous commençons par une mise à jour du système Ubuntu. $ sudo apt-get update Ensuite, nous avons installé la version récente de java à l’aide de la commande : $ sudo apt-get install default-jdk Et pour vérifier la version de java : $ java -version java version "1.7.0_65" OpenJDKRuntimeEnvironment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu1) OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) Initialement ; les utilisateurs d’Hadoop doivent être définis. Afin de leurs attribuer les permissions d’utilisation de Hadoop. Pour cela, nous devons créer un groupe d’utilisateurs avec tous les droits sur Hadoop. $ sudo addgroup hadoop $ sudo adduser --ingroup hadoop hduser Hduser est l’utilisateur crée dans notre cas pour gérer Hadoop. La gestion des droits est très stricte dans les systèmes Linux. A cet effet ; la création d’une clé SSH pour notre utilisateur hduser est obligatoire.
  54. 54. 49 Création est installation des certificats SSH : Hadoop nécessite un accès SSH pour gérer ses nœuds, c’est à dire les machines distantes ainsi que notre machine locale. Pour notre configuration à un nœud unique (Single Node) , nous avons donc besoin de configurer l'accès SSH à localhost : acef@pcubuntu01:~$ su - hduser hduser@pcubuntu01:~$ ssh-keygen -t rsa -P "" Generating public/private rsa key pair. Enter file in which to save the key (/home/hduser/.ssh/id_rsa): Created directory '/home/hduser/.ssh'. Your identification has been saved in /home/hduser/.ssh/id_rsa. Your public key has been saved in /home/hduser/.ssh/id_rsa.pub. The key fingerprint is: 9b:82:ea:58:b4:e0:35:d7:ff:19:66:a6:ef:ae:0e:d2 hduser@pcubuntu01 The key's randomart image is: …….. Afin que Hadoop peut utiliser SSH sans demander un mot de passe à chaque accès ; nous avons besoin d’ajouter la clé nouvellement créée à la liste des clés autorisées. Pour cela nous devons taper la commande suivante : hduser@pcubuntu01:~$ cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys Nous pouvons vérifier si SSH fonctionne: hduser@pcubuntu01:~$ ssh localhost The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is d7:87:25:47:ae:02:00:eb:1d:75:4f:bb:44:f9:36:26. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Pour installer Hadoop-1.0.4, nous l’avons téléchargé à partir du site Apache. Après l’extraction, le dossier hadoop est déplacé vers /usr/local. $ cd /usr/local $ sudo tar xzf hadoop-1.0.4.tar.gz $ sudo mv hadoop-1.0.3 hadoop $ sudo chown -R hduser:hadoop hadoop Réglage des fichiers de paramètres Les fichiers suivants devront être modifiés pour terminer la configuration d’Hadoop:
  55. 55. 50 1. ~/.bashrc 2. /usr/local/hadoop/etc/hadoop/hadoop-env.sh 3. /usr/local/hadoop/etc/hadoop/core-site.xml 4. /usr/local/hadoop/etc/hadoop/mapred-site.xml.template 5. /usr/local/hadoop/etc/hadoop/hdfs-site.xml 1. ~/.bashrc: Avant de modifier le fichier .bashrc dans notre répertoire personnel, nous devons trouver le chemin où Java a été installée pour définir la variable d'environnement JAVA_HOME en utilisant la commande suivante: $ update-alternatives --config java There isonly one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java Nothing to configure. Maintenant, nous pouvons ajouter les lignes suivantes à la fin de ~ / .bashrc # Set Hadoop-related environment variables export HADOOP_HOME=/usr/local/hadoop # Set JAVA_HOME (we will also configure JAVA_HOME directly for Hadoop later on) export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 # Some convenient aliases and functions for running Hadoop-related commands unalias fs &> /dev/null alias fs="hadoop fs" unalias hls &> /dev/null alias hls="fs -ls" # If you have LZO compression enabled in your Hadoop cluster and # compress job outputs with LZOP (not covered in this tutorial): # Conveniently inspect an LZOP compressed file from the command # line; run via: # # $ lzohead /hdfs/path/to/lzop/compressed/file.lzo # # Requires installed 'lzop' command. # lzohead () { hadoop fs -cat $1 | lzop -dc | head -1000 | less } # Add Hadoop bin/ directory to PATH export PATH=$PATH:$HADOOP_HOME/bin 2. /usr/local/hadoop/etc/hadoop/hadoop-env.sh Nous devons définir JAVA_HOME en modifiant le fichier hadoop-env.sh :
  56. 56. 51 export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 L’ajout de la déclaration ci-dessus dans le fichier hadoop-env.sh assure que la valeur de la variable JAVA_HOME sera disponible pour Hadoop chaque fois qu'il est mis en marche. 3. /usr/local/hadoop/etc/hadoop/core-site.xml: Le fichier /usr/local/hadoop/etc/hadoop/core-site.xml contient les propriétés de configuration utilisées par Hadoop au démarrage. Premièrement nous devons créer un dossier de travail pour Hadoop. $ sudo mkdir -p /app/hadoop/tmp $ sudo chown hduser:hadoop /app/hadoop/tmp # ...and if you want to tighten up security, chmod from 755 to 750... $ sudo chmod 750 /app/hadoop/tmp Ensuite il faut modifier le fichier /usr/local/hadoop/etc/hadoop/core-site.xml <property> <name>hadoop.tmp.dir</name> <value>/app/hadoop/tmp</value> <description>A base for other temporary directories.</description> </property> <property> <name>fs.default.name</name> <value>hdfs://localhost:54310</value> <description>The name of the default file system. A URI whose scheme and authority determine the FileSystem implementation. The uri's scheme determines the config property (fs.SCHEME.impl) naming the FileSystem implementation class. The uri's authority is used to determine the host, port, etc. for a filesystem.</description> </property> 4. /usr/local/hadoop/etc/hadoop/mapred-site.xml Le fichier mapred-site.xml est utilisé pour spécifier dans quel cadre est utilisée MapReduce. Nous devons entrer le contenu suivants dans le bloc <configuration></configuration> <property> <name>mapred.job.tracker</name> <value>localhost:54311</value>
  57. 57. 52 <description>The host and port that the MapReduce job tracker runs at. If "local", then jobs are run in-process as a single map and reduce task. </description> </property> 5. /usr/local/hadoop/etc/hadoop/hdfs-site.xml Le fichier /usr/local/hadoop/etc/hadoop/hdfs-site.xml doit être configuré pour chaque hôte du cluster qui va l’utiliser. Il est utilisé pour spécifier les répertoires qui seront utilisés comme NameNode et DataNode sur cette hôte. Ouvrez le fichier et entrez le contenu suivant entre <configuration></ configuration> : <property> <name>dfs.replication</name> <value>1</value> <description>Default block replication. The actual number of replications can be specified when the file is created. The default is used if replication is not specified in create time. </description> </property> Formater le nouveau système de fichier HDFS pour Hadoop : hduser@pcubuntu01:~$ /usr/local/hadoop/bin/hadoop namenode -format L’écran suivant s’affiche : .../hadoop-hduser/dfs/name has been successfully formatted. ************************************************************ SHUTDOWN_MSG: Shutting down NameNode at ubuntu/127.0.1.1 ************************************************************/ 6- Lancement d’Hadoop Maintenant il est temps de démarrer le cluster Hadoop Single-Node nouvellement installé. Nous pouvons lancer (start-dfs.sh et start-yarn.sh) ou start-all.sh. hduser@pcubuntu01:~$ /usr/local/hadoop/bin/start-all.sh
  58. 58. 53 Pour vérifier le bon fonctionnement d’Hadoop : On tape la commande : jps 7- Et pour arrêter Hadoop : hduser@pcubuntu01:~$ /usr/local/hadoop/bin/stop-all.sh Par défaut, Hadoop est configuré avec des interfaces WEB afin de faciliter la gestion de ces composants : - http://localhost:50070/ – Web UI pour le NameNode - http://localhost:50030/ – Web UI pour le JobTracker - http://localhost:50060/ – Web UI pour le TaskTracker
  59. 59. 54 http://localhost:50070/ – Web UI pour le NameNode
  60. 60. 55 http://localhost:50030/ – Web UI pour le JobTracker http://localhost:50060/ – Web UI pour le TaskTracker
  61. 61. 56 IV.2.1.3. Installation de HBASE L’installation de HBASE est très facile à réaliser. Il faut choisir une version stable conforme à la configuration disponible. Les étapes à suivre pour effectuer l’installation : 1- Télécharger HBASE, version stable, depuis le site : http://www.apache.org/dyn/closer.cgi/hbase/. 2- Extraire le fichier téléchargé dans le chemin /usr/local $ cd /usr/local $ sudo tar xzf hbase-0.90.4.tar.gz $ sudo mv hbase-0.90.4 hbase $ sudo chown -R hduser:hadoop hbase 3- Modifier le fichier ~/.bashrc en ajoutant les lignes : # Set Hadoop-related environment variables export HADOOP_HOME=/usr/local/hadoop export HBASE_HOME=/usr/local/hbase # Add Hadoop bin/ directory to PATH export PATH=$PATH:$HADOOP_HOME/bin:$HBASE_HOME/bin 4- Modifier le fichier /usr/local/hbase/conf/hbase-site.xml <configuration> <property> <name>hbase.cluster.distributed</name> <value>true</value> </property> <property> <name>hbase.rootdir</name> <value>hdfs://localhost:54310/hbase</value> <description>The directory shared by RegionServers. </description> </property> <property> <name>dfs.replication</name> <value>1</value> <description>The replication count for HLog and HFile storage. Should not be greater than HDFS datanode count. </description> </property> </configuration> 5- Remarque : Il faut modifier le fichiers /etc/hosts pour éviter des erreurs de fonctionnement da HBASE :
  62. 62. 57 Modifier l’adresse IP de 127.0.1.1 pcubuntu01 à : 127.0.0.1 pcubuntu01 6- Lancer Hadoop avec la commande : $start-all.sh 7- Lancer HBase avec la commande : $start-hbase.sh 8- Vérifier le bon fonctionnement de HBase en tapant la commande : jps 9- La gestion des tables HBase se fait à l’aide de l’invite : hbase shell $hbase shell HBase Shell; enter 'help<RETURN>' for list of supportedcommands. Type "exit<RETURN>" to leave the HBase Shell Version 0.90.4, r1150278, Sun Jul 24 15:53:29 PDT 2011 hbase(main):001:0>create 'test','cf' 0 row(s) in 1.3890 seconds hbase(main):004:0>list TABLE Test row(s) in 0.0120 seconds
  63. 63. 58 L’interface WEB de HBASE est définit par l’adresse : - http://localhost:60010 L’interface WEB offre toutes les informations utiles à propos de la base de données.
  64. 64. 59 IV.2.1.4. Installation de MongoDB Les étapes d’installation figurent dans la page WEB : http://docs.mongodb.org/manual/tutorial/install-mongodb-on-linux/ L’installation dans le cas d’un système Linux 64 bits se résume dans les étapes suivantes : 1- Télécharger MongoDB : curl -O http://downloads.mongodb.org/linux/mongodb-linux-x86_64- 2.6.7.tgz 2- Extraire le fichier téléchargé : tar -zxvf mongodb-linux-x86_64-2.6.7.tgz 3- Copier le dossier mongodb-linux-x86_64-2.6.7 dans l’emplacement Mongodb : mkdir -p mongodb cp -R -n mongodb-linux-x86_64-2.6.7/ mongodb 4- Ajouter la ligne suivante au fichier ~/.bashrc export PATH=/home/hduser/mongodb/bin:$PATH 5- Créer le dossier /data/db mkdir -p /data/db 6- Lancer MongoDB avec la commande : Mongod -rest L’option –rest permet de lance l’interface WEB qui peut être obtenu par l’adresse :
  65. 65. 60 - http://localhost:28017 - La liste des bases de donnée est affichée en cliquant sur listDatabases.
  66. 66. 61 IV.2.1.5. Comparaison des propriétés système Tableau 1: HBASE vs MongoDB [W9] Propriétés HBASE MongoDB Description Orienté Colonne basé sur Apache Hadoop et les concepsBigTable Un des plus populaires des orientés document Website hbase.apache.org www.mongodb.org Doc. technique hbase.apache.org docs.mongodb.org/manual Développeur Apache Foundation MongoDB, Inc Version initiale 2008 2009 License Open Source Open Source Langage d’implém. Java C++ OS Linux, Unix, Windows Linux, OS X, Solaris, Windows Modèle BD Orienté colonne Orienté Document Indexes secondaires NON Oui APIs et d’autre méthodes d’accés Java API, RESTful HTTP API, Thrift proprietaryprotocolusing JSON Langages de programmation supportés C, C#, C++ Groovy, Java PHP, Python, Scala Actionscript, C, C#, C++ Clojure, ColdFusion, D, Delphi, Erlang, Go, Groovy, Haskell, Java, JavaScript, Lisp, Lua, MatLab, Perl, PHP PowerShell, Prolog, Python, R, Ruby, Scala, Smalltalk Méthode de partitionnement Sharding Sharding Methode de replication selectablereplication factor Master-slave replication MapReduce Oui Oui
  67. 67. 62 IV.2.1.6. Installation de YCSB 1- Télécharger la source YCSB avec la commande : ~$ gitclone http://github.com/brianfrankcooper/YCSB.git 2- Accéder au dossier YCSB et compiler avec la commande : /YCSB/ mvn clean package 3- Après la phase de compilation ; copier et extraire le fichier ycsb-0.1.4.tar.gz se trouvant dans le dossier /YCSB/distribution/ vers un emplacement de votre choix Exécution des tests avec l’outil YCSB. Test de HBASE - Pour tester HBase, nous commençons par la phase de chargement (Load process). Taper : hduser@pcubuntu01:~/ycsb-0.1.4$ bin/ycsb load hbase -P workloads/workloada -p columnfamily=f1 -p recordcount=600000 -s > loadh.dat Le message suivant s’affiche pour indiquer le temps d’exécution du chargement (Load process). Loading workload... Starting test. 0 sec: 0 operations; 10 sec: 131095 operations; 13108,19 current ops/sec; [INSERT AverageLatency(us)=68,84] 20 sec: 234099 operations; 10297,31 current ops/sec; [INSERT AverageLatency(us)=98,74] 30 sec: 369877 operations; 13577,8 current ops/sec; [INSERT AverageLatency(us)=72,27] 40 sec: 486927 operations; 11705 current ops/sec; [INSERT AverageLatency(us)=78,94] 50 sec: 561839 operations; 7490,45 current ops/sec; [INSERT AverageLatency(us)=138,5] 54 sec: 600000 operations; 8226,13 current ops/sec; [INSERT AverageLatency(us)=125,09] - Pour l’exécution du Workload : hduser@pcubuntu01:~/ycsb-0.1.4$ bin/ycsb run hbase -P workloads/workloada - p columnfamily=f1 -p recordcount=600000 -s > rha.datPour tester MongoDB avec YCSB :
  68. 68. 63 - Le temps d’exécution des opérations est affiché dans l’écran : Loading workload... Starting test. 0 sec: 0 operations; 2 sec: 1000 operations; 442,28 current ops/sec; [UPDATE AverageLatency(us)=87,59] [READ AverageLatency(us)=4199,08] Test de MongoDB - Pour tester MongoDB, nous commençons par Load process : hduser@pcubuntu01:~/ycsb-0.1.4$ bin/ycsb load mongodb -P workloads/workloada -p recordcount=600000 -s > loadm.da - Le temps des opérations du chargement s’affiche à l’écran: Loading workload... Starting test. 0 sec: 0 operations; 10 sec: 35224 operations; 3517,12 current ops/sec; [INSERT AverageLatency(us)=271,46] 20 sec: 69417 operations; 3417,59 current ops/sec; [INSERT AverageLatency(us)=285,98] 30 sec: 103515 operations; 3409,46 current ops/sec; [INSERT AverageLatency(us)=287,16] 40 sec: 134375 operations; 3086 current ops/sec; [INSERT AverageLatency(us)=317,35] ………………… 110 sec: 341262 operations; 2663,43 current ops/sec; [INSERT AverageLatency(us)=369,1] 120 sec: 374153 operations; 3289,1 current ops/sec; [INSERT AverageLatency(us)=285,67] 130 sec: 405036 operations; 3087,99 current ops/sec; [INSERT AverageLatency(us)=328,89] 140 sec: 436248 operations; 3121,2 current ops/sec; [INSERT AverageLatency(us)=315,09] 150 sec: 467971 operations; 3171,98 current ops/sec; [INSERT AverageLatency(us)=308,4] 160 sec: 495816 operations; 2784,5 current ops/sec; [INSERT AverageLatency(us)=352,09] 170 sec: 520900 operations; 2508,15 current ops/sec; [INSERT AverageLatency(us)=393] 180 sec: 554563 operations; 3366,3 current ops/sec; [INSERT AverageLatency(us)=291,19] 190 sec: 586224 operations; 3165,78 current ops/sec; [INSERT AverageLatency(us)=309,9] 194 sec: 600000 operations; 2944,85 current ops/sec; [INSERT AverageLatency(us)=332,82]
  69. 69. 64 - L’étape de l’exécution se lance après la commande : hduser@pcubuntu01:~/ycsb-0.1.4$ bin/ycsb run mongodb -P workloads/workloada -p recordcount=600000 -s > rma.dat - Le résultat du test est le suivant : Loading workload... Starting test. 0 sec: 0 operations; 0 sec: 1000 operations; 1798,56 current ops/sec; [UPDATE AverageLatency(us)=482,79] [READ AverageLatency(us)=279,77] IV.3. Deuxième partie : Analyse des tests IV.3.1. Introduction Les objectifs ciblés dans ce chapitre sont les évaluations de performance de HBASE et MongoDB qui sont analysés sur deux niveaux :  L’évaluation de performance dans une architecture nœud unique (Single Node).  Et l’évaluation de performance dans une architecture distribuée hébergée par un environnement Cloud. Dans le premier cas, nous avons réalisé nos expériences présentées dans ce chapitre sous forme de test de scénarios (Benchmarks) en utilisant l’utilitaire YCSB. Ces tests sont exécutés sur les bases de données HBASE et MongoDB. Les résultats des tests sont notés et suivis par des explications et des commentaires. Afin de renforcer la validation des résultats de nos expériences, nous avons pris comme cadre de rapprochement les résultats publiés dans l’article « EXPERIMENTAL EVALUATION OF NOSQL DATABASES » écrit par Veronika Abramova, Jorge Bernardino et Pedro Furtado [16]. Les résultats obtenues par Veronika Abramova et son équipe dans leur article [16] sont en global plus lentes par rapport à nos résultats. La configuration utilisée dans leur expérience était: VM Ubuntu 32 bits 2 Go de RAM, hébergée dans un PC 32 bits Windows 7 avec 4 GO RAM. Notre configuration était : Ubuntu 14.10, PC 64 Bits, i5 CORE, 6 GO RAM.
  70. 70. 65 Pour le deuxième cas, celui de l’expérimentation dans un environnement distribué, et à cause de la difficulté d’implémenter ce genre d’expériences, due au manque d’infrastructures Cloud à notre niveau; nous nous somme limité uniquement sur les résultats publiés par DATASTAX CORPORATION dans son livre blanc « Benchmarking Top NoSQLDatabases », publié en février 2013 [17]. . IV.3.2. Tests et analyse des résultats IV.3.2.1. Première étude : Evaluation dans un Single Node Cluster Initialisation Nous avons commencé par initialiser l’outil YCSB avec 8 Workloads afin de rendre les scénarios plus significatifs [16]: • Workload A: Mise à jour lourde, se compose d'un rapport de 50% Read /50% Update ; • Workload B: Lire Partiellement, Il consiste en un rapport de 95% Read /5% Update ; • Workload C: Lecture seule, ce workload est 100% Read; • Workload D: Ce Workload se compose de 95% Read /5% Insert ; • Workload E: Se compose d'un rapport de 95% Scan /5% Insert ; • Workload F: Ce workload se compose d'un rapport de 50% Read /50% Read-Modify-Write ; • Workload G: Se compose d'un rapport de 5% Read /95% Update ; • Workload H: Ce workload est composé de 100% Update. Evaluation de performance Dans ce paragraphe, nous présentons et analysons les résultats de chargement de 600000 enregistrements générés par YCSB. Nous présentons également le temps d'exécution des Workloads enregistré pendant les opérations de lecture, écriture, et mises à jour.  Chargement de données (LoadProcess) Nous commençons par l’étape de chargement des donnés (Load Process). Les résultats obtenus après le lancement du Workload Load sont les suivants : - Le journal de chargement généré par YCSB pour HBASE :
  71. 71. 66 YCSB Client 0.1 Command line: -db com.yahoo.ycsb.db.HBaseClient -P workloads/workloada -p columnfamily=f1 -p recordcount=600000 -s -load [OVERALL], RunTime(ms), 54644.0 [OVERALL], Throughput(ops/sec), 10980.162506405095 [INSERT], Operations, 600000 [INSERT], AverageLatency(us), 88.99416833333333 [INSERT], MinLatency(us), 4 [INSERT], MaxLatency(us), 2639999 [INSERT], 95thPercentileLatency(ms), 0 [INSERT], 99thPercentileLatency(ms), 0 [INSERT], Return=0, 600000 [INSERT], 0, 599843 [INSERT], 1, 6 [INSERT], 2, 2 [INSERT], 999, 0 [INSERT], >1000, 10 - Le journal de chargement généré par YCSB pour MongoDB : YCSB Client 0.1 Command line: -db com.yahoo.ycsb.db.MongoDbClient -P workloads/workloada -p recordcount=600000 -s -load new database url = localhost:27017/ycsb mongo connection created with localhost:27017/ycsb [OVERALL], RunTime(ms), 189957.0 [OVERALL], Throughput(ops/sec), 3158.6095800628564 [INSERT], Operations, 600000 [INSERT], AverageLatency(us), 310.31195 [INSERT], MinLatency(us), 65 [INSERT], MaxLatency(us), 2379463 [INSERT], 95thPercentileLatency(ms), 0 [INSERT], 99thPercentileLatency(ms), 0 [INSERT], Return=0, 600000 [INSERT], 0, 598502 [INSERT], 1, 132 [INSERT], 2, 66 [INSERT], 3, 7 [INSERT], 4, 3 [INSERT], 5, 2 [INSERT], 6, 0 ………… [INSERT], 997, 0 [INSERT], 998, 0 [INSERT], 999, 0 [INSERT], >1000, 5

×