MongoDB-adoption.pdf

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 ?’ }