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

Un petit tour du côté du NoSQL

Avatar for Boris Feld 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

Avatar for Boris Feld

Boris Feld

February 13, 2015
Tweet

More Decks by Boris Feld

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. From RDBMS… • Comment stocker les données ? • Adapté

    aux données relationnelles. • Concepts maîtrisés et éprouvés. • Solution robustes et matures.
  4. 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…
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. « 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.
  10. 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.
  11. 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.
  12. Redis • L’une des bases clé / valeur la plus

    connue. • Les valeurs sont structurées (liste, arbre, etc…). • Non distribuée. • Superbe documentation.
  13. 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
  14. SimpleDB • Hebergé par Amazon. • Massivement distribué. • Opérations

    de mises à jour et de suppression conditionnelles.
  15. Cache Database • Base de données clé / valeur optimisée

    pour la performance. • Le plus souvent stocké en mémoire.
  16. 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é.
  17. 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
  18. Column orienté database • Facilité d’évolution du schéma. • Insertion

    dans les colonnes en parallèle. • Distribution par colonne. • Gain de place.
  19. 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.
  20. Dynamo DB • Hostée par Amazon • On ne paie

    que le trafic, pas le stockage. • Trafic personnalisable en fonction des besoins.
  21. Document • Utile pour les enregistrements "complexes" • Compte utilisateur

    • Très dev-friendly • Se rapproche du modèle relationnel, mais sans schéma
  22. 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
  23. 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…).
  24. 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']}
  25. 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.
  26. 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é :
  27. ElasticSearch • Moteur de recherche full-text le plus reconnu. •

    Massivement distribué. • Performances impressionnantes.
  28. Requêtes • Enregistrement d’un document • Requête d’un document précis.

    • Recherche des documents correspondant à une recherche utilisateur (full-text).
  29. 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.
  30. 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.
  31. 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.
  32. 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.
  33. 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.
  34. 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).
  35. 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.
  36. 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.
  37. 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
  38. 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 !