Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Super marmite-pourquoi-choisir-mongodb

2 000 vues

Publié le

Pourquoi Supermarmite a choisi MongoDB comme backend

Publié dans : Technologie
  • Soyez le premier à commenter

Super marmite-pourquoi-choisir-mongodb

  1. 1. supermarmite It’s cooking up in your neighborhoodConstruire une application Géolocalisé avec mongoDB
  2. 2. Un réseau social deproximité pourrechercher etpartager vos petitsplatsfaits maison !
  3. 3. Maintenant qu’on a l’idée, il faut la développer.
  4. 4. Mais surtout choisir son backend
  5. 5. Quel sont nos besoins ?
  6. 6. Gestion de requête géospatial
  7. 7. Gestion de la panne
  8. 8. Scalabilité horizontale
  9. 9. Aide au reporting
  10. 10. Evolution simplifiée et rapide de notre schéma de base de donnée
  11. 11. Gestion des fichiers avec scalabilité horizontale
  12. 12. Tout est déjà dans MongoDB DE BASE
  13. 13. Gestion de la géolocalisation
  14. 14. DéfinitionLa géolocalisation ou géoréférencement estun procédé permettant de positionner un objet(une personne,...) sur un plan ou une carte àlaide de ses coordonnées géographiques. source: Wikipedia ( http://fr.wikipedia.org/wiki/Geolocalisation )
  15. 15. Pour faire des requêtes de proximité
  16. 16. Il faut faire des requêtes Géospatiale
  17. 17. Comment faire avec MongoDB ?
  18. 18. Insertion des coordonnées GPS :db.addresses.insert({loc:{lat: 40.739037, long: 73.992964}}) Récupérer par google map API
  19. 19. Création de l’indexpour requêter en géospatial 2D db.addresses.ensureIndex({loc:"2d"})
  20. 20. On peux faire nos requêtes pour savoir qui est à coté avec $near db.addresses.find({loc: { $near: [50,50]}})
  21. 21. Et même limiter en distance avec $maxDistancedb.addresses.find({loc: { $near: [50,50], $maxDistance : 5}})
  22. 22. Attentionla distance est exprimée en Radian donc : 1km == 0,111°
  23. 23. Gestion de la panne
  24. 24. Utilisation du ReplicatSet
  25. 25. Plusieurs serveurs Master/Slave
  26. 26. Master change si le précédent master devient indisponible
  27. 27. On limite au maximum les interruptions de service
  28. 28. Scalabilité horizontale ?
  29. 29. Le sharding
  30. 30. Plusieurs serveurs se partagent les données
  31. 31. On a donc fictivement une capacité illimitée
  32. 32. Répartition des données au plus prêt de leur demande
  33. 33. Aide au reporting ?
  34. 34. Map/Reduce
  35. 35. Calcul en BDDmise à jour d’une Collection
  36. 36. On obtient ainsi une collection par graphique souhaité
  37. 37. Mise à jour simplifiée
  38. 38. Création des collections automatiquement
  39. 39. Tous les documents peuvent avoir un schéma hétérogène
  40. 40. On peux donc faire ses migrationsdurant l’utilisation de son application
  41. 41. Cela permet une facilité dansl’évolution de son schéma globale
  42. 42. Gestion des fichiers ?
  43. 43. GRIDFS
  44. 44. Permet d’avoir l’avantage du sharding
  45. 45. Peux remplacer des solutions comme S3
  46. 46. Pas de limitations du nombre de fichiers
  47. 47. Déplacer au plus proche despersonnes en faisant la demande
  48. 48. On a ainsi pu économiser sur plusieurs applications indépendante.
  49. 49. Tout est dans MongoDB
  50. 50. Merci MongoDB
  51. 51. Questions ?

×