6. Contrairement aux idées reçues
• NoSQL n’est pas un remplaçant des SGBDR
The right tool for the right job
• NoSQL reste un domaine d’innovation
Mais déjà déployé en production !
• NoSQL est un écosystème riche et complexe
« Le diable est dans le détail »
7. Au commencement
Des cas d’usage différents mais des
besoins similaires : - Création de Dynamo
- Dernier incident majeur en 2004
• Performance
- < 40 min d’indisponibilité par an
• Disponibilité (> 99.99 %)
• Résilience
• Scalabilité horizontale
- Création de BigTable + MapReduce
- Toutes les pages Web du monde
- Fonctionnement online et offline
8. Amazon : naissance de Dynamo
Besoin en requêtes complexes,
indisponibilité temporaire acceptable
Fill cart Checkout Payment Process order Prepare Send
Stockage clé-valeur suffisant,
disponibilité en écriture
9. Comment assurer la scalabilité avec un SGBDR ?
Mise en oeuvre
typique avec MySQL
Réplication
synchrone ou
asynchrone
13. Sharding avec un SGBDR
Sur serveur A Dénormalisation
Sur serveur B
Dénormalisation
14. Sharding avec un SGBDR
Sur serveur A Dénormalisation
Sur serveur B
Dénormalisation
On perd alors beaucoup de l’intérêt du relationnel !
15. Sharding avec un SGBDR : les problèmes
• Pour garder de bonnes performances, les relations many-to-many et
many-to-one nécessitent d’être dénormalisées
• Gestion du resharding
• Code applicatif complexifié
16. D’une table de hachage à une BDD clé-valeur
Ensemble des clés
partitionnées selon
leur préfixe
17. D’une table de hachage à une BDD clé-valeur
Ensemble des clés
Consistent hashing
18. D’une table de hachage à une BDD clé-valeur
Une partition par Multiples partitions
instance par instance
19. Organisation des noeuds en anneau
Noeud Noeud
Noeud
Noeud
Noeud Replica
Noeud Partition 1
Replica Replica
Partition 2 Partition N
20. Organisation des noeuds en anneau
Noeud Noeud
Communication de
Noeud
proche en proche
Noeud
pour diffuser les
changements de
topologie
Noeud
Noeud
23. Organisation des noeuds en anneau
Client Noeud Noeud
replica
Client
Noeud Noeud
replica
Client
Noeud
Client replica Noeud
Agit en tant
que proxy
24. Que devient ACID ?
• Tout accès réseau est faillible
• Des concessions doivent être faites sur le modèle de données
• Des concessions doivent être faites sur la consistance
25. Le théorème CAP
BDD NoSQL BDD relationnelles
Consistance
Disponibilité
Tolérance
aux défaillances Impossible
26. Consistance éventuelle
Client Noeud Noeud
replica
Client
Noeud Noeud
replica
Client
Noeud
Client replica Noeud
Transfère les requêtes R/W
vers tous les réplicas
28. Consistance selon nombre de réponses attendues
Temps
A A A A
4 réplicas B A A A
Ecriture avec attente
d’accusé d’un seul noeud
29. Consistance selon nombre de réponses attendues
Temps
R+W<N
A A A A
4 réplicas B A A A
B A A A
Lecture avec attente de Ecriture avec attente
réponse de 2 noeuds d’accusé d’un seul noeud
30. Consistance selon nombre de réponses attendues
R+W=N
A A A A
B B A A
B B A A
Lecture avec attente de Ecriture avec attente
réponse de 2 noeuds d’accusé de 2 noeuds
31. Consistance selon nombre de réponses attendues
R+W>N
A A A A
B B B A
B B B A
Lecture avec attente de Ecriture avec attente
réponse de 3 noeuds d’accusé de 2 noeuds
32. Consistance apparente pour le client
1
Client Noeud Noeud
2 replica
3
Client
4 2
Noeud Noeud
3 replica
Client
3 2
Noeud
Client replica Noeud
Transfère les requêtes R/W
vers tous les réplicas
33. Atomicité et Isolation
• Les données ne sont plus co-localisées
Localisation non prédictible dans le temps
• Les transactions distribuées nuiraient à la disponibilité et aux performances
• Atomicité et Isolation par opération sur une clé
34. Durabilité
• Ecriture sur un ou plusieurs disques
La réplication permet de renforcer la durabilité
• Ecriture multiples en mémoire
La réplication apporte la durabilité
• En mémoire avec écriture asynchrone sur disque
Pas de durabilité
44. L’intérêt pour l’entreprise
• Stockage polyglotte : une meilleure adéquation entre la BDD et les données
• Scalabilité linéaire : être à même de répondre aux besoins les plus gourmands
• Haute disponibilité : du multi-serveurs au multi-datacenters
• Elasticité : une intégration naturelle à la logique du Cloud Computing
• Curseur pour s’adapter : + de consistence ou + de fiabilité (R + W > N)
• Et finalement... la possibilité crée le besoin !
45. NoSQL en production ?
• En production chez de nombreux « Grands du Web »
• Outillage encore réduit
• Monitoring par JMX
• Backups peuvent être problématiques avec des volumes importants
46. Cas d’usage : batch distribué
Stockage des
informations en Traitement batch
production distribué
Application HBase Hadoop
Exploitation Stockage
des résultats des résultats
47. Cas d’usage : stockage polyglotte
Recherche des
Lucene
produits
Stockage du
catalogue produits MySQL
Application
Stockage des
Cassandra
comptes clients
Stockage de
Redis
données de sessions