MongoDB Paris 2012: Toutes les Raisons (et +) D'Adopter MongoDB

A brief summary of the most important reasons about why choosing MongoDB might be a good solution in current common problems in IT. This talk is dedicated to software engineers, DBA, managers, CTO that could know MongoDB but don't see why they should deploy it in production.

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