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

Un petit tour du côté du NoSQL

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

Boris Feld

February 13, 2015
Tweet

More Decks by Boris Feld

Other Decks in Programming

Transcript

  1. Un petit tour du côté du NoSQl
    FELD Boris - IUT-BM
    13 février 2014

    View Slide

  2. About ME
    • Python Dev
    • DevOps
    • NoSQL fan
    • @lothiraldan

    View Slide

  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

    View Slide

  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

    View Slide

  5. Welcome in DB world!

    View Slide

  6. From RDBMS…
    • Comment stocker les données ?
    • Adapté aux données relationnelles.
    • Concepts maîtrisés et éprouvés.
    • Solution robustes et matures.

    View Slide

  7. Pourquoi NoSQL ?

    View Slide

  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…

    View Slide

  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.

    View Slide

  10. Explosion du web

    View Slide

  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.

    View Slide

  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.

    View Slide

  13. From ACID to CAP

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  17. NoSQL Taxonomy

    View Slide

  18. Clé / Valeur
    Clé Valeur
    Foo …
    Bar …

    View Slide

  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.

    View Slide

  20. Redis
    • L’une des bases clé / valeur la plus connue.
    • Les valeurs sont structurées (liste, arbre, etc…).
    • Non distribuée.
    • Superbe documentation.

    View Slide

  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

    View Slide

  22. SimpleDB
    • Hebergé par Amazon.
    • Massivement distribué.
    • Opérations de mises à jour et de suppression
    conditionnelles.

    View Slide

  23. Cache Database
    • Base de données clé / valeur optimisée pour la
    performance.
    • Le plus souvent stocké en mémoire.

    View Slide

  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é.

    View Slide

  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

    View Slide

  26. Column oriented Database

    View Slide

  27. Column orienté database
    • Facilité d’évolution du schéma.
    • Insertion dans les colonnes en parallèle.
    • Distribution par colonne.
    • Gain de place.

    View Slide

  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.

    View Slide

  29. Cassandra
    • Scalable.
    • Orienté Big Data, développé par Facebook.
    • Très bonnes performances en insertion.

    View Slide

  30. Dynamo DB
    • Hostée par Amazon
    • On ne paie que le trafic, pas le stockage.
    • Trafic personnalisable en fonction des besoins.

    View Slide

  31. Document

    View Slide

  32. Document
    • Utile pour les enregistrements "complexes"
    • Compte utilisateur
    • Très dev-friendly
    • Se rapproche du modèle relationnel, mais sans
    schéma

    View Slide

  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

    View Slide

  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…).

    View Slide

  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']}

    View Slide

  36. CouchDB
    • Materialized Map / Reduce
    • Expose une API Rest.

    View Slide

  37. Graph database

    View Slide

  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.

    View Slide

  39. Neo4J
    • Écrit en JAVA.
    • Langage de requête dédié (cypher) relativement
    verbeux.

    View Slide

  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é :

    View Slide

  41. FullText DB

    View Slide

  42. ElasticSearch
    • Moteur de recherche full-text le plus reconnu.
    • Massivement distribué.
    • Performances impressionnantes.

    View Slide

  43. Requêtes
    • Enregistrement d’un document
    • Requête d’un document précis.
    • Recherche des documents correspondant à une
    recherche utilisateur (full-text).

    View Slide

  44. Time Series DB

    View Slide

  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.

    View Slide

  46. Visualisation

    View Slide

  47. Visualisation

    View Slide

  48. Visualisation

    View Slide

  49. Visualisation

    View Slide

  50. Whisper
    • Base de donnée derrière graphite.
    • Écrite en Python.

    View Slide

  51. Concepts communs

    View Slide

  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.

    View Slide

  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.

    View Slide

  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.

    View Slide

  55. Le cas Elastic Search

    View Slide

  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.

    View Slide

  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).

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  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 !

    View Slide

  62. Questions ?

    View Slide