Présentation de NoSQL par Orlando Cassano, Senior Engineer R&D au Cetic. http://www.cetic.be Présenté le 28 janvier 2014 à Louvain-la-Neuve

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