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