-
NoSQL
Etat de lart et benchmark
Travail de Bachelor ralis en vue de lobtention du Bachelor HES
par :
Adriano Girolamo PIAZZA
Conseiller au travail de Bachelor :
David BILLARD, Professeur HES
Genve, 9 octobre 2013
Haute cole de Gestion de Genve (HEG-GE)
Filire Informatique de Gestion
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo i
Dclaration
Ce travail de Bachelor est ralis dans le cadre de lexamen final de la Haute cole de
gestion de Genve, en vue de lobtention du titre de Bachelor en informatique de gestion.
Ltudiant accepte, le cas chant, la clause de confidentialit. L'utilisation des
conclusions et recommandations formules dans le travail de Bachelor, sans prjuger
de leur valeur, n'engage ni la responsabilit de l'auteur, ni celle du conseiller au travail
de Bachelor, du jur et de la HEG.
Jatteste avoir ralis seul prsent travail, sans avoir utilis des sources autres que
celles cites dans la bibliographie.
Fait Carouge, le 9 septembre 2013
Adriano Girolamo Piazza
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo ii
Remerciements
Tout dabord, je tiens remercier Monsieur David BILLARD pour mavoir suivi tout au
long de ce travail de Bachelor, ainsi que les diffrents points sur lesquels il ma conseill.
Je souhaite galement remercier ma famille ainsi que la famille POLI qui mont
encourag reprendre mes tudes et mont apport un trs grand soutien.
Pour finir je tiens remercier mes amis pour leur relecture de ce document, ainsi que
les corrections orthographiques quils ont pu amener.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo iii
Rsum
Les bases de donnes NoSQL, qui signifie not only SQL sont des types de base de
donnes qui ont commenc merger depuis 2009, pour rpondre aux nouveaux
besoins. Le nom peut sembler comme une opposition aux bases de donnes SQL, sa
fonction premire ntant pas de remplacer les bases de donnes relationnelles, mais
de proposer une alternative.
La premire partie de ce travail consistera expliquer ce que sont les bases de donnes
de type NoSQL, lhistoire du NoSQL, dans quel but ce que genre de base de donnes a
vu le jour.
Nous allons galement voir de quelle manire ces type de base de donnes
fonctionnent, les technologies quelles utilisent, sur quelles fondements elles sappuient,
ainsi que les avantages et dsavantages quune base de donnes de type NoSql peut
avoir en comparaison une base de donnes relationnel standard. Nous allons
galement voir un bref aperu du march actuel.
La dernire partie sera une synthse dun travail pratique reprenant la partie Bdd
effectue lors du projet de Gnie logiciel et de le reproduire sur une base de donnes
NoSql. Ce rapport expliquera les diffrents rsultats obtenus ainsi quune conclusion sur
lapplicabilit du NoSql plutt que le SQL standard pour ce type de projet.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo iv
Table des matires
Dclaration......................................................................................................... i
Remerciements ................................................................................................ ii
Rsum ............................................................................................................ iii
Table des matires .......................................................................................... iv
Liste des figures ............................................................................................. vii
1. Introduction ................................................................................................ 1
2. Lmergence du NoSQL ............................................................................ 2
2.1 Pourquoi lalternative du NoSQL ? ............................................................. 2
3. Les diffrences entre le NoSQL et le SQL ............................................... 2
3.1 Les principes du relationnel ........................................................................ 3
3.1.1 Le modle de donnes ............................................................................ 3
3.1.2 La gestion de la valeur NULL .................................................................. 3
3.2 Les transactions ........................................................................................... 4
3.2.1 Les proprits ACID ................................................................................ 4
3.3 Cohrence contre disponibilit ................................................................... 5
3.3.1 Le thorme de CAP ............................................................................... 5
3.4 Diffrents types de base de donnes NoSQL ............................................ 7
3.4.1 Les bases de donnes cl-valeur ............................................................ 7
3.4.2 Les bases de donnes orientes colonnes ............................................. 8
3.4.3 Les bases de donnes orientes document ...........................................10
3.4.4 Les bases de donnes orientes graphe ................................................11
4. Le march ................................................................................................. 13
4.1 DynamoDB (oriente cl-valeur) ................................................................13
4.2 Cassandra (oriente colonne) ....................................................................14
4.3 MongoDB (oriente document) ..................................................................15
4.4 Neo4j (oriente graphe) ..............................................................................15
5. Caractristiques techniques ................................................................... 16
5.1 La distribution de donnes .........................................................................16
5.1.1 Distribution sur un schma matre esclave. ............................................16
5.1.2 Distribution sur un schma multi-maitre .................................................18
5.2 MapReduce ..................................................................................................23
5.2.1 Principe de MapReduce .........................................................................23
5.2.2 Programmation fonctionnelle ..................................................................24
5.2.3 Fonctionnement de MapReduce ............................................................24
5.2.4 Les avantages ........................................................................................26
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo v
5.2.5 Les inconvnients ..................................................................................26
5.2.6 Hadoop ..................................................................................................27
5.3 La gestion de la cohrence des donnes ..................................................31
5.3.1 Anti Entropie .......................................................................................31
6. Les avantages / dsavantages du NoSQL ............................................ 33
6.1 Les avantages .............................................................................................33
6.1.1 Plus volutif ............................................................................................33
6.1.2 Plus flexible ............................................................................................34
6.1.3 Plus conomique....................................................................................34
6.1.4 Plus simple.............................................................................................34
6.1.5 Le Cloud Computing ..............................................................................34
6.2 Les dsavantages .......................................................................................35
6.2.1 Fonctionnalits rduites .........................................................................35
6.2.2 Normalisation et Open Source ...............................................................35
6.2.3 Performances et volutivit au dtriment de la cohrence .....................35
6.2.4 Manque gnral de maturit ..................................................................35
6.3 Conclusion ..................................................................................................36
7. Benchmark ............................................................................................... 36
7.1 Prsentation du sujet ..................................................................................36
7.2 Le modle de donnes Cassandra .............................................................36
7.2.1 La colonne .............................................................................................37
7.2.2 La ligne ..................................................................................................37
7.2.3 Famille de colonnes ...............................................................................38
7.2.4 Le keyspace ...........................................................................................38
7.2.5 Les diffrents types dattributs ................................................................38
7.3 Mise en place de la base de donnes EasyLocation sur Cassandra .......39
7.3.1 Cration de la base de donnes .............................................................39
7.3.2 Gestion des utilisateurs ..........................................................................40
7.3.3 La modlisation par la dnormalisation ..................................................42
7.3.4 Modle de donnes Easy_location ...................................................42
7.3.5 Lindexation ............................................................................................45
7.3.6 Utilisation de Cassandra-cli pour une meilleure approche ......................46
7.3.7 La cration de familles de colonnes .......................................................46
7.3.8 Insertion de donnes ..............................................................................48
7.4 Conclusion ..................................................................................................50
Bibliographie .................................................................................................. 53
Webographie .................................................................................................. 54
Annexe 1 : Script CQL de cration des utilisateurs et Dattribution des permissions .................................................................................................... 58
Annexe 2 : Modle de donnes relationnelle Easy_Location ..................... 59
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo vi
Annexe 3: Modle de donnes dnormalis.. ................................... 60
Annexe 4: Cration des familles de colonnes avec le client Cassandra-cl 61
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo vii
Liste des figures
Figure 1 : Gestion de la valeur NULL ............................................................................ 4
Figure 2 : Thorme de CAP.......................................................6
Figure 3 : Reprsentation cl-valeur7
Figure 4 : Comparaison schma relationnel vs colonne.. 9
Figure 5 : Reprsentation dune famille de colonnes9
Figure 6 : Base de donnes oriente document..10
Figure 7 : Reprsentation des graphes.12
Figure 8 : Logo DynamoDB.13
Figure 9 : Logo Cassandra..14
Figure 10 : Logo mongoDB........................................................................................15
Figure 11 : Logo Neo4j.15
Figure 12 : Distribution sur schma matre-esclave17
Figure 13 : Illustration de problme de cohrence lors de la consultation..18
Figure 14 : Protocole de bavardage...19
Figure 15 : Distribution par hachage sur la cl primaire.20
Figure 16 : Rpartition sur hachage consistant21
Figure 17 : Ajout dun nouveau nud22
Figure 18 : Schma MapReduce25
Figure 19 : Exemple comptage de mot..26
Figure 20 : Hadoop Distributed FileSystem..28
Figure 21 : Architecture dun cluster Hadoop...29
Figure 22: Fonctionnement de MapReduce dans Hadoop.30
Figure 23 : Reprsentation du HashTree sur Cassandra...32
Figure 24 : Reprsentation de conflit.33
Figure 25 : Description dune colonne...37
Figure 26 : Description dune ligne.37
Figure 27 : Description dune famille de colonnes...38
Figure 28 : Diffrents types proposs par Cassandra.39
Figure 29 : Modle conceptuel de donnes..43
Figure 30 : Modlisation par la dnormalisation..44
Figure 31 : Interrogation table client..49
Figure 32 : Interrogation table client..50
Figure 33 : Modle de donnes SQL Easy Location...59
Figure 34 : Modle de donnes dnormalis...60
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 1
1. Introduction
Quest-ce quune base de donnes ? A quoi cela peut-il servir ? Une base de donnes
est un dispositif servant stocker des donnes de diffrents types telles que des lettres,
des chiffres, des dates de manire structur. Aujourdhui, pratiquement tous les
programmes informatiques utilisent une base de donne afin de pouvoir consulter,
ajouter, modifier des informations diverses. La gestion de ces donnes, ainsi que laccs
se fait travers une suite de programme quon appelle SGBD (Systme de gestion de
base de donnes).
Le SQL qui est aujourdhui le langage le plus utilis par les systmes informatiques, fut
dveloppe par IBM en 1970, sous le nom SEQUEL (Structured English Query
Language), par la suite renomm SQL en 1975 pour des raisons de proprit
intellectuelle, soit de marque dpose. Il sera finalement normalis internationalement
par ISO en 1987.
Bien que le terme soit entendu pour la premire fois en 1988 par Carlo Strozzi qui
prsentait a comme un modle de base de donne plus lger et sans interface SQL,
cest en 2009, lors de la rencontre meetup NoSql de San Francisco, quil prend un
essor important. Durant cette confrence, il y sera prsent des solutions de projet telles
que Voldemort, Cassandra Project, Dynomite, HBase, Hypertable, CouchDb, MongoDb.
Ce meetup sera considre comme linauguration de la communaut des
dveloppeurs de logiciel NoSql.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 2
2. Lmergence du NoSQL
Avec laugmentation de la bande passante sur internet, ainsi que la diminution des cots
des matriels informatiques, de nouvelles possibilits ont vu le jour dans le domaine de
linformatique distribue. Le passage au 21me sicle par la rvolution du WEB 2.0 a vu
le volume de donnes de certaines entreprises augmenter considrablement. Ces
donnes proviennent, essentiellement, de rseaux sociaux, base de donnes
mdicales, indicateurs conomiques,etc. Linformatisation croissante de traitement en
tout genre a eu pour consquence une augmentation exponentielle de ce volume de
donnes qui se compte dsormais en ptaoctets, les anglo-saxon lont nomm le Big
Data. La gestion de ces volumes de donnes est donc devenue un problme que les
bases de donnes relationnelles nont plus t en mesure de grer. Le NoSQL regroupe
donc de nombreuses bases de donnes qui ne se reposent donc plus sur une logique
de reprsentation relationnelle. Il nest toutefois pas simple de dfinir explicitement ce
quest une base de donnes NoSql tant donn quaucune norme na encore t
instaure.
2.1 Pourquoi lalternative du NoSQL ?
Le besoin fondamental auquel rpond le NoSQL est la performance. Afin de rsoudre
les problmes lis au Big data , les dveloppeurs de socits telles que Google et
Amazone ont procd des compromis sur les proprits ACID des SGBDR. Ces
compromis sur la notion relationnelle ont permis aux SGBDR de se librer de leurs freins
la scalabilit horizontale. Un autre aspect important du NoSql est quil rpond au
thorme de CAP qui est plus adapt pour les systmes distribus.
Lautre avantage du NoSQL est dordre financier. Servant manipuler de gros volumes
de donnes, il est donc destins aux grandes entreprises. Ds 2010, le NoSql a
commenc stendre vers les plus petites entreprises. Majoritairement des start-up
nayant pas les moyens dacqurir des licences Oracle qui ont donc dvelopp leurs
propres SGBD en imitant les produits Google et Amazon.
3. Les diffrences entre le NoSQL et le SQL
Pour commencer, il est important de savoir que le SQL nest pas un modle relationnel
en soit, mais un langage de manipulation de donnes conu autour du modle
relationnel. Les bases de donnes NoSql nont pas pour but de sloigner de ce langage
mais du modle relationnel. Nous allons voir les facteurs diffrenciateurs.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 3
3.1 Les principes du relationnel
3.1.1 Le modle de donnes
Le modle relationnel bas est sur un modle mathmatique qui est celui de la notion
des ensembles. Chaque ensemble ici est reprsent par une table, et ces attributs sont
quant eux reprsents par des colonnes. Lun des principes fondamentaux est
justement cette notion de relation entre tables laide de cardinalits, cls primaires et
cl trangres, ceci implique au pralable une tude minutieuse sur la modlisation du
schma de la base de donnes. Comme par exemple les tables dont le systme aura
besoin, ses attributs, les relations possibles entre diffrentes tables, etc. Une fois ce
modle mis en place dans un SGBDR, il est difficile de changer la structure de celui-ci
et ceci pose par consquent des problmes lors de sa ringnierie.
Le mouvement NoSql lui est plus pragmatique, bas sur des besoins de stockage de
donnes ainsi quune liaison plus forte avec les diffrents langages clients. La plupart
des moteurs de base de donnes NoSQL nutilisent pas de schmas prdfinis
lavance, do lappellation schema-less , ce qui signifie sans schma. Ainsi le moteur
de la base de donnes neffectue pas de vrification et nimpose pas de contrainte de
schma, les donnes tant organises du cot client du code. Toutefois le principe
schema-less est thorique et ne se vrifie pas entirement en pratique. Le maintien
dune structure de donnes homognes est important, pour des questions dindexation,
de recherche par critre ou tout simplement pour des raisons de logique.
3.1.2 La gestion de la valeur NULL
En SQL, lors de la dfinition dune table, il est possible de dcider si un attribut peut
contenir une valeur ou non lors de lenregistrement dun tuple en dfinissant la colonne
Null ou Not Null . Ceci est utile pour contraindre lutilisateur renseigner sur
certains attributs que ladministrateur de la base de donnes considre comme
indispensables. Cela dit, d au fait de sa reprsentation en deux dimensions (ligne,
colonne) et de sa rigidit dans sa structure, il est indispensable de signaler labsence de
valeur laide dun marqueur NULL, ce qui cote en espace mmoire. Un autre souci du
NULL est sa gestion dans le langage SQL. Etant donn que le NULL nest pas une
valeur, il ne peut donc pas tre comparable. En voici une illustration avec la clause
WHERE :
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 4
Figure 1
Gestion de la valeur NULL
Lexemple ci-dessus dmontre quil faut explicitement citer la valeur NULL dans la
requte. En effet, le test sur une valeur NULL ne retourne pas TRUE ou FALSE mais la
valeur UNKNOW. Dans nos 2 premiers tests il va donc slectionner les produits qui
rpondront TRUE leur requte respective. Dans le troisime test il faut explicitement
signaler une valeur NULL possible pour que la valeur Null soit prise en considration. Il
faut donc grer une logique 3 tats possibles.
Dans des bases de donnes NoSQL la gestion du NULL nexiste pas. Etant donn que
dans des bases de type document ou cl-valeur la notion de schma nexiste pas, si lon
veut exprimer quun attribut na pas de valeur il suffit de ne pas le mettre. Mme chose
dans les bases de type colonne, les colonnes tant dynamiques, elles ne seront
prsentes quen cas de ncessit.
3.2 Les transactions
Une transaction est une suite doprations faisant passer ltat du systme dun point A
(antrieur la transaction) un point B (postrieur la transaction). Dans les SGBDR
une transaction doit respecter les proprits ACID afin que celle-ci soit valide. Le
respect de ces proprits dans un environnement distribu est pnible et il existe un
risque de diminution des performances proportionnelle aux nombres de serveurs. Les
moteurs NoSQL font limpasse sur ces proprits, leur but tant daugmenter les
performances par lajout de serveurs ( scalabilit horizontale ).
3.2.1 Les proprits ACID
Les proprits ACID (atomicit, cohrence, isolation, durabilit) sont un ensemble de
proprits garantissant la fiabilit dune transaction informatique telle quun virement
bancaire par exemple.
Atomicit : cette proprit assure quune transaction soit effectue
compltement, ou pas du tout. Quelle que soit la situation, par exemple lors dune
panne dlectricit, du disque dur ou de lordinateur, si une partie de la
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 5
transaction na pu tre effectue, il faudra effacer toutes les tapes de celle-ci et
remettre les donnes dans ltat o elles taient avant la transaction.
Cohrence : la cohrence assure que chaque transaction prserve la cohrence
de donnes, en transformant un tat cohrant en un autre tat de mme
donnes cohrent. La cohrence exige que les donnes concernes par une
potentielle transaction soient protgs smantiquement.
Isolation : lisolation assure que chaque transaction voit ltat du systme comme
si elle tait la seule manipuler la base de donnes. En dautres termes, si
pendant la transaction T1, la transaction T2 sexcute au mme moment, T1 ne
doit pas la voir, tout comme T2 ne doit pas voir T1.
Durabilit : La durabilit assure quune transaction confirme le demeure
dfinitivement, peu importe les diffrents imprvus (panne dlectricit, panne
dordinateur etc). Pour ce faire, un journal contenant toutes les transactions est
cr, afin que celles-ci puissent tre correctement termines lorsque le systme
est nouveau disponible.
3.3 Cohrence contre disponibilit
La cohrence de donnes ou la disponibilit de celles-ci, que choisir? Cest lun des
sujets les plus sensibles entre les deux mondes que constituent le relationnel et le
NoSQL. Dans un systme de gestion de base de donnes relationnelle, les diffrents
utilisateurs voient la base de donnes dans un tat cohrent, les donnes en cours de
modification par un utilisateur ntant pas visibles aux autres utilisateurs, on dit quun
verrou a t pos. Le maintien de cette cohrence de donnes dans une base contenue
dans un seul serveur (ou autrement dit architecture centralise) est tout fait
envisageable (les SGBRD ont longuement fait leurs preuves), cela devient cependant
problmatique dans le contexte dune architecture distribue.
Les fondateurs du NoSQL tel que Google, Amazon, Facebook etc., dont les besoins en
disponibilit priment sur la cohrence des donnes, ont dcids de privilgier celle-ci au
dtriment de la cohrence. Lopposition de ces deux proprits a t prsente par Eric
Brewer dans ce quon appelle aujourdhui le thorme de CAP.
3.3.1 Le thorme de CAP
Le thorme de cap ou thorme de Brewer a t nonc pour la premire fois en tant
que conjecture par le chercheur en informatique Eric Brewer. En 2002, deux chercheurs
au MIT, Seth Gilbert et Nancy Lynch, ont formellement dmontr la vrifiabilit de la
conjecture de Brewer afin den faire un thorme tabli. Ce thorme nonce quune
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 6
base de donnes dun systme distribu ne peut garantir les trois contraintes suivantes
en mme temps, savoir :
Cohrence (Consistency) : tous les nuds (serveurs) du systme voient exactement
les mmes donnes au mme moment.
Disponibilit (Availability) : garantie que toutes les requtes reoivent une rponse.
Rsistance au morcellement (Partition Tolerence) : le systme doit tre en mesure
de rpondre de manire correcte toutes requtes dans toutes circonstances sauf en
cas dune panne gnrale du rseau. Dans le cas dun morcellement en sous-rseaux,
chacun de ces sous-rseaux doit pouvoir fonctionner de manire autonome.
Figure 2
Thorme de CAP
Le thorme de CAP dit que seules deux de ces trois contraintes peuvent tre
respectes un instant T car elles se trouvent en opposition. La plupart des bases de
donnes NoSql se concentrent plus sur la rsistance au morcellement, afin de garantir
une disponibilit en tout temps et par consquent abandonnent la cohrence.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 7
3.4 Diffrents types de base de donnes NoSQL
Les bases de donnes NoSql sont donc une catgorie de base de donnes qui nest
plus fonde sur larchitecture classique des bases relationnelles, et non pas un type
part entire. Quatre grandes catgories se distinguent parmi celles-ci.
3.4.1 Les bases de donnes cl-valeur
La base de donnes de type cl-valeur est considre comme la plus lmentaire. Son
principe est trs simple, chaque valeur stocke est associe une cl unique. Cest
uniquement par cette cl quil sera possible dexcuter des requtes sur la valeur.
La structure de lobjet stock est libre
et donc la charge du dveloppeur de
lapplication. Un avantage
considrable de ce type de base de
donnes est quil est trs facilement
extensibles, on parle donc de
scalabilit horizontale. En effet dans le
cas o le volume de donnes
augmente, la charge est facilement
rpartissable entre les diffrents serveurs en redfinissant tout simplement les
intervalles des cls entre chaque serveur.
En ce qui concerne le besoin de la scalabilit verticale, celle-ci est trs fortement rduite
par la simplicit des requtes qui se rsument PUT, GET, DELETE, UPDATE. Ce type
de base de donnes affiche donc de trs bonnes performances en lecture/criture et
tendent diminuer le nombre de requtes effectues, leur choix tant restreint.
Nanmoins, les requtes ne peuvent tre excutes uniquement sur les cls cause
de la simplicit du principe. Permettant un stockage de donnes sans schma, le client
est contraint rcuprer tout le contenu du blob et ne peut obtenir un rsultat de
requtes plus fin tel que des rsultats de requtes SQL pourraient permettre.
Ce type de base de donnes orient cl-valeur implique donc des cas dutilisation trs
spcifiques, cause de leur simplicit de modle et de la fine palette de choix de
requtes proposes. Ces systmes sont donc principalement utiliss comme dpt de
donnes condition que les types de requtes ncessites soient trs simples. On les
retrouve comme systme de stockage de cache ou de sessions distribues,
particulirement l o lintgrit des donnes est non significative. Aujourdhui, les
Figure 3
Reprsentation cl-valeur 1
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 8
solutions les plus connues ayant adoptes le systme de couple cl-valeur sont
Voldemort (LinkedIn), Redis et Riak.
3.4.2 Les bases de donnes orientes colonnes
Les bases de donnes orientes colonnes ont t conues par les gants du web afin
de faire face la gestion et au traitement de gros volumes de donnes samplifiant
rapidement de jours en jours. Elles intgrent souvent un systme de requtes
minimalistes proche du SQL.
Bien quelles soient abondamment utilises, il nexiste pas encore de mthode officielle
ni de rgles dfinies pour quune base de donnes oriente colonnes soit qualifie de
qualit ou non.
Le principe dune base de donnes colonnes consiste dans leur stockage par colonne
et non par ligne. Cest--dire que dans une base de donnes oriente ligne (SGBD
classique) on stocke les donnes de faon favoriser les lignes en regroupant toutes
les colonnes dune mme ligne ensemble. Les bases de donnes oriente colonnes
quant elles vont stocker les donnes de faon ce que toute les donnes dune mme
colonne soient stockes ensemble. Ces bases peuvent voluer avec le temps, que ce
soit en nombre de lignes ou en nombre de colonnes. Autrement dit, et contrairement
une base de donnes relationnelle ou les colonnes sont statiques et prsentes pour
chaque ligne, celles des bases de donnes oriente colonnes sont dite dynamiques et
prsentes donc uniquement en cas de ncessit. De plus le stockage dun null est
0. Prenons lexemple de lenregistrement dun client ncessitant son nom, prnom et
adresse. Dans une base de donnes relationnelle il faut donc au pralable crer le
schma (la table) qui permettra de stocker ces informations. Si un client na pas
dadresse, la rigidit du modle relationnel ncessite un marqueur NULL, signifiant une
absence de valeur qui cotera toutefois de la place en mmoire. Dans une base de
donnes oriente colonne, la colonne adresse nexistera tout simplement pas. Les bases
de donnes colonnes ont t penses pour pouvoir stocker plusieurs millions de
colonnes et se relvent donc parfaites pour grer le stockage dit one-to-many
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 9
Figure 4
Comparaison schma relationnel vs colonne
Ces deux schmas dmontrent que le stockage de donnes en colonne permet de
gagner un espace considrable, spcialement lors des stockages des tuples incomplets.
En effet, la valeur null nest pas stocke dans ce type de base de donnes.
Dans des bases de donnes telles que Cassandra ou HBase il existe quelques concepts
supplmentaires qui sont pour commencer les familles de colonnes, qui est un
regroupement logique de lignes. Dans le monde relationnel ceci quivaudrait en quelque
sorte une table. Cassandra offre une extension au modle de base en ajoutant une
dimension supplmentaire appele Super colonnes contenant elle-mme dautres
colonnes.
Figure 5
Reprsentation dune famille de colonnes
Les bases de donnes orientes colonnes comportent des avantages considrables.
Leur capacit de stockage est accrue, en partie grce lespace conomis sur les
valeurs null *, comme dj vu plus haut. Leur compression est significative pour
autant que les donnes des colonnes se ressemblent fortement. Afin dviter la
dcompression chaque interrogation des donnes, de plus en plus de SGBD orientes
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 10
colonnes ont intgr une technologie permettant daccder directement aux donnes
sans les dcompresser au pralable.
Elles assurent galement une rapidit remarquable daccs aux donnes. Si lon
souhaite rcuprer un gros volume de donns dun attribut spcifique dun
enregistrement, il est prfrable de rcuprer les informations de toute cette colonne
plutt que de parcourir les lignes une une et de prendre uniquement cette information.
Cependant, lutilisation de ces bases de donnes nest rellement quefficace dans un
contexte BigData , pour les grands volumes de donnes de mme type, et dont les
donnes se ressemblent. De plus, le systme de requtes minimalistes comme cit plus
haut a son prix et les diffrentes solutions possibles pour interroger les donnes sont
trs limites.
3.4.3 Les bases de donnes orientes document
Les bases de donnes document sont une volution des bases de donnes de type cl-
valeur. Ici les cls ne sont plus associes des valeurs sous forme de bloc binaire mais
un document dont le format nest pas impos. Il peut tre de plusieurs types diffrents
comme par exemple du JSON ou du XML, pour autant que la base de donnes soit en
mesure de manipuler le format choisit afin de permettre des traitements sur les
documents. Dans le cas contraire, cela quivaudrait une base de donnes cl-valeur.
Bien que les documents soient structurs, ce type de base est appele schemaless .
Il nest donc pas ncessaire de dfinir les champs dun document.
Figure 6
Base de donnes oriente document
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 11
Comme limage peut nous le montrer, chacun des documents ci-dessus a une structure
diffrente, ils peuvent donc tre trs htrognes. Un document peut contenir des
chanes de caractres comme illustr sur cette image, mais galement des valeurs
numriques ainsi que dautres documents.
Lavantage des bases de donnes document est de pouvoir rcuprer un ensemble
dinformations structures hirarchiquement depuis une cl. Une opration similaire
dans le monde relationnelle quivaudrait plusieurs jointures de table.
Les bases de donnes document sont par consquents trs convoites par les
applications Web diffusant des pages entires obtenues par un ensemble de jointures.
Ces applications peuvent galement mettre en cache des informations sous une forme
intelligible. Pour la majorit dentre elles, la base peut tre directement mise sur la
mmoire RAM permettant un gain de performance considrable.
Un point ngatif concernant ces bases de donnes document concerne la duplication
des informations. Les donnes tant regroupes par document, il se pourrait que des
problmes dintgrit surgissent, certaines donnes tant ncessairement dupliques
sur plusieurs documents. De plus, par la trs grande flexibilit de leur schma ( priori
un atout), il est trs facile de commettre une erreur lors de linsertion de donnes. Les
bases de donnes relationnelles offrent une plus grande garantie de cohrence des
donnes, car dans un cas comme celui-ci, le serveur refusera dexcuter la requte si le
schma de la base de donnes nest pas respect.
3.4.4 Les bases de donnes orientes graphe
Bien que les bases de donnes de type cl-valeur, colonne, ou document tirent leur
principal avantage de la performance du traitement de donnes, les bases de donnes
orientes graphe permettent de rsoudre des problmes trs complexes quune base de
donnes relationnelle serait incapable de faire. Les rseaux sociaux (Facebook,
Twitter,etc), o des millions dutilisateurs sont relis de diffrentes manires, constituent
un bon exemple : amis, fans, famille etc. Le dfi ici nest pas le nombre dlment grer,
mais le nombre de relations quil peut y avoir entre tous ces lments. En effet, il y a
potentiellement n relations stocker pour n lments. Mme sil existe des solutions
comme les jointures, les bases de donnes relationnelles se confrontent trs vite des
problmes de performances ainsi que des problmes de complexit dans llaboration
des requtes. Lapproche par graphes devient donc invitable pour les rseaux sociaux
tels que Facebook ou Twitter.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 12
Les bases de donnes graphe sont galement utilises pour la gestion dimportantes
structures informatiques. Elles permettent galement llaboration de liens entre les
divers intrts que pourraient avoir un internaute, afin de pouvoir lui proposer des
produits susceptibles de lintresser. Ainsi, les pubs saffichant sur Facebook sont trs
souvent en relation avec les recherches effectus sur Google, et les propositions
dachats de sites de vente en ligne tels qu'Ebay et Amazon sont en relation avec des
achats dj effectus (par exemple : les personnes ayant achet ce produit ont
galement achet ).
Comme son nom l'indique, ces bases de donnes reposent sur la thorie des graphes,
avec trois lments retenir :
Un objet (dans le contexte de Facebook nous allons dire que cest un utilisateur)
sera appel un Nud.
Deux objets peuvent tre relis entre eux (comme une relation damiti).
Chaque objet peut avoir un certain nombre dattributs (statut social, prnom, nom
etc.)
Les donnes sont donc stockes sur chaque nud, lui-mme organis par des relations.
A partir de l, il sera nettement plus ais deffectuer des oprations qui auraient t trs
complexes et lourdes dans un univers relationnel.
Figure 7
Reprsentation des graphes
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 13
Limplmentation dune base de donnes graphe peut varier selon les besoins, ou les
proprits mettre en avant suivant lutilisation. Certaines se basent sur des
orientations colonne, dautres sur lenregistrement cl-valeur ou sur une combinaison de
plusieurs dentre elles. HyperGraphDB, Neo4j, FlockDB, BigData sont quelques noms
de bases de donnes orientes graphe.
Le point positif de ce type de bases est qu'elles sont parfaitement adaptes la gestion
des donnes relationnelles mme dans un contexte de BigData . De plus, leur
architecture tant modelable, elles peuvent tre adaptes selon les besoins rencontrs.
Cependant, cette architecture est trs limite dans dautre cas plus classiques car trs
spcifique aux graphes.
4. Le march
Principalement lanc par les gants du Web (Facebook, LinkedIn, Google etc.) pour
trouver une solution leurs besoins, On dcompte aujourdhui 150 bases de donnes
NoSQL de tous types (Cl-valeur, Colonne, Document, Graphe). La majorit de ces
bases de donnes se trouve sous licence Open Source. Etant donn le nombre
relativement lev de ces bases de donnes, je ne vais parler que des plus populaires.
4.1 DynamoDB (oriente cl-valeur)
Conu par Amazon, DynamoDB est un
service de base de donnes NoSQL de
type cl-valeur. Parce quil est un
service bas sur le cloud, il permet aux
clients lutilisant de saffranchir de
lourdes tches administratives que
peuvent reprsenter lexploitation et le
dimensionnement dun cluster de base de donnes distribu hautement disponible.
DynamoDB propose galement une grande quantit de fonctionnalits permettant le
dveloppement de celle-ci de manire rapide et efficace. Afin de garantir un haut niveau
de durabilit ainsi que de disponibilit, les donnes sont stockes sur des disques SSD
sur trois zones de disponibilits. Cette nouvelle gnration de mmoire, proche de celles
quutilisent les cls USB, constitue un atout trs important en faveur DynamoDB. Elle
propose des temps daccs bien plus courts quun accs disque classique.
Un autre aspect important dAmazon DynamoDB est son intgration Amazon Elastic
MapReduce (Amazon EMR), un puissant outil qui permet entre autres deffectuer des
Figure 8
Logo DynamoDB
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 14
analyses complexes sur de trs gros volume de donnes. Nous reviendrons plus en
dtail sur le paradigme MapReduce plus bas.
La souscription aux services de DynamoDB permet aux entreprises dviter des cots
dinfrastructure et de maintenance considrables, et permet ainsi aux entreprises de se
focaliser sur leur core-business.
4.2 Cassandra (oriente colonne)
Initialement dvelopp par Facebook
afin de rpondre des besoins
concernant son service de messagerie,
Cassandra a t libr en Open-source
et a t adopt par plusieurs autres
grands du Web tel que Digg.com ou
Twitter. Il est aujourdhui lun des principaux projets de la fondation Apache, une
organisation but non lucratif dveloppant des logiciels open-source. Cassandra est un
systme de gestion de base de donnes NoSQL oriente colonne et crit en java. Il
permet la gestion massive de donnes rparties sur plusieurs serveurs, assurant ainsi
une haute disponibilit des donnes. Voici une liste des principales caractristiques de
Cassandra.
Haute tolrance aux pannes : les donnes dun nud sont automatiquement
rpliques sur diffrents nuds. De cette manire, les donnes quil contient
sont galement disponibles sur dautres nuds si lun des nuds venait tre
hors service. Conu sur le principe quune panne nest pas une exception mais
une normalit, il est simple de remplacer un nud qui est tomb sans rendre le
service indisponible.
Modle de donnes riche : Cassandra propose une modle de donnes bas
sur BigTable (par Google) de type cl-valeur. Il permet de dvelopper de
nombreux cas dutilisation dans lunivers Web.
Elastique : Que ce soit en criture ou en lecture, les performances augmentent
de faon linaire lorsquun serveur est ajout au cluster. Cassandra assure
galement quil ny aura pas dindisponibilit du systme, ni aucune interruption
au niveau des applications.
Figure 9
Logo Cassandra
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 15
4.3 MongoDB (oriente document)
Dvelopp depuis 2007 par 10gen
(une socit de logiciel), MongoDB
est un systme de gestion de base
de donnes oriente document. Ecrit
en C++ et distribu sous licence
AGPL(licence libre), elle est trs
adapt aux applications web.
MongoDB a t adopt par plusieurs
grands noms de linformatique, tels que Foursquare, SAP, ou bien mme GitHub.
Manipulant des documents au format BSON (Binary JSON), un driv de JSON binaire
plus ax sur la performance, lutilisation dun pilote est donc ncessaire pour
communiquer avec une base MongoDB. Fonctionnant comme une architecture
distribue centralise, il rplique les donnes sur plusieurs serveurs avec le principe de
matre-esclave, permettant ainsi une plus grande tolrance aux pannes. La rpartition et
la duplication de document est faite de sorte que les documents les plus demands
soient sur le mme serveur et que celui-ci soit dupliqu un nombre de fois suffisant.
Par sa simplicit dutilisation du point de vue de dveloppement client, ainsi que ces
performances remarquables, MongoDB est lune de base de donnes orientes
document la plus utilis.
4.4 Neo4j (oriente graphe)
Neo4j est une base de donnes
oriente graphe crite en Java.
Dvelopp par Neo Technology,
elle a vu le jour pour la premire
fois en 2007. Celle-ci est open-
source et est distribue sous
une double licence GPLv3 et
AGPLv3. Son usage fait intuitivement sens dans le contexte des rseaux sociaux comme
par exemple Viadeo dans le cadre de son moteur de recommandation de contact. Neo4j
est galement prsent dans les tlcoms (Teleno, Deutsche Telekom, SFR) avec un but
de gestion de catalogues permettant la modlisation dune large palette de
combinaisons entre forfait tlphonique, option ligible, etc. Il sest avr tre galement
trs utile pour la dtection de fraudes.
Figure 10
Logo mongoDB
Figure 11
Logo Neo4j
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 16
Une grande particularit de Neo4j est quil supporte les transactions dites ACID. Il est
dot dun moteur de graphe extrmement performant et possde toutes les
caractristiques dune base de donnes de production. Outre les points forts qui sont la
haute disponibilit des donnes et une trs grande scalabilit, il est important de noter
que Neo4j est en production depuis 2003 sans jamais avoir subi la moindre interruption
ce qui tmoigne de sa trs grande robustesse.
5. Caractristiques techniques
Dans ce chapitre je vais aborder les caractristiques techniques principales sur
lesquelles se repose le NoSQL.
5.1 La distribution de donnes
Comme dj dit prcdemment, les moteurs NoSQL sont majoritairement conus pour
tre utiliss sur une architecture distribue, afin de pouvoir grer la monte de charge
et de volumtrie de donnes, rappelons-nous du principe de la scalabilit horizontale.
Les moteurs NoSQL utilisent deux manires diffrentes pour distribuer les traitements
et les donnes sur leurs divers nuds. La distribution de donnes avec matre et celle
sans.
5.1.1 Distribution sur un schma matre esclave.
La distribution de donnes sur un schma dit matre esclave consiste avoir un seul
serveur dit matre dans un cluster, les autres serveurs tant esclave. Les requtes des
clients arrivent directement sur le serveur matre, pour ensuite tre rediriges sur les
serveurs esclaves qui contiennent linformation de la requte.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 17
Lune des vulnrabilits de cette
configuration consiste dans lexposition
un point unique de dfaillance (SPOF
Single Point of Failure). Ainsi, une
malfonction du serveur matre
entrane la panne du cluster. En effet, si
le serveur tombe en panne, il ne pourra
plus rceptionner les requtes clientes et
les redistribuer aux serveurs esclave
concerns.
Un point important ici est la faon dont
sont rpliques les donnes dans un
schma matre-esclave. Une rplication
de donnes consiste faire une copie
des donnes entre serveurs afin de
garantir non seulement la disponibilit de
celles-ci mais aussi de se protger de la perte de donnes.
Cela fonctionne ainsi : Les critures se font uniquement sur le serveur matre , le
serveur lui va se charger de faire les rplications de donnes sur les serveurs
esclaves . Le processus de rplication est gr automatiquement par le serveur et sa
frquence peut tre configurable par ladministrateur. La lecture de donnes peut tre
faite aussi bien sur le matre que sur lesclave, avec nanmoins un risque de produire
des problmes de cohrence de donnes si une lecture est faite sur un esclave nayant
pas reu la dernire version des donnes du matre.
Prenons un exemple, soit deux utilisateurs Facebook lutilisateur A et lutilisateur B.
Lutilisateur A met jour son tat civil en passant de clibataire en couple ,
lutilisateur B au mme moment va consulter ltat civil de lutilisateur A indiquant
clibataire . Ceci sexplique par le fait que le serveur sur lequel les informations ont
t consultes se trouvait tre un serveur esclave nayant pas encore reu le rplica
de la base de donne jour du serveur matre . En effet, les rplications de donnes
ne se font pas en temps rel.
Figure 12 Distribution sur schma
matre-esclave
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 18
Figure 13
Illustration de problme de cohrence lors de la consultation
5.1.2 Distribution sur un schma multi-maitre
La distribution de donnes sur une architecture multi-matre part du principe que la
panne est une normalit et que chaque serveur du cluster a exactement la mme
importance et que chaque serveur peut fournir un service complet en criture ou en
lecture. Il est important daborder diffrents point cruciaux afin quune architecture de ce
type puisse fonctionner correctement, tel que la redirection de requte aux bons
serveurs, savoir quels serveurs composent le cluster, ainsi que les techniques pour
distribuer au mieux les donnes sur les diffrentes machines du cluster.
5.1.2.1 Le protocole de bavardage (Gossip Protocole)
Le protocole de bavardage est bien connu dans le milieu du rseau, il est utilis dans le
but dinformer tout le monde dans un rseau sans recourir un gros systme centralis.
Le principe de ce protocole est simple : toutes les paires du rseau, savoir les nuds
du cluster, transmettent linformation dautres paires choisies au hasard parmi les
nuds connus, qui refont le mme processus. Il est essentiel que chaque nud
maintienne un historique (information envoye, destinataire de linformation, etc.) pour
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 19
un fonctionnement optimal, afin de ne pas perdre de temps retransmettre des
messages au mme nud par exemple.
Les communications se font priodiquement afin de ne pas saturer le rseau par la
communication des diffrents nuds et impliquent un ralentissement au niveau de la
distribution des donnes. Voici une petite illustration du fonctionnement de ce protocole
Figure 14
Protocole de bavardage
Une information a t mise jour dans le nud A. Parmi les autres nuds dont le nud
A a connaissance (ici B,C,D) il va en choisir un de faon alatoire afin de communiquer
linformation, ici la communication numro 1 avec le nud B. Il est important de noter
quune communication va dans les deux sens et que si le nud B doit communiquer
quelque chose au nud A il le fera lors de cette communication. Ensuite chaque nud
en contactera un autre intervalle rgulier. Le A contacte C. Ensuite A contacte D et C
contacte F. Ensuite C contacte E et F contacte D et D contacte G.
Ce protocole est aussi utilis pour lajout dun nouveau nud dans un cluster, au-del
de lchange des donnes. Aprs son ajout, le nud publie sa prsence et aprs
plusieurs changes, grce un historique des membres du cluster, tous les nuds
seront avertis. Il permet galement lchange dinformations de partitions entre nuds,
permettant ainsi chaque nud de savoir sur quel nud il doit rediriger une requte
pour laquelle il ne contient pas dinformation.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 20
La trs grande tolrance aux pannes constitue un des points fort de ce protocole. En
effet si un nud tombe, linformation quil tait cens retransmettre sera connue par un
autre nud. Prenons un exemple avec limage ci-dessus : le nud G reoit linformation
par le nud D et si le nud D devait tomber en panne nous pourrions imaginer une
connexion entre le nud F et le nud G pour recevoir linformation. Dans un souci de
lisibilit, les communications possibles entre les diffrents nuds sur limage ci-dessus
ont t simplifies et ne sont donc pas exhaustives.
5.1.2.2 Le hachage consistant
Le partitionnement de donnes constitue un point important dans une architecture
distribue dcentralise. Il faut en effet pouvoir distribuer les donnes de la meilleure
faon possible entre les nuds. Lalgorithme de hachage consistant a t conu pour
rpondre des problmes que lon peut rencontrer lors de rpartition des donnes dans
une architecture volutive. Afin de dmontrer les problmes ci-dessus, nous allons
prendre lexemple dune distribution des donnes classique avec un hachage sur la cl
primaire.
Figure 15
Distribution par hachage sur la cl primaire
Voici une reprsentation simplifie dune rpartition utilisant le hachage sur la cl
primaire. Cette solution semble adapte pour autant que la composition dun cluster
reste ainsi fige et nvolue pas. Malheureusement la ralit des choses dans un
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 21
environnement distribu est souvent diffrente. Il arrive souvent que des nuds soient
ajouts au cluster, que dautres soient remplac et dautre supprims. Que faire si un
nud venait sajouter ce cluster de quatre nuds ? Il faudrait redistribuer toutes les
cls sur un modulo de cinq. Nous nous rendons trs vite compte que ce processus nest
pas envisageable sur une taille darchitecture consquente, telle que pourraient avoir
besoin des socits comme Google. Cest justement l que rside le grand avantage du
hachage consistant, qui permet lajout ou la suppression dun nud avec un
drangement minimal.
Cette solution a initialement t dveloppe pour la mise en cache distribue par David
Ron Karger, professeur dinformatique au MIT. Elle a nanmoins t reprise par dautres
domaines dont, notamment, la rpartition des donnes dans les systmes distribus.
Le principe est le suivant : plusieurs nuds pour un systme distribu et une valeur de
hachage dfinissant chacun de ces nuds la range de valeurs stockes attribue.
Aprs avoir obtenu la valeur de hachage partir de sa cl, le systme va chercher le
nud dont sa valeur est suprieure et y stocker la donne. Voici une reprsentation dun
systme distribue en forme danneau et les nuds positionns sur cet anneau.
Figure 16
Rpartition sur hachage consistant
Chaque nud contient toutes les cls infrieures sa valeur de hachage et suprieures
la valeur de hachage du nud le prcdent.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 22
Que va-t-il se passer si un nud vient sajouter au systme ? Il va dabord venir se
positionner sur le cluster. Pour ce faire, il va contacter son successeur et une fois entr
en contact avec celui-ci, il va lui demander quel est son prdcesseur. Une fois
dtermin qui tait son successeur et son prdcesseur, il va leurs demander de
linsrer entre les deux, fractionnant la range de valeurs en deux. Une fois install, il va
rcuprer une partie des cls de son successeur, comme le montre limage ci-dessous.
Figure 17
Ajout dun nouveau noeud
Ici le nouveau nud rcuprera la range de 400 500. Si le nouveau nud rajout
venait tre retir, toutes ces cls seraient relocalises sur le nud succdant le nud
retir et une information serait envoye son prdcesseur pour linformer de son
nouveau successeur. Le successeur lui, mettrait jour la DHT. On peut effectivement
voir que la redistribution des cls lors de lajout ou de la suppression dun nud naffecte
le systme que de faon minimale.
5.1.2.3 Table de hachage distribue
Comme dj vu prcdemment chaque nud a le mme niveau dimportance dans un
systme distribu sans matre et peut fournir un service complet. Il est donc essentiel
que chaque nud sache o se trouve linformation demande par le client si celle-ci ne
se trouve pas dans son propre serveur, afin de pouvoir rediriger la requte. De plus, la
taille du systme est modelable et des donnes peuvent changer de localisation (vu
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 23
prcdemment) sur les nuds. La solution ces problmes est donc le maintien dune
table de hachage sur chaque nud. Une table de hachage distribue est donc un grand
annuaire consultable pour savoir o se trouve linformation recherche. La table peut
tre entirement maintenue sur chaque nud, ou alors elle peut tre partitionne. Dans
le premier cas, cette configuration permet un accs direct du client la donne. Dans le
deuxime cas, il se peut que la donne soit retrouve aprs plusieurs sauts. En effet, un
nud qui contient toute la table de hachage peut directement rediriger le client au bon
endroit, tant donn quil sait o se trouvent toutes les cls. Par contre, il peut arriver
que le client demande une information sur un nud ne contenant quune partie de la
table de hachage et dont il ignore la localisation. Le nud va donc demander un autre
nud sil ne saurait pas o se trouve linformation. Ce processus est appel un accs
multiple hops . La table de hachage distribue est change dans le systme en
utilisant le protocole de bavardage.
5.1.2.4 Rplication de donnes
5.2 MapReduce
Le traitement de donnes de faon distribue soulve certaines questions, comment
distribuer le travail entre les serveurs ? Comment synchroniser les diffrents rsultats ?
Comment grer une panne dune unit de traitement ? MapReduce rpond ces
problmes.
Il ne sagit pas dun lment de base de donnes, mais dun modle de programmation
sinspirant des langages fonctionnels et plus prcisment du langage Lisp. Il permet de
traiter une grande quantit de donnes de manire parallle, en les distribuant sur divers
nuds dun cluster. Ce mcanisme a t mis en avant par Google en 2004 et a connu
un trs grand succs auprs des socits utilisant des DataCenters telles que Facebook
ou Amazon.
5.2.1 Principe de MapReduce
Le principe de MapReduce est simple: il sagit de dcouper une tche manipulant un
gros volume de donnes en plusieurs tches traitant chacune un sous-ensemble de ces
donnes. MapReduce est vu en deux tapes. La premire tape, appel map
consiste dispatcher une tche, ainsi que les donnes quelle traite en plusieurs sous-
tches traitant chacune delles un sous-ensemble de donnes. La deuxime tape se
nomme Reduce . Dans cette partie il sagit de rcuprer les rsultats des diffrents
serveurs ( savoir les sous-tches) et de les consolider. Nous reviendrons plus en dtail
sur le sujet plus bas. Bien que le principe soit relativement simple, il lest surtout grce
lapport du modle MapReduce simplifiant au maximum les complexits de
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 24
linformatique distribue. Il permet ainsi aux dveloppeurs de se focaliser sur le
traitement proprement dit. Le fait que MapReduce soit dvelopp en java permet de
sabstraire de larchitecture matrielle pour quun framework MapReduce puisse tourner
sur un ensemble de machines htrognes.
5.2.2 Programmation fonctionnelle
Avant dapprofondir sur le sujet il est important de faire un dtour sur les orientations de
MapReduce la programmation fonctionnelle. Les langages fonctionnels sont trs
diffrents de la majorit des autres langages de programmation dits impratifs. Ces
types de langages se basent sur le concept de machine dtat, o les diffrents
traitements de donnes produisent des changements dtat. Un tat est donc lensemble
des valeurs prsentes dans un systme un moment donn. Un langage manipule donc
cet tat travers diffrentes instructions comme par exemple des affectations de valeur
des variables, le branchement conditionnel, le bouclage, etc.
Cependant ce type de langage pouvant affecter ltat dun systme peut produire des
effets de bord sur dautres sous-ensembles du systme. Cela veut dire quune fonction
peut modifier un tat autre que sa valeur de retour, comme par exemple une variable
statique ou globale. La situation devient problmatique si plusieurs serveurs peuvent
changer ltat gnral du systme. Le langage fonctionnel rpond cette problmatique
en rejetant le changement dtat et la mutation de donnes, et souligne lapplication des
fonctions. La programmation de type fonctionnelle permet donc de grer le traitement de
donnes de manire sre, car elle ne maintient quun tat transitoire. En effet les
rsultats obtenus sont stocks de manire locale, et aucun tat nest maintenu hors du
temps dexcution de la fonction. Cela permet de diminuer les effets de bord et de gagner
en souplesse lors des traitements.
5.2.3 Fonctionnement de MapReduce
Comme dit prcdemment, le modle MapReduce consiste en deux tapes,
reprsentes toutes deux par des fonctions. Dans la fonction map on prend en entre
un ensemble de cl-valeurs , le nud fait une analyse du problme et il va le sparer
en sous-tches, pour pouvoir les redistribuer sur les autres nuds du cluster. Dans le
cas ncessaire, les nuds recevant les sous-tches refont le mme processus de
manire rcursive. Les sous-tches des diffrents nuds sont traites chacune dentre
elles dans leur fonction map respective et vont retourner un rsultat intermdiaire. La
deuxime tape nomm Reduce , consiste faire remonter tous les rsultats leur
nud parents respectif. Les rsultats se remonte donc du nud le plus bas jusqu la
racine. Avec la fonction Reduce, chaque nud va calculer un rsultat partiel en
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 25
associant toutes les valeurs correspondant la mme cl en un unique couple (cl
valeur). Une fois obtenu ce couple (cl-valeur), le rsultat est remont au nud parent,
qui va refaire le mme processus de manire rcursive jusquau nud racine. Quand
un nud termine le traitement dune tche, un nouveau bloc de donnes est attribu
une tche Map. Voici un schma illustrant tout a.
Figure 18
Schma MapReduce
Voici un exemple dutilisation. Le problme ici sera de compter le nombre doccurrence
de chaque mot. Comme donnes en entre nous allons avoir des fichiers texte. La
fonction Map aura pour but de dcomposer le texte en couple de mots cl-valeur. La
fonction Reduce va prendre les couples avec la mme cl et compter la totalit des
occurrences pour ne faire quune seul paire cl-valeur par mot.
[(m,[1,1,1,])m2,[1,1,1,..],]. Lillustration ne montre quune partie du processus et est
incomplte.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 26
Figure 19
Exemple comptage de mot
5.2.4 Les avantages
Voici une liste de quelques avantages quapporte MapReduce :
Simplicit dutilisation : lutilisateur peut se focaliser sur son propre code et
ngliger laspect du traitement distribu, trait de manire totalement
transparente.
Polyvalence : il est adaptable de nombreux type de traitement de donnes,
comme par exemple les fouilles de donnes, calculs de taille de plusieurs milliers
de documents.
Sa facult de dcomposition dun processus en plusieurs tches distribuables, et
cela sur une multitude de nuds.
5.2.5 Les inconvnients
Voici une liste de quelques dsavantages de MapReduce :
Il ny a quune seul entre pour les donnes. Par consquent, les algorithmes qui
ncessitent plusieurs lments en entre sont mal supports, MapReduce tant
prvu pour lire un seul lment en entre et de produire un lment en sortie.
La tolrance aux pannes ainsi que la scalabilit horizontale, font que les
oprations du MapReduce ne sont pas toujours optimises pour les
entres/sorties. De plus le flux de donnes en deux tapes le rend trs rigide,
car pour passer ltape suivante, ltape courante doit tre termine. Tous ces
problmes rduisent donc la performance.
Ne supporte pas les langages de haut niveau tel que le SQL.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 27
5.2.6 Hadoop
Le modle de programmation MapReduce est implment dans la plupart des moteurs
NoSQL, comme par exemple CouchDB, MongoDB et Riak pour nen citer que quelques
un. Il est difficile de parler de MapReduce sans parler de Hadoop qui est aujourdhui le
framework le plus populaire.
Hadoop est donc un framework open source dvelopp en java, faisant partie des projets
de la fondation de logiciel Apache depuis 2009. Il est destin faciliter le dveloppement
dapplications distribues et scalables, permettant la gestion de milliers de nuds ainsi
que des ptaoctets de donnes.
Doug Cutting lun des fondateurs de Hadoop, travaillant lpoque sur le dveloppement
de Apache Lucene, cherchait une solution quant la distribution du traitement de Lucene
afin de btir le moteur dindexation web Nutch. Il dcidait donc de sinspirer de la
publication de Google sur leur systme de fichier distribu GFS (Google File System).
Premirement, renommer NDFS, il sera rebaptis HDFS pour
HadoopDistributedFileSystem. Hadoop est aujourdhui lun des outils les plus pertinents
pour rpondre aux problmes du Big Data.
Hadoop sinspire de deux produits, le premier est le Google FileSystem , un systme
de fichiers distribus. Le deuxime est bien videmment le modle de Programmation
MapReduce, qui, en 2004, avait t mis en avant par la firme de MountainView dans
lune de leurs publications.
5.2.6.1 Hadoop Distributed FileSystem (HDFS)
Dans Hadoop, les diffrents types de donnes, quelles soient structures ou non, sont
stockes laide du HDFS. Le HDFS va prendre les donnes en entre et va ensuite les
partitionner en plusieurs blocs de donnes. Afin de garantir une disponibilit des
donnes en cas de panne dun nud, le systme fera un rplica des donnes. Par
dfaut les donnes sont rpliques sur trois nuds diffrents, deux sur le mme support
et un sur un support diffrent. Les diffrents nuds de donnes peuvent communiquer
entre eux pour rquilibrer les donnes.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 28
Figure 20
Hadoop Distributed FileSystem
5.2.6.1.1 Typologie dun cluster Hadoop
Hadoop repose sur un schma dit matre-esclave et peut tre dcompos en cinq
lments.
Le nom du nud (Name Node) : Le Name Node est la pice centrale dans le
HDFS, il maintient une arborescence de tous les fichiers du systme et gre lespace de
nommage. Il centralise la localisation des blocs de donnes rpartis sur le systme. Sans
le Name Node , les donnes peuvent tre considres comme perdues car il
soccupe de reconstituer un fichier partir des diffrents blocs rpartis dans les diffrents
Data Node . Il ny a quun Name Node par cluster HDFS.
Le gestionnaire de tches (Job Tracker) : Il soccupe de la coordination des tches
sur les diffrents clusters. Il attribue les fonctions de MapReduce aux diffrents Task
Trackers . Le Job Tracker est un Daemon cohabitant avec le Name Node
et ne possde donc quune instance par cluster.
Le moniteur de tches (Task tracker) : Il permet lexcution des ordres de
mapReduce, ainsi que la lecture des blocs de donnes en accdant aux diffrents Data
Nodes . Par ailleurs, le Task Tracker notifie de faon priodique au Job Tracker
le niveau de progression des tches quil excute, ou alors dventuelles erreurs pour
que celui-ci puisse reprogrammer et assigner une nouvelle tche. Un Task Tracker
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 29
est un Deamon cohabitant avec un Data Node , il y a un donc un Task Tracker
par Data Node .
Le nud secondaire (Secondary node) : Ntant initialement pas prsent dans
larchitecture Hadoop, celui-ci a t ajout par la suite afin de rpondre au problme du
point individuel de dfaillance (SPOF- Single point of failure). Le Secondary Node va
donc priodiquement faire une copie des donnes du Name Node afin de pouvoir
prendre la relve en cas de panne de ce dernier.
Le nud de donnes (Data Node) : Il permet le stockage des blocs de donnes. Il
communique priodiquement au Name Node une liste des blocs quil gre. Un HDFS
contient plusieurs nuds de donnes ainsi que des rplications dentre eux. Ce sont les
nuds esclaves.
Figure 21
Architecture dun cluster Hadoop
Un cluster Hadoop peut-tre constitu de machines htrognes, que ce soit au niveau
du hardware comme au niveau software (systme dexploitation). Cependant il est bien
plus simple dadministrer un cluster de type homogne.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 30
5.2.6.2 Implmentation de MapReduce dans Hadoop
Figure 22
Fonctionnement de MapReduce dans Hadoop
Voici comment fonctionne le processus MapReduce dans le framework Hadoop. Pour
commencer, le Job Tracker va recevoir une requte cliente Map , il va alors
demander au Name Node quelles sont les informations ncessaires ainsi que leur
localisation dans le cluster pour rpondre la requte du client. Une fois la rponse
reue, le Job Tracker enverra la fonction map aux diffrents Task Trackers .
Les Task Trackers vont alors chercher les donnes correspondant au traitement sur
leur Data Nodes . Une fois que les fonctions map ont termins leur traitement, les
rsultats de ceux-ci sont stocks. Il est bon de noter que les donnes sont compiles au
niveau de chaque Data Nodes , et non pas de manire centralise. Cest ce qui fait
la caractristique principale de Hadoop.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 31
Une fois que la partie Map est termine, cest la partie Reduce qui commence faire
remonter les diffrents rsultats et les consolider en un seul rsultat final (voir 5.2.3
fonctionnement de MapReduce) pour rpondre la requte du client.
5.3 La gestion de la cohrence des donnes
Nous avons prcdemment vu (dans le chapitre 3.3 cohrence contre disponibilit) que
le thorme de CAP dmontre le fait que dans un environnement distribu, il tait
impossible de maintenir les trois contraintes (qui sont la cohrence, la disponibilit et la
rsistance au morcellement) en mme temps. Nous avons not que les bases de types
NoSQL privilgiaient la disponibilit au dtriment de la cohrence des donnes. Une
telle affirmation pourrait cependant induire les personnes en erreur, pouvant leur faire
croire quil n y a aucun traitement de la cohrence dans les moteurs NoSQL, ce qui nest
pas tout fait vrai. En effet, pour rpondre la forte cohrence des SGDBR, les moteurs
NoSQL appliquent la cohrence finale (eventual consistency).
La cohrence finale est donc un modle de programmation qui affirme que pour la mise
jour dune donne, au bout dun certain temps, celle-ci aura t mise jour sur tous
ses rplicas, on dit alors que le systme a t converg. Lors dune mise jour dune
information dans une base NoSQL, la donne nest pas totalement verrouille et peut
tre accessible en lecture. Tout ceci nest pas sans consquence et de nombreux cas
dincohrence se crent. Cest donc pour cela que des outils de rconciliation ont t
mis en place.
5.3.1 Anti Entropie
Le processus qui consiste concilier les diffrences entre plusieurs rplicas de donnes
distribues sappelle anti-entropie. Entropie signifiant un tat de dsordre, anti-entropie
pourrait se traduire comme un anti-dsordre . Lanti-entropie se base sur deux
principes ;
Le premier est le HashTree qui est un mcanisme de comparaison de volume de
donnes. Il sera utilis dans ce contexte pour comparer deux bases de donnes qui sont
supposes tre de parfaits rplicas. En comparaison avec dautres algorithmes de
hachage, lavantage du HashTree est que son processus est beaucoup moins long et
couteux. Au lieu de comparer la valeur de hachage ligne par ligne, le HashTree va
calculer le hachage dune table tout entire et comparer sur cette unique valeur. Si les
deux valeurs sont gales, cela signifie que les tables sont identiques. Dans le cas
contraire, cela veut dire quelles ne sont pas identiques et que lalgorithme va descendre
un niveau plus dtaill en crant des hachages sur des critres plus fins et ainsi rpter
le mme processus jusqu trouver llment diffrenciateur. Nous pouvons tout de suite
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 32
nous rendre compte du gain de temps et de traitement de donne que le HashTree
apporte dans un contexte de Big Data . Voici une reprsentation du HashTree
schmatis pour un systme Cassandra :
Figure 23
Reprsentation du HashTree sur Cassandra
Le deuxime principe est celui de la gestion des conflits . Dans un systme
distribu o lon peut mettre jour la mme donne se trouvant sur des serveurs
diffrents au mme moment, une gestion des conflits est essentielle. En effet,
comment pourrait-on savoir si linformation provenant du serveur que lon a interrog
est la dernire mise jour ?
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 33
Figure 24
Reprsentation de conflit
Il existe diverses solutions implmentes par les moteurs NoSQL pour la gestion de
conflit. Les techniques les plus utilises sont les timestamps et les vectorclocks .
Lillustration ci-dessus reprsente la gestion du conflit dans un systme tel que
Cassandra o chaque valeur possde un timestamps . Un timestamps est donc la
date et lheure laquelle linformation a t mise jour. Cassandra dfinit plusieurs
niveaux de consistance, et de faon gnrale, lors de la lecture (pour ne parler que de
cet exemple), un des niveaux consiste lire la donne sur plusieurs nuds afin de
comparer les timestamps pour choisir linformation la plus jour.
6. Les avantages / dsavantages du NoSQL
SQL et NoSql ont chacun son lot davantages et de dsavantages ; aucune des deux
solutions nest donc meilleure que lautre. En fonction des types de besoins que peut
avoir une entreprise par exemple, une solution SQL pourrait tre plus avantageuse
quune solution NoSql, et vice-versa. Notons que NoSQL signifie Not Only Sql .
6.1 Les avantages
6.1.1 Plus volutif
NoSQL est plus volutif. Cest en effet llasticit de ses bases de donnes NoSQL qui
le rend si bien adapt au traitement de gros volumes de donnes. Au contraire, les bases
de donnes relationnelles ont souvent tendance utiliser la scalabilt verticale, qui
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 34
consiste augmenter les capacits du serveur (plus despace, ajout de RAM,
augmentation de la puissance du processeur) quand celui-ci atteint ses limites. Mise
part le cot lev que peut engendrer ce genre de processus, il nest tout simplement
pas viable dans un contexte de BigData. Il est donc de loin prfrable dadopter une
solution NoSQL utilisant la scalabilit horizontale, dont le principe est dajouter des
serveurs en parallle afin de mieux rpartir la charge. La scalabilit horizontale offre
dautres avantages non ngligeables, comme une grande tolrance aux pannes ou les
cots rduits relatifs lachat du matriel (plus besoin dacheter de serveurs
extrmement puissants).
6.1.2 Plus flexible
Ntant pas enferme dans un seul et unique modle de donnes, une base de donnes
NoSQL est beaucoup moins restreinte quune base SQL. Les applications NoSQL
peuvent donc stocker des donnes sous nimporte quel format ou structure, et changer
de format en production. En fin de compte, cela quivaut un gain de temps
considrable et une meilleure fiabilit. Il va sans dire quune base de donnes
relationnelle doit tre gre attentivement. Un changement, aussi mineur soit-il, peut
entraner un ralentissement ou un arrt du service.
6.1.3 Plus conomique
Les serveurs destins aux bases de donnes NoSQL sont gnralement bon march et
de faible qualit, contrairement ceux qui sont utiliss par les bases relationnelles. De
plus, la trs grande majorit des solutions NoSQL sont opensource, ce qui reflte dune
part une conomie importante sur le prix des licences, mais aussi une vitesse de
dveloppement du produit beaucoup plus grande.
6.1.4 Plus simple
Les bases de donnes NoSQL ne sont pas forcment moins complexes que les bases
relationnelles, mais elles sont beaucoup plus simples dployer. La faon dont elles ont
t conues (rparation automatique, donnes distribues, simplicit des modles de
donnes) permet une gestion beaucoup plus lgre. Toutefois, la prsence de DBA
(Database administrator) dans un environnement NoSQL est quand mme ncessaire
(pour le moment), ne serait-ce que pour la gestion de la performance et pour la
disponibilit dune banque de donnes critique.
6.1.5 Le Cloud Computing
NoSQL et le cloud sassocient de faon naturelle. En effet, le cloud computing rpond
extrmement bien aux besoins en matire de scalabilit horizontale que requirent les
bases de donnes NoSQL. De plus, la facilit de dploiement et de gestion de ces bases
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 35
en fait un partenaire de choix pour le cloud computing, permettant aux administrateurs
de se concentrer davantage sur laspect logiciel sans devoir se soucier du matriel quils
utilisent. Le service dAmazon DynamoDb en est lexemple parfait.
6.2 Les dsavantages
6.2.1 Fonctionnalits rduites
Les bases de donnes NoSQL sont principalement conues pour stocker des donnes
et offrent trs peu de fonctionnalits autres que celle-l. Lorsque les transactions entrent
dans lquation, les bases de donnes relationnelles restent le meilleur choix. Voil
pourquoi les bases NoSQL ne pourront jamais remplacer entirement SQL (ce nest pas
le but dailleurs).
6.2.2 Normalisation et Open Source
Etrangement, le critre dopen source pour les bases de donnes NoSQL est la fois
sa plus grande force et sa plus grande faiblesse. La raison est quil nexiste pas encore
de normalisation fiable pour NoSQL
6.2.3 Performances et volutivit au dtriment de la cohrence
En raison de la faon dont les donnes sont gres et stockes dans ces bases, la
cohrence des donnes pourrait bien tre une proccupation. Comme dj vu
prcdemment, les bases de donnes NoSQL font limpasse sur les proprits dites
ACID afin de mieux rpondre aux besoins de performances et dvolutivit. La
cohrence des donnes est donc un facteur moins important. Selon le besoin, ces
caractristiques peuvent tre un srieux atout tout comme un paramtre irrecevable. Sil
faut faire face de trs grosses montes en charge de trs gros volumes de donnes,
NoSQL est le systme adquat. Si on traite des donnes sensibles (transactions
bancaires ou autres), la cohrence des donnes est indispensable.
6.2.4 Manque gnral de maturit
Bien que les bases de donnes NoSQL soient prsentes depuis longtemps, leurs
technologies sont encore immatures par rapport celles des bases relationnelles. Cela
se traduit galement par un manque dadministrateurs et de dveloppeurs ayant les
comptences dans ce systme. Les bases de donnes ont beau tre administrator-
friendly (simples administrer), cela na pas de sens si les administrateurs en question
ne savent pas comment les utiliser. A lheure actuelle, les bases de donnes
relationnelles sont beaucoup mieux implmentes dans les entreprises. Elles disposent
dun nombre plus grand de fonctionnalits et de professionnels qui comprennent
comment les grer.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 36
6.3 Conclusion
Etant donn que, ces dernires annes, les bases de donnes NoSQL ont gagn en
popularit avec lmergence du BigData et quelles ont pu venir bout de problmes
que les bases de donnes relationnelles taient incapables de rsoudre, elles restent
nanmoins limites dans dautres domaines importants. Un administrateur doit par
consquent examiner soigneusement le type de bases de donnes le mieux adapt
ses besoins, car un mauvais choix pourrait avoir de trs lourdes consquences.
7. Benchmark
La deuxime partie de ma recherche consiste en un rapport dun travail pratique, le but
est de reprendre un script de base de donnes SQL et de le rcrire sur Cassandra, qui
est un moteur NoSQL de type colonne.
7.1 Prsentation du sujet
Lors de mes tudes la HEG jai d dvelopper, dans le cadre dun cours de gnie-
logiciel, un mini-programme permettant la gestion dun vido club : Easy Location. Ce
projet tait divis en deux tapes. La premire partie consistait en la mise en place de
la base de donnes, ce qui comprend la ralisation des modles MCD,MLD, et MPD,
ainsi que celle des diffrents scripts (script de cration de base de donnes, cration
dutilisateurs, cration des tables, etc.). La deuxime partie tait le dveloppement du
software en langage .Net.
Dans le cadre de la prsente recherche, mon travail consiste donc reprendre la partie
BDD de ce projet et de la traduire sur Cassandra. Lintrt dune base de donnes
NoSQL repose sur le fait quelle soit implmente sur plusieurs machines afin de rpartir
la charge de travail. Malheureusement, lexprimentation naura pas lieu en raison dun
manque de moyens matriels et dun volume insuffisant de donnes traiter.
7.2 Le modle de donnes Cassandra
Afin de mieux comprendre la mise en place de la base de donnes, il est important de
nous attarder quelques instants sur le modle de donnes utilis par Cassandra, cest-
-dire sur les diffrents lments qui composent cet outil.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 37
7.2.1 La colonne
La colonne est la plus petite valeur possible dans
un systme Cassandra. Cest un triplet compos
du nom de la colonne, de la valeur quelle possde,
et de son timestamp. Ce dernier indique lheure et
la date laquelle linformation a t enregistre. Il
est utilis par le systme pour savoir quelle est
linformation la plus actuelle. Une colonne peut
contenir plusieurs valeurs, comme dans une
collection de chanes de caractres. Elle peut aussi
ne pas en avoir du tout.
7.2.2 La ligne
Une ligne est un enregistrement. Elle est compose dun ensemble de colonnes. Chaque
ligne est identifie par une cl, quon appellera rowKey . Il est possible dutiliser des
colonnes comme cl primaire dune ligne. Une ligne peut contenir jusqu deux milliards
de colonnes.
Figure 26
Description dune ligne
Dans lillustration ci-dessus, on remarque que la deuxime ligne ne contient pas autant
de colonnes que la premire et que les noms de colonnes sont diffrents. Cela sexplique
par le fait que le schma dune base de donnes oriente colonne est dynamique, que
ce soit par rapport au nombre de lignes ou par rapport au nombre de colonnes (voir le
chapitre 3.4.2 Les bases de donnes orientes colonne).
Figure 25
Description dune colonne
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 38
7.2.3 Famille de colonnes
Une famille de colonnes est un regroupement logique de lignes (denregistrements).
Dans le monde relationnel, elle est comparable une table.
Figure 27
Description dune famille de colonnes
Lorsquon cre une famille de colonnes, il est possible dy dfinir des informations
concernant les mtadonnes des colonnes, cest--dire dy dfinir les diffrents attributs
dune table. Or, cest au moment de lenregistrement dune ligne que lon dcide des
colonnes qui seront exploites. On distingue deux types de familles de colonnes : la
famille de colonnes statique, o les colonnes sont dfinies lors de la cration ou la
modification de celle-ci, et la famille de colonnes dynamique, o les colonnes sont
dfinies lors de la cration ou la modification dune ligne.
7.2.4 Le keyspace
Le keyspace est un regroupement des diffrentes familles de colonnes. On peut le
considrer comme un schma de base de donnes.
7.2.5 Les diffrents types dattributs
Tout comme SQL, Cassandra propose plusieurs types dattributs. Voici un tableau
prsentant les types en question. La premire partie du tableau contient les types sous
leur format natif, tandis que la seconde partie montre leur type correspondant en format
CQL.
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 39
Figure 28
Diffrents types proposs par Cassandra
7.3 Mise en place de la base de donnes EasyLocation sur Cassandra
Dans ce chapitre, je vais aborder les diffrentes tapes de la cration de la base de
donnes Easy Location sur le systme Cassandra. Il convient de noter que ces tapes
ne sont pas toutes reproductibles entre un environnement Oracle et Cassandra. Cest la
raison pour laquelle je vais uniquement me consacrer aux parties qui peuvent ltre.
Bien quhistoriquement Cassandra-CLI ait t le premier outil pouvoir manipuler une
base Cassandra, je vais utiliser CQL Shell, qui est non seulement plus commun, mais
aussi trs similaire SQL dans sa syntaxe. CQL Shell est apparu suite larrive du
langage CQL.
7.3.1 Cration de la base de donnes
La cration du keyspace est lune des premires tapes par lesquelles il faut passer pour
mettre sur pied une base de donnes sur Cassandra. Pour rappel, le keyspace est le
schma de la base de donnes. Cest dans ce schma-l que je vais crer toutes les
familles de colonnes ncessaires lapplication.
CREATE KEYSPACE Easy_Location WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
Grce cette commande, jai cr le keyspace portant le nom de Easy_Location . Le
paramtre replication est obligatoire et sert dfinir les stratgies de rplication de
la base entre les diffrents nuds du cluster. Or, il nest pas ncessaire dans le contexte
du projet, tant donn que la base ne se trouve que sur une seule machine. Cest
-
NoSql : Etat de lart et benchmark PIAZZA, Adriano Girolamo 40
pourquoi je ne vais pas me pencher non plus sur les diffrentes stratgies de rplication.
Dans le cadre de cette recherche, je me contenterai donc dappliquer la stratgie par
dfaut.
7.3.2 Gestion des utilisateurs
Dans le systme Cassandra, la gestion des droits dutilisateurs correspond
lauthentification et lautorisation internes. Lauthentification interne consiste en la
gestion des noms dutilisateurs et de leur mot de passe par Cassandra. Quant
lautorisation interne, elle gre les diffrents droits accords un utilisateur sur
lensemble de la base de donnes.
Afin que le systme dauthentification et dautorisation soit actif, il faut changer quelques
paramtres dans un fichier de configuration. En effet, sur Cassandra, le systme
dauthentification et dautorisation est par dfaut dsactiv. Pour lactiver, il faut modifier
les deux lignes suivantes dans le fichier cassa