Les bases NoSQL et Python Youenn Boussard
Les bases de données <ul><li>Avant 1960 : organisation classique sous forme de fichier
1960 : 1er base de donnée : militaire , hiérarchique, sous forme d'arbre
1970 : Théorie sur l'algèbre relationnelle de Codd
1980 : troisième génération des sgbd :  les bases de données orientées objets </li></ul>
Le développement Internet <ul><li>1962 – Premier concept d'internet
1969 – RFC
1974 – Mise au point de la norme IP
1981 – 213 ordinateurs connectés
1989 – Naissance du World wide Web
2004 – Web 2.0, Facebook
2006 – twitter
186,7 millions de sites web </li></ul>
Web 2.0 et les limites des modèles relationnels <ul><li>Beaucoup de données </li><ul><li>Digg 3TB
Facebook 50TB
Ebay 2PB </li></ul><li>Beaucoup d'utilisateurs
Beaucoup de trafic
Et les bases relationnelles pour gérer tout cela ? </li></ul>
Le cas de  <ul><li>Partition verticale maître-esclave avec  </li></ul>
Maître esclave <ul><li>Réplication Maître esclave </li><ul><li>Un unique maître
Un ou plusieurs esclave
Toute les écritures vont sur le maître, répliquer sur les esclaves
Les lectures sont réparties entre les différents maîtres et esclaves </li></ul><li>Cela implique </li><ul><li>Le maître es...
Le maître est le point d'engorgement du système </li></ul></ul>
Partition Horizontale <ul><li>Réparties sur plusieurs noeuds
Les jointures sont déportées au niveau de l'application
Cela implique </li><ul><li>On n'est plus relationnel
Le fonctionnel devient compliqué
La maintenance aussi !! </li></ul></ul>
Et la disponibilité !! Des centaines de millions de  lignes Des millions de  lignes 14sec
Sytème distribué : Trois états <ul><li>C comme Consistence
A comme Availability (Disponibilité)
P comme Partition tolérance  </li></ul><ul>Dr. Eric Brewer </ul>CAP THEOREM = On ne peut avoir que  2 états en simultanée ...
ACID contre BASE <ul><li>Atomique
Cohérente
Isolée
Durable </li></ul><ul><li>Basically Available
Soft state
Eventually consistent </li></ul>
<ul><li>Non relationnelle
Distribuée
Open source
Scalable horizontablement </li></ul><ul>Une nouvelle Génération de base de donnée </ul>
 
 
CouchDB est <ul><li>Orienté document -> Pas de schéma, représentation des données telle quelle
Accessible via RESTful
Distribué, réplication incrémental, résolution de conflit bi directionnel
Donnée indexable et requetable suivant des vues
Ecrit en  </li></ul>
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 c...
RESTFul API REST est basé sur le protocole HTTP <ul><li>Lecture : GET /somedatabase/some_doc_id
Ecriture / update : PUT
Créer : POST
Supprimer : DELETE </li></ul>
Robuste <ul><li>N'écrase pas une donnée « commité »
Si le serveur tombe, il faut juste redémarrer CouchDB -> pas de « repair »
On peut prendre des snapshots avec des simples cp
Plusieurs niveaux de durabilité :  Choix entre synchroniser à toutes les mises à jours ou à la demande </li></ul>
Vues <ul><li>Méthodes pour aggréger et requeter les documents de la base de donnée
Les vues sont définies par des documents spéciaux les « designs documents »
Les vues sont écrites en javascript.
Prochain SlideShare
Chargement dans…5
×

Base NoSql et Python

4 613 vues

Publié le

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

1 commentaire
8 j’aime
Statistiques
Remarques
  • tres interessé par votre exposé merci
    avez vous liens ou sites web à me conseiller ?
    merci
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
4 613
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
171
Commentaires
1
J’aime
8
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Les données sont apparues avec les programmes. L&apos;exploitation des ces données est la raison d&apos;être de l&apos;informatique. Avec la gestion automatique des données, l&apos;entreprise et les états peuvent évoluer et rivaliser avec leur concurrent à l&apos;aide de nouveaux moyens. Base de donnée relationnelle : données dans de simple tables à deux dimentions -&gt; Suffisant pour toutes les applications ? Milieu des années 80 : conviction que tout les problemes seront résolue par les bases de donnée avec leur structure logique et physique, indépendante des applications. Année 90 avenement des technologies objets : Des estimations montrent en effet que les développeurs de programmes OO utilisant des bases de données relationnelles passent entre 25 et 40 % de leur temps à écrire un code mappant les objets aux tables relationnelles.
  • L’histoire de l’Internet remonte au développement des premiers réseaux de télécommunication. L’idée d’un réseau informatique, permettant aux utilisateurs de différents ordinateurs de communiquer, se développa par de nombreuses étapes successives. 1 Licklider présente l&apos;ordinateur comme un outil de communication et de partage des ressources. C&apos;est le concept de l&apos;Internet. 2 Request for comment – mise en place des norme qui régiront internet 4 Dès les années 1980, les techniques que nous reconnaissons maintenant comme les fondements de l’Internet moderne commencèrent à se répandre autour du globe 5 - La tendance depuis 2004 est l&apos;apparition d&apos;applications web 2.0 pour lesquelles l&apos;internaute joue un rôle participatif.
  • Digg est un site Internet communautaire qui a pour but de faire voter les utilisateurs pour une page web intéressante et proposée par un utilisateur Facebook
  • Lorsque l&apos;on veux scaler une base de données,une première solution peut être le partitionnement : Vertical : une base pour les livres, une base pour les CDs, etc Horizontal : une base pour les livre de A-M et une pour les livres de N-Z, …
  • On renonce à la normalisation des données Frais de gestion importante La scabilité a un coup qui devient important
  • consistence -&gt; tout les noeuds ont les meme données en meme temps disponible -&gt; le systeme est toujours disponible tant qu&apos;il y a un noeud tolérance à la partition -&gt; le systeme continue à fonctionner malgré la perte de message
  • Certaines données nous paraissent logiques d&apos;être consistantes mais cela est souvent du à notre inertie d&apos;esprit. Prenons le cas d&apos;une valeur indiquant le stock d&apos;un article. Si deux serveurs ont des valeurs non consistantes, il peut arriver qu&apos;un serveur considère qu&apos;il en reste un alors qu&apos;un autre qui a était mis à jour, sait qu&apos;il n&apos;en reste plus. Lorsque vous faites un achat et si par malchance vous acheter un livre qui n&apos;est plus en stock, le site marchand à deux possibilités : vous rembourser ou réapprovisionner le stock (je ne sais pas vous, mais cela m&apos;est déjà arrivé de recevoir un mail en disant que le produit était épuisé,après l&apos;avoir commandé) les sites ont fait leur choix ! Amazon a d&apos;ailleurs constaté qu&apos;un dixième de seconde de latence leur fait diminuer les ventes de 1%, et Google a remarqué qu&apos;une demi seconde de latence fait chuter le trafic d&apos;un cinquième.
  • Nosql : not only sql schema-free, easy replication support, simple API, eventually consistent / BASE (not ACID)
  • Les différents types de base de donnée : Relationnel -&gt; ACID Key-value -&gt; support get, put, delete sur leur cle Orientée colonne -&gt; utilise des tables mais pas de joins, les données sont stockées par colonne opposé aux traditionnels données stocké en ligne Orientée document -&gt; stocke des documents structurée en JSON ou en XML : facil de mapper avec des langages orientée objets CA : ont des difficultés avec les partitions et doivent répliquer leurs données (base de donnée) CP : ont des difficultés avec la disponibilités en gardant consistante leurs données sur l&apos;ensemble des noeuds AP : eventuellement consitant avec la replication et les verifications.
  • Elle est conçue avant tout pour les applications web Chaque document est composé de propriétés. Il n’y a aucune contrainte sur le nombre de propriétés d’un document, sur le type de ces propriétés... Le protocole permettant d’accéder à un serveur CouchDB est basé sur HTTP, avec une interface REST. Erlang est langage fonctionnel concurrent, temps réel et distribué basé sur le modèle d&apos;acteur. Il possède des fonctionnalités de tolérance aux pannes et de mise à jour du code à chaud permettant le développement d&apos;applications à haute disponibilité.
  • Il y a trois clés qui sont imposées par CouchDB : ● _id : l’identifiant unique du document ; ● _rev : le numéro de révision du document, géré automatiquement par le moteur CouchDB ; ● _attachments : les éventuels fichiers attachés à ce document. Stockée sous la forme de texte json ( Javascript Standard Object Notation) sérialisation d&apos;objet une chaîne de caractères doit être mise entre quotes : &amp;quot;ceci est un string&amp;quot;. ● un objet (qui supporte des données de type &amp;quot;clé&amp;quot; =&gt; valeur&amp;quot;) est représenté par des accolades : { &amp;quot;key1&amp;quot;: &amp;quot;value1&amp;quot;, &amp;quot;key2&amp;quot;:&amp;quot;value2&amp;quot; }. ● une liste de valeurs (un tableau) est représenté par des crochets : [ &amp;quot;value1&amp;quot;,&amp;quot;value2&amp;quot;]. ● JSON supporte les booléens : true et false ainsi que null. ● JSON supporte les nombres flottants : 21.34576. MVCC : multiversion concurrency control
  • REST : Representational State Transfer, est connu comme une alternative simple au protocole SOAP, pour interfacer des web services. Rest n’est pas un protocole, c’est un style d’architecture.
  • CouchDB uses an &amp;quot;optimistic concurrency&amp;quot; model Ie Couchdb rejete le document si celui si n&apos;est pas celui que vous avez envoyer ! Retrieve the document, take note of the _rev property that CouchDB sends along Decrement the quantity field, if it&apos;s greater than zero Send the updated document back, using the _rev property If the _rev matches the currently stored number, be done! If there&apos;s a conflict (when _rev doesn&apos;t match), retrieve the newest document version
  • Map Par exemple, considérons une liste de notes d&apos;examen, où chaque note est 1 point trop élevée. Une fonction map de s - 1 pourrait être appliquée sur chaque note s. Reduce comment faire si l&apos;on souhaite connaître la moyenne de la classe ? On peut définir une fonction de réduction qui diminue de moitié la liste par ajout d&apos;une entrée dans la liste des voisins, récursivement, on continue jusqu&apos;à ce qu&apos;il y ait seulement une (grosse) entrée, et divise la somme totale par l&apos;entrée originale d&apos;éléments pour avoir la moyenne).
  • 1 – Le plus gros cluster cassandra utilise 100 TB de donnée répartie sur 150 machine 2 – Les donnée sont automatiquement repliqués dur des mutliples noeud . La replication entre plusieurs data center est supporter . Les noeuds mort sont remplacer sans rupture de service 3 – Tout les noeuds sont identiques. Pas de point de failure 4 – Vous avez le choix entre une replication assynchrone et synchone pour chaque mis à jour 5 – Modele oriente colonne 5 – les lectures et les écritures augmente lineairement lorsqu&apos;on ajoute des machines 6 – Procedure via un commitlog de ne perdre aucune donnée
  • 1 – Au lieu de travailler sur des statc et rigide table avec des lignes et des colonnes vous travailler sur un graph flexible qui s&apos;adapte a vos besoin en ayant a votre disposition des noeud , des relation et des propriétés. 2 – C&apos;est l&apos;application qui embarque la base de donnée neo4j 3 – Une gestion de stokage optimiser pour stocker plusieurs billion de noeud, de relaction , de proprietes. La base de donnée peut etre répartie sur plusieurs disque 4 framework performant de traversé.
  • 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>

    ×