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

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

/usr/bin/whoami • Un adepte de MongoDB, depuis + de 2 ans • Dans un cadre professionnel, mais pas seulement • Pas un anti-MySQL

#0 • Les vraies fausses raisons : • C’est écrit en C++ • C’est libre • Les gens qui contribuent sont sympathiques

#1 • Facilité extrême : • Déploiement en 2 minutes • API simples et intuitives • ... mais possibilité d’écrire des requêtes complexes.

#1 Demo

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.

#2 • Souple : • Modèle de données simple « Ça, c’était avant. »

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 }

#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)

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...)

http://demo.hummingbirdstats.com/

• Extensible, tolérant aux pannes • Pas de SPOF • Ajout de shards à la volée • = Extensibilité R/W #4

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.

#5 • Intégration avec les nouvelles technologies • Node.JS • Hadoop • Azure • Scala • Talend (github.com/adrien-mogenet) • Mais aussi aux classiques (PHP, Java...)

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.

#6 • Polyvalent : • Indexes géographiques • Système de fichiers distribué (GridFS)

Situations • Éviter la multiplication d’outils « proches » • MongoDB « incite » les équipes à imaginer de nouveaux usages : • Utilisations d’informations géographiques • Stockage extensible

#7 • Rentabiliser des données vaporeuses : • Agrégation de logs • Tracking Utilisation de Map/Reduce a posteriori

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.

#8 • Communauté active : • Correction de bugs • Ajout de fonctionnalités pertinentes • Éco-système riche (IHM d’administration...)

#8

#8

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

Conclusion • Simple • Performant • Fiable • Extensible • Communauté active

{ end: ‘Questions ?’ }