NoSQL : hype ou innovation

Transcription

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
Primum
Relationalus
Adabasolite databasauris
2000
2010
Columnus
NoSQLausis KeyValueraptor
IBM LOTUS
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
en 1992 pour les
systèmes distribués CA
asynchrones
Choisissez-en deux  C
A
AP
CP
P
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 peutelle 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
CAP
VS
Simple
Flou
PACELC
Complexe
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
consistency
− Durability
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
Modulo 3
- 934
- 327, 395, 471
Serveur 0 Serveur 1 Serveur 2
327, 471
Modulo 5
-
- 352, 934
- 395
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
N81
N11
N91
N21
N71
N31
N61
N51
N41
N11
N21
N81
N31
N71
N41
N61
N51
26
Octobre 2011
Partitionnement
• Pondération des noeuds
N1-1
N1-1
C
A
C
A
N3-2
N2-1
B
N2-1
B
27
Octobre 2011
Partitionnement
• Consistent hashing +
réplication
• Relativement simple
• Chaque nœud sait
où se trouve
N4-1
chaque donnée
N1-1
A
G
B
C
B
F
D
A
E
G
C
N2-1
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)
Inst 1
Inst 4
• Let’s go…
Inst 2
Inst 5
Inst 3
Inst 6
29
Octobre 2011
Quorum (éventuellement consistant)
SE = 3
SL = 2
Inst 1
Inst 2
Inst 3
Inst 4
Inst 5
Inst 6
Inst 1
Inst 2
Inst 3
Inst 4
Inst 5
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
SL
Lectures rapides
X
32
Octobre 2011
Plus complexe en pratique
Inst 1
Inst 2
Inst 3
Inst 4
Inst 5
Inst 6
Inst 1
Inst 2
Inst 3
Inst 4
Inst 5
Inst 6
Inst 1
Inst 2
Inst 3
Inst 4
Inst 5
Inst 6
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
MySQL
Vertica
Oracle
Postgres
K/V
COL
KAI
Voldemort
Dynamo
Cassandra
HypergraphDB
CouchDB
FlockDB
Riak
SimpleDB
REL
DOC
Hbase
Hypertable
Terrastore
GR
BigTable
MongoDB
Berkeley DB
Scalaris
Redis
MemcacheDB
38
Octobre 2011
• CA – AP – CP
• K/V – COL – DOC – GR
• 12 types de DB…
• … diverses architectures et modes
de fonctionnement par type
© http://www.paramount.com/
39
Octobre 2011
Tokyo Cabinet
NEO4J
MySQL
Vertica
Oracle
Postgres
K/V
COL
KAI
Voldemort
Dynamo
Cassandra
HypergraphDB
CouchDB
FlockDB
Riak
SimpleDB
REL
DOC
Hbase
Hypertable
Terrastore
GR
BigTable
MongoDB
Berkeley DB
Scalaris
Redis
MemcacheDB
40
Octobre 2011
Tokyo Cabinet
Cassandra
NEO4J
MemcacheDB
Redis
CouchDB
K/V
COL
DOC
GR
Hypertable
FlockDB
MongoDB
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
Clé
A
C
Valeur
B
D
RDBMS
Clé
A
C
Valeur
B
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
K1
C1 : V
C2 : V
C3 : V
K2
C1 : V
C3 : V
C6 : V
K
=
C
= Column
V
=
Key
Value
C8 : V
46
Octobre 2011
Parfois possible d'avoir un
niveau de hiérarchie
supplémentaire (super
colonnes)
K
C1 : V
C2 : V
C3 : V
C4 : V
K
=
C
= Column
V
=
Key
Value
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
A
E
B=1
F=4
C=2
D=3
G=5
Node
A
E
B
C
D
F
G
Father
NULL
NULL
A
A
A
E
E
Value
NULL
NULL
1
2
3
4
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
Documents structurés sans
schémas prédéfinis
F1 : V
= Field
V
= Value
K
=
Key
F1 : V
F2 : V, V, V
K
F
F3 : V
F2 : V
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
Node Father
Value
de formulaires)
A
NULL
NULL
NoSQL doc
A
B=1
C=2,D=3
H=6
F=4,G=5
I=7,J=8,K=9
L=10,M=11
B
CD
C
D
FG
F
G
H
IJK
I
J
K
LM
L
M
A
A
NULL
NULL
CD
NULL
NULL
A
H
NULL
NULL
NULL
IJK
NULL
NULL
1
NULL
2
3
NULL
4
5
NULL
NULL
7
8
9
NULL
10
11
RDBMS
Node
C
D
F
G
I
J
K
L
M
MemberOf
CD
CD
FG
FG
IJK
IJK
IJK
LM
LM
54
Octobre 2011
• DEMOS
CouchDB
K/V
COL
DOC
GR
MongoDB
55
Octobre 2011
NoSQL : Solutions orientées graphes
N
Graphes orientés
= Noeud
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
A
H
E
D
Src Dst
A B
B D
C B
C D
D A
B
J
C
G
I
RDBMS
Rel
E
G
I
J
H
F
58
Octobre 2011
NoSQL : Orientées graphes
© http://www.foxmovies.com/
• DEMOS
NEO4J
K/V
COL
DOC
GR
FlockDB
59
Octobre 2011
NoSQL : Récapitulatif
K/V
Key
K
COL
Value
F1 : V
F2 : V, V, V
F3 : V
F4 : V, V
F5 : V
F6 : V
DOC
K1
C1 : V
C2 : V
C3 : V
N2
N1
N3
N5
N4
GR
60
Octobre 2011
K/V
Cache site Web
Stockage données
élémentaires
Documents complexes
(DMFA, profils utilisateurs,
cache de données
structurées )
DOC
COL
Données chronologiques
(log système, dossier
médical)
Relations One-to-Many
Gérer des relations
complexes et dynamiques
(ontologies, relations
personnes/administrations)
GR
61
Octobre 2011
Tokyo Cabinet
NEO4J
MySQL
Vertica
Oracle
Postgres
K/V
COL
KAI
Voldemort
Dynamo
Cassandra
HypergraphDB
CouchDB
FlockDB
Riak
SimpleDB
REL
DOC
Hbase
Hypertable
Terrastore
GR
BigTable
MongoDB
Berkeley DB
Scalaris
Redis
MemcacheDB
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
MySQL
Vertica
Oracle
Postgres
K/V
COL
KAI
Voldemort
Dynamo
Cassandra
HypergraphDB
CouchDB
FlockDB
Riak
SimpleDB
REL
DOC
Hbase
Hypertable
Terrastore
GR
BigTable
MongoDB
Berkeley DB
Scalaris
Redis
MemcacheDB
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

Transcription

Documents pareils

Responsable Informatique

Evaluez vos cotisations - Pajemploi

Logiciel Caneco HT

Fiche profil ITRF IGR2 ExpertDev2016

Contrat de Prêt entre la BOAD et la société de gestion du Bénin

Introduction aux systèmes NoSQL (Not Only SQL)

Parvis de la defense - Archives orales

Education Physique Et Sport Dans L Enseignement Secondaire

m´emoire de stage de master m2

NFE204 - Bases documentaires et NoSQL