MongoDB : entretien avec le fondateur, Dwight Merriman

En quelques années, la base de données NoSQL MongoDB s’est forgée une place de choix dans le Big Data. Une des raisons premières est que la technologie a été développée dès le départ en y intégrant les notions de scalabilité horizontale et de parallélisme, explique Dwight Merriman, président et co-fondateur de la société. Celui-ci a cru déceler les besoins de l’industrie en la matière alors qu’il dirigeait Doubleclick,un acteur clé du monde de la publicité en ligne – qu’il a lui-même co-fondé. Il revient avec nous sur les racines de MongoDB et de ses prochaines orientations.

Lorsque MongoDB est apparu en 2007 et alors que les Web apps battaient déjà leur plein, le développement agile était également en pleine progression. Ce qui implique des schémas de données encore plus dynamiques. Cela est-il vrai ?

Dwight Merriman : Si vous considérez la façon dont on écrit du code aujourd’hui, nous n’abordons plus vraiment la gestion du cycle de vie en cascade. Nous faisons davantage de développement agile. Nous parlons d’itérations multiples et de releases plus nombreuses certes, mais plus réduites. Nous avons une release par jour, puis les modifications reprennent.  Chez le chef de produit, l’attitude est plutôt : « non, ce n’est pas ce que je souhaitais ». Et nous réalisons de nouveau des modifications.

Cette notion d’itérations a des implications clés pour la base de données et la couche de données. Si vous êtes confronté à des nouveaux schémas de migration tous les jours, cela est ingérable. Mais si vous disposez de quelque chose de fluide, notamment au niveau de ce qui est stocké, cela correspond bien avec cette notion d’itération. Cela représentait un chainon manquant pour nous et une opportunité, grâce au côté dynamique des schémas de MongoDB.

Est-il vrai que les bases de données déjà établies ne se dimensionnent pas efficacement sur le Web ? La scalabilité a-t-elle été le critère n°1 en matière de design dans la création de la base ?

Dwight Merriman : Je vois MongoDB comme une base opérationnelle. Un cas d’usage fréquent : une personne développe une application et celle-ci est soutenue par un datastore. C’est comme OLTP avec un T minuscule – nous n’avons pas d’importantes transactions.

Avec MongoDB, vous ne disposez pas d’un environnement pour les transactions complexes. Vous pouvez en revanche réaliser des transactions atomiques dans le cadre d’un document. La consistance est forte dans MongoDB. Et cela était intentionnel.

Mais nous avons fait cela parce que nous souhaitions quelque chose qui puisse être dimensionné de façon horizontale avec des machines peu puissantes – et non pas de façon verticale avec un hardware toujours plus important.

Lorsque vous avez inventé la base avec votre collègue, la notion de caching était de plus en plus courante sur le Web. Avez-vous essayé d’apporter quelque chose en ce sens lors de la création de la base ?

Dwight Merriman : A l’époque, la difficulté était le Scaling-out. Nous observions les mêmes problèmes, de façon récurrente. Les architectures informatiques étaient en train de changer. Les vitesses d’horloge ne montaient pas en régime. La façon dont  nous traitons cela aujourd’hui est différente : cela passe davantage par le parallélisme.

Vous savez, la notion de caching est parfois très pertinente. Mais était devenue une sorte de béquille. La base de données était trop lente. Pour nous, cela a été un signe. Les entreprises disposaient de 30 serveurs de cache, chacun avec de grande quantité de RAM.

Les applications hautement distribuées ne sont pas faciles à configurer. Les entreprises veulent être comme Google, mais cela peut être difficile lorsque le parc hardware grossit.

Dwight Merriman : La priorité n°1 de notre R&D porte sur l’opérationnel – faciliter la vie pour les DevOps, les administrateurs de bases de données et les administrateurs systèmes, bref les acteurs de l’IT. L’automatisation est nécessaire car le parc de machines augmente. Nous travaillons actuellement sur MongoDB Service Suite, qui comporte des fonctions de monitoring, des outils de sauvegarde et d’autres d’automatisation pour le déploiement.

Traduit de l'anglais par la rédaction