Formation nosql

2 835 vues

Publié le

Extrait d'une formation d'introduction au NoSQL et à Elasticsearch. L'objectif est de parfaitement comprendre les tenants et les aboutissants des différentes technologies NoSQL et d'avoir l'occasion de les manipuler.

Le NoSQL permet à l'entreprise de résoudre avec des performances remarquables des problématiques complexes en adaptant le bon outil au bon usage.

Pour suivre cette formation ou en savoir plus, rendez-vous sur http://www.eisiform.com/nosql

Bon visionnage :)

Publié dans : Technologie
1 commentaire
3 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
2 835
Sur SlideShare
0
Issues des intégrations
0
Intégrations
734
Actions
Partages
0
Téléchargements
131
Commentaires
1
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Formation nosql

  1. 1. Formation NoSQL
  2. 2. Ceci est un extrait d’un formation NoSQL disponible sur http://www.eisiform.com/nosql/
  3. 3. Avant propos : NoSQL n’est ni une évolution, ni une révolution ! I
  4. 4. C’est simplement de nouvelles opportunités. I
  5. 5. I - Introduction au NoSQL I
  6. 6. […] Des slides sont sautés
  7. 7. 4. Stocker les données en fonction des intentions d’usage I-4. Penser usage
  8. 8. Quels objectifs ? - Comprendre la notion d’usage de la donnée - Avoir une première vision de la modélisation des données en fonction de l’usage I-4. Penser usage - Quelles sont les conséquences d’une mauvaise modélisation de la donnée
  9. 9. La chocolaterie I-4. Penser usage
  10. 10. La chocolaterie ? I-4. Penser usage
  11. 11. Le relationnel dans la réalité Mon article de blog Commentaires Table articles Table commentairesTable utilisateurs I-4. Penser usage
  12. 12. Mon article de blog Commentaires Le NoSQL dans la réalité I-4. Penser usage Stockage de donnée déjà packagées Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]
  13. 13. Une modélisation loupée Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } I-4
  14. 14. Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } I-4 Comment récupérer les 10 derniers commentaires postés sur le blog ? Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]
  15. 15. A retenir Le NoSQL demande de penser usage Impossible de créer le schéma de la donnée sans connaitre l’expérience utilisateur finale. NoSQL est très performant pour un usage précis En packageant toutes les données relatives à un usage précis, NoSQL ne requête qu’un emplacement au lieu de « n » emplacements. I-4. Penser usage Le modèle relationnel est plus flexible Dans le modèle relationnel, la donnée peut être assemblée à souhait quelque soit la demande. En NoSQL, un besoin non anticipé peut coûter très très cher en temps et donc en performance.
  16. 16. 5. Différence entre le NoSQL et le Big Data I-5. NoSQL et BigData
  17. 17. Pourquoi s’intéresser au Big data ? - Comprendre en quoi NoSQL est un outil de choix pour le Big Data - Savoir distinguer la limite entre Big Data et NoSQL I-5. NoSQL et BigData - Saisir l’étendu du Big Data
  18. 18. I-5. NoSQL et BigData Qu’est ce que le Big Data ?
  19. 19. I-5. NoSQL et BigData Manipulation de très gros volumes de données provenant de sources hétérogènes. Big data :
  20. 20. - Gros volume de données PROBLEME - Besoin de performance dans le traitement et la manipulation des données CONSEQUENCE - Besoin de machines en cluster - Besoin d’un design de la donnée performant et donc pensé en fonction de l’usage plutôt que des relations SOLUTION NoSQL I-5. NoSQL et BigData
  21. 21. - Données provenant de sources hétérogènes. PROBLEME - Besoin d’un design de donnée semi-structuré plutôt que structuré. SOLUTION NoSQL - Données non structurée que l’on va essayer d’organiser pour pouvoir les traiter. CONSEQUENCE - La diversité initiale empêche de respecter un format rigide de donnée finale. I-5. NoSQL et BigData
  22. 22. […] Des slides sont sautés
  23. 23. II - La scalabilité des bases de donnée II
  24. 24. 2. Le théorème de CAP II-2. Théorème de CAP
  25. 25. […] Des slides sont sautés
  26. 26. Finalement, CAP revient à dire… Partitionnement (tolérance aux pannes) II-2. Théorème de CAP OU Disponibilité Cohérence
  27. 27. Mais dans la réalité, tout est en nuance… Partitionnement (tolérance aux pannes) Disponibilité Cohérence II-2. Théorème de CAP OU
  28. 28. Et en posant le problème autrement… Partitionnement (tolérance aux pannes) Temps de réponse Cohérence Temps réel Sécurité OU II-2. Théorème de CAP C’est LE problème.
  29. 29. D’ou vient exactement ce temps de réponse ? Crédits: kleppmann.com II-2
  30. 30. C dans CAP est différent de C dans ACID ACID Cohérence de la donnée à l’échelle d’un seul noeud. CAP Cohérence de la donnée à l’échelle d’un cluster. II-2. Théorème de CAP
  31. 31. Le cluster recherche de la stabilité II-2. Théorème de CAP • Lorsque la donnée est cohérente dans le cluster, tous les noeuds renvoient le même contenu à la lecture. • Le problème survient lorsqu’une requête insère une nouvelle donnée et que celle-ci doit être propagée dans les réplicas.
  32. 32. La différence entre Relationnel et NoSQL • Relationnel est normalisé donc les transactions sont essentielles et très fréquentes. Utilisation intensive de l’ACID. • Or l’ACID sur un cluster est coûteux en temps • Il scale plus ou moins facilement sur un cluster en fonction du niveau de cohérence demandé Relationnel NoSQL II-2 • NoSQL est pensé pour limiter le nombre de relations entre les tables donc limiter le besoin de l’ACID. Donc plus performant.
  33. 33. Les bases de donnée en fonction de la cohérence Disponibilité Tolérant aux pannesCohérence CouchDb Cassandra Riak Mysql PostgreSQL CouchBase Mongodb HBase II-2. Théorème de CAP
  34. 34. […] Des slides sont sautés
  35. 35. 4. Architecturer le cluster : Distribution et duplication des données II-4. Sharding et replication
  36. 36. II-4. Sharding et replication Duplication : Replica-set Master READ READREAD WRITE WRITE SlaveSlave
  37. 37. II-4. Sharding et replication Duplication : Replica-set Slave Slave READREAD
  38. 38. II-4. Sharding et replication Duplication : Replica-set Slave Master READREAD
  39. 39. II-4. Sharding et replication Distribution : Sharding M S S M S S M S S product facture, order users productfacture, order users product facture, orderusers
  40. 40. II-4. Sharding et replication Distribution : Sharding M S M S M S Minimum pour 75 Go sur 3 shards25 Go 25 Go 25 Go 25 Go 25 Go 25 Go - 6 serveurs pour les données - 3 serveurs arbitres
  41. 41. III - Développer avec NoSQL III
  42. 42. III-2. Points communs 2. Points communs entre les bases NoSQL
  43. 43. Quel points communs à toutes les bases NoSQL ? Aucun. III-2. Points communs
  44. 44. Quel points communs à la plupart des bases NoSQL ? - Un schéma implicite - L’absence de relations - L’absence du language SQL III-2. Points communs - L’open source
  45. 45. III-3. Modélisation 3. Modélisation de la donnée
  46. 46. III-3. Modélisation Rappel : Fonctionnement des bases relationnelles - Support de l’ACID (transactions) - Aucune redondance des données - Des entités décrites par des métadonnée fortement typées - Utilisation de jointures - Les entités sont liées par des relations - Les métadonnées ne sont pas dupliquée à chaque ligne
  47. 47. III-3 Rappel : Distribution et duplication en NoSQL - Distribution de la donnée Factures Clients Produits Produits FacturesClients - Replication de la donnée Serveur 1 Serveur 2 Serveur 3
  48. 48. III-3 Factures Clients Produits Produits FacturesClients Serveur 1 Serveur 2 Serveur 3 Problème : Partitionnement des données Dans ce cas de figure les jointures ne sont pas performantes
  49. 49. Solution apportée par le NoSQL La donnée contient l’intégralité des informations nécessaires pour une requête. agrégat III-3. Modélisation
  50. 50. La notion d’agrégat - Une unité d’information complexe et isolée (semi-structurée) - Identifiée par un élément racine (id) - Traité / Stocké / Echangé de manière atomique - On y accède uniquement par la racine III-3. Modélisation
  51. 51. […] Des slides sont sautés
  52. 52. L’agrégat en NoSQL - Rapide car pas d’agrégat à construire lors de la requête AVANTAGES INCONVENIENT - Entraine la duplication des données - Plus besoin de transaction car l’agrégat est atomique avec lui même - Des données à mettre à jours à plusieurs endroits - L’agrégat est désignée pour un usage précis et peu flexible III-3. Modélisation
  53. 53. L’agrégation via les requêtes SQL - Extrême flexibilité dans le requêtage des données AVANTAGES INCONVENIENT - Besoin de transactions pour modifier les différentes tables en « simultané » - Aucune redondance de la donnée, ni des métadonnées - Lenteur de l’exécution de la requête du à la formation de l’agrégat - Difficulté pour distribuer la donnée sur le cluster, dû aux dépendances entre les tables III-3. Modélisation
  54. 54. III-4. Inconvénients 4. De nouvelles problématiques de développement
  55. 55. III-4. Inconvénients Problématique 1 : Schéma implicite User { name: "Franck", age: 20 } { name: "Franck" } { name: "Franck", age: "20" } { book: "Colère de l’ombre", publication: 2005 }
  56. 56. […] Des slides sont sautés
  57. 57. III-4. Inconvénients Problématique 2 : Requêtage propriétaire db.collection.find( {} ) MATCH (all) RETURN all GET /collection DESCRIBE keyspaces; MongoDb Neo4j CouchDB Cassandra
  58. 58. III-4. Inconvénients Problématique 3 : Plus de normalisation - Des données peuvent être dupliquées - Les update / insert / delete doivent être réalisé à plusieurs endroits - Des scripts batch peuvent vérifier l’état de la donnée ou la corriger
  59. 59. III-4. Inconvénients Problématique 4 : Gestions des transactions ACID
  60. 60. […] Des slides sont sautés
  61. 61. III-4. Inconvénients Problématique 5 : Gestions des modifications concurrentes
  62. 62. […] Des slides sont sautés
  63. 63. IV - Les différents types de bases IV
  64. 64. IV-1. Clé-valeur 1. Bases clé-valeur
  65. 65. IV-1. Clé-valeur S1 RAM : Hash map session Session 1 -> Jérémie Session 2 -> Frédéric Session 3 -> John Request -> Session 3 Le besoin : Mémoire partagée
  66. 66. IV-1. Clé-valeur S4 S2 S1 S3 Loadbalancer Request -> Session 3 Session 1 -> Jérémie Session 2 -> Frédéric Session 3 -> John Session 4 -> Franck Session 5 -> John Session 6 -> Franck ? RAM : Hash map session Le besoin : Mémoire partagée
  67. 67. […] Des slides sont sautés
  68. 68. Autre besoin : Queue - Envoi d’email est très lent - Inscription -> Email de validation - Envoi de l’email en différé IV-1. Clé-valeur
  69. 69. […] Des slides sont sautés
  70. 70. Cas d’utilisation
  71. 71. […] Des slides sont sautés
  72. 72. Découverte de Redis IV-1. Clé-valeur set "formation:the.mail.queue:state" "enable" Commande redis Clé respectant le standard Valeur
  73. 73. Découverte de Redis : Types de données IV-1. Clé-valeur - String (set, get, incr, incrby…) - List (lpush, rpush, lindex, lrange…) - Hash (hset, hmset, hget…) - Set (sadd, sdiff, sunion…) - Sorted set (zadd, zscore, zrange…)
  74. 74. […] Des slides sont sautés
  75. 75. VI-2. Colonnes 2. Bases colonnes
  76. 76. […] Des slides sont sautés
  77. 77. Cas d’utilisation
  78. 78. Fonctionnalité Ebay : Likes, Own, Want
  79. 79. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  80. 80. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  81. 81. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  82. 82. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  83. 83. Fonctionnalité Ebay : Performances finales Crédits : Ebay Tech blog Mysql : ~ 3 ms / requête Cassandra : ~ 0.12 ms / requête
  84. 84. IV-3. Documents 3. Bases documents
  85. 85. IV-3. Documents Les besoins - Création d’entités classique (user, facture, produits…) - Une majorité de requête read et peu en write - Savoir à l’avance les requêtes que l’on va faire + Populaire
  86. 86. IV-3. Documents Les bases du modèle de donnée - Base de donnée -> Collection -> Documents Base de donnée Table Rows - Donnée semi-structurées en JSON { user: jeremie, hobbies: [technologie, sport]}
  87. 87. Construction du modèle d’un blog - Afficher l’article sur la page article et les 10 premiers commentaires. Charger les suivants si l’utilisateur scroll. - Afficher le résumé des 5 derniers articles sur la page d’accueil, le top 3 des articles et les 2 derniers commentaires - Les auteurs peuvent se connecter pour rédiger des articles et ont un ou des rôles spécifiques (admin, rédacteur, correcteur…) IV-3. Documents - Lister les articles d’un auteur
  88. 88. […] Des slides sont sautés
  89. 89. IV-4. Graphes 4. Bases graphes
  90. 90. Besoin : Relations nombreuses et complexes Relation bi-directionelle Relation directionelle Entité de type différent Personne Voiture Relation qui a plus de poids Emprunte à Relation nommée
  91. 91. […] Des slides sont sautés
  92. 92. Pourquoi choisir une base graphe ? - Facilité de requêtage dans le graphe - Haute performance sur les graphes - ACID + Forte cohérence dans le cluster IV-4. Graphes
  93. 93. […] Des slides sont sautés
  94. 94. V - Vers le NewSQL ? V
  95. 95. V-3. Etat du NewSQL 1. Notion de NewSQL
  96. 96. Google Megastore We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. V-1. Notion de NewSQL
  97. 97. […] Des slides sont sautés
  98. 98. Le NewSQL aujourd’hui V-1. Notion de NewSQL
  99. 99. V-2. In-Memory et BigData 3. NewSQL in-memory et BigData
  100. 100. Usage classique de VoltDB Un important flux de données entrantesIngère Nécessite un traitement par évènement pour analyser les résultats en temps réel. Analyse Décide Exporte les données vers une base persistence pour du stockage ou du batch ultérieur par exemple (Export) V-2. In-Memory et BigData
  101. 101. Crédits : VoltDB Big Data streaming architecture V-2. In-Memory et BigData
  102. 102. VI - Elastic Search VI
  103. 103. 1. Particularités de la base Elastic Search VI-1. Spécificités Elasticsearch
  104. 104. […] Des slides sont sautés
  105. 105. VI-1. Spécificités Elasticsearch Elastic Search - Bâti autour de Apache Lucene - Ajoute la persistence (stockage) des données à Lucene - Simplifie la configuration et unifie / approfondit le requêtage - Base de donnée document NoSQL ayant un index inversé
  106. 106. 2. Expérimentations sur elastic search VI-2. Expérimentations Indexation, Requêtage, Filtrage, Facette, Aggrégation, géolocalisation, catégorisation…
  107. 107. […] Des slides sont sautés
  108. 108. Ceci est un extrait d’un formation NoSQL disponible sur http://www.eisiform.com/nosql/

×