Table vs Document : BridgeStone préfère le modèle document pour la conception de ses pneus
La modélisation des données sous la forme de documents de MongoDB, plutôt que sous la forme relationnelle, a permis au spécialiste des pneumatiques de pouvoir requêter plus granulairement ses données et de favoriser le partage d’informations avec l’ensemble de ses équipes.
Bridgestone a préféré modéliser l’ensemble des données de conception et de simulation de ses pneus dans un modèle document (avec MongoDB) plutôt que dans un modèle relationnel, afin de faciliter l’accès aux données par ses équipes de R&D dans le monde entier. L’équipementier, spécialisé dans la fabrication de pneumatiques est un grand consommateur de R&D. Celle-ci est composée d’équipes localisées dans trois centres, un aux Etats-Unis (Akron, Ohio), un autre en Europe (Rome) et un autre au Japon (Tokyo) pour le marché asiatique. A travers le fruit de leurs recherches, ces équipes alimentent 180 usines du groupe.
Bridgestone équipe historiquement ces équipes d’une solution-maison dédiée à la conception et à la simulation nommée Vulcan. Celle-ci permet de partager simplement des fichiers que les équipes se transmettent via un client Windows. Vulcan a connu de nombreuses itérations et ce système a fini par devenir spécifique à chaque pays, lance Andy Hovest, Software Architect, chez BrigdeStone Americas, qui intervenait lors de MongoDB World 2019.
« Collaborer sur les design se résumait la plupart du temps à copier des fichiers d’un endroit vers un autre. »
Andy HovestSoftware Architect, BrigdeStone Americas
Les fichiers étaient stockés selon la propre structure de chacun. « Collaborer sur les design se résumait la plupart du temps à copier des fichiers d’un endroit vers un autre. Les fichiers étaient envoyés par courriel à un autre ingénieur, qui essayait de récupérer ces fichiers dans sa version de Vulcain ». Un problème de synchronisation d’abord, mais aussi un problème de continuité de l’activité, ajoute-t-il. Car si un membre de l’équipe japonaise venait au centre américain, il ne retrouvait pas systématiquement ses travaux réalisés dans son centre à Tokyo s’il n’avait pas copié au préalable ses fichiers. Il est donc apparu qu’une base de données était la solution à mettre en place dans la R&D de Bridgestone. L’intérêt était aussi de pouvoir bénéficier d’accès multiples aux données et d’en modifier les entrées de façon concurrentielle.
Des tables trop étriquées
Mais Bridgestone, en travaillant minutieusement à analyser la nature de ses données, a conclu que le modèle relationnel ne convenait pas à sa structure de données et à ses usages. Comme Andy Hovest le précise, le modèle de données qu’implique la conception et la simulation des pneus est complexe, car elle doit prendre en compte nombre de composants type, mais également les données à destination et issues des simulations. Les équipes ont ainsi élaboré une « métaphore » spécifique, comme l’indique le responsable, qui prend aussi en compte l’ensemble des aspects de la géométrie des pneus. Cela consiste à mentionner des points, des lignes, des courbes, des zones. « Ce qui ne semblait pas convenir à des tables », a ainsi appris Andy Hovest.
« L'utilisation de la base de données documents et l'utilisation de documents imbriqués nous aide vraiment à interroger différents aspects de la géométrie. »
Andy HovestSoftware Architect, BrigdeStone Americas
« Avec les bases de données relationnelles, l'information est stockée sous la forme d'un gros blob binaire dans une table, que vous sortez simplement quand vous en avez besoin. Mais cela ne nous permet pas en grande partie d'interroger des caractéristiques spécifiques de cette géométrie, ou encore d'autres informations qui pourraient être enfouies dans ce blob binaire. L'utilisation de la base de données documents et l'utilisation de documents imbriqués [Embedded documents, N.D.L.R.] nous aide vraiment à interroger différents aspects de la géométrie et ce dans les différentes phases de données de fabrication ».
« En plus de la géométrie, les simulations elles-mêmes ne se prêtent souvent pas très bien aux tables », ajoute-t-il encore. « Avec des tables, vous essayez de faire entrer dans un schéma fixe des entrées qui ont des quantités exponentielles d'informations. »
Cette structure de données permet en somme de descendre beaucoup plus granulairement dans la captation de l’information. Chaque document correspond à la représentation d’un aspect de la métaphore de Bridgestone (géométrie, simulations et leurs résultats, spécification de fabrication, projets en cours), et chacun de ces aspects ajoute ses propres informations à chaque étape. L’ensemble est partagé et accessible à l’ensemble des équipes.
