1. NoSQL
Des grands du Web aux entreprises
08/12/2010

2. Speaker
@mfiguiere
blog.xebia.fr
Michaël Figuière
NoSQL UG
JUGs

3. A propos de NoSQL
No SQL

4. A propos de NoSQL
Not Only
No SQL

5. A propos de NoSQL
Not Only
No SQL
Relational

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

10. Sharding avec un SGBDR

11. Sharding avec un SGBDR
Sur serveur A
Sur serveur B

12. Sharding avec un SGBDR
Sur serveur A
Sur serveur B
?
?

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

21. Interactions Client / Serveur
Client Noeud Noeud
Client
Noeud
Noeud
Client
Client Noeud
Noeud

22. Interactions Client / Serveur
Client
Client
? Noeud Noeud
replica
Noeud Noeud
replica
Client
Noeud
Client replica 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

27. Consistance selon nombre de réponses attendues
Temps
A A A A
4 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é

35. Base de données orientées clé-valeur
= HashMap !

36. Exemple avec Riak

37. Base de données orientées document
La BDD est consciente du
contenu. Les requêtes
complexes sont possibles

38. Exemple avec MongoDB

39. Base de données orientées colonnes
A chaque ID de ligne correspond
une liste de couples clé-valeur
BDD relationnelle BDD orientée colonnes

40. Exemple avec Cassandra

41. A propos de Cassandra

42. Base de données orientées graphe

43. Exemple avec Neo4j

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

48. Questions / Réponses
?