Bases NoSQL

herbshopeulikitInternet και Εφαρμογές Web

11 Φεβ 2013 (πριν από 4 χρόνια και 5 μήνες)

555 εμφανίσεις

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

1





Rapport

: Architecture Logicielle


Big Data et NoSQL

: de l’explosion des
volumes de donne es lie e a l’essor du Web
a l’e mergence de nouvelles architectures
de stockage et d’
interrogation de
donne es.




















Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

2

Sommaire

Sommaire

................................
................................
................................
................................
......................

2

I.

Le Big Data

: Les Enjeux

................................
................................
................................
.........................

3

I.1
-

Le contexte actuel

................................
................................
................................
..............................

3

I.2
-

De grands enjeux économiques et technologiques

................................
................................
...........

3



.......................

4

II.
Bases NoSQL

: De nouvelles architectures de stockage et de traitement des données
II.1
-

Bases de do
nnées clé
-
valeur

................................
................................
................................
.............

5

II.1.1
-

Présentation du concept de stockage et d’interrogation des données

................................
.....

5

II.1.2
-

Les plus

................................
................................
................................
................................
.......

5

II.1.3
-

Les

moins

................................
................................
................................
................................
....

6

II.1.4


DynamoDB

: Une solution NoSQL pour les bases de données clé
-
valeur

................................
.

6

II.2
-

Bases de données orientées colonnes

................................
................................
..............................

7

II.2.1
-

Présentation du concept de stockage et d’interrogation des données

................................
.....

7

II.2.2
-

Les plus

................................
................................
................................
................................
.......

9

II.2.3
-

Les moins

................................
................................
................................
................................
..

10

II.2.4


Exemples

................................
................................
................................
................................
..

10

II.3
-

Bases de données
orientées documents

................................
................................
.........................

13

II.3.1
-

Présentation du concept de stockage et d’interrogation des données

................................
...

13

II.3.2
-

Les plus

................................
................................
................................
................................
.....

14

II.3.3
-

Les moins

................................
................................
................................
................................
..

14

II.3.4
-

Exemples

................................
................................
................................
................................
..

15

II.4
-

Bases de données orientées graphes

................................
................................
..............................

17

II.4.1
-

Présentation du concept de stockage et d’interrogation des données

................................
...

17

II.4.2
-

Différentes natures de bases de données orientées graphe

................................
...................

18

II.4.2
-

Les

plus

................................
................................
................................
................................
.....

20

II.4.3
-

Les moins

................................
................................
................................
................................
..

20

II.5
-

Une solution (open
-
source)

: Hadoop

................................
................................
.............................

21

II.5.1
-

Présentation du produit

................................
................................
................................
...........

21

II.5.2
-

Hadoop Distributed File System (HDFS)

................................
................................
...................

21

II.5.3
-

Le modèle MapReduce

................................
................................
................................
.............

22

II.5.4


Les points forts d’Hadoop

................................
................................
................................
........

23

Conclusion

................................
................................
................................
................................
...................

24

Bibliographie
................................
................................
................................
................................
................

25


Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

3


I.
Le Big Data

:
Les Enjeux

I.1
-

Le contexte actuel

La taille de l’univers
numérique est estimée à 2,7 Zett
aoctets (10
21

octets) de données et devrait
atteindre 35 Zetta
octet
s en 2020. Gérer une telle masse d’information répartie à travers le monde
devi
ent un véritable enjeu de l’informatique actuelle. Par exemple, de plus en plus d’entreprises se
reposent sur l’agrégation de données utilisateur, que ce soit à des fins de ciblage marketing, d’étude de
marché ou de toutes sortes de statistiques
requérant

une masse sans cesse croissante d’informations
souvent hétérogènes.

Dans le domaine de l’informatique ubiquitaire (ou ambiante) se pose également le problème de savoir
gérer des flux d’informations incessant et provenant de source diverses et toujours plu
s nombreuses.

Le terme de BigData est utilisé depuis quelques années pour désigner ces ensembles de données qui
s’étendent et deviennent si grands et volumineux qu’il en devient très difficile à la fois de les stocker et
d’interroger ces données avec les o
utils classiques pour gérer les bases de données (SGBD) surtout
relationnels. Pour un système de gestion de données relationnel classique, il est nécessaire, pour
accroitre les capacités de stockage et de vitesse de traitement (si le volume de données à st
ocker et
traiter devient plus important), d’augmenter la puissance et la capacité d’un serveur unique. C’est là une
des grandes limites qu’ont atteinte ces systèmes. De nouvelles technologies, de nouveaux concepts de
stockage et d’interrogation des données

sont donc nécessaires.

I.2
-

De grands enjeux économiques

et technologiques

Le stockage de données a un coût matériel important, sans oublier que les données d’une base sont très
souvent dupliquées sur différents serveurs, afin de permettre une meilleure
disponibilité du service
proposé,
et de garantir la possibilité d’accès aux données ainsi que leur restauration
en cas de problème
sur l’un des serveurs par exemple.

Bien que l’espace d
isque nécessaire au stockage soit quelque chose de

simple à augmenter, en rajoutant
des disques durs, interroger des volumes de données très volumineux devient très vite difficile et
nécessite des capacités de calcul et de vitesse de traitement toujours plus importants impliquant l’achat
de serveurs toujo
urs plus coûteux. De nouvelles technologies de stockage et t
raitement de données
s’imposent
donc, c’est là le sujet des différentes
technologies dites NoSQL, c’est
-
à
-
dire “not only SQL”.

Bigdata

tente de répondre à trois problématiques très importantes. Dans un premier temps, BigData doit
répondre au problème des volumes de données à stocker, qui deviennent de plus en plus importants. En
effet, BigData doit prévoir des solutions afin de palier au

problème engendré par l’explosion des
données. On peut citer par exemple la solution de répartir la charge de données sur plusieurs serveurs.

Ensuite, vient un second problème, lié à celui du volume des données, qui est la vitesse de traitement,
ou véloci
té. Ma
lgré

l’importance du nombre de données stockées, on doit pouvoir être capable d’obtenir
de très faibles temps de traitement.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

4

Enfin, BigData pose aussi le problème lié au fait que les données sont hétérogènes et ne sont pas toutes
structurées de la mê
me manière : c’est le problème de la variété des données. En effet, on souhaite
stocker dans une même base de données distribuées des données très différentes.


II.
Bases
NoSQL

: De nouvelles architectures de
stockage et de traitement des données

Le
problème que pose le Big Data

rend nécessaire l’utilisation de nouveaux moyens pour faire persister
ces grands volumes de données ainsi que pour les interroger et les traiter. Les bases de données NoSQL,
c’est
-
à
-
dire «

not only

SQL », sont une solution à
ce problème.
En effet, contrairement à une base de
données relationnelle, dont la montée en charge ne peut se faire qu’en augmentant la puissance d’un
serveur unique, les bases de données NoSQL permettent une montée en charge en augmentant le
nombre de ser
veurs à bas coûts. Ceci n’est
rendu
possible qu’en renonçant
au modèle relatio
nnel et aux
conditions fortes du modèle

transaction
nel,

c’est
-
à
-
dire
aux propriétés ACID d’atomicité, de cohérence,
d’isolation et de durabilité
.

Parmi le large panel actuel de
bases de données NoSQL, on peut distinguer quatre grandes catégories de
bases NoSQL

: les bases de données clé
-
valeur, orientées colonne, orientées document, et les bases de
données orientées graphes.

Nous en exposerons les différents principes
de stockage
s et les différentes
stratégies d’interrogatio
n et de traitements des données, ainsi que leurs cas d’utilisations spécifiques,
dans la suite de ce rapport.



Schéma

: positionnement des différents types de bases NoSQL, par rapport au volume des données à
traiter et de leur complexité.


Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

5

II.1
-

Bases de données
clé
-
valeur

II.
1.1
-

Présentation du concept de stockage et d’interrogation des données

Les bases de données clé
-
valeur sont une solution dite noSQL et pouvant répondre au problème du « Big

Data ». Le principe est très simple : il consiste à stocker en mémoire des couples clé
-
valeur, c'est à dire
un identifiant définissant un blob (Binary Large Object) correspondant aux données.

Les bases de données clé
-
valeur ne respectent donc pas de sché
ma de structuration des données comme
pour les SGBD classiques. En effet les données ne sont pas organisées en différents champs, et c'est donc
à la personne ayant défini la base de données, de choisir la sémantique du champ « valeur » (qui n'est
rien de p
lus, qu'une série de bits). Le concepteur de la base choisit alors ses propres règles de
sérialisat
ion et désérialisation du champ

valeur qui est un bl
ob. Le champ

« valeur » stocké et défini par
sa clé peut aussi être un pointeur, une adresse vers la ress
ource de la donnée. Par exemple, la clé peut
être une référence vers un fichier XML contenant les données pertinentes : dans ce cas on parle alors de
base de
données « orientées documents », type de base de données
que nous allons étudier plus tard
dans ce

rapport.

Les bases de données clé
-
valeurs sont couramment utilisées pour stocker des données de sessions par
exemple. On peut notamment citer Amazon qui utilise la solution « Amazon DynamoDB » pour leur
bases de données clé
-
valeur, qui leurs permettent de

stocker les paniers des utilisateurs de leur boutique
en ligne.

II.
1.2
-

Les plus



Simplicité et extensibilité

Un avantage des bases de données clé
-
valeur est qu'elles sont très faciles et rapides à réaliser. De plus
elles ont le mérite d’être facilement e
xtensibles. En effet, dans le cas où le nombre de données
augmente, on peut facilement répartir la charge entre différents serveurs de stockage, en définissant par
exemple des intervalles de clés sur chaque serveur.

De plus, les applications utilisant une
persistance avec des bases de type clé
-
valeur ont la particularité
d'avoir un code simplifié et facile à lire par rapport à des applications standards utilisant SQL.



Performances

Enfin, les bases de données clé
-
valeurs ont de très bonnes performances et ont tendance à réduire le
nombre total de requêtes effectuées sur la base puisque
les seul
s type
s

de requêtes possibles sont la
lecture et l'écriture de données.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

6

II.
1.3
-

Les moin
s



Simplicité impliquant des cas d’utilisation très spécifiques

Du fait de l’extrême simplicité du principe des bases clé
-
valeur, on ne peut faire que des requêtes basées
sur les clés. En effet, ce type de bases permet un stocka
ge sans schéma de données
c'est
-
à
-
dire sans
champs dans les tables (hormis le blob bien sûr) et sans modèle relationnel comme avec des SGBD
classiques. Le client est donc contraint de récupérer tout le blob à chaque requête et il ne peut pas avoir
de résultat de requêtes plus fins
comme avec des SGBD autorisant les requêtes en langage SQL.

II.1.4


DynamoDB

: Une solution NoSQL pour les bases de données clé
-
valeur

DynamoDB est une base de données NoSQL de type clé
-
valeur très connue, et propose un grand nombre
de fonctionnalités afi
n de développer sa base de données de manière très rapide et efficace.

Cette solution est recommandée afin de concevoir une base de données qui a vocation à traiter
d'importantes quantités d'informations et à être « scalable ».

DynamoDB dispose d'un modèle

de données bien particulier. En effet, les informations sont stockées
sous la forme de paire
s

nom
-
valeur que l'on appelle attribut. Ensuite, on défini
t

ce qu'on appelle des «
Items », qui sont représentés par une série d'attributs. Pour chaque Item, il fa
ut qu'un attribut le
composant soit défin
i comme étant clé
-
primaire. Tous

les Items sont alors stockés dans des tables.

Le schéma ci
-
dessous (tiré de la documentation officielle de DynamoDB sur le site aws.amazon.com),
montre le modèle de données de Dynamo
DB : on voit notamment que les di
fférents Items d'une même
table

n'ont pas forcément les mêmes attributs, ni le même ordre pour ceux qu'ils peuvent avoir en
commun.



Schéma

: Modèle de données de DynamoDB

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

7

II.2
-

Bases de données orientées colonnes

II.2
.1

-

Présentation du concept de stockage et d’interrogation des données



Le principe

:

Une base de données colonnes est tout simplement une base de données dont les
données

sont
stockées par colonne, et non par ligne.
Un SGBD relationnel est organisé en ligne
s
. Une base de données
orientée colonnes n’a pas de schéma conceptuel, et peut évoluer avec le temps en nombre de colonnes
tout comme

en nombre de lignes.



Schéma

: données d’une base de données relationnelle

Nom

Ecole

CouvreChef

Jean

(1)

Polytech

(2)

Chapeau

(1)

Paul

(2)


Casquette

(4)

Jacques

(3)


Sombrero

(5)

Schéma

: données d’une base de données orientée colonnes

On comprend immédiatement en regardant les 2 tableaux ci
-
dessus qu’un stockage en Base de données
colonne permet un gain considérable en espace de stockage physique nécessaire pour la persistance des
données, rien qu’en
considérant le fait qu’on ne stocke

aucune valeur «

null

» en base

dans le cas de
tuples incomplets
.

Les

base
s

de données colonne
s

son
t conçue
s

pour pouvoir stocker un très grand nombre de colonnes, et
sont par conséquent idéales pour du stockage dit «

one
-
to
-
many

».

Elles sont destinées à être utilisées
pour indexer de grand nombre de documents, par des sites dont le traffic est important, pour gérer des
données dont la taille varie beaucoup
, ou encore pour du traitement d’énormes volumes de données.



Créées pour le t
raitement de données massif

Les bases de données colonnes sont un c
oncept créé par les grands du web, pour répondre au besoin de
traitement de volumes de données toujours plus grand
s
, pour gérer de larges volumes de données
structurées
.

Souvent, ces bases
intègrent un système de requê
tes minimaliste

proche de SQL.

De nombreuses bases de données NoSQL orientées colonnes intègre une architecture «

Massively
Parallel Processing

» (MPP) implémentant des algorithmes type «

MapReduce

» (décrit dans la suite du
ra
pport) pour l’interrogation et l’indexation des données.
De plus, ces bases sont s
ouvent couplées avec
une couche MPP au niveau du traitement (ex

: Hadoop), c’est ainsi le MPP à tous les niveaux.

id

Nom

Ecole

CouvreChef

1

Jean


Chapeau

2

Paul

Polytech


3

Jacques



4



Casquette

5



Sombrero

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

8


Google BigTable est un SGBD orienté colonne
cré
é par G
oogle, pour leur moteur de recherche et leurs
indexations des donnée
s.
Google BigTable est très similaire à la solution Libre HBase, proposée par
Apache.

Sa structure complexe se base sur un stockage en colonne, et permet toutes sortes
d’optimisations pour

l’indexation notamment. BigTable n’est pas librement distribuée, et est réservée à
l’usage interne de Google, étant, de plus, spécifiquement conçue pour traiter les données relatives à la
société.

De nombreux autres grands du web et des sociétés indépenda
ntes se sont inspiré de la solution mise en
place par google, et ont créé leur propre base NoSQL orientée colonnes.



Des bases en plein essor

Les bases de données colonnes sont de plus en plus utilisées par les grands du Web, dont notamment
Google, Faceboo
k, ou encore Linkedin. Cependant il n’existe pas encore de système officiel de
classification de celles
-
ci, ni de règles conventionnelles officiellement définies pour qu’une base soit
déclarée comme base de données colonnes de qualité.

Les 12 regles de Cod
d ont donc été créées pour définir ce qui est exigé d'un système de gestion de base
de données (SGBD) afin qu'il puisse être considéré comme relationnel (SGBDR). Ces 12 règles pour les
BDD relationnelles n’ont pas encore d’équivalent pour les BDD colonnes
et autres destinées au
traitement de gros volumes de données, c’est là le propos des 6 règles établies par Michael Stonebraker,
créateur de

Ingres et

PostgréSQL et co
-
fondateur de Vertica (dont nous parlerons plus loin).

La base de données orientée colonn
es Vertica
satisfait bien
-
sûr toutes ces 6 règles

proposées par M.
Stonebraker

:



Un bloc de stockage ne doit contenir de données que d’une seule colonne
.



Le taux de compression doit être amélioré grâce à une implémentation de compression des
données agress
ive, c’est
-
à
-
dire en effectuant, au besoin, des rotations de block.



Il faut pouvoir se passer des ID d’enregistrement.



La base de données orientée colonnes doit disposer d’un moteur d’exécution au niveau de la
colonne et non au niveau de l’enregistrement (
ce qui limite le nombre de boucles nécessaires
pour accéder aux enregistrements).



Le moteur doit pouvoir travailler directement sur les données compressées et non au travers
d’
un buffer de décompression.



Le moteur doit être capable de traiter
aussi bien
de
s données

stockées chronologiquement que
sur une clé.

Ces règles sont une première proposition de normes et indicateurs de qualités pour une base colonne.
Des règles officielles seront probablement bientôt établies, tant les bases colonnes tendent à envahir le
monde du BigData.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

9

II.2
.2
-

Les plus



Une c
apacité
de stockage accrue

Comme nous l’avons vu précédemment, il n’y a aucun
e valeur «

null

» dans une

base de données
colonne, et l’on peut s’affranchir du stockage des id. Cela représente un gain en v
olume,

donc en espace
disque utilisé considérable
.

Qui dit
gain en espace de stockage, dit également bien sûr gain économique
important, puisque la taille de l’infrastructure nécessaire à l’accueil des données en est réduite.



Compression

Dans le cas d’une base de données colonnes, les données sont compressées le p
lus possible. En effet, si
chaque colonne contient des données qui se ressemblent beaucoup, la compression de ces données sera
très significative.

On pourrait penser que l’accès à des données compressées est lent car il nécessiterait une
décompression de c
elles
-
ci. Cependant de plus en plus d’éditeurs de SGBD colonnes permettent un accès
direct aux données, sans décompression lors de l’interrogation des données.



Rapidité d’accès aux données

Pour le cas d’une base de données où l’on réalise plus de lectures
que d’écritures et dont on veut
récupérer de gros volumes d’une donnée spécifique donnée (par exemple l’évolution d’un indicateur
relevé sur un sous réseau télécom durant une période définie), il est beaucoup plus performant de
récupérer directement les in
formations de toute une colonne, plutôt que de parcourir toutes les lignes
pour n
e prendre que cette information, comme vu précédemment.


Cependant, on peut aussi voir un intérêt aux bases colonnes dans le cas de relations one
-
to
-
many
simples comme par exe
mple des listes d’articles pour un utilisateur.

En effet, dans ce cas d’utilisation se
proche du modèle de base de données clé
-
valeur précédemment décrit, les données étant regroupées
dans une même colonne, l’accès à celles
-
ci en sera beaucoup plus rapide.



Ajout de nouveaux types de données facilité

L’orientation en colonnes de la base permet d’avoir un ajout de nouvelles colonnes à la base grandement
facilité, car contrairement à un SGBD relationnel, il n’est pas nécessaire de redimensionner les lignes
.



Architecture
MPP

(Massively Parallel Processing)

Souvent, les bases de données colonnes intègrent une couche de traitement MPP, basée sur des
algorithmes comme «

Map Reduced

»
, dont nous parlerons en détail dans la partie traitant d’Hadoop
. De
plus, les do
nnées sont souvent ré
parties sur plusieurs serveurs,
et dupliquées
. Les bases de données
colonnes se prêtent bien au clustering de base de données,

permettant d’obtenir une haute
disponibilité, et autorisant des

traitements pouvant être répartis sur différ
ents serveurs/clusters.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

10

II.2
.3
-

Les moins



Efficace uniquement dans un contexte «

BigData

»

L’utilisation de bases de données colonnes n’est vraiment efficace et profitable dans le cas de grands
volumes de données de mêmes types (une colonne pour chaque ty
pe), et dont les données au sens d’un
type se ressemblent.



Interrogation des données limitée en complexité

Le système

de requê
tes
d’une base de données orientée colonnes est souvent
minimaliste
. L
e stockage
en colonne est plus optimisé pour récupérer de larges volumes de données qui se ressemblent, mais ce
système a un prix

: les opérations possibles pour interroger les données s’
en voient

grandement limité
es

par rapport à un SGBD relationnel.
Seul
es des requêtes simples du type «

select/update/delete

» sont
généralement possibles.
Le choix d’une base colonnes se justifie dans le cas de
grands volumes de
données de même type dont on veut traiter massivement certains «

attributs

»,

mais pas dans le c
as de
données dont un traitement complexe
et «

ponctuel

»
doit être effectué lors de leur interrogation

ou
encore où il est nécessaire de conserver des liens comme dans un modèle relationnel.

II.2.4


Exemples

La base orientée colonne la plus connue est ce
lle développée et exploitée par Google

: BigTable. C’est de
cette base colonnes
et de son fonctionement
que se sont inspirés de nombreux projets similaires libres,
comme HBase (base colonne proposée par Apache Hadoop), Cassandra (qui fut longtemps utilisée

par
facebook) ou encore Hypertable.

Toutes ces bases col
onnes intègrent une couche MPP pour le
traitement des données, c
e qui permet des architectures distribuées

et une interrogation de données
très performant.





L’exemple de
la base de données analyti
que
Vertica


Un exemple de base de données colonne très populaire aujoud’hui est Vertica. Vertica
est une entreprise
indépendante faisant partie du «

Carré Magique des Data WareHouse

», qui
a été co
-
fondée par

Michael
Stoneb
racker, créateur notamment de
Postgre
SQL
, et a été rachetée par HP récemment.

Vertica adopte
un système de stockage des données en colonne spécifique, qui a été mis au point par M. Stonebraker
lui
-
même, et intègre aussi une architecture MPP pour l’interrogation des données.


Une telle
base de données peut être couplée à des systèmes de traitement des données comme Hadoop
(solution libre dont nous développerons les aspects dans la suite de ce rapport), ce qui permet d’avoir
des traitements basés sur l’algorithme de MapReduce (détaillé pl
us loin) à tous les niveaux. On peut par
exemple citer Linkedin qui utilise Vertica pour stocker des données et Hadoop pour réaliser les calculs, et
qui réalise des agrégations de données et des calculs temps réel (toutes les 15 minutes) sur plus de 75To
d
e données.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

11

Vertica regroupe sensiblement toutes les fonctionnalités qui peuv
ent être envisagée
s

pour un systè
me
de stockage colonne
, et se rapproche du confort que l’on trouve dans une base de don
nées relationnelle
,
et

proposant de nombreuses fonctionnalit
és, tout en ayant un fonctionnement très optimisé.

La base de
données analytique Vertica est une base innovante qui propose un système de gestion de données
ressemblant à celui qu’on trouve dans un SGBD relationnel, et qui est optimisée pour la lecture mas
sive
de données.

Vertica permet des requêtes ad hoc SQL extrêmement rapides et performantes, même pour
de très grandes bases de données, ce qui la rend très bien adaptée pour le Data Warehouse, et pour
toute application nécessitant des requêtes gourmandes.

Sans rentrer dans les détails, Vertica utilise un
système appelé FlexStore, qui permet tout un tas d’optimisation comme des regroupements de colonnes
dans un même fichier de stockage, une gestions d’utilisation de disque dur intelligente, ou encore des
su
p
p
ressions (delete) et mises à jours (update) très rapides.



Vertica pour le DataWarehouse

Afin d’offrir de grandes performances dans le cas de grands volumes de données, Vertica

vise à stocker
les données de la manière dont elles sont accédées, et adopte le stockage de données en colonnes.

Comme nous l’avons vu précédemment, le système des bases de données colonnes permet de réduire
considérablement les accès disque lors d’une in
terrogation massive des données.


Comparaison des lectures des données SGBDR/Base colonne

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

12

De plus, Vertica propose un système de compression des données très optimisé,


et permet donc le
stockage de plus de données. En effet, lorsque des données similaire
s sont regroupées, il est possible
d’atteindre d’excellents taux de compressions. Vertica applique plus de douze schémas de compression,
dépendant
de la nature
des données,
et
du système

«

host

»
. On peut ajouter que des valeurs de
données à «

null

» n’occ
upent vi
r
tuellement aucun espace. Au final, les taux de compressions des
données constatés avec Vertica sont de l’ordre de 50% à 90%.

Enfin, l’une des plus grandes forces de Vertica est le fait de travailler directement sur les données
encodées et compres
sées.

Vertica offre
aussi
une solution de clustering et permet l’ajout de toujours plus de hardwares. Les
colonnes sont alors dupliquées sur différentes machines, pour permettre une disponibilité maximale des
données

et une possibilité de récupération des données performante, en cas de problème survenu
.

Comme dit précédemment, Vertica respecte les 6 règles pour les bases de données colonnes proposées
par Michael Stonebraker, son créateur.


Position de Vertica comparé
e à d’autres bases colonnes, par rapport aux 6 règles de Stonebraker


Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

13

II.3
-

Bases de données orientées documents

II.3
.1
-

Présentation du concept de stockage et d’interrogation des données

Les bases de données orientées documents sont une évolution des ba
ses de données clé
-
valeur
présentées précédemment. La valeur associée à une clé n’est plus un BLOB mais un document. Le format
de ce dernier n’est pas imposé. Cela peut être du JSON (JavaScript Object Notation), du XML ou du YAML
par exemple. L’important é
tant que la base de données soit capable de manipuler des fichiers du format
utilisé afin de permettre diverses actions sur les documents, tel que la sélection de documents en
fonction d’un critère, ou la modification d’une partie du document. Dans le cas
contraire, on se
retrouverait avec une base de données clé
-
valeur classique. Pour certaines bases de données orientées
documents comme CouchDB, qui sera présentée dans ce rapport, cela se fait avec un langage généraliste
tel que JavaScript.

Contrairement a
ux bases de données relationnelles, il n’y a pas de schémas de base de données, c’est
-
à
-
dire que deux documents peuvent avoir des propriétés différentes comme l’illustre l’image ci
-
dessous.


Schéma

: Base de données orientée documents

Le premier document contient des commentaires, alors que le second contient une image. Ceci illustre la
flexibilité des bases de données orientées document. Un document peut contenir des valeurs comme un
chaine de caractère mais aussi d’autres documents. D
ans le schéma ci
-
dessus «

COMMENT 1

» pourrait
être
une chaî
ne de caractère
s

o
u un document contenant une chaî
ne de caractère
s

et une date par
exemple.

Il est très simple de récupérer les commentaires du document ayant pour titre TITLE pour les bases
orie
ntées documents, contrairement aux SGBDR où il faudra faire une jointure.


Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

14

II.3
.2
-

Les plus



Adaptées pour traiter des données hétérogènes

Les données n’étant pas structurées dans des tables comme pour les SGBDR
(Système de Gestion de
Base de Données Relat
ionnelle)
, l’organisation s’en retrouve beaucoup plus flexible. On peut ainsi avoir
des propriétés différentes entre les documents.
Ce qui est adapté dans le cas où

l’on a un modèle de
données très hétérogène.



D’excellentes performance possibles

Les bases

de données orientée documents s
ont particulièrement adapté
e
s pour regrouper du contenu
utilisé par une même page web. Cela évite les jointures en SQL des SGBD qui peuvent être couteuses en
termes de performances. En outre, elles sont adaptées aux gros volu
mes de données.

Elles peuvent aussi servir à mettre en cache des informations sous une forme intelligible (possibilité
d’effectuer des requêtes dessus). Pour la plupart d’entre elles, il est possible de mettre la base
directement en
mémoire
RAM, ce qui amé
liore grandement les performances.



Une bonne scalabilité horizontale

Les SGBDR ne sont pas très adaptés à la scalabilité horizontale puisqu’ils doivent respecter les
caractéristiques ACID. Ainsi quand on rajoute des machines, il faudra entre autre s’assure
r qu’une
donnée n’est pas verrouillée par une autre transaction sur un autre serveur, si on souhaite l’utiliser. Bien
sûr, il existe plusieurs solutions pour rendre plus efficace la scalabilité horizontale telles que RAC (Real
Application Cluster) pour Or
acle ou Service Broker pour MS SQL Server. Mais ce genre de solution n’est
pas aisé à mettre en place. A l’inverse, la plupart des bases de données orientées documents sont
pensées pour avoir une bonne scalabilité horizontale facilement. En effet, ce type
de bases fonctionne
avec quelque chose de semblable aux DHT (Distributed Hash Table). En effet, les bases de données
orientées documents étant une évolution des bases de données clé
-
valeurs, elles se prêtent bien aux
DHT. D’où une scalabilité horizontale e
fficace.

II.3
.3
-

Les moins



Duplications de données

Les données étant regroupées dans un document, cela peut causer des problèmes d’intégrité puisque
certaines données seront inévitablement dupliquées. Par exemple, dans le cas d’une base de données
des pr
oduits et des ventes d’un magasin, on aurait des documents représentant les produits avec leurs
nom
s

et des documents représentant les commandes avec les noms des produits de la commande. Il y a
donc duplication concernant les noms des produits et une poss
ible incohérence si on modifie le nom
d’un produit sans le changer dans les commandes ou il apparait.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

15



Un type de base peut
-
être un peu trop flexible

Les bases de données orientées document sont très flexibles. Le revers de la médaille est qu’on peut,
involontairement ou pas, insérer des données incohérentes (se tromper dans le nom d’un attribut d’un
document). A l’inverse, dans les SGBDR, si on ne respecte pas le schéma de la base de données, le
serveur refuse d’exécuter la requête. Ce qui offre d’avan
tage de garanties concernant la cohérence des
données.

Elles sont aussi inadaptées dans les systèmes où les entités sont peu autonomes et avec des relations
complexes. Il en est de même pour les situations, en particulier dans les environnements transactio
nnels
critiques, les banques notamment.

II.3.4
-

Exemples

Il existe bon nombre de systèmes de gestion de bases de données orientées documents tel que
Terrastore, RavenDB, RaptorDB, SimpleDB ou encore Redis. Cependant deux des plus connus vont être
présenté
s en détails, MongoDB et CouchDB.









MongoDB

MongoDB est un système de gestion de bases de données de plus en plus connu développé par la société
10gen. Celui
-
ci gère des documents au format BSON (Binary

JSON) qui est un dérivé de JSON binaire.
BSON est utilisé pour accroitre les performances. En effet, MongoDB est axé sur la performance, surtout
en ce qui concerne la vitesse du traitement des données. Sur, un ordinateur classique, le nombre
d’insertions
de documents par seconde est de l’ordre de 100

000.

Une base de données MongoDB est constituée de collections. Ces dernières contiennent des documents
au format BSON. De ce fait, l’utilisation d’un pilote est nécessaire pour interagir avec une base
MongoDB
.

MongoDB peut fonctionner sur plusieurs serveurs en répartissant les documents entre ces derniers. Ce
qui permet de répartir la charge entre les serveurs. En outre, il offre la possibilité de répliquer les
données sur plusieurs serveurs avec le principe
maître
-
esclave. Ce qui permet une meilleure résistance
aux pannes. La répartition et la duplication des documents permet de répartir efficacement la charge en
mettant sur un serveur les données les plus demandées et en dupliquant ce dernier un nombre suffi
sant
de fois.

Néanmoins, une architecture maître
-
esclave a pour défaut d’avoir un SPOF (Single Point of Failure).
Récemment, MongoDB offre la possibilité d’utiliser un parti
ti
onnement horizontal qui permet de répartir
les données entre différents nœuds de
serveurs.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

16

MongoDB est utilisé par plusieurs grands noms de l’informatique et du web tels que Foursquare, SAP ou
GitHub.

Il permet également d’utiliser le principe Map/Reduce, présenté dans la partie sur Hadoop,
qui permet aussi une meilleure scalabilité.



C
ouchDB

CouchDB est un système de gestion de bases de données développé à l’origine par Damien Katz pour
IBM. Il est actuellement maintenu par l’Apache Software Foundation. CouchDB

est particulièrement
adapté au web. En effet, la communication avec un serveur CouchDB se fait avec le protocole HTTP via
une interface REST (REpresentationnal State Transfer) et le format des documents est JSON. Il est donc
aisé de récupérer et manipuler

des documents depuis le navigateur web avec le langage JavaScript et le
concept AJAX (Asynchronous JavaScript And XML) qui permet de communiquer avec des serveurs sans
recharger la page web. Ce qui est très utile pour des applications web ou des pages web

dynamiques.

Pour stocker, lire, modifier ou supprimer un document on envoie une requête HTTP sur une URL. Par
exemple, pour obtenir le document ayant pour clé «

doc

» se situant dans la base «

base

», on utilisera la
méthode GET sur l’URL

«

http://localho
st/base/doc

» qui renverra un fichier au format JSON.

CouchDB étant orienté document, et pas seulement clé
-
valeur, il permet d’effectuer des requêtes sur les
documents via ce que l’on appelle des vues. Ceci, non pas en SQL, mais en JavaScript (par défaut,
il est
possible d’utiliser d’autres langages tels que Python ou PHP). Les vues reposent sur le principe
Map/Reduce.

CouchDB permet la répartition de charge. En effet, il est possible d’avoir des copies des données sur
d’autres serveurs CouchDB avec un sys
tème de réplication qui gère la resynchronisation. Cette
synchronisation peut être réglée très finement. Il est possible d’indiquer quels documents doivent être
synchronisés via un filtre qui pour chaque document indique s’il faut, ou pas, le synchroniser
. Cela est
utile pour créer des répliques spécialement pour certains documents. CouchDB est écrit en Erlang,
langage conçu pour la programmation distribuée, la montée en charge et la tolérance aux pannes.
En
effet, ce langage a été créé

par Ericsson, un
opérateur téléphonique, dans le but d’avoir une
architecture disponible 24 heures sur 24.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

17

II.4
-

Bases de données
orientées graphes

II.4
.1
-

Présentation du concept de stockage et d’interrogation des données

Lorsque l'on souhaite décrire les relations ex
istantes entre de nombreux objets, les bases de données
relationnelles ne sont, paradoxalement, pas les plus adaptées. L'exemple le plus évident est celui des
réseaux sociaux en pleine expansion aujourd'hui, au sein desquels des millions d'utilisateurs son
t reliés
entre eux par plusieurs types de liens : amis, famille, collègues etc., chaque utilisateur possédant de plus
un grand nombre d'attributs.

Afin de définir ces relations dans une base de données relationnelle classique, nous pourrions créer une
tabl
e contenant l'ID d'un utilisateur, ainsi que celui de chacun de ses amis. Le problème est alors que
pour chacun de ces types de relations de plusieurs vers plusieurs (many
-
to
-
many), une table contenant
de multiples entrées pour chaque utilisateur sera néce
ssaire. Cela devient encore plus complexe si l'on
souhaite associer à chaque liaison des informations complémentaires, telles que la relation entre les
deux personnes, ou la date à laquelle le lien a été créé.

Ainsi, si au final des solutions existent (tel
les que l'utilisation de jointures), des problèmes de
performance apparaîtront très tôt, sans parler bien sûr de la complexité des requêtes nécessaires

pour
interroger les données
.

C'est afin de résoudre ce problème
qu’est la représentation

des réseaux (qu
e ce soit de personnes, de
systèmes d'information ou autres) en base de données qu'ont été développé
e
s les bases orientées
graphe
s
, basées comme
leur nom l’indique,

sur les théories des graphes.

Au sein de ce type de base,
trois éléments sont à retenir :



Un objet (pouvant être par exemple un utilisateur) sera appelé un Nœud.



Deux objets pourront être liés par un Lien (tel qu'une relation d'amitié).



Chaque objet pourra enfin avoir un certain nombre de Propriétés (âge, ville de naissance,
activités etc..)
.

Une base de données orientée graphe stocke donc des données sur chaque nœud, et ces nœuds eux
-
mêmes sont organisés par des relations. Il est ensuite possible d'effectuer des opérations particulières à
des graphes sans avoir besoin de passer par des
jointur
es et des requête très complexes et lourdes
. Ces
opérations comprennent par exemple :



De parcourir le graphe à partir d'un nœud, sur une profondeur donnée.



De récupérer les relations existantes entre des nœuds ayant des propriétés similaires.



De retrouver
des « ancêtres » communs à plusieurs nœuds.



De calculer la profondeur et la largeur d'un morceau du graphe.

Et bien
d'autres possibilités encore...



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

18

Loin d'être toutefois réservées au domaine des réseaux sociaux, les bases de données orientées graphe
sont

également utilisées pour gérer d'importantes structures de réseaux informatiques, pour proposer
des produits en relation avec celui acheté sur un quelconque site de vente en ligne (du type « les
personnes ayant acheté ce produit ont également acheté... »)
, ou pour orchestrer les liens existants
entre un très grand nombre d'objets « intelligents » dans le domaine sans cesse croissant de
l'informatique ambiante.

Plus que le nombre d'objets à gérer, c'est ici le nombre de relations entre ces objets qui pose u
n
véritable défi. En effet, pour n objets il y a potentiellement n² relations à stocker et utiliser avec les
meilleures performances possibles. Lorsque le nombre d'objets atteint un certain seuil (pensons à
Facebook et à ses 700 millions d'utilisateurs), i
l est donc essentiel d'utiliser une approche par les
graphes.

II.4.2
-

Différentes natures de bases de données orientées graphe

La particularité des bases de données orientées graphe se fonde sur leur utilisation de nœuds, liens et
propriétés au lieu de ta
bles, lignes et colonnes, ceci afin d’obtenir de bien meilleures performances lors
de la gestion de données associatives. Toutefois, leur implémentation varie selon les besoins et les
propriétés à mettre en avant pour tel ou tel type d’utilisation. Il exis
te ainsi des bases orientées graphes
se basant sur un enregistrement key/value, d’autre sur une orientation colonne ou BigTable, voire sur
une combinaison de ces architectures.

Voici ci
-
dessous quelques exemples de bases de données orientées graphes, et le
urs particularités.



HyperGraphDB

En terme d’intelligence artificielle, la solution ayant tendance à s’imposer repose sur une architecture de
type neuronale, n’étant ni plus ni moins qu’un réseau de « neurones » dont les interconnexions sont
évolutives. C’e
st dans cette optique qu’a été développé HyperGraph DB, une base orientée graphe sous
licence LGPL. Une de ses particularités est de pouvoir relier des liens, et pas seulement des nœuds, par
d’autres liens.

Egalement utilisée dans le cadre du web sémantiqu
e, HyperGraph DB se repose sur un modèle
mathématique d’hypergraphe (chaque lien peut pointer sur plus de deux nœuds) probabiliste et pouvant
s’auto
-
modifier, modèle se rapprochant beaucoup de la manière dont fonctionne un cerveau. A l’instar
de ce dernier
, un très grand nombre de « neurones » (les nœuds, ici appelés atomes) et de liaisons sont
toutefois nécessaires, d’où la nécessité de pouvoir manipuler ce très grand nombre d’éléments à travers
une base de données orientée graphe.



Neo4j

Neo4j est une base

orientée graphe classique mais efficace et open source, respectant les conditions
ACID et offrant une réplication maitre/esclave, ce qui lui vaut une certaine popularité.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

19



FlockDB

Ayant pour particularité de ne pas supporter d’opérations transversales, F
lockDB a été développé par
Twitter à des fins d’analyse de relations pour son réseau de microblogage. Cette limitation, due au fait
que Twitter n’a pas besoin de connaitre plus de relations au
-
delà de celle entre deux utilisateurs, illustre
bien la possibi
lité, voire la nécessité de devoir faire des choix concernant l’architecture de la base afin de
correspondre au mieux aux exigences du système auquel cette base s’applique, sans en faire de trop afin
d’optimiser les performances.

Toutefois, il existe une controverse afin de savoir si cela fait de FlockDB un simple graphe persistant, car
ne gérant pas certaines des opérations de bases d’un graphe, et non une base de données orientée
graphe.



BigData

Pouvant charger un milliards de li
ens en moins d’une heure, et capable de gérer plus de 50 milliards de
triplets (Nœud
-
Lien
-
Nœud) par machine, BigData est une autre base de données orientée graphe
portant bien son nom. Il est possible de stocker la base sur une seule machine aussi bien que

sur
plusieurs à l’aide d’un indexage parallèle, tout en respectant les conditions ACID et en assurant son
extensibilité.

BigData rend donc possible ce qui est essentiel dans ce cadre d’expansion des données, à savoir la
possibilité de distribuer la base s
ur un grand nombre de machines, et d’obtenir ainsi un espace de
stockage théoriquement illimité sans que cela ne réduise trop les performances grâce à son système de
traitement de données distribuées.



Exemple de relations telles que
celles
décrites par
une base orientée graphe (Neo4j)

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

20

II.4
.2
-

Les plus

Parfaitement adaptées à la gestion de données relationnelles, même lorsque ces données atteignent une
taille très importante, les bases de données orientées graphe sont une solution ayant l’avantage d’être

basée sur le modèle mathématique des graphes. Cela permet d’y appliquer des algorithmes déjà
existants et optimisés, faisant de ce type de base une architecture relativement aisée à comprendre et à
prendre en main. Comme vu précédemment, il est également
possible de modeler cette architecture
afin d’obtenir un modèle plus proche des besoins rencontrés, en y ajoutant ou en y omettant des
fonctionnalités.

Les bases de données orientées graphe font donc partie intégrante du noSQL en proposant une
alternative
aux bases relationnelles pour toute problématique liée à une représentation relationnelle
entre des données.

II.4
.3
-

Les moins

Cependant, cette architecture est très spécifique aux graphes, et la formation noeud/lien/propriété est
très limitée, pour ne pa
s dire inadaptée, dans des cas plus classiques. Loin de remplacer les bases de
données relationnelles, de même que d’autres types de bases noSQL, les bases orientées graphe ne sont
donc qu’une solution particulière à une forme particulière de BigData, et n
on une solution « miracle »
pouvant répondre à tous les besoins de ce domaine.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

21


II.5
-

Une solution
(
open
-
source
)

: Hadoop

II.5.1
-

Présentation du produit

Hadoop est un framework

open
-
source développé par Apache qui est dédié à la réalisation d'application
utilisant des bases de données distribuées. Il a été conçu pour répondre à la problématique posée par le
Big Data et permet donc de traiter et manipuler de très grandes quantité
s de données, de l'ordre du
petabit. Hadoop est très connu et est utilisé par de nombreuses entreprises renommées comme Google,
Ebay, IBM et Facebook.

La particularité d'Hadoop est qu'il peut gérer n'importe quels types de données stockées sur tout type
d'
infrastructure. On peut alors mélanger des données structurées avec des données non
-
structurées.

Les données stockées grâce à Hadoop sont réparties sur plusieurs serveurs, l'ensemble des données est
alors scindé et stocké sur les différents serveurs. Cela
forme ce qu'on appelle un « cluster ». C'est grâce à
cet ensemble de serveurs que l'on peut disposer à la fois, d'une grande capacité de stockage et d'une
importante puissance de calcul.

Hadoop fonctionne grâce à son système de fichier HDFS, qui permet de
répartir la charge sur chaque
machine composant le cluster. L'utilisation d'une implémentation de l'algorithme de MapReduce permet
à Hadoop de répartir la charge de calculs pour traiter les requêtes du client.

II.5.2
-

Hadoop Distributed File System (HDFS)

HDFS est le système de fichier qu'utilise Hadoop pour sa base de données distribuées, inspiré de Google
File System (GFS). Il est composé d'un Namenode qui est le serveur maître et d'un certain nombre de
Datanodes

qui sont des serveurs contenant les données. Une même donnée est répliquée un certain
nombre de fois sur différents Datanodes afin d'éviter les pertes d'information.

Le Namenode a pour objectif de connaître en permanence la localisation des données dans l
e cluster.
Ainsi lorsqu'une application veut accéder à une certaine donnée, elle va commencer par demander au
Namenode, la localisation du Datanode à interroger. Le Namenode va aussi servir à contrôler que la
charge est bien répartie sur les différents Dat
anodes et va s'assurer que les données sont répliquées le
bon nombre de fois.

Le Secondary Namenode permet de sauvegarder régulièrement les états du Namenode « principal » afin
de retrouver très rapidement et simplement un état stable en cas de panne ou d'
erreur avec le
Namenode.

Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

22


Schéma issu d'un article sur le site de Zenika, illustrant le système de fichiers d'Hadoop : HDFS

II.5.3
-

Le modèle MapReduce

Hadoop implémente un algorithme de MapReduce, qui a été popularisé par Google, et qui permet de
divise
r et répartir la charge de travail afin d'augmenter

Cela se déroule en deux étapes distinctes : l'étape du Map, ou l'on va séparer le travail à effectuer en
une multitude de sous
-
taches plus simple, aux différents nœuds du cluster. Une certaine donnée en
e
ntrée va alors être transformée en une liste de paires clé
-
valeur.

Ensuite, viens l'étape du Reduce, ou l'on récupère les résultats trouvés lors des différentes subdivisions
de la tâche, et où l'on va produire le résultat final de la requête. On va alors p
arcourir la liste des paires
clé
-
valeur retournée par l'étape Map et on va effectuer un traitement sur toutes les valeurs pour chaque
clé. On fusionne alors les informations produites par l'opération Map afin de former le résultat de la
requête demandée in
itialement.

Pour illustrer l'algorithme de MapReduce on peut donner un exemple simple. Imaginons que l'on
souhaite compter le nombre de caractères total d'un ensemble de textes. Dans ce cas, notre opération
Map prendra en paramètre un texte et va renvoyer
une liste de paires clé
-
valeur, associant un mot à son
nombre d’occurrences dans ce texte. On va répartir l'ensemble des textes aux différents Datanode afin
qu'ils exécutent cette opération Map.

L'opération Reduce aura pour rôle de collecter l'ensemble des

résultats des différentes opérations Map,
c'est à dire plusieurs listes de paires clé
-
valeurs, afin d'effectuer un certain traitement. Dans notre
exemple, on souhaite additionner pour chaque mot, les différentes valeurs d'occur
r
ences renvoyées par
Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

23

les opé
rations Map précédentes. En d'autres termes, on va simplement additionner, pour une même clé,
toutes les valeurs des paires. Au final, on obtient bien le résultat souhaité, c'est à dire une liste de paires
clé
-
valeur, avec pour clé un mot et en valeur son
nombre d’occurrence cumulé.

II.5.4


Les points forts d’Hadoop

Hadoop permet de réaliser des applications facilement extensibles. En effet, si la quantité de données à
stocker augmente, il suffit d’ajouter de nouveaux serveurs de stockage à notre cluster.

Hadoop est efficace aussi bien dans sa manière de répartir la charge de données entres les différents
Datanodes, que dans sa décomposition et répartition du travail, pour un traitement donné.

De plus, Hadoop est très flexible puisque l’on peut l’utiliser p
our stocker n’importe quels types de
données, structurées ou non.

Enfin, Hadoop est très peu impacté par les erreurs : si un client souhaite accéder à une donnée d’un
certain Datanode et que celui de répond pas, le Namenode

redirigera le client vers la location d’un autre
Datanode contenant la donnée souhaitée qui avait été répliquée précéde
m
ment par Hadoop.



Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

24

Conclusion

Dans le contexte
actuel
où les volumes de données ne cessent de croitre et de se complexifier, il faut
in
nover, tant dans la façon de stocker ces données que dans celle de les traiter. Nous avons vu que les
SGBD classiques, relationnels, ne suffisent plus à traiter efficacement les données dans de grandes
structures. C’est pour cela que depuis quelques années
, de nouvelles technologies ont vu le jour pour
répondre à ce besoin, dont les bases de données dites NoSQL.

Parmi cette large gamme de bases de
données, chacune peut être préférable à une autre selon les données spécifiques qui doivent être
stockées, pouv
ant offrir de meilleures performances lors de l’insertion et l’interrogation de données et
un espace de stockage moins volumineux.

On peut ajouter que, pour «

contrer

» l’essor

des bases de données noSQL, des bases de données
NewSQL ont vu le jour. NewSQL
désigne des SGBD relationnels cherchant à fournir des performances et
une extensibilité similaires à celles des SGBD NoSQL. Les bases newSQL respectent le modèle ACID et
utilisent SQL. La plupart sont optimisées pour effectuer de grands nombres de transact
ions et pour
effectuer des requêtes répétitives, et proposent souvent un système d’indexation optimisé. Les bases
NewSQL peuvent être considérées comme une bonne alternative à un SGBD classique, n’obligeant pas à
se défaire du modèle relationnel.

La tendan
ce actuelle est de vouloir faire des agrégations sur des données de tout type, structurées ou
non, pour par exemple proposer des choix
selon les goû
ts d’un utilisateur, ou encore être capable de
mettre en relation des données vidéos (non structurées) avec
des informations diverses (données
structurées). De nombreux projets en cours existent, dont par exemple Autonomy, appartenant à HP, qui
propose un moteur de recherche appelé IDOL, permettant de mettre en relation des données
structurées massives stockées
dans une base colonne Vertica par exemple, avec des données vidéo,
vocales, provenant de réseaux sociaux, etc. grâce à des algorithmes d’agrégation probabilistes
complexes.
Ces nouveaux systèmes d’interrogation et de traitement des données constituent
cert
ainement l’
avenir

en terme
s

de surcouche à des SGBD toujours plus optimisés aux données qu’ils
contiennent
.


Maxime Bérard


Kévin Dumoulin


Thomas Moreau


Guillaume Roche

SI5
-

AL

Rapport : Big Data & NoSQL

25

Bibliographie

Bases de données key
-
value :

http://ayende.com/blog/4449/that
-
no
-
sql
-
thing
-
key
-
value
-
stores


http://blog.xebia.fr/2010/04/26/nosql
-
europe
-
bases
-
de
-
donnees
-
cle
-
valeur
-
et
-
riak/


Bases de do
nnées orientées document

:

http://www.siteduzero.com/news
-
62
-
36259
-
sortie
-
de
-
couchdb
-
0
-
11.html


http://
blog.xebia.fr/2010/12/15/mongodb
-
en
-
pratique/


http://www.unixgarden.com/index.php/gnu
-
linux
-
magazine/couchdb
-
la
-
base
-
de
-
donnees
-
qui
-
change
-
to
ut


http://ruby.about.com/od/nosqldatabases/a/nosql1.htm


http://blog.xebia.fr/2010/04/30/nosql
-
europe
-
bases
-
de
-
donnees
-
orientees
-
documents
-
et
-
mongodb/


http://en.wikipedia.org/wiki/Document
-
oriented_database


Bases orientées colonnes :


Docu
ments officiels de Vertica (HP)

http://blog.xebia.fr/2010/05/04/nosql
-
europe
-
bases
-
de
-
donnees
-
orientees
-
colonnes
-
et
-
cassandra/


http://www.legrandbi.com/2011/01/classification
-
bases
-
de
-
donnees
-
en
-
colonnes/


http://w
ww.legrandbi.com/2009/10/stockage
-
en
-
colonnes
-
adoop
-
le
-
duo
-
gagnant/


http://www.legrandbi.com/2011/02/hp
-
vertica/


http://fr.wikipedia.org/wiki/Edgar_Frank_Codd

http://www.legrandbi.com/2012/02/linkedin
-
bigdata/


Bases de données orientées graphes

:

http://dbpedias.com/wiki/NoSQL:Survey_of_Distributed_Databases#NoSQL_Databases


http://readwrite.com/2011/04/20/5
-
graph
-
databases
-
to
-
consider


http://en.wikipedia.org/wiki/Graph_database


http://www.bigdata.com/bigdata/blog/


Hadoop :

http://aws.amazon.com/fr/dynamodb/#functionality


http://strata.oreilly.com/2011/01/what
-
is
-
hadoop.html


http://blog.zenika.com/index.php?post/2012/07/11/Hadoop
-
et
-
le
-
MapReduce
-
au
-
service
-
des
-
gros
-
volumes
-
de
-
donn%C3%A9es


Autres sources
:

http://www.youtube.com/user/ibmbigdata


http://nosql
-
database.org/


http://www.internetactu.net/2012/10/04/big
-
data
-
le
-
grand
-
desequilibre/


http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC4QFjAA&url=http%3A%2