MongoDB chez sfr.fr

Antoine Raith, Jérome Leleu, Mathieu Blanc et David Rault présentent un rétour d’expérience de l’adoption de MongoDB chez sfr.fr.

  • A propos des intervenants :
  • A propos de l’événement : Mongo Day Paris s’est déroulé chez Xebia le 2 Février 2012.

Les slides


Tous les podcasts Xebia France :

  • Subscribe with iTunes
  • Xebia France Podcast Feed

Billets sur le même thème :

9 commentaires

  • Merci pour ce retour d’experience très enrichissant.

  • Pour compléter mon propos suite à cette présentation, la seconde mise en production avec Mongo a été un succès.
    Quelques chiffres :
    - Volumétrie moyenne d’écriture : 75k/heure (~ 20 écritures/s)
    - Volumétrie moyenne de lecture : 1065k/heure (~ 300 lectures/s)
    - Temps moyen de lecture/écriture : 7 ms
    - Taux moyen d’erreur : 0,18%

  • C’est bien de proposer de nouveaux outils mais c’est mieux de les justifier :
    Pour cela, y a pas mieux que de faire des tests de comparaison entre l’ancien outil et le nouveau. Or ceci n’a malheureusement pas été fait à ma connaissance !

  • Bonjour,
    Merci pour cette présentation très enrichissante. J’avais une petite question pour Jérôme. Finalement quelle solution avez vous retenu pour l’accès aux données du projet user profil ? Ecrire sur le master avec acknowledge et lire sur les slaves ou écrire sans aknowledge et lire sur le master ?
    Merci d’avance pour votre réponse.

  • Bonjour,

    Finalement, je suis parti sur l’option « Lecture / écriture sur master », cela me paraissait plus sûr. J’ai préparé le mode « Ecriture master / lecture slaves », mais je l’ai pas encore testé en production.
    Cdlt,
    Jérôme

  • OK merci pour la réponse et bon continuation pour la suite ;-)

  • Bonjour,

    Juste un nouveau message pour aller plus loin dans ce retour d’expérience.

    Contents de MongoDB, nous avons commencé à l’utiliser de plus en plus. Nous sommes montés à des volumétries 3 à 4 fois supérieures à celles que j’avais déjà indiquées et c’est là que nous avons commencé à avoir des incidents et des taux d’erreurs sur les écritures avec acknowledge (WriteConvern.SAFE) très importants, de l’ordre de 6%. En ajoutant de nouveaux serveurs (2 -> 6), nous sommes revenus à un taux d’erreurs quasi nul.

    En conclusion, je dirai que MongoDB est un produit très performant avec deux faiblesses principales :
    - l’écriture est bloquante pour tout le process serveur, ce qui peut poser des problèmes de performance. Ce ne sera plus le cas en version 2.2, on peut aussi créer plusieurs process MongoDB serveurs pour dépasser cette limitation
    - le mécanisme de sharding à base de mongos et de config server reste jeune et source de problèmes. Si on peut se passer de sharding, on simplifie grandement l’architecture et on élimine les plantages des mongos et config server.

    Cdlt,
    Jérôme

  • Bonjour,
    MongoDB est seulement la mode! Est-ce que vous avez calculé le coût de support après. Je vois qu’il n’y aucune innovation dans MongoDB (un mixe des types de données). Si seulement pour stocker les données, pourquoi MongoDB? Pour les autres tâches comme agrégation, un petit module programmé en java/C/C++ peut calculer 1000 fois plus vite. Je ne comprends pas le monde actuel, vous inventez des arguments juste pour dépenser l’énergie et l’argent inutilement. Ce que une base de données basique ne permet pas de faire peut etre accompli par un module supplémentaire programmé… Vous voulez mixer tous dans un outil: stocker données, calculer… Vous gagner quoi a la fin? Désolé, mais avec mongoDB, je ne suis pas convaincu.

  • Bonjour,
    je vous remercie pour ce superbe présentation très intéressantes. bonne continuation…

Laisser un commentaire