Python et les bases de données non sql

3 645 vues

Publié le

Presentation I give in french to Pycon FR 2009.

Publié dans : Technologie, Business
0 commentaire
5 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 645
Sur SlideShare
0
Issues des intégrations
0
Intégrations
37
Actions
Partages
0
Téléchargements
113
Commentaires
0
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive


  • question de relations
    modélisations de données
    UMl, .... .
  • on essaie souvent de faire rentrer ses modeles de données dans sql à travers differents bricolages
    ex de Friendfeed
    ORM.
  • apres avoir reussi à faire rentrer ses données, vient svt l’étape de migration. sueurs froides, comment garantir l’intégrité ...
    Pb de scalabilité. Plus on a de données, plus les index grossissent, les joins prennent du temps ...
    Problème de sharding (au moins sur les bases de données opensource)
  • bien sur tout cela est possible.
    mais fatiguant et ennuyeux.
    Digg fait de moins en moins appels aux bases de données relationnelles.

  • part du principe qu’une interruption de service est inacceptable
    disponible = 2 noeuds au moins
    monter en charge est plus important que tout
    Au détriment parfois de la rapidité la rapidité
  • Tous les clients voient les mêmes données même lors de mise-à-jours concurrentes
    Tous les clients peuvent accéder à une version des données
    Les données peuvent être mises sur différentes base de données

  • Tous les clients voient les mêmes données même lors de mise-à-jours concurrentes
    Tous les clients peuvent accéder à une version des données
    Les données peuvent être mises sur différentes base de données




  • existe un système de vue/plugin en lua.
    a été ajouté un système de table (utilisé par cloudkit.) basé sur les colonnes. possibilité de schema less. (mais aussi systeme de hash, in memory ...)
    à quand un cloudkit en python ?
    tokyo distopia: recherche
  • tc se base sur pytc
    lightcloud offre un systeme de réplication master-master (couchdb), fail over automatique et load balancing. Se base sur pytyrant. possède un client. Manager pour prendre le controle des nodes, backups.... Client python, se base sur tyrant.
    comparé aux client ruby comme rufus, clients python limités. à vous de jouer.
  • similaire à memcached, mais les données sont non volatiles
    conservation en ram et écris de temps en temps sur le disque (pas de consistence)
    serveur de structure de données
    réplication non bloquante en arrière plan (master -> slave)
    bon serveur de cache/session ?

  • le client python au contraire du client ruby ne permet pas le sharding.



  • couchdb-python n’a pas encore de version stable pour couchdb 0.9 et trunk
    couchdb-python: serveur de vue, non threadsafe, basé sur httplib2 (pb py26)
    couchdbkit entierement dynamique. helper pour les vues, compatible py25/py26, fonctionne avec les dernieres versions de couchdb. compatible avec couchapp.
  • parfait pour tout ce qui requiert un accès rapide au données (log, ...) qui ne demande pas de consistance.

  • le plus connu en non opensource est bigtable (Google). Repose sur un master qui a la connaissance de tous les nodes. scalabilité horizontable. Plus rapide d’interroger sur des colonnes. Possibilité de ne prendre que certaines colonnes ....

  • thrift est un framework pour générer des interfaces et des services dans différents langages
  • (rien à voir avec le module plone)


  • différent des bases de donnnées orientées documents





  • Python et les bases de données non sql

    1. 1. PYTHON ET LES BASES DE DONNÉES NON SQL Benoît Chesneau 31/05/2009 PYCON FR 2009
    2. 2. introduction 1998, CanalFood, les menus de restaurants 2008, créé Enki Multimedia minimal web Échanger des resources
    3. 3. BASES DE DONNÉES RELATIONNELLES
    4. 4. Faire rentrer des carrés dans des ronds
    5. 5. Modélisation de données Migration difficile Problèmes de scalabilité
    6. 6. Ça fatigue.
    7. 7. DES DONNÉES VARIÉES ET TOUJOURS PLUS NOMBREUSES.
    8. 8. ACID • Atomicity: tout ou rien • Consistency: données toujours accessibles • Isolation : distinction écritures/lectures • Durability: pas de mensonges
    9. 9. CAP • Consistency: • Availability: • Partition tolerance
    10. 10. BASE • Basically Available • Soft state • Eventually consistant • Tout le monde le fait (google, amazon, facebook...)
    11. 11. Clé/Valeur
    12. 12. MEMCACHED • Pas de persistence, Ram seulement • Rapide • Utilisé principalement pour du cache • Tout le monde l’utilise
    13. 13. MEMCACHED • python-memcached: http://www.tummy.com/ Community/software/python-memcached/ • ...
    14. 14. TOKYO CABINET TYRANT • Persistent sur le disque • Performant • Activement développé • Système de réplication équivalent à MySQL. • tokyo distopia & index inversé
    15. 15. TOKYO CABINET TYRANT • pytc: http://pypi.python.org/pypi/pytc • tc : http://github.com/rsms/tc/tree/master • pytyrant: http://code.google.com/p/pytyrant/ • Lightcloud: http://opensource.plurk.com/ LightCloud/
    16. 16. REDIS • Pas seulement un dépôt clé/value • Valeurs peuvent être des listes, sets, strings, entiers... • Possibilité de prendre des ensemble de valeurs • réplication
    17. 17. REDIS • Client python officiel • http://code.google.com/p/redis/
    18. 18. BDs orientées Document
    19. 19. COUCHDB • Réplication asynchrone • Documents en JSON • Vues automatiquement incrementées • map/reduce
    20. 20. COUCHDB • couchdb-python: http://code.google.com/ p/couchdb-python/ • couchdbkit: http://bitbucket.org/benoitc/ couchdbkit/ • couchapp: http://github.com/couchapp/ couchapp/
    21. 21. • Rapide • JSON ou BSON (json binaire avce des extensions) • Réplication asynchrone • Système d’index • Système de requête avancé (adhoc) • Gestion de références entre documents (nested documents)
    22. 22. • pymongo : http://github.com/mongodb/ mongo-python-driver/tree/master • app-engineconnector : http://github.com/ mongodb/mongo-appengine-connector
    23. 23. BDs orientées colonnes
    24. 24. HBASE • Sous-projet hadoop. basé sur hfs • entierement distribué • bigtable like • map/reduce et cascading
    25. 25. HBASE • Accès en python via jython. • Thrift
    26. 26. CASSANDRA • Facebook • Mélange de Dynamo et BigTable • éventuellement consistant • facilité d’administration
    27. 27. CASSANDRA • Thrift
    28. 28. HYPERTABLE • http://hypertable.org/ • Thrift
    29. 29. BDs objets
    30. 30. • Python object persistence • problème de la migration • Gestion des conflits en lecture (écriture?) • Atomicité • Scalabilité possible via ZEO et ZRS (payant)
    31. 31. Questions
    32. 32. @benoitc
    33. 33. Cette création est mise à disposition selon le Contrat Paternité 2.0 France disponible en ligne http:// creativecommons.org/licenses/by/2.0/fr/ ou par courrier postal à Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
    34. 34. SOURCES TOUTES LES SOURCES SONT RÉUTILISABLES (CC) 1 2 3 4 5 6 7 8 9 10 1. http://www.flickr.com/photos/protolog/359340112/ 6.http://flickr.com 2. web (unknown) 7.http://flickr.com 3.http://www.flickr.com/photos/clauer/2051770839/ 8.http://www.flickr.com/photos/-bast-/349497988/ 4.http://www.flickr.com/photos/50895074@N00/2702417725/ 9.http://www.flickr.com/photos/piaser/3020094082/ 5.http://flickr.com 10.http://www.flickr.com/photos/-bast-/349497988/

    ×