Nantes JUG - Traçabilité dans une architecture distribuée avec Node.js et MongoDB
Toutes les raisons d'adopter MongoDB
-
Upload
adrien -
Category
Technology
-
view
2.690 -
download
2
description
Transcript of Toutes les raisons d'adopter MongoDB
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 ?’ }