Le document présente le mouvement NoSQL, né en 2009, comme une réponse aux limitations des bases de données relationnelles face à l'explosion des données. NoSQL offre divers modèles de données (clé/valeur, orienté document, orienté colonnes, orienté graphe) adaptés aux environnements distribués et traite les défis du Big Data liés à la scalabilité, la vélocité et la variété des données. Les systèmes NoSQL, utilisés par des géants du web, permettent une meilleure gestion des données massives et des performances optimisées selon les besoins spécifiques des applications.

1. NoSQL & BigData
Qui? Quand? Et Pour qui?
28/01/2014
Cassano Orlando

2. Quelques mots sur le CETIC
Centre R&D en ICT au Service des
entreprises
Académies
Industries

3. Génèse du mouvement NoSQL
• Première
appari*on
du
terme
en
2009...
...
même
si
certaines
technologies
sont
plus
anciennes
• Mouvement
lancé
par
les
entreprises
• Nouveaux
besoins
provenant
de
l’explosion
des
données
• Les
RDBMS
classiques
ont
aGeint
leurs
limites
• Le
NoSQL
propose
des
alterna*ves
au
modèle
rela*onnel
è
NoSQL
=
Not
Only
SQL

4. Mais pourquoi ?
• Traitement
sur
les
données
de
plus
en
plus
efficace
• Temps
d’exécu*on
souvent
passé
en
accès
disque
– Les
disques
durs
sont
lents
– Les
alterna*ves
(SSD)
restent
onéreuses
• 1
disque
dur
=
75MB/sec
1000
disques
durs
=
75GB/sec
• àBesoin
de
paralléliser
l’accès
aux
données
structurées

5. Mais pourquoi ?
• Ensemble
des
modèles
non
rela*onnels
convenant
aux
environnements
distribués
• Solu*on
aux
limites
du
modèle
rela*onnel
– Des
structures
rigide
de
données
– Le
temps
d'inser(on/de
lecture
augmente
grandement
avec
le
nombre
d'enregistrements
– Par**onnement
difficile
à
meGre
en
œuvre
– Gain
non
linéaire
en
fonc*on
du
nombre
de
serveurs

6. Stockage scalable
• Scalabilité
ver*cale
Scaling
up
– Augmenta*on
de
la
capacité
matérielle
de
la
machine
(fréquence
du
processeur,
mémoire,
taille/vitesse
du
disque)
– Solu*on
limitée
et
à
coût
croissant
en
fonc*on
de
la
scalabilité
• Scalabilité
horizontale
Scaling
out
A-­‐Z
– Augmenta*on
du
nombre
de
machines
– Nécessite
une
distribu*on
des
données
sur
différentes
machines
(Sharding)
A-­‐I
J-­‐P
Q-­‐Z

7. Théorème CAP
• Nouvelles
contraintes
liées
aux
environnements
distribués
– Respecte
au
plus
2
des
3
contraintes
du
théorème
CAP
– Les
objec*fs
des
systèmes
NoSQL
sont
différents
Consistency
:
les
données
sont
vues
de
la
même
manière
au
même
instant
par
tous
les
nœuds
du
réseau
;
Availability
:
garan*e
d’obtenir
une
réponse,
même
en
cas
de
panne
;
Par11on
tolerance
:
le
système
doit
con*nuer
à
répondre
correctement
même
si
une
par*e
de
l’infrastructure
est
inaccessible.
Consistency:
Transac*ons
ACID
Par66on
tolerance:
Scaleout
infini
NO
GO
NoSQL
DB
Oracle
RAC
Availability
(Redondance
des
données)

8. La solution NoSQL
• Objec*fs
sont
différentsàRelaxa*on
de
certaines
contraintes
– DBMS:
Atomicity,
Consistency,
Isola*on,
Durability
(ACID)
– NoSQL
:
BASE
Basically
Available
:
le
système
semble
fonc*onner
à
tout
moment
;
So9
state
:
le
système
n’a
pas
à
être
cohérent
à
tout
instant
;
Eventually
consistent
:
la
cohérence
sera
assurée
ultérieurement
.
Source:
Eric
Brewer

9. BASE Vs. ACID
• Ges*on
de
la
cohérence
selon
3
paramètres
– N: Le nombre de copies d’une donnée qui seront maintenues (nombre
de réplications)
– R: Le nombre de copies qui seront interrogées lors d’une lecture
– W: Le nombre d’écritures à effectuer avant marquer l’insertion
comme complétée
Configuration NRW
Résultat
W=N R=1
Optimisé pour la lecture – cohérence forte
W=1 R=N
Optimisé pour l’écriture – cohérence forte
W+R<=N
Une lecture peut ne pas voir le dernier état de la
donnée – Eventually consistent – disponibilité forte
W+R>N
Une lecture recevra au moins une fois le dernier état
de la donnée – consistance forte
9

10. Qui ?
• U*lisé
par
«
les
géants
du
Web
»
pour
gérer
les
grands
ensembles
de
données
– Google
:
BigTable
– Amazon
:
Dynamo
–
Yahoo!
:
HBase
– Microsoq
:
Azure
Storage
– Facebook
:
Cassandra
-­‐
HBase
– LinkedIn
:
Voldemort
– ...

11. Quoi?
• Différents
modèles
de
données
en
fonc*on
de
l’applica*on
• DB
catégorisées
en
4
modèles
– Clé/Valeur
– Orienté
document
– Orienté
colonnes
– Orienté
graphe
• Extensions
du
modèle
clé/valeur
Colonne1
:
Valeur
Clé
Valeur
Clé
Colonne
2:
Valeur
Colonne
3
:
Valeur
BDD
Clé/Valeur
BDD
orientée
colonnes
Nœud
2
Champ1:
Valeur
Clé
Champ2:
Valeur
Champ3:
Valeur
Nœud
1
Nœud
3
Champ4:
Valeur
Nœud
4
BDD
orientée
document
BDD
orientée
graphe

12. Clé
Valeur
Stockage Clé-Valeur
• Une
clé
unique
dans
la
base
est
associée
à
une
valeur
arbitraire
(en
bits)
– Similaire
à
une
Hashtable
distribuée
• Accès
aux
données
très
efficaces
– Pour
des
mul*ples
accès
aléatoires
– A
une
donnée
spécifiée...
Si
on
en
connait
la
clé
• Idéalement
parallélisable
(+
réplica*on
possible)
• Cohérance
forte
en
jouant
sur
les
paramètres
NRW
• Scalabilité
linéaire
12

13. Champ1:
Valeur
Clé
Champ2:
Valeur
Champ3:
Valeur
Orientée documents
Champ4:
Valeur
• Chaque
champ
au
sein
d’un
document
est
accessible
• Grande
flexibilité
dans
la
structure
des
documents
– Un
schéma
pour
chaque
document
– Généralement
des
documents
XML/JSON
• Modèle
le
plus
proche
du
modèle
rela*onnel
• Ajout,
modifica*on,
lecture
ou
suppression
de
seulement
certains
champs
dans
un
document
(pas
pour
toutes
les
solu*ons)
13

14. Colonne1
:
Valeur
Clé
Colonne
2:
Valeur
Orientée colonnes
Colonne
3
:
Valeur
• Le
modèle
de
données
– Ensemble
de
tables
contenant
une
liste
de
clés
– A
chaque
clé
est
associée
un
ensemble
fixe
de
familles
de
colonnes
– Chaque
famille
de
colonnes
peut
contenir
une
nombre
indéterminé
de
colonnes
•
•
•
•
Structure
flexible
pour
les
tables
Bien
adapté
aux
rela*ons
one-­‐to-­‐many
Stockage
des
données
de
façon
ver*cale
Pas
de
coût
de
stockage
pour
les
valeurs
vide
/
«
null
»

15. Column
1
:
Value
Key
Column
2:
Value
Column
3
:
Value
3
Orientée colonnes

16. , A

17. • Vue
conceptuelle
de
la
table
,

18. #

20. • Vue
physique
de
la
table

21. Nœud
2
Nœud
1
Nœud
3
Graph oriented
Nœud
4
•
•
•
•
•
Représenta*on
des
données
sous
forme
d'un
graphe
Modèle
le
plus
“Human-­‐friendly”
U*les
quand
on
doit
faire
face
à
des
JOIN
en
chaîne
Idéales
pour
les
rela*ons
many-­‐to-­‐many
Algorithms
de
parcours
de
graphe
pour
explorer
la
BDD
(conduit
à
des
requêtes
complexes)
16

22. Les modèles NoSQL : résumé

23. Et le BigData?
• Scalabilité
au
niveau
– du
stockage
– de
la
capacité
de
traitement
• Volume
• Velocity,
vitesse
d’arrivée,
durée
de
traitement
• Variety,
hétérogénéité
• Et
encore
d’autres...
Variability,
validity,
veracity,
value
,
etc.
• Le
NoSQL
aide
à
tous
les
niveaux
de
la
pile
BigData

24. La pile BigData
BI
VISUALISATION
DATA
ANALYSIS
SCALABILITY
STORAGE
DATA
ACQUISITION
DATA
EXTRACTION
STRUCTURED
DATA
UNSTRUCTURED
DATA
WORKFLOW
PRE-­‐PROCESSING
AND
REQUEST

25. Traitement distribués
• Algorithme
Mapreduce
majoritairement
u*lisé
• Convient
parfaitement
aux
infrastructures
de
Cloud
Compu*ng
• Réduc*on
du
transfert
de
données
(share
nothing
architecture)
èLes
données
sont
traitées
là
où
elles
se
situent

26. Stockage scalable
• Systèmes
de
fichiers
distribués
– Pas
de
modèle
pré-­‐défini
– Agit
comme
un
système
de
fichier
classique
– Réplica*on
des
données
– Prêt
pour
du
traitement
en
parallèle
des
données
– Solu*ons
pour
ajouter
un
modèle
sur
les
données
• Hive
=
Requêtes
SQL
sur
les
fichiers
plats
distribués
• Bases
de
données
• RDBMS
distribués
• NoSQL

27. Pour moi ?
• Pas
de
conversion
directe
entre
un
système
rela*onnel
et
le
NoSQL
• Une
bonne
connaissance
de
l’applica*on
et
des
accès
aux
données
est
nécessaire
• Emploi
de
NoSQL
lié
au
besoin
…
…
pas
uniquement
aux
performances
• Pourquoi
pas
plusieurs
modèles
de
données
à
différents
niveaux
de
l’applica*on?
(solu*on
mixte)
• Les
bases
de
données
rela*onnelles
restent
de
bons
candidats
22

28. Merci
Aéropôle de Charleroi-Gosselies
Rue des Frères Wright, 29/3
B-6041 Gosselies
info@cetic.be
orlando.cassano@cetic.be
www.cetic.be