J'ai récemment découvert que Red Hat supprime la prise en charge de MongoDB par Satellite (par exemple, en raison de changements de licence). Cela m'a fait penser qu'au cours des dernières années, j'ai vu un tas d'articles sur la gravité de MongoDB et que personne ne devrait jamais l'utiliser. Mais pendant ce temps, MongoDB est devenu un produit beaucoup plus mature. Ce qui s'est passé? Toute la haine est-elle vraiment due à des erreurs au début de la commercialisation du nouveau SGBD ? Ou les gens utilisent-ils simplement MongoDB au mauvais endroit ?

Si vous avez soudainement l'impression que je défends MongoDB, veuillez lire clause de non-responsabilité à la fin de l'article.

Nouvelle tendance

Je suis dans l'industrie du logiciel depuis plus d'années qu'il n'est juste de le dire, mais je n'ai toujours fait partie que des tendances qui ont frappé notre industrie. J'ai été témoin de l'essor de 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… la liste est interminable. Chaque année, de nouvelles tendances apparaissent. Certains disparaissent rapidement, tandis que d'autres changent fondamentalement la façon dont les logiciels sont développés.

Autour de chaque nouvelle tendance, une certaine effervescence générale se crée : soit les gens sautent eux-mêmes dans le bateau, soit ils voient le bruit généré par les autres - et suivent la foule. Ce processus a été codifié par Gartner dans Cycle de battage médiatique. Bien que discutable, ce graphique décrit approximativement ce qui arrive aux technologies avant qu'elles ne deviennent finalement utiles à l'utilisation.

Mais de temps en temps, il y a (ou il y a une seconde venue, comme dans ce cas) une nouvelle innovation, motivée par une seule mise en œuvre spécifique de celle-ci. Dans le cas de NoSQL, le battage médiatique a été fortement motivé par l'avènement et l'ascension fulgurante de MongoDB. MongoDB n'a pas lancé cette tendance : en effet, les grandes entreprises Internet ont commencé à avoir des problèmes pour traiter de grandes quantités de données, ce qui a conduit au retour des bases de données non relationnelles. Le mouvement général a commencé avec des projets tels que Bigtable de Google et Cassandra de Facebook, mais c'est MongoDB qui est devenu l'implémentation la plus célèbre et la plus accessible de la base de données NoSQL à laquelle la plupart des développeurs avaient accès.

Remarque : Vous pourriez penser que je confonds les bases de données de documents avec les bases de données de colonnes, les magasins de clés/valeurs ou l'un des nombreux autres types de magasins de données qui relèvent de la définition générale de NoSQL. Et vous avez raison. Mais à l'époque, le chaos régnait. Tout le monde est obsédé par NoSQL, c'est devenu tout absolument nécessaire, même si beaucoup n'ont pas vu les différences entre les différentes technologies. Pour beaucoup, MongoDB est devenu synonyme de NoSQL.

Et les développeurs ont sauté dessus. L'idée d'une base de données sans schéma qui évolue comme par magie pour résoudre n'importe quel problème était assez tentante. Vers 2014, il semblait que partout où une base de données relationnelle telle que MySQL, Postgres ou SQL Server était utilisée il y a un an, des bases de données MongoDB étaient déployées. Lorsqu'on vous demande pourquoi, vous pouvez obtenir des réponses allant du banal "c'est l'échelle du Web" au plus réfléchi "mes données sont très vaguement structurées et s'intègrent bien dans une base de données sans schéma".

Il est important de se rappeler que MongoDB, et les bases de données documentaires en général, résolvent un certain nombre de problèmes avec les bases de données relationnelles traditionnelles :

• Régime strict : avec une base de données relationnelle, si vous avez des données générées dynamiquement, vous êtes obligé de créer un ensemble de colonnes de données "différentes" aléatoires, d'y insérer des blobs de données ou d'utiliser une configuration EAV… tout cela a des inconvénients importants.
• Difficulté de mise à l'échelle: S'il y a tellement de données qu'elles ne tiennent pas sur un seul serveur, MongoDB a proposé des mécanismes pour lui permettre de s'étendre sur plusieurs machines.
• Modifications de circuits complexes: pas de migration ! Dans une base de données relationnelle, changer la structure de la base de données peut être un énorme problème (surtout lorsqu'il y a beaucoup de données). MongoDB a été en mesure de simplifier considérablement le processus. Et l'a rendu si facile que vous pouvez simplement mettre à jour le schéma lors de vos déplacements et avancer très rapidement.
• Performances en écriture: Les performances de MongoDB étaient bonnes, surtout lorsqu'elles étaient correctement réglées. Même la configuration prête à l'emploi de MongoDB, pour laquelle il a souvent été critiqué, a montré des performances impressionnantes.

Tous les risques sont sur vous

Les avantages potentiels de MongoDB étaient énormes, en particulier pour certaines classes de problèmes. Si vous lisez la liste ci-dessus sans comprendre le contexte et sans expérience, vous pourriez avoir l'impression que MongoDB est vraiment un SGBD révolutionnaire. Le seul problème était que les avantages énumérés ci-dessus s'accompagnaient d'un certain nombre de mises en garde, dont certaines sont énumérées ci-dessous.

Pour être juste, personne chez 10gen/MongoDB Inc. ne dira pas que ce qui suit n'est pas vrai, ce ne sont que des compromis.

• Perte de transactionsR : Les transactions sont une fonctionnalité essentielle de nombreuses bases de données relationnelles (pas toutes, mais la plupart). Transactionnel signifie que vous pouvez effectuer plusieurs opérations de manière atomique et vous assurer que les données restent cohérentes. Bien sûr, avec une base de données NoSQL, la transactionnalité peut être dans un seul document, ou vous pouvez utiliser des validations 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 difficile et chronophage. Souvent, vous ne réalisez pas le problème jusqu'à ce que vous voyiez que les données de la base de données entrent dans des états invalides car il est impossible de garantir l'atomicité des opérations. Remarque : beaucoup m'ont dit que les transactions ont été introduites dans MongoDB 4.0 l'année dernière, mais avec certaines limitations. La conclusion de l'article reste la même : évaluez comment la technologie répond à vos besoins.
• Perte d'intégrité relationnelle (clés étrangères): si vos données ont des relations, alors vous devrez les appliquer dans l'application. Avoir une base de données qui respecte ces relations enlèvera beaucoup de travail à l'application et donc à vos programmeurs.
• Incapacité à appliquer la structure de données: Les schémas stricts peuvent parfois être un gros problème, mais ils sont aussi un mécanisme puissant pour une bonne structuration des données s'ils sont utilisés à bon escient. Les bases de données de documents comme MongoDB offrent une flexibilité de schéma incroyable, mais cette flexibilité enlève la responsabilité de garder les données propres. Si vous ne vous en occupez pas, vous finirez par écrire beaucoup de code dans votre application pour tenir compte des données qui ne sont pas stockées sous la forme que vous attendez. Comme on dit souvent dans notre entreprise Simple Thread… l'application sera réécrite un jour, mais les données vivront pour toujours. Remarque : MongoDB prend en charge la validation de schéma, ce qui est utile mais n'offre pas les mêmes garanties qu'une base de données relationnelle. Tout d'abord, l'ajout ou la modification de 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 en fonction du nouveau schéma. Décidez vous-même si cela suffit à vos besoins.
• Langage de requête propre / perte d'écosystème d'outils: L'avènement de SQL a été une révolution absolue, et rien n'a changé depuis. C'est un langage incroyablement puissant, mais aussi assez complexe. La nécessité de construire des requêtes de base de données dans un nouveau langage, composé de fragments JSON, est considérée comme un grand pas en arrière par les personnes qui ont 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 convertir les données en SQL afin de les utiliser, ce qui peut être plus difficile que vous ne le pensez.

De nombreux développeurs qui se sont tournés vers MongoDB n'ont pas vraiment compris les compromis et ont souvent plongé la tête la première dans sa configuration en tant que magasin de données principal. Après cela, il était souvent incroyablement difficile de revenir en arrière.

Qu'est-ce qui aurait pu être fait différemment ?

Tout le monde n'a pas sauté la tête la première et s'est écrasé au fond. Mais un certain nombre de projets ont installé la base MongoDB là où elle ne convenait tout simplement pas - et ils devront vivre avec pendant de nombreuses années encore. Si ces organisations avaient pris le temps de réfléchir méthodiquement à leurs choix technologiques, beaucoup auraient fait un choix différent.

Comment choisir la bonne technologie ? Il y a eu plusieurs tentatives pour créer un cadre systématique pour l'évaluation des technologies, comme "Cadre pour la mise en œuvre des technologies dans les organisations logicielles" и "Framefork pour l'évaluation des technologies logicielles", mais il me semble que c'est une complexité inutile.

De nombreuses technologies peuvent être évaluées intelligemment en posant seulement deux questions fondamentales. Le problème consiste à trouver des personnes capables d'y répondre de manière responsable, en prenant le temps de trouver des réponses et sans parti pris.

Si vous ne rencontrez aucun problème, vous n'avez pas besoin d'un nouvel outil. Point.

Question 1 : Quels problèmes est-ce que j'essaie de résoudre ?

Si vous ne rencontrez aucun problème, vous n'avez pas besoin d'un nouvel outil. Point. Pas besoin de chercher une solution et ensuite de trouver un problème. À moins que vous ne rencontriez un problème que la nouvelle technologie ne résout pas beaucoup mieux que votre technologie existante, il n'y a rien à discuter ici. Si vous envisagez d'utiliser cette technologie parce que vous en avez vu d'autres l'utiliser, réfléchissez aux problèmes qu'ils rencontrent et demandez-leur si vous rencontrez ces problèmes. Il est facile d'adopter la technologie parce que d'autres l'utilisent, la difficulté est de savoir si vous rencontrez les mêmes problèmes.

Question 2 : Qu'est-ce qui me manque ?

C'est certainement une question plus difficile, car vous devez creuser et bien comprendre à la fois l'ancienne et la nouvelle technologie. Parfois, vous ne pouvez pas vraiment comprendre un nouveau jusqu'à ce que vous ayez construit quelque chose avec lui ou que vous ayez un collègue avec cette expérience.

Si vous ne possédez ni l'un ni l'autre, il est logique de réfléchir à l'investissement minimum possible pour déterminer la valeur de cet instrument. Et si vous faites un investissement, à quel point sera-t-il difficile de revenir sur la décision ?

Les gens gâchent toujours tout

En essayant de répondre à ces questions le plus impartialement possible, retenez une chose : vous devez combattre la nature humaine. Il existe un certain nombre de biais cognitifs qui doivent être surmontés afin d'évaluer efficacement la technologie. En voici quelques-unes :

• L'effet de rejoindre la majorité Tout le monde le connaît, mais il est toujours difficile de le combattre. Assurez-vous simplement que la technologie correspond vraiment à vos besoins réels.
• effet de nouveauté De nombreux développeurs ont tendance à sous-estimer les technologies avec lesquelles ils travaillent depuis longtemps et à surestimer les avantages d'une nouvelle technologie. Pas seulement les programmeurs, tout le monde est sujet à ce biais cognitif.
• Effet d'attribut positif Nous avons tendance à voir ce qui est et à perdre de vue ce qui n'est pas. Cela peut conduire au chaos, combiné à l'effet de nouveauté, car non seulement vous surévaluez intrinsèquement la nouvelle technologie, mais vous ignorez également ses lacunes..

L'évaluation objective n'est pas facile, mais comprendre les biais cognitifs sous-jacents vous aidera à prendre des décisions plus rationnelles.

Résumé

Lorsqu'une innovation émerge, il faut répondre avec beaucoup de précaution à deux questions :

• Cet outil résout-il un vrai problème ?
• Sommes-nous bons pour comprendre les compromis ?

Si vous ne pouvez pas répondre en toute confiance à ces deux questions, prenez du recul et réfléchissez.

Alors, la MongoDB était-elle généralement le bon choix ? Bien sûr que oui; comme pour la plupart des technologies d'ingénierie, cela dépend de nombreux facteurs. Parmi ceux qui ont répondu à ces deux questions, beaucoup ont bénéficié de MongoDB et continuent de le faire. Pour ceux d'entre vous qui ne l'ont pas encore fait, j'espère que vous avez appris une leçon précieuse et pas trop douloureuse sur la façon de traverser le cycle du battage médiatique.

Avertissement

Je tiens à préciser que je n'aime ni ne déteste MongoDB. Nous n'avions tout simplement pas le genre de problèmes que MongoDB est le mieux placé pour résoudre. Je sais que 10gen/MongoDB Inc. a agi très audacieusement au début, en définissant des valeurs par défaut non sécurisées et en promouvant MongoDB partout (en particulier lors des hackathons) comme une solution unique pour travailler avec n'importe quelles données. C'était probablement une mauvaise décision. Mais cela confirme l'approche décrite ici : ces problèmes pourraient être détectés très rapidement même avec une évaluation superficielle de la technologie.

Source: habr.com