70
NoSQL Etat de l’art et benchmark Travail de Bachelor réalisé en vue de l’obtention du Bachelor HES par : Adriano Girolamo PIAZZA Conseiller au travail de Bachelor : David BILLARD, Professeur HES Genève, 9 octobre 2013 Haute École de Gestion de Genève (HEG-GE) Filière Informatique de Gestion

NoSQL Etat de l’art et benchmark - RERO DOCdoc.rero.ch/record/209288/files/Travail_de_Bachelor_-_NoSql_Etat... · 5.2.6 Hadoop ... Architecture d’un cluster Hadoop ... lors de

Embed Size (px)

Citation preview

  • 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