Drupal et le NoSQL - drupagora 2011

4 961 vues

Publié le

Panorama des technologies NoSQL compatibles avec Drupal 7 et 6 à fin 2011: objectifs globaux, tâches fonctionnelles, techniques de mise en oeuvre, coûts, bonnes pratiques, compromis, modules disponibles.

Avec une bibliographie.

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

Aucun téléchargement
Vues
Nombre de vues
4 961
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 078
Actions
Partages
0
Téléchargements
48
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Drupal et le NoSQL - drupagora 2011

  1. 1. Drupal et le NoSQL Frédéric G. MARAND OSInethttp://drupal.org/user/27985 http://drupal.org/node/1121720
  2. 2. • "Drupal et le NoSQL" de Frédéric G. MARAND est mis à disposition selon les termes de la licence Creative Commons Paternité - Partage à lIdentique 2.0 France.• Les autorisations au-delà du champ de cette licence peuvent être obtenues à mailto:sales@osinet.fr
  3. 3. Drupal NoSQL : sommaire● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  4. 4. Drupal NoSQL● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quels tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  5. 5. Objectifs : supporter les volumes• Contenus stables : entités Drupal• Flux volatils : ordres de grandeur décart• Exemple, pour U utilisateurs – nodes : n*U – comments : c*n*U – user relationships ; r*U² – activités : a*(n+c*n+r*U+ ...)*U
  6. 6. Objectifs : réduire la complexité• CCK, SQL Field storage : stockage en étoile – nombreuses jointures – requêtes coûteuses à exécuter ou à écrire• Bases documentaires : – 1 enregistrement = 1 document complet. – requêtes économiques à exécuter et à écrire
  7. 7. Objectifs : performance
  8. 8. Objectifs : performance• Exemple Figaro Plus : MySQL→MongoDB – MySQL Slow Queries rate: -85% – Durée extraction du coeur de page: -98%• Alternatives SQL : – Libres : PGSQL, SQLite – Propriétaires : MSSQL, DB2, Oracle – MongoDB avec DBTNG ! • "You must be really desperate to drive a NoSQL database with SQL commands." - chx
  9. 9. Drupal NoSQL● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  10. 10. Tâche : backup hors site• Cest AUSSI une tâche de production• backup_migrate_* – FTP – Amazon S3 – NodeSquirrel (wrapper S3) – Rackspace Cloudfiles
  11. 11. Tâche : déport des blocs• Limitations du cache de blocs – node_access en D6• Drupal 7 – le module block nest plus obligatoire – mongodb_block – possibilité dautres implémentations
  12. 12. Tâche : antémémoireProfusion de solutions D6, convergence en D7• In-process, local par frontal : – apc, eaccelerator, xcache, zend – incohérence entre frontaux• Pools mémoire réseau : memcached• Bases NoSQL : mongodb_cache, redis
  13. 13. Tâche : stockage des champs• Field Storage D7 - Inapplicable en CCK• MongoDB : référence Examiner.com – http://drupal.org/project/mongodb• Riak - pas encore dEFQ – http://drupal.org/project/riak_field_storage• ElasticSearch - pas encore dEFQ – http://drupal.org/sandbox/damz/1234634
  14. 14. Tâche : file storage• Multiples solutions D6 ± hackées• Storage API : Stockage / Accès – FTP / non spécifique – AWS S3 / CDN AWS Cloudfront – Rackspace CloudFiles / CDN Limelight• Core Streams Wrappers – Microsoft Azure
  15. 15. Tâche : exclusion mutuelle• Le "verrouillage" core de lock.inc – souffre de problèmes à forte charge – fonctionne en attente active• Alternative : redis.lock.inc – attente passive – utilisation des mutex Redis
  16. 16. Tâche : MapReduce• Distribution de charge liée aux données stockées sur un cluster• MongoDB – Directement utilisable depuis mongodb – Pas dhabillage Drupal spécifique• Riak – Habillage Drupal dans riak_field_storage
  17. 17. Tâche : file dattente (queue)• Alternatives SQL, dont AdvancedQueue : http://drupal.org/project/advancedqueue• MongoDB: – Référence Examiner.com – http://drupal.org/project/mongodb• Redis – http://drupal.org/project/redis – Non lié à Resque et autre files basées sur Redis
  18. 18. Tâche : recherche• Core inadapté aux sites professionnels• Principaux moteurs interfacés – SOLR SaaS : Acquia Search, Adyax Cloud Search – Sphinx, Google• CouchDB : couchdb_node – stockage automatique des nodes dans le stockage documentaire – pas de fonctions de recherche
  19. 19. Tâche : sessions• PHP – natif : fichiers – PECL : memcached (pas memcache!)• Drupal core: SQL• Alternatives : – handler du module Memcache – handler MongoDB Attention : particularités Debian/Ubuntu
  20. 20. Tâche : journal derreurs• 2 versions core : dblog / syslog• Fichiers plats• MongoDB – capped collections. Avantages et risques – synthèse des événements• Redis : redis_watchdog• Tokyo Tyrant
  21. 21. Drupal NoSQL● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  22. 22. Technique : accès aux données• API spécifiques – AWS SimpleDB http://drupal.org/node/482318• EntityFieldQuery – Modèle dutilisation dual – Lien avec le FieldStorage• Document Storage D8 – Natif vs DBTNG
  23. 23. Technique : intégration Views• Interfaçage DBTNG – http://drupal.org/project/mongodb_dbtng• Greffon EFQ – http://drupal.org/project/efq_views
  24. 24. Technique : Drupal 6 CCK• Core : La plupart des API sont utilisables – natif ou backports (Queue API) – nécessité de patches core multiples• CCK lié à SQL, pas de field storage NoSQL – hooks pre-load / post-save – patches intrusifs ou non, conséquences – Exemple : Freerice → > 8E9 enregistrements
  25. 25. Drupal NoSQL● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  26. 26. Coûts : nature des coûtsInvestissement Charges récurrentes• Licences • Licences perpétuelles périodiques• Développement • Hosting spécifique • Support ← Formation →
  27. 27. Coûts : licences• Cas général Drupal: licences "libres" – MongoDB : serveur AGPL 3, clients Apache 2 – Redis : BSD 3 clauses – CouchDB, Riak : Apache 2 – Tokyo : LGPL 2.1• Outils propriétaires – Oracle NoSQL – Progress ObjectStore, etc
  28. 28. Coût : développement• Limites du support contrib – Volume de développement• Limites de la communauté – Rareté de la ressource – Coût des spécialistes• Nécessité du test unitaire/intégral
  29. 29. Coûts : formation• Corollaire du coût de développement – pénurie de la ressource "développeur" – risque technologique• Investissement ou charge ? – réduction du coût de développement – réduction du TCO – récurrence : turnover, technologie
  30. 30. Coût : hébergement SaaS• Base NoSQL : AWS SimpleDB• Fichiers : Azure, CloudFiles, S3...• Backup : CloudFiles, S3...• Recherche : – SOLR : Acquia Search, Adyax Cloud Search – Antidot AFS@Web, Exalead On Demand ...
  31. 31. Coûts : support• Pas disponible en libre non commercial : – ElasticSearch, Redis• Coûts en libre commercial : – 10Gen pour MongoDB • 2500 USD/serveur/an / 4000 USD/serveur/an (Gold) – Couchbase pour CouchDB • 2500 USD/serveur/an / 4500 USD/serveur/an (Premier) – Riak : «contact us»
  32. 32. Drupal NoSQL : sommaire● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  33. 33. BCP (MongoDB) : modélisation 1• Ne pas chercher à simuler SQL JOIN – requêtes multiples avec A/R code – Field Storage : stockage entité cf index couvrant• Le document comme cache – données pour la partie "recherche" du find() – données additionnelles dans un cache interne – logique côté client pour scaling horizontal – penser aux multikeys
  34. 34. BCP (MongoDB) : modélisation 2• Concevoir les documents pour lindexation – "1 index par requête" vs "économiser les index" • 40 index maximum par collection • MongoDB modifié pour supporter FieldStorage – Utiliser des index couvrants• Conformité : penser à l"après" – préserver laccès après la vie de lapplication – la seconde vie du cache interne – Exemple : craigslist
  35. 35. BCP (MongoDB) : Réalisation• La requête la plus rapide est celle quon nexécute pas !• Cache != DB : savoir choisir• Typage vs pratique PHP/Drupal/MySQL• Tests en vraie grandeur durant le développement – volume – charge
  36. 36. BCP : Production• Instrumentation : de lalerte à la réparation – Alertes et réactions: Monit, Nagios – Mesure en continu • Surveillance individuelle : Munin, Cacti, • Synthèse : Ganglia – Logs serveur : activer ET utiliser• Tolérance aux pannes et à la charge – Réplication ET sauvegardes, deux besoins
  37. 37. Drupal NoSQL : sommaire● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  38. 38. Compromis : flexibilité schéma• Schéma relationnel – flexibilité illimitée – méthodes de design reconnues et éprouvées• Document storage (MongoDB) – pas de schéma par "table" (collection) – à grande liberté, grandes responsabilités – pas doutils pratiques comme PMA, Workbench
  39. 39. Compromis : durabilité• Relationnel : – évolutivité illimitée – accessibilité hors application limitée – encore plus limitée dans Drupal sans FK• Document (MongoDB) – évolutivité en production difficile – accessibilité hors application PEUT être facile : auto-contenus
  40. 40. Compromis : CAP• Théorème de Brewer (CAP theorem) :« it is impossible for a distributed computer system tosimultaneously provide all three of the following guarantees:Consistency, Availability, Partition tolerance »• Bases SQL : potentiel ACID – Pas systématique (MyISAM)• MongoDB, bases K/V : "BASE" – Basically Available, Soft state, Eventually consistent
  41. 41. Compromis : sharding• Drupal : pas de sharding applicatif intégré• Exemple avec MongoDB http://www.mongodb.org/display/DOCS/Sharding+Introduction
  42. 42. Compromis : répliques et clusters• MySQL – par défaut : réplication master/slave • Pressflow 6, core 7 • Utilisation réelle : limites core 6/7 – MySQL cluster• MongoDB – master/slave dans le module – replicaSet dans MongoDB ≥ 1.6
  43. 43. Compromis : support• MySQL = Oracle, membres ODBA, SkySQL• NoSQL : – Communautaire : valeur et limitations – Professionnel • CouchDB : Couchbase, Cloudant • MongoDB : 10Gen • Redis : vmWare • Ryak : Ryak
  44. 44. Compromis : licencesLogiciel Licence par défautDrupal et contributions drupal.org GPL 2.0 et suivantesMongoDB - serveur AGPL 3.0MongoDB - clients Apache 2.0MongoDB - documentation Creative CommonsRedis BSD 3 clauseCouchDB Apache 2.0Riak Apache 2.0Tokyo Tyrant / Tokyo Tycoon LGPL 2.1 ● Etes-vous concerné ? ● Agir en conséquence
  45. 45. Drupal NoSQL● Quels objectifs ● Quels coûts ? globaux ? ● Quelles bonnes● Quelles tâches pratiques ? fonctionnelles ? ● Quels compromis ?● Quelles techniques ● Quels modules de mise en œuvre ? contribués ?
  46. 46. Modules : Bases Document• MongoDB http://drupal.org/project/mongodb• CouchDB http://drupal.org/project/couchdb• ElasticSearch http://drupal.org/sandbox/damz/1234634• Amazon SimpleDB http://drupal.org/project/awssdk
  47. 47. Modules : clef/valeur• Apache Cassandra http://drupal.org/project/cassandra• Redis http://drupal.org/project/redis http://drupal.org/project/redis_queue http://drupal.org/project/redis_watchdog• Ryak http://drupal.org/project/riak_field_storage• Tokyo Cabinet / Tokyo Tyrant http://drupal.org/node/844354
  48. 48. ALLER PLUS LOIN
  49. 49. Merci de votre attention ! fgm@osinet.frhttp://drupal.org/user/27985 http://drupal.org/node/1121720 Audit, conseil, formation Drupal

×