Toutes les raisons (et +)  d’adopter MongoDB       Adrien Mogenet                        14 juin 2012
À proposCette présentation :    • Est une première (!)    • Pour convaincre sa hiérarchie    • Pour convaincre ses équipes
/usr/bin/whoami• Un adepte de MongoDB, depuis + de 2 ans• Dans un cadre professionnel, mais pas  seulement• Pas un anti-My...
#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...
#1Demo
Situations• Je suis un [DBA | Développeur | Patron], je  veux me rendre compte rapidement des  possibilités offertes, sans...
#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.     { _id: 1234...
#3• Produit performant : • Écrit en C++    (Pas de pauses « Stop The World » à cause du GC Java) • Indexes • Gestion de la...
Situations• Je veux écrire massivement des données, et  satisfaire 10.000 connexions concurrentes  avec accès aléatoires.•...
http://demo.hummingbirdstats.com/
#4• Extensible, tolérant aux pannes • Pas de SPOF • Ajout de shards à la volée • = Extensibilité R/W
Situations• Je suis dépassé par le succès, scaler MySQL  me revient cher.• Je ne veux pas intervenir la nuit pour un  prob...
#5• Intégration avec les nouvelles technologies • Node.JS • Hadoop • Azure • Scala • Talend (github.com/adrien-mogenet) • ...
Situations• Typiquement, je suis une start-up jeune et  innovante.• Je modernise mon infrastructure• Je veux une solution ...
#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 :...
#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...
#8• Communauté active : • Correction de bugs • Ajout de fonctionnalités pertinentes • Éco-système riche (IHM d’administrat...
#8
#8
Situations• Besoin de garantie sur la longévité du  projet.• S’approprier rapidement la solution via les  documentations e...
Conclusion• Simple• Performant• Fiable• Extensible• Communauté active
{ end: ‘Questions ?’ }
Prochain SlideShare
Chargement dans…5
×

Toutes les raisons d'adopter MongoDB

3 487 vues

Publié le

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.

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 487
Sur SlideShare
0
Issues des intégrations
0
Intégrations
311
Actions
Partages
0
Téléchargements
74
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Toutes les raisons d'adopter MongoDB

  1. 1. Toutes les raisons (et +) d’adopter MongoDB Adrien Mogenet 14 juin 2012
  2. 2. À proposCette présentation : • Est une première (!) • Pour convaincre sa hiérarchie • Pour convaincre ses équipes
  3. 3. /usr/bin/whoami• Un adepte de MongoDB, depuis + de 2 ans• Dans un cadre professionnel, mais pas seulement• Pas un anti-MySQL
  4. 4. #0• Les vraies fausses raisons : • C’est écrit en C++ • C’est libre • Les gens qui contribuent sont sympathiques
  5. 5. #1• Facilité extrême : • Déploiement en 2 minutes • API simples et intuitives • ... mais possibilité d’écrire des requêtes complexes.
  6. 6. #1Demo
  7. 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. 8. #2• Souple : • Modèle de données simple « Ça, c’était avant. »
  9. 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. 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. 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. 12. http://demo.hummingbirdstats.com/
  13. 13. #4• Extensible, tolérant aux pannes • Pas de SPOF • Ajout de shards à la volée • = Extensibilité R/W
  14. 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. 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. 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. 17. #6• Polyvalent : • Indexes géographiques • Système de fichiers distribué (GridFS)
  18. 18. Situations• Éviter la multiplication d’outils « proches »• MongoDB « incite » les équipes à imaginer de nouveaux usages : • Utilisations d’informations géographiques • Stockage extensible
  19. 19. #7• Rentabiliser des données vaporeuses : • Agrégation de logs • Tracking Utilisation de Map/Reduce a posteriori
  20. 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. 21. #8• Communauté active : • Correction de bugs • Ajout de fonctionnalités pertinentes • Éco-système riche (IHM d’administration...)
  22. 22. #8
  23. 23. #8
  24. 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. 25. Conclusion• Simple• Performant• Fiable• Extensible• Communauté active
  26. 26. { end: ‘Questions ?’ }

×