Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MongoDB-adoption.pdf

D8fc2580cfaca035f666d9e4ee79a7f7?s=47 mongodb
June 22, 2012
430

 MongoDB-adoption.pdf

D8fc2580cfaca035f666d9e4ee79a7f7?s=128

mongodb

June 22, 2012
Tweet

Transcript

  1. Toutes les raisons (et +) d’adopter MongoDB Adrien Mogenet 14

    juin 2012
  2. À propos • Est une première (!) • Pour convaincre

    sa hiérarchie • Pour convaincre ses équipes Cette présentation :
  3. /usr/bin/whoami • Un adepte de MongoDB, depuis + de 2

    ans • Dans un cadre professionnel, mais pas seulement • Pas un anti-MySQL
  4. #0 • Les vraies fausses raisons : • C’est écrit

    en C++ • C’est libre • Les gens qui contribuent sont sympathiques
  5. #1 • Facilité extrême : • Déploiement en 2 minutes

    • API simples et intuitives • ... mais possibilité d’écrire des requêtes complexes.
  6. #1 Demo

  7. Situations • Je suis un [DBA | Développeur | Patron],

    je veux me rendre compte rapidement des possibilités offertes, sans perdre une semaine de déploiement et configuration. • Je ne veux pas fondamentalement modifier mes méthodes d’interrogation des données.
  8. #2 • Souple : • Modèle de données simple «

    Ça, c’était avant. »
  9. Situations • Mon modèle relationnel s’est complexifié avec le temps,

    je vois une occasion de le simplifier. • Évolutions simplifiées • Rationaliser les motifs d’accès { _id: 1234, name: ‘Mogenet’, likes: [‘scala’, ‘haskell’] } { _id: 1234, name: ‘Mogenet’, likes: [‘scala’, ‘haskell’], sex: H }
  10. #3 • Produit performant : • Écrit en C++ (Pas

    de pauses « Stop The World » à cause du GC Java) • Indexes • Gestion de la mémoire efficace (Memory mapped files, LRU de l’OS)
  11. Situations • Je veux écrire massivement des données, et satisfaire

    10.000 connexions concurrentes avec accès aléatoires. • Je veux fournir des accès en temps réels à ces nouvelles données (monitoring, messagerie instantanée...)
  12. http://demo.hummingbirdstats.com/

  13. • Extensible, tolérant aux pannes • Pas de SPOF •

    Ajout de shards à la volée • = Extensibilité R/W #4
  14. Situations • Je suis dépassé par le succès, scaler MySQL

    me revient cher. • Je ne veux pas intervenir la nuit pour un problème de BDD.
  15. #5 • Intégration avec les nouvelles technologies • Node.JS •

    Hadoop • Azure • Scala • Talend (github.com/adrien-mogenet) • Mais aussi aux classiques (PHP, Java...)
  16. Situations • Typiquement, je suis une start-up jeune et innovante.

    • Je modernise mon infrastructure • Je veux une solution intégrable dans un S.I. aux technologies variées.
  17. #6 • Polyvalent : • Indexes géographiques • Système de

    fichiers distribué (GridFS)
  18. Situations • Éviter la multiplication d’outils « proches » •

    MongoDB « incite » les équipes à imaginer de nouveaux usages : • Utilisations d’informations géographiques • Stockage extensible
  19. #7 • Rentabiliser des données vaporeuses : • Agrégation de

    logs • Tracking Utilisation de Map/Reduce a posteriori
  20. Situations • Je veux prendre un avantage concurrentiel. Je veux

    mieux connaître mes clients, et mes futurs clients. • Je m’autorise à stocker un maximum de données inutiles à un instant T. Le cadre concurrentiel/législatif/autre change. Je rentabilise mes données.
  21. #8 • Communauté active : • Correction de bugs •

    Ajout de fonctionnalités pertinentes • Éco-système riche (IHM d’administration...)
  22. #8

  23. #8

  24. Situations • Besoin de garantie sur la longévité du projet.

    • S’approprier rapidement la solution via les documentations et les mailing-lists. • Assister à MongoDB Paris
  25. Conclusion • Simple • Performant • Fiable • Extensible •

    Communauté active
  26. { end: ‘Questions ?’ }