Je discutais récemment avec un ami du choix d’une base de données pour un projet à venir. Je lui ai demandé ce qu’il pensait de MongoDB. Il m’a répondu que, d’après ce qu’il en savait, il ne pensait pas que cela fonctionnerait. Le problème, c’est que tout ce qu’il savait de MongoDB datait de 2013. Il n’avait pas suivi les améliorations et modifications apportées au cours de la dernière décennie. D’après mes échanges avec d’autres développeurs, cette situation semble assez courante. Beaucoup se sont fait une première idée de MongoDB entre 2012 et 2014 et ont arrêté leur jugement sur cette base. Dans cet article, nous allons nous pencher sur l’histoire des bases de données et comparer MongoDB aux relational databases d’aujourd’hui.
Pour rappel, il existe plusieurs types de bases de données, mais nous nous concentrerons sur les relational databases et les bases de données NoSQL orientées document, car ce sont deux des types les plus largement utilisés actuellement. Les relational databases ont été introduites dans les années 1970 et stockent les données dans des tables. Bien que le terme NoSQL ait été inventé en 1998 par Carlo Strozzi, il a fallu quelques années de plus pour que les bases de données NoSQL et leur approche plus flexible du stockage des données décollent vraiment. En 2009, MongoDB s’est lancé avec l’idée de stocker des données dans des documents similaires à des objets JSON. Lorsque j’explique la différence fondamentale entre les relational databases et les bases de données orientées document à ma famille, je dis généralement que l’une est comme une feuille de calcul et que l’autre est comme un Google Doc. Je ne sais toujours pas si ma grand-mère comprend vraiment en quoi consiste mon travail, mais au moins, elle connaît maintenant la différence entre les types de bases de données.
Bien, maintenant que nous avons rappelé les bases, nous allons aborder les idées reçues qui apparaissent lors de la comparaison de MongoDB avec les relational databases.
Mythe 1 : MongoDB ne possède pas de schéma
Les schémas définissent la structure des données dans une base de données. Avec les relational databases, vous concevez généralement votre schéma en fonction de la normalisation de vos données. La normalisation signifie que vous divisez vos données en différentes tables afin de ne pas les dupliquer. Ces schémas définis sont parfaits si vous pouvez anticiper tous vos besoins futurs en matière de données et les concevoir avec élégance à l’avance. La mise à jour de ces schémas pour ajouter de nouveaux champs peut entraîner un surcroît de travail et des temps d’indisponibilité pour votre application.
Avec MongoDB, votre schéma dépend des besoins de votre application. Il s’agit d’une approche plus flexible de la conception de schéma. Bien qu’il existe une certaine flexibilité, des bonnes pratiques peuvent toujours être appliquées, comme la règle selon laquelle « les données accessibles ensemble doivent être stockées ensemble ».
Voici un exemple des données relationnelles ci-dessus stockées dans MongoDB :
Dans cet exemple, vous pouvez récupérer toutes les informations sur « Paul Miller » sans avoir à effectuer de JOINS sur trois tables différentes. Vous pouvez effectuer des JOINS dans MongoDB, mais c’est un sujet que nous aborderons plus tard.
Grâce à un schéma flexible, les développeurs peuvent commencer à créer des applications sans avoir à concevoir au préalable un schéma définitif auquel ils seraient ensuite contraints de se conformer. Vous pouvez facilement ajouter de nouveaux champs à votre schéma dès que l’application le nécessite. Si vous souhaitez disposer d’un schéma plus structuré, vous pouvez utiliser la fonctionnalité de validation de schéma de MongoDB. Si vous avez besoin que votre schéma évolue au fil du temps, vous pouvez également implémenter facilement le modèle de versioning de schéma.
En fin de compte, je pense que ce mythe selon lequel MongoDB n’a pas de schéma se résume à deux choses. Premièrement, il n’y avait pas de validation de schéma au début (elle a été ajoutée dans la version 3.6 en 2017). L’autre raison vient de la flexibilité dont disposent les développeurs pour créer leur schéma en fonction des besoins de leurs applications. Liberté et flexibilité ne signifient pas qu’il n’y a pas de schéma, mais simplement qu’il est important de suivre les bonnes pratiques pour créer un schéma élégant qui permet à votre application de fonctionner de manière optimale.
Idée reçue n° 2 : MongoDB n’est pas conforme au modèle ACID
Les bases de données ont besoin de moyens pour garantir que les opérations et les données qui en résultent sont fiables, même en cas d’erreurs ou de pannes de courant. La principale façon d’y parvenir consiste à implémenter quatre propriétés : l’atomicité, la cohérence, l’isolation et la durabilité, également connues sous le nom d’ACID.
MongoDB est conforme au modèle ACID. Chaque fois que vous effectuez une opération de création, de lecture, de mise à jour ou de suppression sur un document, l’intégrité des données est préservée. MongoDB traite les données document par document. Sinon, ce ne serait pas une base de données documentaire. Ce serait une base de données chaotique et imprévisible. Pouvez-vous imaginer de nombreux contributeurs essayant de modifier le même document en même temps ? J’ai déjà participé à des documents Google avec plus de 10 contributeurs travaillant simultanément, et cela ne donne certainement pas l’impression de respecter les principes ACID.
Nous parlons ici d’un seul document, mais que se passe-t-il lors de transactions multidocuments ? Celles-ci sont fréquentes dans les relational databases, car vous devez souvent accéder à plusieurs tables lors d’opérations telles que la mise à jour d’un enregistrement client. MongoDB garantit les transactions ACID multidocuments depuis et vers n’importe quel emplacement de votre cluster MongoDB. Cette garantie est proposée depuis la version 4.0 en 2018.
En fait, la transactionnalité est l’un des principaux atouts de MongoDB. De nombreuses entreprises de services financiers font confiance aux transactions MongoDB pour les cas d’utilisation bancaires et commerciales de base. La garantie du tout ou rien des transactions multidocuments de MongoDB est là pour vous.
Idée reçue n° 3 : MongoDB ne peut pas créer de JOINS pour traiter les données relationnelles
Nous avons montré plus haut comment les relational databases s’appuient sur des données fractionnées entre plusieurs tables pour une conception de schéma efficace. Pour travailler avec des données relationnelles, vous devez souvent extraire des données de ces tables et les combiner à l’aide de jointures (JOINS).
Il est possible d’effectuer des JOINS dans MongoDB avec la commande $lookup. Mais le fait que vous puissiez faire quelque chose ne signifie pas que vous devez le faire. Les données MongoDB sont modélisées de manière différente des données relationnelles. Dans MongoDB, les données accessibles ensemble sont stockées ensemble. La plupart des données étant regroupées dans un document unique plutôt que disséminées dans de multiples tables, vous n’aurez pas besoin d’effectuer de JOINS puisque les données sont déjà au bon endroit. Ce passage du modèle relationnel au document model implique un réel changement d’état d’esprit. Mais une fois que vous en aurez compris les avantages, il vous sera difficile de revenir en arrière. Cependant, si vous avez toujours besoin d’effectuer des JOINS avec MongoDB, la commande $lookup est votre meilleur alliée. Vous pouvez même créer une VIEW (ajoutée en 2016) pour joindre deux collections.
La croyance selon laquelle les jointures ne sont pas possibles repose en fin de compte sur la différence fondamentale entre les modèles relationnels et les document models. Les données accessibles dans les tables et les données accessibles dans les documents nécessitent des approches différentes, mais en général, même si vous pouvez effectuer des JOINS dans MongoDB, vous n’en aurez pas besoin si vous avez bien conçu le schéma de vos documents.
Pour en savoir plus sur MongoDB, rendez-vous sur MongoDB University et suivez notre cours d’introduction à MongoDB gratuit.
Lisez le deuxième blog de cette série pour découvrir les mythes sur les cas d’utilisation de MongoDB en entreprise.
Regardez la vidéo complète pour découvrir les 6 autres mythes que nous démystifions dans cette série.