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.

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

2. À propos
Cette présentation :
• Est une première (!)
• Pour convaincre sa hiérarchie
• Pour convaincre ses équipes

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.
{ _id: 1234, name: ‘Mogenet’, likes: [‘scala’, ‘haskell’] }
• Évolutions simplifiées
{ _id: 1234, name: ‘Mogenet’, likes: [‘scala’, ‘haskell’], sex: H }
• Rationaliser les motifs d’accès

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. #4
• Extensible, tolérant aux pannes
• Pas de SPOF
• Ajout de shards à la volée
• = Extensibilité R/W

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