Et si on optimisait…

Je discutais dernièrement avec d’autres développeurs au sujet de la manière optimale pour conserver des données non-structurées dans une base de données.  Plus précisément nous cherchions à entrer données descriptives liées à un profil utilisateur.  Nous utilisions une base de données relationnelle pour le reste du projet et il me semblait normal de continuer avec le même système.  Nous avions même trouvé une structure permettant de faire le travail.  Elle était cependant un peu lourde.  Ceci a soulevé des craintes sur les performances qu’il était possible d’atteindre chez quelques personnes.  Quelqu’un a alors proposé d’utiliser une base de données non relationnelle pour cette section du logiciel.  La base de données en question était MongoDB.

Je dois avouer que j’aime bien les bases de données non relationnelles.  Elles sont fantastiques pour obtenir des performances époustouflantes.  En plus, elles possèdent des caractéristiques très intéressantes pour la réplication des données.  Les bases de données non relationnelles sont même maintenant utilisées dans des systèmes d’envergure tel que Facebook et Amazon.  Cependant, elles ne me semblent pas appropriées pour toutes les utilisations.  Étions-nous devant l’un de ces cas ou devant un exemple classique de sur-optimisation?

Observons nos deux boxeurs quelques instants.  Dans le coin droit, nous avons la base de données NoSQL: le nouveau prétendant au titre.  Il est rapide, flexible et capable de servir le web en entier si on le réplique assez souvent.  Dans le coin gauche, nous avons la base de données relationnelle.  Le champion en titre au punch puissant et précis.  Le champion place un uppercut dévastateur sur la pommette gauche du challenger et le met KO du premier coup.  En effet, une base de données NoSQL doit absolument être répliquée pour obtenir un niveau de fiabilité suffisant pour une entreprise.  Avec une seule instance, c’est un boxeur à la machoire de verre.

Il y aura d’autres matchs et les deux champions ont leur place.  Le truc est juste de les utiliser à bon escient.  Pour revenir au problème principal, je suis certain que c’est un cas de sur-optimisation.  Après tout nous n’avons pas encore rencontré de véritable problème de rapidité.  Le logiciel n’est pas encore développé et une base de données relationnelle permet d’aller très loin avant d’atteindre ses limites.  Bref, il reste encore bien des étapes à suivre avant même de savoir si un changement est nécessaire.

Publicités