Il y a quelques jours, un collègue posait innocemment la question suivante : « Pourquoi certains choisissent-ils d’utiliser MongoDB alors qu’elle est moins rapide que les autres bases NoSQL ? » Son raisonnement était simple : on prend une base de données pour avoir de bonnes performances, donc une base NoSQL qui n’est pas ultrarapide n’est pas digne d’intérêt.

Au premier abord, le raisonnement semble pertinent : les bases NoSQL ont été créées en premier lieu pour obtenir des performances beaucoup plus importantes que sur nos vieilles bases relationnelles au prix d’une perte de certaines fonctionnalités. Et pourtant, est-ce bien le cas ?

Supposons un instant que vous vouliez acheter une voiture. Laquelle de ces trois choisiriez-vous ?

Vu qu’elle vous servira à aller travailler, à faire vos courses le weekend, partir en vacances, je suis prêt à parier que vous ne choisirez pas le modèle le plus rapide.

De même, lorsqu’on choisit une base NoSQL, la vitesse pure n’est qu’un critère parmi d’autres. Alors comment choisit-on sa base NoSQL ? La question est compliquée et les critères sont nombreux.

Voici les critères qui sont, à mon sens, les plus importants.

La modélisation

Le critère le plus important est la façon dont les données sont modélisées dans la base. En effet, toute base de données impose une façon d’organiser les données. Cette organisation est très structurante et aura une influence sur les possibilités de requête et de traitements sur ces données. Il est difficile de modéliser un graphe dans une base relationnelle, alors que c’est facile dans une base graph ou une base RDF. Il est plus facile de suivre une suite d’évènements dans une base de type Cassandra que dans une base graph.

L’hégémonie des bases relationnelles a fait oublier que d’autres modèles existaient. Tant que les performances le permettaient, on tordait nos modèles de données pour les faire rentrer dans le modèle relationnel. Quitte à créer des couches de mapping (ex : ORM) plutôt que d’utiliser des bases objet.

Utiliser un modèle inadapté, c’est comme mettre des chaussures qui ne vous vont pas. Il faut un chaussepied pour tout faire rentrer, ça fait mal et on marche moins vite.

Le véritable apport du mouvement NoSQL est d’avoir rendu leurs lettres de noblesse aux bases qui ne respectent pas le modèle relationnel. Autant en profiter pour choisir la base la plus adaptée à notre besoin.

La polyvalence

C’est l’une des principales raisons pour lesquelles les bases relationnelles se sont développées de façon tellement hégémonique qu’aujourd’hui, encore, certaines personnes croient qu’il n’existe pas d’autre moyen de stocker des données. En effet, le modèle relationnel est capable d’absorber beaucoup de domaines métiers. Mais surtout, le SQL et sa capacité d’écrire des requêtes ad hoc les ont portées aux sommets.

Pouvoir lire des données d’une façon non prévue lors de la création de la base est un vrai plus. Elle offre une souplesse salvatrice et fait gagner en agilité autant que l’absence de schéma.

Certaines requêtes seront rapides. D’autres seront plus lentes, car non optimisées. Mais une requête non optimale est toujours plus utile qu’une requête impossible à formuler.

La performance

Évidemment, la performance est un élément important. C’est ce critère qui nous a permis de briser la barrière psychologique qui nous enfermait dans le monde relationnel. Encore aujourd’hui, c’est le seul argument entendu dans les DSI irréductibles qui résistent encore et toujours au changement.

Oui, la performance est importante ! Mais ça ne veut pas dire qu’il faut prendre la base la plus rapide, mais une de celles dont les performances sont suffisantes pour votre application. Peu de gens vont faire leurs courses en formule 1, une voiture traditionnelle va suffisamment vite.

Autre point important, la capacité de la base à monter en charge, ce qu’on appelle la scalabilité. En effet, certaines bases sont très rapides à petit volume et s’effondrent lorsque la charge augmente. On considère qu’une base est capable de monter en charge, si la puissance matérielle nécessaire croît proportionnellement avec la charge, sans limites atteignables. En gros, à chaque fois que la charge double, il suffit de doubler le nombre de machines pour garder les mêmes performances.

Tout cela est largement documenté sur Internet. Il y a par contre, une distinction d’importance qu’on ne lit que trop rarement. La charge d’un système s’oriente sur deux axes indépendants:

• le nombre de requêtes ou d’utilisateurs,
• la quantité de données conservées ou traitées.

Or, les solutions à mettre en œuvre pour ces deux axes sont différentes et parfois en oppositions. Certaines bases gèreront très bien un très grand nombre d’utilisateurs et très mal un très grand volume. D’autres gèreront la montée en charge des consultations, mais pas des écritures. Choisir la bonne base nécessite donc de connaitre le profil de l’application.

La communauté

Le quatrième critère que je retiendrai est la communauté. C’est un peu un argument de cours de récré. Mais n’est-il est la garantie de la durabilité cette base sur laquelle vous construisez votre application ?

Une grande communauté garantit qu’il y aura des acteurs pour faire vivre et évoluer la base. Elle garantit que vous trouverez de la documentation et de l’aide en abondance. Vous bénéficierez des retours d’expérience des autres utilisateurs. Et vous trouverez facilement des développeurs et des administrateurs compétents.

L’existant

Enfin, à moins d’être une start-up dans son garage ou de commencer une application d’un type totalement nouveau, vous avez déjà des bases de données que vos équipes connaissent et maitrisent. C’est donc tout naturellement que vous réutiliserez la même base dans vos nouveaux projets.

Et c’est une bonne chose. Il n’est pas bon de s’éparpiller sur un trop grand nombre d’outils. Cependant, la réutilisation doit rester raisonnable. Vouloir à tout prix réutiliser une base dont le modèle est inadapté aux usages se révèle à terme couteux et peu efficace. Au contraire, on trouve de plus en plus d’applications qui utilisent plusieurs formes de base de données en même temps.

Et MongoDB dans tout ça ?

Si MongoDB est tant utilisée c’est qu’elle offre un bon compromis entre tous ces critères.

Sa modélisation documentaire s’adapte parfaitement à de nombreuses applications. Toutes les applications de gestion de dossiers, factures, commandes ou produits le modélisent plus facilement avec une base documentaire qu’avec une base relationnelle. Idem pour les CMS dont les contenus ne sont rien d’autre que des documents.

MongoDB offre un grand nombre de fonctions qui la rendent très polyvalente. En plus de la capacité à faire des requêtes ad hoc, on retiendra les index géographiques, le framework d’agrégation, le map/reduce intégré et les nombreux outils de chargement de données en masse ou de sauvegarde et de restauration.

Certes, MongoDB n’est pas la base la plus rapide et ceux qui ont des besoins de performances pures passeront leur chemin. Cependant, MongoDB ne s’en tire pas si mal et suffit largement à la plupart des applications réelles. Elle est capable de monter en charge selon les deux axes volume (via le partitionnement) et requêtes (via la réplication et le partitionnement, quand la clé de partition a été bien choisie).

Enfin, MongoDB est une des bases les plus utilisées. Elle est vivante et dynamique. De plus, son éditeur, 10gen MongoDB Inc, travaille intensivement à construire une communauté. La documentation est abondante et à jour. Il organise, notamment, des formations en ligne gratuites pour les nouveaux utilisateurs. Bref, s’il est difficile de pronostiquer les bases qui survivront à terme, MongoDB fait partie des candidats les mieux placés.

Voilà pourquoi beaucoup d’utilisateurs choisissent MongoDB.