Les modèles NoSQL

6 407 vues

Publié le

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

Aucune remarque pour cette diapositive

Les modèles NoSQL

  1. 1. NOSQL LES CONCEPTS Hayssam Saleh
  2. 2. SOMMAIRE Les modèles  Le Map / Reduce 
  3. 3. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Gérer le persistance des données Les données non volatiles sont stockées sur disque  Un RDBMS permet de récupérer un sous-ensemble de données de manière beaucoup plus simple et beaucoup plus rapide qu’un accès disque.  Un simple « SELECT » avec des jointures  versus  Plusieurs lectures disques sur plusieurs fichiers suivi d’un filtre. 
  4. 4. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Concurrence d’accès  Accès par plusieurs utilisateurs aux mêmes données peut conduire à des incohérences si la concurrence d’accès n’est pas prise en compte  Débit multiple d’un compte par exemple (1) select amount from table (1) select amount from table (2) set amount = amount – 100 (3) update table (4) set amount = amount -100 (5) update table
  5. 5. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Concurrence d’accès  Accès par plusieurs utilisateurs aux mêmes données peut conduire à des incohérences si la concurrence d’accès n’est pas prise en compte  Débit multiple d’un compte par exemple (1) lock amount from table (2) set amount = amount – 100 Bloqué en attente de la libération du verrou (3) update table and unlock (1) lock amount from table (4) set amount = amount -100 (5) update table and unlock
  6. 6. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Gestion des erreurs Dans un système de fichiers classique, une erreur lors de la séquence de mise à jour rend difficile le retour à une situation antérieure.  Les transactions dans les bases relationnelles permettent un retour arrière transparent   Atomicité des transactions
  7. 7. POURQUOI LES BASES DE DONNÉES RELATIONNELLES  Modèle d’intégration  Les données mises à jour en base sont instantanément disponibles à l’ensemble des applications qui y accèdent.  Le langage d’interrogation est indépendant du langage de programmation et est (quasiment) identique quelque soit la base de données relationnelle utilisée. Application 1 PHP Application 2 Java Application … Ruby SQL SQL SQL
  8. 8. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL  Impédance mismatch Le modèle relationnel est éloigné du modèle mémoire  Les solutions de mapping O/R ont montré leurs limites en terme de performance.  Product Page Product description Price Products Brands Brand Category Pics Tag1 Tag2 tag3 Tags Categories
  9. 9. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL  Une approche SOA des Systèmes d’information La base de données n’est plus le point d’intégration  L’intégration est agnostique vis à vis du langage  Les applications deviennent multi-protocolaires  Application 1 PHP Peu importe SOAP/XML Application 2 Java Peu importe JSON Application … Ruby Peu importe
  10. 10. LES RAISONS DE L’ÉVOLUTION VERS LE NOSQL L’explosion de la volumétrie des données  Avec les RDBMS Le modèle big server  Coûteux  La base et le serveur restent un Single Point Of Failure (SPOF)   Avec le RAC Oracle, le système de fichiers reste un SPOF VERY BIG SERVER SERVER1 SERVER2 SERVER…
  11. 11. NOSQL : LES ORIGINES  Le terme  Apparaît pour la première fois dans le nom d’une base de données créée par Carlo Strozzi en 1998   En 2009 Johan Oskarsson cherche sur twitter un hashtag pour un meetup sur les alternatives au bases SQL tel que Google BigTable et Amazon Dynamo     C’est une base de données  Qui stocke les données dans des fichiers texte, les colonnes étant tabulées.  que l’on interroge avec des shell script UNIX Eric Evans un développeur de Rackspace suggère le terme NoSQL Le terme se répand sur la toile comme une trainée de poudre A ce meetup sont présents  Voldemort, Cassandra, Dynomite, Hbase, Hypertable, CouchDB et MongoDB La signification   Pas de définition précise Regroupe toutes les bases de données qui n’utilisent pas SQL comme moyen d’accès.
  12. 12. POURQUOI LE NOSQL  Synthèse       Les RDBMS gèrent la persistance, la concurrence. Les RDBMS permettent une intégration des éléments du S.I. par le partage des données accessible au travers d’un langage universel L’impédance mismatch entre le modèle relationnel et le modèle objet d’où les solutions de mapping objet/relationnel et les problèmes de performance qui en découlent Le nombre croissant et non quantifiable d’utilisateurs conduit à une explosion de la volumétrie Les RDBMS en sont pas prévus pour fonctionner en cluster NoSQL  Qu’est ce que c’est ?
  13. 13. LE MODÈLE RELATIONNEL  Entité/Relation Le modèle de données est constitué d’un ensemble de tables  Chaque ligne d’une table est composée de colonnes  Une colonne héberge une et une seule valeur  Les relations sont permises par le fait qu’une colonne peut référencer une ligne de la même table ou d’une autre table  Brands Products Categories
  14. 14. LES MODÈLES DE DONNÉES NOSQL  Modèle NoSQL  Clef / Valeur, Document , Famille de colonnes Les données sont agrégées  L’agrégation obéit en général au modèle de consultation  Toutes les entités censées être restituées ensemble sont agrégées au sein d’une même structure  Autant de tables que d’entités Une seule et unique entité
  15. 15. LES MODÈLES DE DONNÉES NOSQL  Conséquence du modèle d’agrégat  Dans le modèle relationnel il est impossible de distinguer les relations d’agrégation des relations de liaison.  Les RDBMS ne peuvent donc pas utiliser cette information pour optimiser le modèle de stockage ou distribuer les données sur plusieurs serveurs.
  16. 16. LES MODÈLES DE DONNÉES NOSQL  Quand utiliser le modèle d’agrégat  Lorsque la volumétrie le justifie. Les données doivent être réparties sur plusieurs serveurs (sur un cluster)   L’agrégation indique au DBMS l’unité de consultation. Les constituants d’un agrégat seront ainsi toujours stockés sur le même nœud. L’atomicité d’une mise à jour sera garantie pour un agrégat mais pas pour un ensemble d’agrégats mis à jour simultanément dans la même transaction.  Quand l’atomicité est nécessaire, il faut alors fusionner les agrégats en un seul et unique agrégat.
  17. 17. LES MODÈLES DE DONNÉES NOSQL  Le modèle Clef / Valeur Interface de type Map.  La valeur est opaque au DBMS. Il la considère comme un Blob  Key = « product1 » Value est un Blob/CLob Key = « product2 » Value est un Blob/CLob Key = « product… » Value est un Blob/CLob
  18. 18. LES MODÈLES DE DONNÉES NOSQL  Le modèle Orienté Document La structure de l’agrégat est visible du DBMS  Les requêtes peuvent référencer des propriétés de l’agrégat  Et renvoyer un sous-ensemble de l’agrégat  Key = "product1" { product : { title: "product1", Requête sur un critère du document et extraction d’un sous ensemble category:"computer", tags :["tag1", "tag2", "tag2"] … } } Key = "product2" { product : { …
  19. 19. LES MODÈLES DE DONNÉES NOSQL  Les modèles Orienté Document et Clef / valeur :  Une frontière floue  Certains moteurs clef/valeur permettent de rajouter des métadonnées qui peuvent être ensuite indexées et utilisées en tant que critères  Lorsque la valeur est au format JSON et XML, certains moteurs permettent d’utiliser Apache SOLR pour de la recherche full-text sur l’agrégat Key = « product1 » Prop1: … Prop2: … Prop3: … Value à a Blob/CLob
  20. 20. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Column Column name Column Value Title Product1
  21. 21. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Super column name Column name Column Value … Column name Column Value ProductInfo Title Description Product1 Beautiful product you’ll find nowhere else 
  22. 22. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes: Famille de colonnes Row key Column name Column name … Column Value Column Value … Title "1234-3213-2134-2121" … Description … Beautiful product you’ll find nowhere else  Product1
  23. 23. LES MODÈLES DE DONNÉES NOSQL Famille de colonnes et super colonnes Super column name Column name Row key … Column Value Super column name Column name … Column Value Column name … Column Value Column name Column Value … ProductInfo "1234…2121" SellerInfo Title … Description Name … Location Product1 … l ToyStore … Paris Keyspace.get("products », »1234…2121", "ProductInfo », "Title »)
  24. 24. LES MODÈLES DE DONNÉES NOSQL  Le modèle famille de colonnes:  S’il fallait comparer aux RDBMS Modèle relationnel Schéma Keyspace Table Famille de colonnes Clef primaire Idem Nom de colonne Idem Valeur de colonne  Il Modèle famille de colonnes (terminologie Cassandra) Idem vaut mieux considérer une famille de colonnes comme suit :  SortedMap[RowKey, SortedMap[ColumnKey, ColumnValue]]
  25. 25. LES MODÈLES DE DONNÉES NOSQL  Synthèse  Dans les modèles Clef/Valeur, Orientés documents et famille de colonnes:  L’agrégat est l’unité de données  Les opérations sur un agrégat respectent le principe ACID  L’agrégat permet au DBMS de gérer d’organiser le stockage des données sur les noeuds du cluster  Lorsque les opérations sont groupées par agrégat, les modèles NoSQL sont justifiés.  Lorsque un nombre de relations limité doit être établi entre plusieurs agrégats les modèles relationnels nous permettent de conserver les propriétés ACID.  Mais alors comment gérer un nombre important de relations entre les objets  Les modèles relationnels font exploser les jointures  C’est là qu’intervient le modèle NoSQL communément appelé Base de données orientée Graphe
  26. 26. LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE  Hayssam et Michèle ont des gouts similaires ?  Je peux proposer à Michèle tous les produits  Les produits dans l’ordre suivant :  Les produits achetés, "aimés" ou consultés par Hayssam
  27. 27. LES MODÈLES DE DONNÉES NOSQL : BASE ORIENTÉE GRAPHE  Synthèse  Permet la gestion des relations entre agrégats  Organise  les données en nœuds et liens Ce modèle est intéressant en présence d’un volume important de liens  Inadapté à la navigation en cluster
  28. 28. LES MODÈLES DE RÉPARTITION Le modèle centralisé  Le sharding  Maitre / esclave  Réplication point à point 
  29. 29. LES MODÈLES DE RÉPARTITION  Le modèle centralisé Probablement le modèle le plus courant  Adapté à la grande majorité des cas  N’est pas en contradiction avec le modèle NoSQL 
  30. 30. LES MODÈLES DE RÉPARTITION  Le sharding Résoudre le problème d’une trop forte charge sur les serveurs pour l’accès à des données disjointes.  Cible => Situation idéale (inatteignable dans la réalité)  Les utilisateurs sont uniformément répartis sur les serveurs  Ils accèdent à des données elles-aussi uniformément réparties  Big Server Row 1 … Row1000000 Row 1 Row 1000001 … Row2000000 … Row3000000 Row 2000001 … Row3000000
  31. 31. LES MODÈLES DE RÉPARTITION  Les intérêts du sharding Meilleures performances en consultation et mises à jour  Réduction de la volumétrie des index   Les difficultés du sharding  Non transparent  L’application doit savoir quel serveur contient quelle donnée Jointures non autorisées entre les shards  Perte de l’intégrité référentielle inter-shards.   Autosharding Le DBMS est responsable de la répartition des données sur les serveurs  Service présent sur la majeure partie des DBMS NoSQL 
  32. 32. LES MODÈLES DE RÉPARTITION  Maître / Esclave Propagation Mise à jour Maitre Esclave Consultation Propagation Esclave      Consultation Consultation Les lectures se font sur n’importe quel nœud du cluster Toutes les écritures sont effectuées sur le maître qui est chargé de les répercuter sur les esclaves Certaines lectures peuvent être incorrectes si l’écriture n’a pas encore été répercutée Inadapté à un trop important volume de données à écrire Le maitre est un SPOF
  33. 33. LES MODÈLES DE RÉPARTITION  Réplication point à point Maître Maître Lecture / écriture Maitre Lecture/écriture Lecture/écriture Propagation Des écritures Les lectures / écritures se font sur n’importe quel nœud du cluster  Inconsistance en cas d’écritures simultanées sur un même sous ensemble de données à partir de différents maîtres  Merge des écritures possible malgré tout. 
  34. 34. LES MODÈLES DE RÉPARTITION  Synthèse Le sharding permet de répartir les données sur plusieurs serveurs, chaque serveur étant responsable d’un sousensemble des données  La réplication duplique les données sur plusieurs serveurs  Le modèle maitre/esclave consiste à avoir un serveur chargé de propager les écritures  Le maître reste un SPOF  Le modèle point à point permet d’écrire sur n’importe quel nœud du cluster. Les nœuds se coordonnent ensuite pour synchroniser les copies  Peut provoquer des conflits lors des mises à jour de données 
  35. 35. LA COHÉRENCE DES DONNÉES Le modèle ACID  Le théorème CAP  Les quorums  Le versioning 
  36. 36. LA COHÉRENCE DES DONNÉES  Le modèle ACID  Atomicité   Tout ou rien Cohérence  Les transactions qui modifient l’état de la base font en sorte que les contraintes d’intégrité référentielle sont respectées  Est-ce bien de la cohérence ? Non   Isolation   Conflit en lecture et en écriture toujours possible Une transaction ne peut pas accéder aux données mise à jour par une autre transaction avant qu’elle ne soit validée par son propriétaire Durabilité  Toute transaction validée (commitée) est assurée d’être prise en compte quelque soit la panne (transaction logs).
  37. 37. LA COHÉRENCE DES DONNÉES  Les conflits en écriture 1- Hayssam récupère le montant De la base soit 100€ 3- Hayssam rajoute 20 € 4- Hayssam met à jour la donnée en base 2- Michèle récupère le montant de la base soit 100€ 3- Michèle rajoute 10 € 5- Michèle met à jour la base Nouvelle valeur = 110 €   Solution : Verrou optimiste  L’enregistrement est verrouillé avant la lecture  Risque de provoquer un inter-blocage si Hayssam attend Michèle sur cette ressource et que Michèle attend Hayssam sur une autre ressource
  38. 38. LE THÉORÈME CAP  Cohérence (Consistency)   Disponibilité (Availablity)   Garantie que les requêtes reçoivent une réponse même si un ou plusieurs nœuds sont défaillants Résistance au morcellement (Partition Tolerance)   Tous les nœuds du système voient exactement les mêmes données au même moment Aucune panne autre qu’une coupure réseau totale ne doit empêcher le système de répondre. Idéalement, le système doit être en mesure de réconcilier les mises à jour une fois les nœuds à nouveaux accessibles les uns des autres Théorème de Brewer:  Un système distribué ne peut garantir à un instant donné que 2 de ces 3 contraintes.
  39. 39. LE THÉORÈME CAP  Situation idéale N 1 N 1 A V1 N 1 A V0 A V1 V1 U N 2 N 2 B 1 N 2 B V0 2 B V0 3 V1 V1
  40. 40. LE THÉORÈME CAP  CAP Application
  41. 41. LE THÉORÈME CAP CAP : Une panne du maître provoque une indisponibilité Maître Esclave Esclave Lectures Client Client Mises à jour Mises à jour 
  42. 42. LE THÉORÈME CAP CAP = Résistance au morcellement => la valeur lue par B est incohérente  N 1 N 1 A V1 N 1 A V0 A V1 V1 U N 2 N 2 B 1 N 2 B V0 2 B V0 3 V0 V0
  43. 43. CONSISTENT HASHING   Chaque partition est gérée par un et un seul vnoeud  Les vnoeud sont répartis sur les noeuds physiques  L’ajout ou le retrait d’un nœud physique amène le système à se reconfigurer en déplaçant des vnoeuds pour conserver une répartition uniforme des partitions.  Nombre minimum de partitions doit être de 10. 3 nœuds et 64 partitions – • La partitionnement est réalisé une fois pour toutes et devient DEFINITIF.  • Une clef est sur 160 bits 22 partitions sur un nœud et 21 sur les deux autres. On ajoute 1 nœud supplémentaire – Le système se reconfigure pour avoir 16 partitions par noeud.
  44. 44. LES QUORUMS  Qorum  Le nombre minimum de nœuds qui doivent répondre avec succès pour considérer que l’opération s’est déroulée avec succès   N      Les R premiers nœuds qui renvoient la valeur demandée R<N W   Nombre de nœuds sur lesquels les données doivent être répliquées. R   Permet de réconcilier la cohérence et la disponibilité. Nombre de nœuds qui doivent répondre avec succès pour considérer que la création/mise à jour a été effectuée avec succès W<N Les performances sont directement liées à l’importance des valeurs R & W. Cohérence et disponibilité   Tolérer un nœud défaillant : N = 3, R = W = 2 Tolérer deux nœuds défaillants : N = 5, R = W = 3
  45. 45. LE QUORUM DE LECTURE
  46. 46. LE QUORUM D’ÉCRITURE
  47. 47. DÉTECTION ET RÉSOLUTION DES CONFLITS VECTOR CLOCKS Chaque donnée est accompagnée d’un identifiant de nœud et d’un timestamp  Quand deux clients mettent à jour la même donnée, on obtient une donnée avec deux vector clocks distincts.  La résolution est alors à l’initiative du client. 
  48. 48. DÉTECTION DU CONFLIT Réplication Mise à jour Mise à jour Réplication Conflit détecté
  49. 49. RÉSOLUTION ET QUORUM Value = Data.v2 Client GET (K, Q=2) Value = Data.v2 Update K = Data.v2 Value = Data.v1
  50. 50. LA COHÉRENCE DES DONNÉES  Synthèse        Les conflits en écriture surviennent lorsque 2 clients mettent à jour la même donnée au même moment La prévention des conflits par une stratégie pessimiste peut provoquer des inter-blocages La prévention des conflits conduit à des algorithmes bloquants qui provoquent un ralentissement des applications Le théorème CAP indique qu’il faut choisir entre la disponibilité et la cohérence La cohérence ne requiert de consulter tous les noeuds du cluster, il suffit que le quorum soit rempli Les estampilles permettent de détecter les conflits Le vecteur d’estampilles indiquent quand les différents nœuds ont eu des mises à jour en conflit.
  51. 51. Source: http://blog.beany.co.kr/archives/275 http://blog.beany.co.kr/archives/275 LE THÉORÈME CAP : POSITIONNEMENT DES BASES NOSQL
  52. 52. CAS D’USAGE  Clef / Valeur  Cas d’usage      Stockage des informations de session  Memcached ou Riak Profil utilisateur ou Préférences Memcached si préférences non persistantes, Riak sinon Gestion de panier  Riak Cas à éviter    Relations entre les agrégats  Bien que certaines bases comme Riak permettent naviguer d’un agrégat à un autre Transactions multi-agrégats  Rend complexe le rollback Inerrogation sur la valeur de l’agrégat  La valeur n’est pas accessible   Même si Riak par exemple offre un mode recherche en texte intégral avec SOLR Opérations ensemblistes  Il n’est pas possible d’accéder à plusieurs clefs simultanément  Plusieurs aller/retour sont nécessaires entre le client et le DBMS
  53. 53. CAS D’USAGE  Orienté Document  Cas d’usage    Logging d’événements  Les données pourront être shardées par application ou type d’événements (commande / Paiement / ect …) CMS / Blog  Publication de sites Web, Gestion des commentaires … Real time Web Analytics  Les agrégats peuvent être mis à jour     Nombre de pages vues, nombre de visiteurs Les agrégats étant sans schéma, de nouvelles métriques peuventêtre ajoutées à tout moment Applications e-commerce  Supporter n’importe quel type de produit avec n’importe quelle propriété. Cas à éviter  Transactions multi-document
  54. 54. CAS D’USAGE  Orienté colonnes  Cas d’usage Logging d’événements  CMS, Plateforme de Blog  Compteurs  Famille de colonne CounterColumnType  Propriétés avec une date d’expiration  Bannières publicitaires  Accès en démo   Cas à éviter  Inadapté pour un prototype  Requiert de concevoir les familles de colonnes en amont de l’utilisation
  55. 55. CAS D’USAGE  Graphes  Cas d’usage Réseaux sociaux  Services de géolocalisation, routage ou dispatching  Moteurs de recommandation   Cas à éviter Volume de données trop important pour résider sur un seul serveur  Mise à jour de propriétés sur un nombre important de noeuds 
  56. 56. L’ANALYSE DE DONNÉES  Map / Reduce : Principe fonctionnel  La phase de mapping lit les données de la base et génère une map de clef/valeur   Parallélisation : Chaque couple sera traité par un acteur Ne fonction de réduction les entrées avec la même clef pour les agréger en une seule valeur Map Combine Map Job' request Map Map Map Reduce
  57. 57. MAPREDUCE  Exemple : Calculer le nombre de pages dans la catégorie AUTO accédées entre le 1er janvier et le 7 janvier { "categories" : [ “Assurance”,” Auto”, “Promotion” ], "interaction" : { "age" : -1, "domain" : null, "name" : "INTERACTION_ID", "path" : null, "value" : "4b40fb8b-55eb-4319-9745-fccfe2be8f88" }, "keywords" : [ “ABC” ], "nodePath" : "/sites/ACME-SPACE/home/community/publications", "requestData" : { "accept" : "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "accept-charset" : "ISO-8859-1,utf-8;q=0.7,*;q=0.3", "accept-encoding" : "gzip,deflate,sdch", "accept-language" : "en-US,en;q=0.8,fr;q=0.6", "connection" : "keep-alive", "cookie" : "JSESSIONID=62b7421a-8e85-42aa-a0fd-816c34456502; INTERACTION_ID=4b40fb8b-55eb-4319-9745-fccfe2be8f88", "host" : "127.0.0.1:8080", "ipAddress" : "127.0.0.1", "referer" : "http://127.0.0.1:8080/cms/en/sites/ACME-SPACE/home/activities/satellites.html", "user-agent" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11" }, "sessionId" : "62b7421a-8e85-42aa-a0fd-816c34456502", "tags" : [ “Avantages” ], "time" : 1353415058212, "userid" : " guest " }
  58. 58. MAP / REDUCE : UN EXEMPLE CONCRET  Phase de Mapping : Un objet est à retenir s’il référence la catégorie Auto var doTheMap = function(value) { try { var obj = Riak.mapValuesJson(value)[0]; if (obj.categories.indexOf("Auto") > -1 && new Date(2012,0,1).getTime() >= obj.time && new Date(2012,0,7).getTime() <= obj.time ) return [obj]; else return []; } catch (error) { return []; } }  Phase de Reduce : Compter le nombre de pages var reduceIt = function(values) { return [values.reduce(function(total, value) { return total + 1;}, 0)]; }  Lancer le Map/Reduce sur le bucket des visites riak.add("visites").map(doTheMap).reduce(reduceIt).run()   Plusieurs phases de maps et de reduce peuvent être appliquées successivement riak.add("visites").map(doTheMap1).map(doTheMap2). reduce(reduceIt1). reduce(reduceIt2).run()
  59. 59. L’ANALYSE DE DONNÉES  Synthèse Map-reduce est un pattern de parallélisation des calculs sur un cluster  La Phase de mapping lit les données d’un agrégat et implemnte la condition qui consiste à retenir la donnée  La phase de réduction prend la liste des valeurs d’une clef et la réduit à une valeur unique 
  60. 60. Questions

×