Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Un petit tour du côté du NoSQL

410e3353165c33043ab69be7fc366428?s=47 Boris Feld
February 13, 2015

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

410e3353165c33043ab69be7fc366428?s=128

Boris Feld

February 13, 2015
Tweet

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 ?