Récemment, j'ai appris que (apparemment à cause des changements de licence). Cela m'a fait réfléchir, car ces dernières années, j'ai vu une multitude d'articles décrire à quel point MongoDB est horrible et que personne ne devrait jamais l'utiliser. Mais pendant ce temps, MongoDB est devenu un produit beaucoup plus mature. Que s'est-il passé ? Toute cette haine s'explique-t-elle par des erreurs commises au début du marketing de ce nouveau SGBD ? Ou les gens utilisent-ils simplement MongoDB là où il ne devrait pas être utilisé ?
Si jamais vous avez l'impression que je défends MongoDB, veuillez lire à la fin de l'article.
Une nouvelle tendance
Je travaille dans l'industrie logicielle depuis plus d'années que je ne devrais le dire, mais j'ai tout de même été témoin d'une petite partie des tendances qui ont frappé notre secteur. J'ai été témoin de la montée des 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… la liste est infinie. Chaque année, de nouvelles tendances émergent. Certaines s'éteignent rapidement, tandis que d'autres changent fondamentalement les façons de développer des logiciels.
Autour de chaque nouvelle tendance, il se crée une sorte d'excitation générale : les gens sautent dans le bateau eux-mêmes ou voient le bruit généré par les autres - et suivent la foule. Ce processus a été codifié par la société Gartner dans le . Bien que contestable, ce graphique décrit à peu près ce qui se passe avec les technologies avant qu'elles ne deviennent finalement utiles.
Mais de temps en temps, une nouvelle innovation apparaît (ou un second avènement se produit, comme dans ce cas) motivée uniquement par une mise en œuvre spécifique. Dans le cas de NoSQL, le hype a été fortement influencé par l'émergence et la montée fulgurante de MongoDB. Ce n'est pas MongoDB qui a lancé cette tendance : en réalité, des entreprises Internet de grande taille ont commencé à rencontrer des problèmes pour traiter de grands volumes de données, ce qui a conduit au retour des bases de données non relationnelles. Le mouvement global a commencé avec des projets comme Bigtable de Google et Cassandra de Facebook, mais c'est MongoDB qui est devenue la mise en œuvre de base de données NoSQL la plus connue et accessible, à laquelle la plupart des développeurs avaient accès.
Remarque : vous pourriez penser que je mélange les bases de données documentaires avec les bases de données colonnes, les magasins de clés/valeurs ou tout autre type de stockage de données qui ressort de la définition générale de NoSQL. Et vous avez raison. Mais à ce moment-là, c'était le chaos. Tout le monde était obsédé par NoSQL, ça devenait absolument nécessaire, bien que beaucoup n'aient pas vu de différences entre les différentes technologies. Pour beaucoup, MongoDB est devenu synonyme de NoSQL.
Les développeurs se sont jetés dessus. L'idée d'une base de données sans schéma, qui se déploie magiquement pour résoudre n'importe quel problème, était plutôt séduisante. Vers 2014, il semblait que partout où l'on utilisait encore une base de données relationnelle, comme MySQL, Postgres ou SQL Server, on déployait désormais des bases MongoDB. En réponse à la question pourquoi, on pouvait recevoir une réponse allant du banal « c'est l'échelle du web » à un « mes données sont très peu structurées et s'intègrent bien dans une base de données sans schéma » plus réfléchi.
Il est important de se rappeler que MongoDB et les bases de données orientées documents en général résolvent un certain nombre de problèmes posés par les bases de données relationnelles traditionnelles :
- Schéma strict: avec une base de données relationnelle, si vous avez des données générées dynamiquement, vous êtes contraint de créer une multitude de « colonnes » de données aléatoires ou d'utiliser une configuration. … tout cela a des inconvénients significatifs.
- Difficulté de mise à l'échelle: s'il y a tellement de données qu'elles ne tiennent pas sur un seul serveur, MongoDB offrait des mécanismes permettant de les répartir sur plusieurs machines.
- Modifications complexes du schéma: aucune migration ! Dans une base de données relationnelle, modifier la structure de la base de données peut devenir un énorme problème (surtout quand il y a beaucoup de données). MongoDB a réussi à simplifier considérablement le processus. C'était devenu si simple que vous pouvez juste mettre à jour le schéma à la volée et avancer très rapidement.
- Performance d'écriture: les performances de MongoDB étaient bonnes, en particulier avec un réglage adéquat. Même la configuration MongoDB par défaut, souvent critiquée, affichait des performances impressionnantes.
Tous les risques reposent sur vous
Les avantages potentiels de MongoDB étaient énormes, en particulier pour certaines classes de problèmes. Si l'on lit la liste ci-dessus sans connaître le contexte et sans expérience, on pourrait avoir l'impression que MongoDB est une véritable base de données révolutionnaire. Le seul problème est que les avantages mentionnés ci-dessus s'accompagnent d'un certain nombre de mises en garde, dont certaines sont indiquées ci-dessous.
Pour être juste, personne chez 10gen/MongoDB Inc. ne dira que ce qui suit est faux, ce sont simplement des compromis.
- Perte de transactions: les transactions sont une caractéristique principale de nombreuses bases de données relationnelles (pas toutes, mais la plupart). La transactionnalité signifie que vous pouvez effectuer plusieurs opérations de manière atomique et garantir que les données resteront cohérentes. Bien sûr, avec une base de données NoSQL, la transactionnalité peut se faire au sein d’un seul document ou vous pouvez utiliser des commits en deux phases pour obtenir une sémantique transactionnelle. Mais vous devrez implémenter cette fonctionnalité vous-même… ce qui peut être une tâche complexe et fastidieuse. Souvent, vous ne réalisez pas les problèmes jusqu'à ce que vous voyiez que les données dans la base de données se retrouvent dans des états non valides, car il est impossible de garantir l'atomicité des opérations. Remarque : beaucoup m'ont dit que des transactions étaient apparues dans MongoDB 4.0 l'année dernière, mais avec certaines limitations. La conclusion de l'article reste la même : évaluez à quel point la technologie répond à vos besoins.
- Perte de l'intégrité relationnelle (clés étrangères): si vos données ont des relations, vous devrez les appliquer dans l'application. Avoir une base de données qui respecte ces relations réduira considérablement la charge de travail de l'application et, par conséquent, celle de vos programmeurs.
- Absence de possibilité d'appliquer une structure de données: des schémas stricts deviennent parfois un gros problème, mais c'est aussi un puissant mécanisme pour bien structurer les données si utilisé correctement. Les bases de données documentaires, comme MongoDB, offrent une flexibilité de schéma incroyable, mais cette flexibilité décharge la responsabilité de maintenir les données en ordre. Si vous ne vous en occupez pas, vous finirez par écrire beaucoup de code dans l'application pour gérer des données qui ne sont pas au format que vous attendez. Comme le dit souvent notre entreprise, Simple Thread… l'application sera réécrite un jour, mais les données vivront éternellement. Remarque : MongoDB prend en charge la validation de schéma : c'est utile, mais cela ne fournit pas les mêmes garanties qu'une base de données relationnelle. Tout d'abord, ajouter ou modifier la validation de schéma n'affecte pas les données existantes dans la collection. Vous devez vous assurer que vous mettez à jour les données conformément au nouveau schéma. Décidez vous-même si cela suffit pour vos besoins.
- Langage de requête propriétaire / perte de l'écosystème des outils: l'émergence de SQL a été une véritable révolution, et depuis lors, rien n'a changé. C'est un langage incroyablement puissant, mais aussi assez complexe. La nécessité de construire des requêtes sur une base de données dans un nouveau langage constitué de fragments JSON est perçue comme un grand pas en arrière par les personnes ayant de l'expérience avec SQL. Il existe tout un univers d'outils qui interagissent avec les bases de données SQL : des IDE aux outils de reporting. Passer à une base de données qui ne prend pas en charge SQL signifie que vous ne pouvez pas utiliser la plupart de ces outils ou que vous devez traduire les données en SQL pour les utiliser, ce qui peut s'avérer plus compliqué que vous ne le pensez.
De nombreux développeurs qui se sont tournés vers MongoDB ne comprenaient pas vraiment les compromis, et plongaient souvent la tête la première, l'installant comme principale base de données. Après cela, il était souvent incroyablement difficile de revenir en arrière.
Que pouvait-on faire autrement ?
Tout le monde ne s'est pas précipité la tête la première. Mais de nombreux projets ont installé MongoDB là où cela ne convenait tout simplement pas - et ils devront vivre avec pendant encore de nombreuses années. Si ces organisations avaient pris un peu de temps pour réfléchir méthodiquement au choix des technologies, beaucoup auraient fait un choix différent.
Comment choisir la bonne technologie ? Il y a eu plusieurs essais pour créer un cadre systématique pour évaluer les technologies, comme et , mais je pense que c'est une complexité excessive.
De nombreuses technologies peuvent être raisonnablement évaluées en posant seulement deux questions fondamentales. Le problème réside dans la recherche de personnes capables d'y répondre de manière responsable, prenant le temps de chercher des réponses et sans préjugés.
Si vous ne rencontrez pas de problème particulier, vous n'avez pas besoin de nouvel outil. Point final.
Question 1: Quels problèmes essaie-je de résoudre ?
Si vous ne rencontrez pas de problème, vous n'avez pas besoin d'un nouvel outil. C'est un fait. Ne cherchez pas une solution puis imaginez un problème. Si vous n'avez pas rencontré un problème qu'une nouvelle technologie résout de manière significativement meilleure que votre technologie existante, il n'y a rien à discuter. Si vous envisagez d'utiliser cette technologie simplement parce que d'autres l'utilisent, réfléchissez aux problèmes qu'ils rencontrent et demandez-vous si vous avez ces mêmes problèmes. Il est facile d'adopter une technologie parce que d'autres l'utilisent, mais il est difficile de comprendre si vous êtes confronté aux mêmes problèmes.
Question 2: Qu'est-ce que je perds ?
C'est certainement une question plus difficile, car il faut sonder et bien comprendre à la fois l'ancienne et la nouvelle technologie. Parfois, vous ne pouvez vraiment comprendre la nouvelle tant que vous n'avez pas construit quelque chose avec ou que vous n'avez pas un employé ayant cette expérience.
Si vous n'avez ni l'un ni l'autre, il est logique de réfléchir aux investissements minimaux nécessaires pour déterminer la valeur de cet outil. Et si vous effectuez des investissements, dans quelle mesure sera-t-il difficile d'annuler la décision ?
Les gens gâchent toujours tout
En essayant de répondre à ces questions de manière aussi objective que possible, gardez une chose à l'esprit : vous devrez lutter contre la nature humaine. Il existe un certain nombre de biais cognitifs qu'il faut surmonter pour évaluer efficacement une technologie. En voici quelques-uns :
- — tout le monde le connaît, mais il est toujours difficile de l'affronter. Assurez-vous simplement que la technologie répond réellement à vos besoins réels.
- — de nombreux développeurs ont tendance à sous-estimer les technologies avec lesquelles ils ont travaillé longtemps et à surestimer les avantages de la nouvelle technologie. Pas seulement les programmeurs, tout le monde est soumis à ce biais cognitif.
- — nous avons tendance à voir ce qui est là et à ignorer ce qui manque. Cela peut conduire à un chaos combiné avec l'effet de nouveauté, car vous n'évaluez pas seulement trop positivement la nouvelle technologie, mais vous ignorez également ses défauts..
Une évaluation objective n'est pas facile, mais comprendre les principales distorsions cognitives peut aider à prendre des décisions plus rationnelles.
Résumé
Lorsqu'une nouvelle innovation apparaît, il faut répondre avec beaucoup de prudence à deux questions :
- Cet outil résout-il un problème réel ?
- Comprenons-nous bien les compromis ?
Si vous ne pouvez pas répondre clairement à ces deux questions, faites quelques pas en arrière et réfléchissez.
MongoDB était-elle vraiment le bon choix ? Bien sûr ; comme dans la plupart des technologies d’ingénierie, cela dépend de nombreux facteurs. Parmi ceux qui ont répondu à ces deux questions, beaucoup ont tiré profit de MongoDB et continuent de le faire. Ceux qui ne l'ont pas fait, espérons qu'ils ont tiré une leçon précieuse et pas trop douloureuse sur le cycle d'engouement.
Avertissement
Je tiens à préciser que je n'ai ni amour ni haine pour MongoDB. Simplement, nous n'avons pas eu de problèmes pour lesquels MongoDB était la meilleure solution. Je sais que 10gen/MongoDB Inc. a initialement agi très audacieusement en définissant des valeurs par défaut peu sécurisées et en promouvant MongoDB partout (surtout lors des hackathons) comme une solution universelle pour gérer toutes les données. Cela a probablement été une mauvaise décision. Mais cela confirme l'approche décrite ici : ces problèmes auraient pu être identifiés très rapidement même lors d'une évaluation superficielle de la technologie.
Source : habr.com
