Un petit tour du côté du NoSQL

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 ?