Commentaires sur : Retour d’expérience sur MongoDB partie 1 : présentation

Par : Amaury

Amaury — Thu, 29 Jul 2010 14:02:49 +0000

Ah, une dernière chose : MongoDB est assurément très intéressant. Mais je ne comprends pas que les questions « réseau » (sharding et réplication) n’aient pas été mieux intégrées à la conception du système.
Ce n’est que mon avis personnel, mais pour qu’une base noSQL se démarque des autres bases existantes, je pense qu’il lui faut traiter en premier ces aspects. Parce que sinon, autant stocker soi-même des fichiers JSON sur le disque… (je schématise, mais tu m’as compris)

Par : Amaury

Amaury — Thu, 29 Jul 2010 13:55:41 +0000

Ah, les bases de données non relationnelles !

Entre ceux qui s’y mettent parce que c’est à la mode, ceux qui y viennent parce qu’ils ne savent pas écrire de requêtes SQL qui tiennent debout, et ceux qui s’y intéressent parce qu’à force d’optimiser les performances de MySQL (à grands coups de dénormalisation et de sharding) il manipulent déjà un modèle qui n’a plus rien de relationnel…

L’exemple qui tue tout en faveur de MySQL, c’est le fait que Google AdSense tourne dessus. Ça pose quand même le truc.

Mais il n’empêche que même si les bases de données relationnelles reposent sur des technologies éprouvées, cela reste des technos « friables ». J’ai déjà vu une base MySQL se corrompre sous mes yeux, sans aucune raison ; ou une réplication avoir un « trou » inexplicable de plusieurs heures…

Il faut voir aussi que la scalabilité horizontale de ces bases est difficile à mettre en œuvre, à moins de payer cher (du Oracle RAC sur un gros cluster SUN, par exemple). Parce qu’un cluster MySQL, c’est 4 machines minimum (6 pour que ça commence à servir à quelque chose), et ce n’est pas évident à mettre en place.

Ce que j’aime bien avec la plupart des bases noSQL, c’est leur pragmatisme : Elles ont souvent certaines limites totalement assumées (eventual consistency, non-indexation de l’ensemble des contenus, …), ce qui permet d’être plus efficace sur d’autres aspects (montée en charge, scalabilité).

Une base orientée document comme MongoDB ne permet pas de faire des recherches complexes dans tous les sens comme le permet une base relationnelle. Mais c’est une solution pérenne dans le cas où la performance devient un jour un point critique.

Mais comme toujours, il n’y a pas une solution miracle qui marche à tous les coups. Il faut savoir utiliser les bons outils pour les bons usages.
Dans mon entreprise, on est en train de mettre en place un système où une base de données relationnelle permettra de faire des requêtes complexes à partir de « meta-données » (plus souple), alors qu’une base orientée document contiendra les données elles-mêmes (meilleure scalabilité), et le tout sera agrégé dans memcache (meilleure performance).

Par : Adrien Mogenet

Adrien Mogenet — Thu, 29 Jul 2010 09:09:23 +0000

Cassandra a aussi son gros soucis avec ses « supers colonnes » qui imposent de redémarrer les noeuds lors d’un ajout/modification…

Par : Richard

Richard — Wed, 28 Jul 2010 18:25:09 +0000

Très intéressant comme article.
Pour le projet auquel je m’occupe chez Dassault Systèmes on s’est intéressé également au NoSQL, notamment Cassandra et MongoDB.

Les deux projets sont intéressants. Les rapidités de Cassandra nous a « bien impressionné » aussi.

Cependant, le client PHP de Cassandra est assez lent et Cassandra possède apparement un fuite mémoire assez génante. Mais les deux projets sont encore jeune et pour l’instant on est reparti sur du MySQL, mais une migration dans le futur vers Cassandra ou MongoDB n’est pas à exclure. ^^