J'ai récemment découvert que Red Hat supprimait le support MongoDB du Satellite (disent-ils en raison de changements de licence). Cela m'a fait penser que ces dernières années, j'ai vu un tas d'articles à quel point MongoDB est terrible 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 la haine est-elle vraiment due à des erreurs au début de la commercialisation d'un nouveau SGBD? Ou les gens utilisent-ils simplement MongoDB au mauvais endroit?

Si vous avez soudain l'impression que je protège MongoDB, veuillez lire l' avertissement à la fin de l'article.

Nouvelle tendance

Je travaille dans l'industrie du logiciel depuis plus que suffisamment de temps pour parler décemment, mais tout de même, seule une petite partie des tendances qui ont frappé notre industrie représentait pour moi. J'ai assisté à la croissance 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 modifient fondamentalement la façon dont les logiciels sont développés.

Autour de chaque nouvelle tendance, une certaine excitation générale se crée: les gens sautent dans le bateau ou voient le bruit généré par les autres - et suivent la foule. Ce processus est codifié par Gartner dans un cycle de battage médiatique . Bien que controversé, ce graphique décrit approximativement ce qui arrive aux technologies avant qu'elles ne deviennent finalement utilisables.

Mais de temps en temps, une nouvelle innovation apparaît (ou arrive une seconde venue, comme dans ce cas), entraînée par une seule implémentation spécifique. Dans le cas de NoSQL, le battage médiatique a été fortement stimulé par l'avènement et l'essor rapide de MongoDB. MongoDB n'a pas lancé cette tendance: en fait, les grandes sociétés Internet ont commencé à avoir des problèmes de traitement de grandes quantités de données, ce qui a conduit au retour de 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 abordable de la base de données NoSQL, à laquelle la plupart des développeurs avaient accès.

Remarque: vous pourriez penser que je mélange des bases de données de documents avec des bases de données de colonnes, des 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 tu as raison. Mais à cette époque, le chaos régnait. Tout le monde était obsédé par NoSQL, tout le monde en avait absolument besoin, bien que beaucoup ne voient pas les différences entre les différentes technologies. Pour beaucoup, MongoDB est devenu synonyme de NoSQL.

Et les développeurs l'ont attaquée. C'était une idée assez tentante d'avoir une base de données sans schéma qui évolue comme par magie pour résoudre n'importe quel problème. Vers 2014, il semblait que partout où une base de données relationnelle était utilisée il y a un an, comme MySQL, Postgres ou SQL Server, les bases de données MongoDB ont commencé à se déployer. À la question de savoir pourquoi, vous pourriez obtenir une réponse du banal «c'est l'échelle du web» au plus réfléchi «mes données sont très mal structurées et s'intègrent bien dans la base de données sans schéma».

Il est important de se rappeler que MongoDB et les bases de données de documents résolvent généralement un certain nombre de problèmes avec 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 obligé de créer un tas de colonnes de données aléatoires "différentes", d'y pousser des objets blob de données ou d'utiliser la configuration EAV ... tout cela a des inconvénients importants.
  
• La difficulté de la 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 les mettre à l'échelle sur plusieurs machines.
  
• Modifications de circuits sophistiquées : pas de migrations! Dans une base de données relationnelle, changer la structure de la base de données peut être un énorme problème (surtout quand il y a beaucoup de données). MongoDB a été en mesure de simplifier considérablement le processus. Et cela l'a rendu si facile que vous pouvez simplement mettre à jour le circuit en déplacement et avancer très rapidement.
  
• Performances d' enregistrement : les performances de MongoDB étaient bonnes, en particulier avec un réglage correct. Même la configuration MongoDB prête à l'emploi, pour laquelle elle a souvent été critiquée, a montré des mesures de 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 ci-dessus étaient accompagnés d'un certain nombre de réserves, dont certaines sont énumérées ci-dessous.

En toute justice, personne chez 10gen / MongoDB Inc. il ne dira pas que ce qui suit n'est pas vrai, c'est juste un compromis.

• Perte de transactions : les transactions sont une caractéristique majeure 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 garantir que les données resteront cohérentes. Bien sûr, avec une base de données NoSQL, la transactionnalité peut être dans le même document, ou vous pouvez utiliser des validations en deux phases pour obtenir la sémantique transactionnelle. Mais vous devez implémenter cette fonctionnalité vous-même ... ce qui peut être une tâche complexe et longue. Souvent, vous n'êtes pas conscient du problème jusqu'à ce que vous constatiez que les données de la base de données tombent dans des états inacceptables, car il est impossible de garantir l'atomicité des opérations. Remarque: beaucoup m'ont dit que les transactions étaient apparues dans MongoDB 4.0 l'année dernière, mais avec un certain nombre de limitations. La conclusion de l'article reste la même: évaluer comment la technologie répond à vos besoins.
  
• Perte d'intégrité relationnelle (clés étrangères) : s'il existe une relation dans vos données, vous devez l'appliquer dans l'application. Le fait d'avoir une base de données conforme à ces relations supprimera une partie importante du travail de l'application et, par conséquent, de vos programmeurs.
  
• Manque de capacité à appliquer la structure des données : les schémas stricts deviennent parfois un gros problème, mais c'est aussi un mécanisme puissant pour une bonne structuration des données, s'il est utilisé correctement. Les bases de données de documents telles que MongoDB offrent une flexibilité de schéma incroyable, mais cette flexibilité élimine la responsabilité de garder les données propres. Si vous ne vous en occupez pas, vous devrez finalement écrire beaucoup de code dans l'application pour tenir compte des données qui ne sont pas stockées sous la forme que vous attendez. Comme notre entreprise le dit souvent Simple Thread ... un jour, l'application sera réécrite et les données vivront pour toujours. Remarque: MongoDB prend en charge la validation de schéma: il est utile, mais n'offre pas les mêmes garanties que dans une base de données relationnelle. Tout d'abord, l'ajout ou la modification d'une vérification de schéma n'affecte pas les données existantes dans la collection. Vous devez vous-même vous assurer de mettre à jour les données conformément au nouveau schéma. Décidez par vous-même si cela suffit à vos besoins.
  
• Langage de requête natif / perte de l'écosystème d'outils : l'avènement de SQL est devenu une révolution absolue, et rien n'a changé depuis lors. C'est un langage incroyablement puissant, mais aussi assez complexe. La nécessité de concevoir 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 ayant de l'expérience avec SQL. Il existe tout un univers d'outils qui interagissent avec les bases de données SQL: de l'IDE aux outils de reporting. Accéder à 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 pour les utiliser, et cela 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é tête baissée, le configurant comme le principal magasin de données. 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 a touché le fond. Mais de nombreux projets ont installé la base MongoDB là où elle ne convenait tout simplement pas - et ils devront vivre avec elle pendant encore de nombreuses années. Si ces organisations avaient passé un certain temps et considéré méthodiquement le choix des technologies, 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 d'évaluation de la technologie, comme «Un cadre pour la mise en œuvre de la technologie dans les organisations de logiciels» et «Un cadre pour évaluer les technologies logicielles» , mais il me semble que c'est une complexité inutile.

De nombreuses technologies peuvent être raisonnablement évaluées en posant seulement deux questions fondamentales. Le problème est de trouver des personnes qui peuvent y répondre de manière responsable, en passant du temps à chercher des réponses et sans parti pris.

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

Question 1: Quels problèmes essaie-je de résoudre?

Si vous ne rencontrez aucun problème, vous n'avez pas besoin d'un nouvel outil. Le point. Pas besoin de chercher une solution et de trouver un problème. Si vous n'avez pas rencontré de problème qu'une nouvelle technologie ne résout pas beaucoup mieux que votre technologie existante, alors il n'y a rien à discuter. Si vous envisagez d'utiliser cette technologie parce que vous avez vu comment les autres l'utilisent, réfléchissez aux problèmes auxquels ils sont confrontés et demandez-leur si vous en avez. Il est facile d’accepter la technologie car d’autres l’utilisent, la difficulté est de comprendre si vous rencontrez les mêmes problèmes.

Question 2: Qu'est-ce que je perds?

C'est certainement une question plus difficile, car il faut creuser et bien comprendre les anciennes et les nouvelles technologies. Parfois, vous ne pouvez pas vraiment comprendre un nouveau jusqu'à ce que vous construisiez quelque chose avec ou que vous ayez un employé avec une telle expérience.

Si vous n'avez ni l'un ni l'autre, alors il est logique de penser à l'investissement minimum possible pour déterminer la valeur de cet outil. Et si vous faites un investissement, sera-t-il difficile d'inverser la décision?

Les gens gâchent toujours tout

En essayant de répondre à ces questions le plus impartialement possible, souvenez-vous d'une chose: vous devez lutter avec la nature humaine. Il existe un certain nombre de biais cognitifs qui doivent être surmontés pour évaluer efficacement la technologie. Voici quelques exemples:

• L'effet de rejoindre la majorité - tout le monde le sait, mais il est toujours difficile de se battre avec. Assurez-vous simplement que la technologie correspond vraiment à vos besoins réels.
  
• L'effet de la nouveauté - de nombreux développeurs ont tendance à sous-estimer les technologies avec lesquelles ils travaillent depuis longtemps et à surestimer les avantages de la nouvelle technologie. Pas seulement les programmeurs, tout le monde est soumis à ce biais cognitif.
  
• L'effet des caractéristiques positives - nous avons tendance à voir ce qui est et à perdre de vue ce qui manque. Cela peut conduire au chaos en combinaison avec l'effet de nouveauté, car non seulement vous surestimez la nouvelle technologie, mais vous ignorez également ses lacunes .

Une évaluation objective n'est pas facile, mais la compréhension des biais cognitifs de base aidera à prendre des décisions plus rationnelles.

Résumé

Lorsqu'une certaine innovation apparaît, il faut répondre avec soin à deux questions:

• Cet outil résout-il un vrai problème?
  
• Comprenons-nous bien les compromis?

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

MongoDB était-il donc généralement le bon choix? Bien sûr, 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 d'en bénéficier. Quiconque n'a pas fait cela, j'espère qu'ils ont reçu une leçon précieuse et pas trop douloureuse sur le mouvement le long du cycle de battage médiatique.

Clause de non-responsabilité

Je tiens à préciser que je n'ai ni amour ni haine pour MongoDB. C'est juste que nous n'avons eu aucun problème pour lequel MongoDB est le mieux adapté. Je sais que 10gen / MongoDB Inc. Au début, elle a agi avec beaucoup d'audace, en définissant des valeurs par défaut dangereuses et en promouvant MongoDB partout (en particulier sur les hackathons) en tant que solution universelle pour travailler avec toutes les 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.