Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Base NoSql et Python

5.238 visualizaciones

Publicado el

La dernière génération des bases de données ont les particularités suivante :
Être non relationnel, distribuée , open source et scalable.
Ce mouvement commence en 2009 et est entrain de grandir rapidement et avec beaucoup d'engouement.
La conférence a pour but de présenté les principales base noSql accessible en python. Elle sera agrémentée pour chaque base de donnée (environ 4, 10 min chacune) d'une présentation informative, d'une modélisation de schéma et d'un exemple d'application accédant au donnée (en python).

  • tres interessé par votre exposé merci
    avez vous liens ou sites web à me conseiller ?
    merci
       Responder 
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí

Base NoSql et Python

  1. 1. Les bases NoSQL et Python Youenn Boussard
  2. 2. Les bases de données <ul><li>Avant 1960 : organisation classique sous forme de fichier
  3. 3. 1960 : 1er base de donnée : militaire , hiérarchique, sous forme d'arbre
  4. 4. 1970 : Théorie sur l'algèbre relationnelle de Codd
  5. 5. 1980 : troisième génération des sgbd : les bases de données orientées objets </li></ul>
  6. 6. Le développement Internet <ul><li>1962 – Premier concept d'internet
  7. 7. 1969 – RFC
  8. 8. 1974 – Mise au point de la norme IP
  9. 9. 1981 – 213 ordinateurs connectés
  10. 10. 1989 – Naissance du World wide Web
  11. 11. 2004 – Web 2.0, Facebook
  12. 12. 2006 – twitter
  13. 13. 186,7 millions de sites web </li></ul>
  14. 14. Web 2.0 et les limites des modèles relationnels <ul><li>Beaucoup de données </li><ul><li>Digg 3TB
  15. 15. Facebook 50TB
  16. 16. Ebay 2PB </li></ul><li>Beaucoup d'utilisateurs
  17. 17. Beaucoup de trafic
  18. 18. Et les bases relationnelles pour gérer tout cela ? </li></ul>
  19. 19. Le cas de <ul><li>Partition verticale maître-esclave avec </li></ul>
  20. 20. Maître esclave <ul><li>Réplication Maître esclave </li><ul><li>Un unique maître
  21. 21. Un ou plusieurs esclave
  22. 22. Toute les écritures vont sur le maître, répliquer sur les esclaves
  23. 23. Les lectures sont réparties entre les différents maîtres et esclaves </li></ul><li>Cela implique </li><ul><li>Le maître est critique
  24. 24. Le maître est le point d'engorgement du système </li></ul></ul>
  25. 25. Partition Horizontale <ul><li>Réparties sur plusieurs noeuds
  26. 26. Les jointures sont déportées au niveau de l'application
  27. 27. Cela implique </li><ul><li>On n'est plus relationnel
  28. 28. Le fonctionnel devient compliqué
  29. 29. La maintenance aussi !! </li></ul></ul>
  30. 30. Et la disponibilité !! Des centaines de millions de lignes Des millions de lignes 14sec
  31. 31. Sytème distribué : Trois états <ul><li>C comme Consistence
  32. 32. A comme Availability (Disponibilité)
  33. 33. P comme Partition tolérance </li></ul><ul>Dr. Eric Brewer </ul>CAP THEOREM = On ne peut avoir que 2 états en simultanée dans un système distribué
  34. 34. ACID contre BASE <ul><li>Atomique
  35. 35. Cohérente
  36. 36. Isolée
  37. 37. Durable </li></ul><ul><li>Basically Available
  38. 38. Soft state
  39. 39. Eventually consistent </li></ul>
  40. 40. <ul><li>Non relationnelle
  41. 41. Distribuée
  42. 42. Open source
  43. 43. Scalable horizontablement </li></ul><ul>Une nouvelle Génération de base de donnée </ul>
  44. 46. CouchDB est <ul><li>Orienté document -> Pas de schéma, représentation des données telle quelle
  45. 47. Accessible via RESTful
  46. 48. Distribué, réplication incrémental, résolution de conflit bi directionnel
  47. 49. Donnée indexable et requetable suivant des vues
  48. 50. Ecrit en </li></ul>
  49. 51. Un document <ul><li>Un document est un objet contenant un ensemble de clés valeurs </li></ul><ul><li>Une base de données couchdb est une collection à plat de ces documents </li></ul>
  50. 52. RESTFul API REST est basé sur le protocole HTTP <ul><li>Lecture : GET /somedatabase/some_doc_id
  51. 53. Ecriture / update : PUT
  52. 54. Créer : POST
  53. 55. Supprimer : DELETE </li></ul>
  54. 56. Robuste <ul><li>N'écrase pas une donnée « commité »
  55. 57. Si le serveur tombe, il faut juste redémarrer CouchDB -> pas de « repair »
  56. 58. On peut prendre des snapshots avec des simples cp
  57. 59. Plusieurs niveaux de durabilité : Choix entre synchroniser à toutes les mises à jours ou à la demande </li></ul>
  58. 60. Vues <ul><li>Méthodes pour aggréger et requeter les documents de la base de donnée
  59. 61. Les vues sont définies par des documents spéciaux les « designs documents »
  60. 62. Les vues sont écrites en javascript.
  61. 63. Pour maintenir des performances sur les vues, le moteur de vues maintient des indexes sous forme btree </li></ul>
  62. 64. MapReduce <ul><li>Introduit par Google </li></ul><ul><li>2 étape </li><ul><li>Etape Map -> itère sur une liste d'éléments indépendants et accomplit une opération spécifique sur chaque élément </li></ul></ul><ul><ul><ul><ul><ul><li>function(doc){} </li></ul></ul></ul></ul></ul><ul><ul><li>Etape Reduce -> prend une liste et combine les éléments selon un algorithme particulier </li></ul></ul><ul><ul><ul><ul><ul><li>fonction(keys, values, rereduce){} </li></ul></ul></ul></ul></ul>
  63. 66. { &quot;_id&quot;:&quot;_design/company&quot;, &quot;_rev&quot;:&quot;12345&quot;, &quot;language&quot;: &quot;javascript&quot;, &quot;views&quot;: { &quot;all&quot;: { &quot;map&quot;: &quot;function(doc) { if (doc.Type == 'customer') emit(null, doc) }&quot; }, &quot;by_lastname&quot;: { &quot;map&quot;: &quot;function(doc) { if (doc.Type == 'customer') emit(doc.LastName, doc) }&quot; }, &quot;total_purchases&quot;: { &quot;map&quot;: &quot;function(doc) { if (doc.Type == 'purchase') emit(doc.Customer, doc.Amount) }&quot;, &quot;reduce&quot;: &quot;function(keys, values) { return sum(values) }&quot; } } } Exemple d'une vue
  64. 67. Exemple de map/reduce
  65. 68. couchdb-python <ul><li>Côté client </li><ul><li>couchdb.client -> client pour s'interfacer avec des servers couchdb
  66. 69. couchdb.design -> pour gérer les design documents
  67. 70. couchdb.mapping -> fournit des mappings entre les document json et les objets python </li></ul><li>Coté serveur </li><ul><li>couchdb.view -> pour écrire des vues en python plutôt qu'en javascript </li></ul></ul>
  68. 71. couchdb.client.Server <ul><li>Représentation d'un server CouchDB </li><ul><li>>>> server = Server(' http://localhost:5984/ ') </li></ul><li>Pour créer une base de données : create
  69. 72. >>> server.create('python-tests')
  70. 73. Pour accéder à une base de données
  71. 74. >>> server['mabase']
  72. 75. Pour supprimer une base de données
  73. 76. >>> del server['mabase'] </li></ul>
  74. 77. couchdb.client.Database <ul><li>Création d'un nouveau document </li><ul><ul><li>>>> server = couchdb.client.Server()
  75. 78. >>> db = server.create('test')
  76. 79. >>> doc_id, doc_rev = db.save({'type' : 'contact', 'name': 'yo'}) </li></ul></ul><li>Récuperation d'un document </li><ul><ul><li>>>> db[doc_id]
  77. 80. <Document … > </li></ul></ul><li>Un document est comme dictionnaire </li><ul><ul><li>>>> db[doc_id]['type']
  78. 81. 'contact' </li></ul></ul></ul>
  79. 82. couchdb.client.ViewResults <ul><li>Représentation d'une vue (permanent ou temporaire) </li><ul><ul><li>>>> map_fun = '''function(doc) {emit([doc.type, doc.name], doc.name); }'''
  80. 83. >>> results = db.query(map_fun) </li></ul></ul><li>En option, on peut envoyer tous les paramètres d'une vue </li><ul><ul><li>>>> db.query(map_fun, count = 10 , skip = 5, descending = true) </li></ul></ul><li>On peut utiliser les slices python pour positionner des startkeys et les endkeys </li><ul><ul><li>>>> results[keystart:keyend] </li></ul></ul></ul>
  81. 84. Mapper les documents Couchdb <ul><li>Permet de mapper des structures json avec du python et vice versa </li><ul><ul><li>>>> Class Person(couchdb.mapping.Document):
  82. 85. … name = couchdb.mapping.TextField()
  83. 86. … age = couchdb.mapping.IntegerField()
  84. 87. … modified = couchdb.mapping.DateTimeField(default=datetime.now)
  85. 88. >>> person = Person(name='youyou', age = 32)
  86. 89. >>> person.store(db)
  87. 90. >>> Person.load(db, 'youyou').rev
  88. 91. .... </li></ul></ul></ul>
  89. 92. couchdb.mapping.ViewField <ul><li>Pour associer une vue à un attribut d'une classe
  90. 93. class Person(Document):
  91. 94. by_name = ViewField('people', ''' </li></ul>... function(doc) { ... emit(doc.name, doc); ... }''') >>> Person.by_name(db, count=3)
  92. 95. couchdbkit <ul><li>Basé sur restkit , librairie http qui n'est pas basé sur urllib2 ou httplib
  93. 96. couchdbkit.client -> API client vers couchdb
  94. 97. Mapping dynamique des documents
  95. 98. Extension django
  96. 99. couchdbkit.consumer -> Ecoute les changements effectués sur la base de données
  97. 100. couchdbkit.loaders -> pousse des fichiers de vues sur couchdb </li></ul>
  98. 101. CouchApp <ul><li>Utilitaire de déploiement d'application pour couchDB
  99. 102. Ecrit en python
  100. 103. Crée un squellete d'application
  101. 104. Génère du code à l'aide de macros
  102. 105. Déploie les applications sur des serveurs CouchDB </li></ul>
  103. 107. Introduction <ul><li>Utiliser en production par Digg, FaceBook, Twitter, Reddit …
  104. 108. Tolérant à la panne
  105. 109. Décentraliser
  106. 110. Sous contrôle
  107. 111. Modèle de données efficient et efficace
  108. 112. Elastique
  109. 113. Durable </li></ul>
  110. 114. Modèle de données <ul><li>Colonne </li><ul><li>La plus petite unité de données dans cassandra
  111. 115. C'est un triplet </li></ul></ul>
  112. 116. Modèle de données <ul><li>Super Colonne </li><ul><li>C'est un tuple qui a un nom et une valeur (comme la colonne)
  113. 117. Mais la valeur est une liste de colonnes </li></ul></ul>
  114. 118. Famille de colonnes <ul><li>Une famille de colonnes est une structure qui contient une liste de lignes (comme les bases de données) </li></ul>
  115. 119. Modèle de données <ul><li>Super Famille de colonnes </li><ul><li>Une Famille de colonne peut être super ou standard
  116. 120. Super c'est que les lignes contiennent des super colonnes aka cle : list( colonne)
  117. 121. Une ligne est une liste de colonnes ou de super colonnes identifiées par une clé </li></ul></ul>
  118. 122. Super famille de colonne
  119. 123. L'ensemble des familles de colonnes et des supers familles de colonnes constituent un espace de clés (keyspace)
  120. 124. Modèle de données <ul><li>Les clés sont triées lorsqu'elle sont insérées dans le modèle
  121. 125. Ce tri est respecté quand on recupère les éléments -> le model doit être conçu en fonction de cela
  122. 126. Les lignes sont triées par leur nom
  123. 127. Les options de tri se font au niveau des familles de colonnes </li></ul>
  124. 128. Twissandra : un twitter like <ul><li>http://github.com/ericflo/twissandra
  125. 129. Cassandra par l'exemple en python
  126. 130. La façon de structurer les données doit être proche de la façon pour lesquelles on doit les récupérer pour les afficher </li></ul>
  127. 131. Twissandra : un twitter like <ul><li>User -> colonne family
  128. 132. La clé de la ligne est l'id de l'utilisateur </li></ul>
  129. 133. Twissandra : un twitter like <ul><li>Les amis et les adeptes sont indexés par le user id </li></ul>
  130. 134. Twissandra : un twitter like <ul><li>Les tweets sont stokées comme les utilisateurs </li></ul>
  131. 135. Twissandra : un twitter like <ul><li>Les tweets sont stokées comme les utilisateurs </li></ul>
  132. 136. Twissandra : un twitter like <ul><li>La ligne de temps et la ligne des utilisateurs doivent afficher les tweets par ordre d'arrivée </li></ul>
  133. 137. Twissandra : un twitter like <ul><li>Twissandra utilise pycassa , API de haut niveau pour accéder à cassandra
  134. 138. Pycassa utilise thrift, un framework d'appel de procédure à distance
  135. 139. Thrift gere 12 languages dont python </li></ul>
  136. 140. pycassa.columnfamily.ColumnFamily <ul><li>Opération sur la famille de colonne </li></ul>
  137. 141. pycassa.columnfamilymap.ColumnFamilyMap <ul><li>Pour mapper des objets avec des colonnes </li></ul>
  138. 142. Les autres librairies python pour cassandra <ul><li>Tragedy: http://github.com/enki/tragedy/
  139. 143. Lazy Boy: http://github.com/digg/lazyboy/tree/master
  140. 144. Telephus: http://github.com/driftx/Telephus/tree/master (Twisted) </li></ul>
  141. 146. Neo4J <ul><li>Modèle de données sous la forme de graphe
  142. 147. Embarqué
  143. 148. Stocké sur disque
  144. 149. Scalable
  145. 150. Framework de traversée
  146. 151. API simple et pratique </li></ul>
  147. 152. Le modele de données : Un graphe orienté <ul><li>Représentation sous la forme de: </li><ul><li>Noeuds
  148. 153. Relations entre les noeuds
  149. 154. De propriétés (au niveau des relations et noeuds) </li></ul></ul>
  150. 155. Exemple : modélisation des familles de produits <ul><li>Règle métier </li><ul><li>Une famille peut être une sous-famille
  151. 156. Dans une famille il peut y avoir des produits
  152. 157. Chaque famille de produits peut avoir des propriétés </li></ul></ul>
  153. 158. Exemple d'une instance de la base
  154. 159. Neo4j.py : binding python pour Neo4j <ul><li>Peut être utilisé indifférement avec </li><ul><li>Jython
  155. 160. Cpython </li></ul><li>Ouvrir une base de données neo4j </li></ul>
  156. 161. Neo4j.py : binding python pour Neo4j <ul><li>Créer une noeud </li></ul><ul><li>Créer une relation entre les noeuds </li></ul>
  157. 162. Neo4j.py : binding python pour Neo4 <ul><li>Traversals </li><ul><li>Sont définis en créant une classe qui hérite de neo4j.Traversal
  158. 163. Un objet Traversal doit définir les attributs suivants: </li><ul><ul><li>Types : la liste des relations qui vont être traversées pendant la traversé
  159. 164. Order : l'ordre de traversée
  160. 165. Stop : la condition de d'arrêt
  161. 166. Returnable : La définition des noeuds qui vont être retournés </li></ul></ul></ul></ul>
  162. 167. Neo4j.py : binding python pour Neo4
  163. 168. Références <ul><li>NoSQL </li><ul><li>http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
  164. 169. http://natishalom.typepad.com/nati_shaloms_blog/2009/12/the-common-principles-behind-the-nosql-alternatives.html
  165. 170. http://horicky.blogspot.com/2009/11/nosql-patterns.html </li></ul></ul>
  166. 171. References <ul><li>CouchDB </li><ul><li>http://www.unixgarden.com/index.php/web/couchdb-la-base-de-donnees-qui-change-tout
  167. 172. http://davidwatson.org/2008/02/python-couchdb-rocks.html
  168. 173. http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views
  169. 174. http://labs.mudynamics.com/wp-content/uploads/2009/04/icouch.html
  170. 175. http://horicky.blogspot.com/2008/10/couchdb-cluster.html </li></ul></ul>
  171. 176. Références <ul><li>Cassandra </li><ul><li>http://www.slideshare.net/Eweaver/cassandra-presentation-at-nosql
  172. 177. http://spyced.blogspot.com/2009/03/why-i-like-cassandra.html
  173. 178. http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model
  174. 179. http://wiki.apache.org/cassandra/ThriftExamples#Python
  175. 180. ttp://www.slideshare.net/stuhood/cassandra-talk-austin-jug
  176. 181. http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/ </li></ul></ul>
  177. 182. Références <ul><li>Neo4J </li><ul><li>http://www.slideshare.net/thobe/persistent-graphs-in-python-with-neo4j
  178. 183. http://python.mirocommunity.org/video/1597/pycon-2010-persistent-graphs-i
  179. 184. http://blog.neo4j.org/2010/03/modeling-categories-in-graph-database.html </li></ul></ul>

×