Téléchargé 43 fois
Téléchargé parMichaël Figuière
Lorraine JUG (dec 2010) - NoSQL, des grands du Web aux entreprises
Le document traite des bases de données NoSQL, soulignant leur rôle dans le paysage technologique moderne et leur complémentarité avec les SGBDR. Il aborde les concepts de scalabilité, disponibilité et résilience, illustrant avec des exemples comme Dynamo et Cassandra, ainsi que les défis posés par la gestion des données distribuées. Les cas d'usage de NoSQL dans les grandes entreprises montrent leur adoption croissante malgré des outils encore limités.
Lorraine JUG (dec 2010) - NoSQL, des grands du Web aux entreprises
- 1. NoSQL Des grands duWeb aux entreprises 08/12/2010
- 2. Speaker @mfiguiere blog.xebia.fr Michaël Figuière NoSQL UG JUGs
- 3. A propos deNoSQL No SQL
- 4. A propos deNoSQL Not Only No SQL
- 5. A propos deNoSQL Not Only No SQL Relational
- 6. Contrairement aux idéesreç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 casd’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 : naissancede 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 lascalabilité avec un SGBDR ? Mise en oeuvre typique avec MySQL Réplication synchrone ou asynchrone
- 10. Sharding avec unSGBDR
- 11. Sharding avec unSGBDR Sur serveur A Sur serveur B
- 12. Sharding avec unSGBDR Sur serveur A Sur serveur B ? ?
- 13. Sharding avec unSGBDR Sur serveur A Dénormalisation Sur serveur B Dénormalisation
- 14. Sharding avec unSGBDR Sur serveur A Dénormalisation Sur serveur B Dénormalisation On perd alors beaucoup de l’intérêt du relationnel !
- 15. Sharding avec unSGBDR : 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 dehachage à une BDD clé-valeur Ensemble des clés partitionnées selon leur préfixe
- 17. D’une table dehachage à une BDD clé-valeur Ensemble des clés Consistent hashing
- 18. D’une table dehachage à une BDD clé-valeur Une partition par Multiples partitions instance par instance
- 19. Organisation des noeudsen anneau Noeud Noeud Noeud Noeud Noeud Replica Noeud Partition 1 Replica Replica Partition 2 Partition N
- 20. Organisation des noeudsen 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 noeudsen 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 BDDNoSQL 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 nombrede réponses attendues Temps A A A A 4 réplicas
- 28. Consistance selon nombrede 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 nombrede 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 nombrede 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 nombrede 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 pourle 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 surun 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éesorientées clé-valeur = HashMap !
- 36.
- 37. Base de donnéesorientées document La BDD est consciente du contenu. Les requêtes complexes sont possibles
- 38.
- 39. Base de donnéesorientées colonnes A chaque ID de ligne correspond une liste de couples clé-valeur BDD relationnelle BDD orientée colonnes
- 40.
- 41. A propos deCassandra
- 42. Base de donnéesorientées graphe
- 43.
- 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.