NoSQL - Hype Ou Innovation

NoSQL : hype ou
innovation ?
Grégory Ogonowski / Recherches

Octobre 2011
Octobre 2011
Sommaire
• Introduction
• Théorème CAP
• NoSQL (principes, mécanismes,
démos,...)
• Ce que nous avons constaté
• Recommandations
• Conclusion
2
Octobre 2011
Introduction
• Bases de données relationnelles :

− Solutions mûres et maîtrisées
− Robustes
− Ont fait leurs preuves
• Pourquoi s'embêter avec autre chose ???

UID NOM Prénom UID GID GID Groupe
1 Jagger Mick 1 2 1 Beatles
2 Harrison George 2 1 2 Rolling Stones
3 Starr Ringo 3 1
3
Octobre 2011
Introduction : impact du Web 2.0
1970 1990 2000 2010
Columnus
Primum Relationalus
IBM LOTUS NoSQLausis KeyValueraptor
Adabasolite databasauris
Dominosaurus Armageddon NoSQLausis
2.0
Graphosis
NoSQLausis
Documentaris
!!! N'ont pas disparu et NoSQLausis
ne disparaîtront pas !!!
Smalsopithecus
4
Octobre 2011
• Énorme masse d'utilisateurs

• Gros volumes de données à gérer
(hype Big Data)
• Contraintes différentes :
− Scalabilité > Consistance
− Disponibilité > Consistance
5
Octobre 2011
• Facebook:
− Pic de 13 000 000 req db/sec
− 690 milliards de pages vues/mois
− 300 To de données… en cache mémoire
− 25 To de logs par jour
− 1 ingénieur/1,1 millions d’utilisateurs
6
Octobre 2011
Théorème CAP
• Consistency,
Availability,
Partition tolerant
• Conjecture, démontrée A
en 1992 pour les
systèmes distribués CA AP
asynchrones
Choisissez-en deux  C P
CP
7
Octobre 2011
Théorème CAP : Consistency
Tous les
utilisateurs ont
toujours la même
vue sur toutes les
données
8
Octobre 2011
Théorème CAP : Availability
Est-il toujours
possible de lire
des données et
d'en écrire ?
9
Octobre 2011
Théorème CAP : Partition tolerant
L'application peut-
elle survivre à un
partitionnement
du réseau ?
10
Octobre 2011
Théorème CAP
C : OK
A – P : Redondants ?
 CAP theorem =?= CRAP theorem
11
Octobre 2011
Théorème CAP
Autre approche : PACELC
"if there is a partition (P) how does the

system tradeoff between availability and
consistency (A and C); else (E) when the
system is running as normal in the absence
of partitions, how does the system tradeoff
between latency (L) and consistency (C) ? "
Ex : PA/EL
12
Octobre 2011
Théorème CAP VS PACELC
VS
CAP PACELC
Simple Complexe
Flou Clair
© http://buzzworld.fr/
Deux manières différentes pour exprimer la
même chose.
13
Octobre 2011
NoSQL : C’est quoi ?
• Catégorie de Bases de Données
• NoSQL = No SQL Not only SQL

(Structured Query Language)
Ex : SELECT champ1, champ2 FROM
table;
14
Octobre 2011
NoSQL : C’est quoi ?
• Souvent
− très scalables
− non-relationnelles
− très spécifiques
− sans schéma
15
Octobre 2011
NoSQL : ACID VS BASE
CAP = On ne peut pas tout avoir

• ACID • BASE
− Atomicity − Basically Available
− Consistency − Soft state
− Isolation − Eventual
− Durability consistency
Souvent choisi pour

NoSQL 16
Octobre 2011
NoSQL : Qui utilise ça ???
• Facebook, Twitter, Google, bit.ly,

Springer, Amazon, digg, IBM,
LinkedIn, Rackspace, sourceforge, …
• Globalement : des sites à très forte

consultation
• Mais aussi de nombreux sites Web en

tant que cache !
17
Octobre 2011
NoSQL : Et ça marche ?
• Oui mais…
18
Octobre 2011
NoSQL : Et ça marche ?
• Oui mais…
• … pas une solution miracle
• Plusieurs mécanismes (souvent
simples) pour améliorer la scalabilité
et/ou la haute disponibilité
19
Octobre 2011
NoSQL : Quelques mécanismes
Partitionnement
Réplication (+ Quorum)
20
Octobre 2011

Partitionnement
• Découpage des
données en vue de
les distribuer
• Pas nouveau
• Mais… différentes
manières de procéder
21
Octobre 2011

Réplication
• Au moins deux
instances de chaque
donnée
• Pas nouveau
• Mais… différentes
manières de procéder
22
Octobre 2011

Partitionnement
• Traditionnellement : un "simple" modulo sur

la clé pour déterminer l'emplacement d'une
donnée
• Chaque nœud sait où se trouve chaque
donnée
127 127 % 4 = 3
Serveur 0 Serveur 1 Serveur 2 Serveur 3
23
Octobre 2011

Partitionnement
• En cas d'ajout ou de retrait d'un serveur,

besoin de tout recalculer  pas évident à
rendre scalable
Modulo 4 Serveur 0 Serveur 1 Serveur 2 Serveur 3

352 - - 934 - 327, 395, 471
Modulo 3 Serveur 0 Serveur 1 Serveur 2
327, 471 - 352, 934 - 395
Modulo 5 Serveur 0 Serveur 1 Serveur 2 Serveur 3 Serveur 4
395 - 471 - 327, 352 - - 934
24
Octobre 2011

Partitionnement
• Consistent hashing
N1-1
C A
N2-1 B
25
Octobre 2011

Partitionnement
• Ajout d’un noeud : ajustements minimes

N1- N1-
1 1
N8- N2- N9- N2-
1 1 1 1
N8- N3-
N7- N3- 1 1
1 1
N7- N4-
N6- N4- 1 1
1 1
N5- N6- N5-
1 1 1
26
Octobre 2011

Partitionnement
• Pondération des noeuds
N1-1
N1-1
C A C A
N3-2 N2-1
N2-1 B B
27
Octobre 2011

Partitionnement
• Consistent hashing +
N1-1
réplication
A
• Relativement simple
G C B
• Chaque nœud sait B D
où se trouve
N4-1 N2-1
chaque donnée F A E C
G F
E D
N3-1
28
Octobre 2011

Quorum (finalement consistant)
• Seuils de lecture (SL) et d’écriture

(SE)
• Un petit exemple ? 
• Hypothèse : 6 copies de chaque
donnée (#C = 6)
• Let’s go… Inst 1 Inst 4
Inst 2 Inst 5
Inst 3 Inst 6
29
Octobre 2011

Quorum (éventuellement consistant)
SE = 3 SL = 2
Inst 1 Inst 1
Inst 2 Inst 2
Inst 3 Inst 3
Inst 4 Inst 4
Inst 5 Inst 5
Inst 6 Inst 6
30
Octobre 2011

• Données finalement consistantes

• Paramétrisation possible
Si (SL + SE > #C) alors Si (SL < SE) alors

données consistantes lectures rapides
Sinon Sinon si (SL > SE) alors
données finalement écritures rapides
consistantes Sinon
même vitesse pour
écriture et lecture
31
Octobre 2011

X
SL + SE
Performances Consistance
SE Ecritures rapides
X
SL Lectures rapides
32
Octobre 2011

Plus complexe en pratique
Inst 1 Inst 1 Inst 1

33
Octobre 2011

• Vector clocks
• …
• Laissons cela en
annexe
34
Octobre 2011
NoSQL : Bases de données

traditionnelles
Grands tableaux avec relations

FF 11 11 0A
GG 44 55 7B
HH 55 66 4C
II 77 99 5M
GG 0A
FF 8Z
TT 4P
NN 5M
35
Octobre 2011
NoSQL : une grande famille
• Clé / Valeur
− (K/V)
• Orientées colonnes
− (COL)
• Orientées documents
− (DOC)
• Orientées graphes
− (GR) K/V COL
DOC GR
© http://www.paramount.com/ 36
Octobre 2011
NoSQL : caractérisation
REL = RDBMS
37
Octobre 2011
http://blog.nahurst.com/visual-guide-to-nosql-systems
Tokyo Cabinet
NEO4J KAI Voldemort
MySQL Vertica Dynamo Cassandra
Oracle Postgres HypergraphDB CouchDB
FlockDB Riak
K/V COL
SimpleDB
REL
DOC GR
Hbase Hypertable BigTable Berkeley DB Redis
Terrastore MongoDB Scalaris MemcacheDB

38
Octobre 2011
• CA – AP – CP
• K/V – COL – DOC – GR
• 12 types de DB…
• … diverses architectures et modes © http://www.paramount.com/
de fonctionnement par type
39
Octobre 2011
Tokyo Cabinet
NEO4J KAI Voldemort
FlockDB Riak
K/V COL
SimpleDB
REL
DOC GR

40
Octobre 2011
Tokyo Cabinet
Cassandra
NEO4J
CouchDB
K/V COL FlockDB
DOC GR
MemcacheDB Hypertable MongoDB
Redis
41
Octobre 2011
NoSQL : Clé-Valeur
Grandes tables de hachages
Key Value
42
Octobre 2011
NoSQL : Clé-Valeur
• Caractéristiques :
− Simples
− Interface pauvre (peu de commandes)
− Très performantes
• Remarques :
− Partitionnement des données pas toujours pris
en charge par la DB
43
Octobre 2011
NoSQL : Clé-Valeur
• Pour que faire :

− Cache d’un site web
− Stockage de données élémentaires
NoSQL K/V RDBMS

Clé Valeur Clé Valeur
A B A B
C D C D
44
Octobre 2011
NoSQL : Clé-Valeur
• DEMOS
Tokyo Cabinet
K/V COL
DOC GR
MemcacheDB
Redis
45
Octobre 2011
NoSQL : Solutions orientées colonnes
Longues listes variées K = Key

C = Column
V = Value
K1 C1 : V C2 : V C3 : V
K2 C1 : V C3 : V C6 : V C8 : V
46
Octobre 2011
Parfois possible d'avoir un K = Key

niveau de hiérarchie C = Column
supplémentaire (super
V = Value
colonnes)
K C1 : V C2 : V C3 : V C4 : V C5 : V
47
Octobre 2011
− Gestion d'un très grand nombre de colonnes
(plusieurs millions)
− Requêtes minimalistes
• Remarques :
− Absolument pas prévu pour le relationnel 
difficile à exploiter pour les gens habitués aux
RDBMS
48
Octobre 2011

− Stockage de données chronologiques (ex : log
système, evolution d’un dossier médical)
− Relations one-to-many (ex : gérer des droits
d’accès)
NoSQL Col RDBMS
Node Father Value
A E A
E
NULL
NULL
NULL
NULL
B A 1
B=1 F=4 C A 2
D A 3
C=2 F E 4
G E 5
D=3 G=5
49
Octobre 2011
• DEMOS
Cassandra
K/V COL
DOC GR
Hypertable
50
Octobre 2011
Pause
A := #persons_before_pause
B := #persons_after_pause
IF A > B THEN
presentation_quality := bad
ELSE
presentation_quality := normal
IF B > A THEN
attenders_punctuality := bad
INSERT "Coffee" INTO "Hall";
51
Octobre 2011
NoSQL : Solutions orientées documents
F = Field
Documents structurés sans
schémas prédéfinis V = Value
K = Key
F1 : V
F1 : V
F2 : V, V, V
F2 : V
F3 : V
K K F3 : V, V
F4 : V, V
F4 : V
F5 : V
F5 : V
F6 : V
52
Octobre 2011
− Très flexibles
− Syntaxe parfois très riche
− Bien adapté au monde du Web
53
Octobre 2011

− Gérer des données avec des structures
complexes et variables (DMFA, profils
utilisateurs complexes)
− Cache de données structurées (manipulation
de formulaires) Node Father Value
A NULL
B
NULL
A 1
RDBMS
CD A NULL
NoSQL doc C NULL 2 Node MemberOf
D NULL 3 C CD
FG CD NULL D CD
A F NULL 4 F FG
G NULL 5 G FG
H A NULL
B=1 C=2,D=3 H=6 I IJK
IJK H NULL
I NULL 7 J IJK
F=4,G=5 I=7,J=8,K=9 J NULL 8 K IJK
K NULL 9 L LM
LM IJK NULL M LM
L=10,M=11 L NULL 10
M NULL 11 54
Octobre 2011
• DEMOS
CouchDB
K/V COL
DOC GR
MongoDB
55
Octobre 2011
NoSQL : Solutions orientées graphes
N = Noeud
Graphes orientés
N2
N1 N3
N5 N4
56
Octobre 2011
• Caractéristiques
− Parfois optimisées pour la résolution de
problèmes complexes et non pour les
performances
• Remarque
− Peu de solutions intéressantes à ce jour
57
Octobre 2011

− Gérer des relations complexes et dynamiques
(ontologies, relations entre personnes,
administrations, …)
NoSQL graph RDBMS

E Src Dst Rel
A
H A B E
B D G
C B I
D B
C D J
D A H
J C I
F
58
G
Octobre 2011
NoSQL : Orientées graphes

© http://www.foxmovies.com/
• DEMOS
NEO4J
K/V COL FlockDB
DOC GR
59
Octobre 2011
NoSQL : Récapitulatif
K/V COL
Key Value K1 C1 : V C2 : V C3 : V
F1 : V N2
F2 : V, V, V
F3 : V N1 N3
K
F4 : V, V
F5 : V
F6 : V N5 N4
DOC GR
60
Octobre 2011
K/V COL
Données chronologiques
Cache site Web
(log système, dossier
Stockage données
médical)
élémentaires
Relations One-to-Many
Documents complexes Gérer des relations

(DMFA, profils utilisateurs, complexes et dynamiques
cache de données (ontologies, relations
structurées ) personnes/administrations)
DOC GR
61
Octobre 2011
Tokyo Cabinet
NEO4J KAI Voldemort
FlockDB Riak
K/V COL
SimpleDB
REL
DOC GR

62
Octobre 2011
Ce que nous avons constaté
• Outils très spécifiques et efficaces dans leur

domaine
• Maturité très variable
d’une solution à l’autre
• Installation et prise en main
aisées
• Peu ou pas d’outils tiers
(incompatible avec
l’existant ?)
63
Octobre 2011
• Se méfier des benchmarks :

− Solutions très spécifiques
− Nécessité de réaliser des benchmarks
exploitant les spécificités des bases de
données testées
− Topologie réseau propre à chaque DB
64
Octobre 2011
• Ne pas négliger la documentation

• Limitations parfois inattendues :
− 4Mo pour
un objet MongoDB,
− 1Mo pour
un object Memcached
− Pas de redéfinition
de colonnes
dans Cassandra
− …
65
Octobre 2011
• Réception auprès des utilisateurs
• Incompréhension • Réticence
66
Octobre 2011
Recommandations
• NoSQL n’est pas un objectif en

soi
• Ne répond pas à tous les

problèmes
• A utiliser uniquement si les

SGBDR ne conviennent pas :
− Trop lents
− Données difficiles à modéliser
− Données difficiles à exploiter
− Format des données variable
© http://www.misterandyriley.com/ 67
Octobre 2011
Recommandations
• Adapter la BD au format des données et non

le contraire
• NE PAS PENSER RELATIONNEL (surtout lors

de la définition du modèle de données)
• Peut être utilisé conjointement

à un RDBMS
68
Octobre 2011
Recommandations (Choix d’une

solution)
Tokyo Cabinet
NEO4J KAI Voldemort
FlockDB Riak
K/V COL
SimpleDB
REL
DOC GR

69
Octobre 2011
Conclusion
• Bases de données NoSQL : une alternative sérieuse au

modèle relationnel ?
• Alternative : non ! (permettent de résoudre des

problèmes différents)
• Sérieux : oui ! (même Oracle va proposer sa solution

NoSQL)
• A utiliser si les bases de données relationnelles se

montrent inefficaces/trop complexes.
70
Octobre 2011
Conclusion
• Beaucoup de solutions, mais très spécifiques
• Ne pas négliger la formation et la

documentation
• Ne pas toujours penser relationnel
• Ne pas toujours penser relationnel !
71
Octobre 2011
Conclusion
• NoSQL : hype ou innovation ?
• Hype et innovation
• Potentiel réel et non négligeable
• Téléchargez, jouez un peu, faites-vous une

idée avant d’essayer ou de dire non ;-)
72
Octobre 2011
Questions ?
SELECT "Questions" FROM "Public";

DELETE FROM "Public";
73

NoSQL - Hype Ou Innovation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NoSQL - Hype Ou Innovation

Uploaded by

Copyright:

Available Formats

NoSQL : hype ou

Grégory Ogonowski / Recherches

• Bases de données relationnelles :

• Pourquoi s'embêter avec autre chose ???

Introduction : impact du Web 2.0

1970 1990 2000 2010

Introduction : impact du Web 2.0

• Énorme masse d'utilisateurs

Introduction : impact du Web 2.0

Théorème CAP : Consistency

Théorème CAP : Availability

Théorème CAP : Partition tolerant

 CAP theorem =?= CRAP theorem

Autre approche : PACELC

"if there is a partition (P) how does the

Théorème CAP VS PACELC

NoSQL : C’est quoi ?

• Catégorie de Bases de Données

• NoSQL = No SQL Not only SQL

NoSQL : C’est quoi ?

NoSQL : ACID VS BASE

CAP = On ne peut pas tout avoir

Souvent choisi pour

NoSQL : Qui utilise ça ???

• Facebook, Twitter, Google, bit.ly,

• Globalement : des sites à très forte

• Mais aussi de nombreux sites Web en

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

• Traditionnellement : un "simple" modulo sur

Serveur 0 Serveur 1 Serveur 2 Serveur 3

NoSQL : Quelques mécanismes

• En cas d'ajout ou de retrait d'un serveur,

Modulo 4 Serveur 0 Serveur 1 Serveur 2 Serveur 3

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

• Ajout d’un noeud : ajustements minimes

NoSQL : Quelques mécanismes

• Pondération des noeuds

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

• Seuils de lecture (SL) et d’écriture

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

• Données finalement consistantes

Si (SL + SE > #C) alors Si (SL < SE) alors

NoSQL : Quelques mécanismes

NoSQL : Quelques mécanismes

Plus complexe en pratique

Inst 1 Inst 1 Inst 1

NoSQL : Quelques mécanismes

NoSQL : Bases de données

Grands tableaux avec relations

NoSQL : une grande famille

NEO4J KAI Voldemort

MySQL Vertica Dynamo Cassandra

Oracle Postgres HypergraphDB CouchDB

Hbase Hypertable BigTable Berkeley DB Redis

Terrastore MongoDB Scalaris MemcacheDB

• K/V – COL – DOC – GR

de fonctionnement par type