Un petit tour du côté du NoSQL

Rapide vue d'ensemble du NoSQL lors du hackhaton de l'IUT-BM du 13 février 2014

Transcript

1. Un petit tour du côté du NoSQl FELD Boris - IUT-BM 13 février 2014
2. About ME • Python Dev • DevOps • NoSQL fan • @lothiraldan
3. Mon parcours • UTBM, 2 Google Summer Of Code • 1 stage de 6 mois chez Dailymotion • Mise en place d’une infrastructure de tests • 1 stage de 6 mois chez Novapost puis 9 mois • Automatisation de l’infrastructure
4. Mon parcours • 6 mois chez Tinyclues • Automatisation de l’infrastructure • Création d’outils en interne • Réflexion sur les processus internes et la culture d’entreprise
5. Welcome in DB world!
6. From RDBMS… • Comment stocker les données ? • Adapté aux données relationnelles. • Concepts maîtrisés et éprouvés. • Solution robustes et matures.
7. Pourquoi NoSQL ?
8. Limites du modèle SQL • Difficulté de modéliser certaines structures de données : • Graphes • Arbres • Enregistrements complexes (compte utilisateur) • Schéma coûteux à designer. • Architecture ancienne. • Difficultés de mise à l’échelle…
9. Scalabilité du modèle relationnel • Scalabilité verticale le plus souvent (== plus grosses machines). • Modèle de réplication master - slave quand disponible sur les solutions open-source. • Des plugins disponibles au-dessus des solutions, mais pas de solutions intégrées. • Difficulté de mise à l’échelle de la capacité d’écriture et la perte du master est souvent problématique.
10. Explosion du web
11. NoSQL • Mouvement qui a vraiment percé en 2009 par les grands du Web, Google, Yahoo, etc. • Au début Not SQL. • Maintenant plutôt Not only SQL.
12. ACID • Atomic – Une transaction s’applique complètement ou pas du tout. • Consistent – Une transaction ne peut rompre les contraintes d’intégrité de la base, qu’elle soit en succès ou non. • Isolated – Les résultats d’une transaction ne sont pas visibles tant que la transaction n’est pas terminée. • Durable – Le résultat des transactions en succès survivent à une panne ou à une transaction en échec.
13. From ACID to CAP
14. Les promesses du NoSQL • Volume de données plus importants. • Meilleures performances. • Meilleure scalabilité horizontale. • Sacrifie la consistance (la valeur n’est pas toujours la dernière disponible). • Schema-less. • Plus dev-friendly.
15. « Inconvénients » • Le plus souvent pas de join à la SQL. • Pas de transactions inter-enregistrements. • Nouvelle manière de penser son schéma. • La dénormalisation est entrée dans les mœurs.
16. Recherche • Recherche classique, on envoie une recherche au serveur et on récupère les résultats. • Requête en JSON-like. • SQL-Like. • Langage dédie (Cypher). • Map / Reduce, méthode de traitement de masse des données. • Materialized Map / Reduce.
17. NoSQL Taxonomy
18. Clé / Valeur Clé Valeur Foo … Bar …
19. Clé / Valeur • La base de tout, toute base de données peut être implémentée au-dessus d’une base de données clé / valeur. • La valeur est arbitraire, soit un contenu binaire (string) soit un contenu plus structuré. • Très bonnes performances.
20. Redis • L’une des bases clé / valeur la plus connue. • Les valeurs sont structurées (liste, arbre, etc…). • Non distribuée. • Superbe documentation.
21. Requêtes >>> import redis >>> r = redis.StrictRedis(host='localhost', port=6379, db=0) >>> r.set('foo', 'bar') True >>> r.get('foo') 'bar' Deux types de requêtes principalement : • Set • Get
22. SimpleDB • Hebergé par Amazon. • Massivement distribué. • Opérations de mises à jour et de suppression conditionnelles.
23. Cache Database • Base de données clé / valeur optimisée pour la performance. • Le plus souvent stocké en mémoire.
24. Memcached • Base de données orientée cache clé / valeur massivement distribuée. • Valeur simple. • Invalidation de cache par expiration ou par algorithme du moins récemment utilisé.
25. Requête >>> import memcache >>> mc = memcache.Client(['127.0.0.1:11211']) >>> mc.set("foo", "bar") >>> mc.get("foo") "bar" Deux types de requêtes principalement : • Set (avec une durée de validité). • Get
26. Column oriented Database
27. Column orienté database • Facilité d’évolution du schéma. • Insertion dans les colonnes en parallèle. • Distribution par colonne. • Gain de place.
28. Requêtes • Set d’une valeur d’une colonne à un index donné. • Récupération d’une colonne ou de plusieurs colonnes entières. • Récupération d’une colonne ou plusieurs colonnes correspondant à une requête.
29. Cassandra • Scalable. • Orienté Big Data, développé par Facebook. • Très bonnes performances en insertion.
30. Dynamo DB • Hostée par Amazon • On ne paie que le trafic, pas le stockage. • Trafic personnalisable en fonction des besoins.
31. Document
32. Document • Utile pour les enregistrements "complexes" • Compte utilisateur • Très dev-friendly • Se rapproche du modèle relationnel, mais sans schéma
33. MongoDB • Base de données orientée document la plus connue et l’une des bases de données NoSQL la plus connue. • Possibilité d’indexation secondaires. • Moteur d’agrégation plus simple que Map / Reduce. • Support de recherches Full-Text
34. Requêtes • Enregistrement d’un document. • Récupération d’un document en particulier. • Recherche d’un document. • Agrégation des documents (count by, group by, sum…).
35. Requêtes >>> from pymongo import MongoClient >>> client = MongoClient() >>> client = MongoClient('localhost', 27017) >>> db = client['test-database'] >>> collection = db['test-collection'] >>> import datetime >>> post = {"author": "Mike", ... "text": "My first blog post!", ... "tags": ["mongodb", "python", "pymongo"], ... "date": datetime.datetime.utcnow()} >>> posts = db.posts >>> post_id = posts.insert(post) >>> posts.find_one() {u'date': datetime.datetime(...), u'text': u'My first blog post!', u'_id': ObjectId('...'), u'author': u'Mike', u'tags': [u'mongodb', u'python', u'pymongo']}
36. CouchDB • Materialized Map / Reduce • Expose une API Rest.
37. Graph database
38. Graph database • Le modèle relationnel est un sous-ensemble du modèle orienté graphe. • Peu ou pas de besoin de design du schéma, le schéma s’enrichit avec les nouveaux liens. • Bonne performance pour les requêtes orientées graphes sur un grand nombre de nœuds.
39. Neo4J • Écrit en JAVA. • Langage de requête dédié (cypher) relativement verbeux.
40. Requêtes MATCH (charlie:Person { name:'Charlie Sheen' })-[:ACTED_IN]- (movie:Movie) RETURN movie • Requête complexe écrit dans un langage dédié (Cypher), par exemple, les films dans lesquels ‘Charlie Sheen’ a joué :
41. FullText DB
42. ElasticSearch • Moteur de recherche full-text le plus reconnu. • Massivement distribué. • Performances impressionnantes.
43. Requêtes • Enregistrement d’un document • Requête d’un document précis. • Recherche des documents correspondant à une recherche utilisateur (full-text).
44. Time Series DB
45. Requête • Agrégation de données sur le temps : • Somme des visiteurs sur telle page de mon site sur le dernier mois. • Moyenne de la charge des serveurs agrégé par serveur sur la dernière semaine par période de 5 minutes.
46. Visualisation
47. Visualisation
48. Visualisation
49. Visualisation
50. Whisper • Base de donnée derrière graphite. • Écrite en Python.
51. Concepts communs
52. Requêtes • Langage de requête structuré (JSON) ou non (Cypher), avancé (MongoDB) ou non (Redis). • Permet de scanner l’ensemble des éléments ou non même sans index. • Nécessite de préparer les requêtes à l’avance ou non.
53. Map / Reduce • Algorithme de traitement de large volumes de données crée par Google. • Recherche en deux étapes : • On extrait les données utiles ou on les calcule à partir des données brutes (Map). • Puis on les fusionne et on les trie (Reduce). • L’opération de Map est du coup facilement parallélisable, l’opération de Reduce un peu moins.
54. Replication • Sharding • On répartie les données entre plusieurs nœuds égaux. • Replication • On recopie les données entre plusieurs nœuds égaux. • Master-Slave • On recopie les données entre un maître et un slave, réplication uni-directionnelle.
55. Le cas Elastic Search
56. Migration de schéma • Il y a toujours un schéma, au moins implicite. • La mise à jour de celui-ci reste à la charge du développeur.
57. Sécurité • Le plus souvent un modèle de sécurité basé sur celui de SQL est disponible. • Mais pas activé par défaut ou non disponible dans un soucis de simplicité (clé-valeur).
58. Choix d’une solution • Le choix d’une solution NoSQL est plus difficile que le choix d’une solution SQL. • Comment votre schéma va s’adapter. • Quelles sont vos contraintes métiers ? • Le temps développeur vous coûtera toujours plus cher.
59. Design du modèle de donnée • Modèle de donnée optimisé pour les requêtes. • CouchDB: préparer les requêtes, pas possible ou difficile d’en ajouter à postériori. • Au besoin, dupliquer la donnée et la démoraliser pour améliorer les requêtes.
60. Pourquoi NoSQL ? • Les bases de données NoSQL couvrent un périmètre bien plus large que les bases SQL, mais elles tentent de répondre aux mêmes besoins : • Plus vite • Plus de données • Plus de serveurs
61. Conclusion • Le modèle relationnel a des limites • Qui peuvent vous suffire, le NoSQL n’est pas une solution magique. • Dans le cas contraire, les bases NoSQL peuvent vous aider • Mais c’est un choix qui doit être bien réfléchi, RTFM !
62. Questions ?