Bonjour,
Nous sommes en pleine réflexion pour revoir nos types de documents suite à la mise en place d'une nouvelle architecture de notre projet.
Nous souhaitons mettre en place une architecture avec une application "core", contenant des entités génériques "core" et nous voudrions agréger d'autres applications à notre architecture. Les applications agrégées vont utiliser les entités "core" et vont les enrichir avec des nouveaux champs. Par exemple, l'entité "Membre" du core contiendrait le nom et le prénom, et l'application X ajouterait à cette entité "Membre" un champ "Adresse professionnelle".
De plus, notre architecture sera utilisée par plusieurs plateformes, chacune bénéficiant d'une base de données et d'un index ElasticSearch propre, mais stocké sur une seule et même instance d'ElasticSearch.
Nous aimerions pouvoir faire des requêtes sur les index ElasticSearch de manière à pouvoir récupérer des informations des entités "core" ainsi que les informations des applications agrégées quand celles-ci sont activées.
Afin de réaliser cela, nous avons pensé à utiliser les relations "parents/enfants" dans nos types ElasticSearch.
Les entités du "core" représenteraient les types parents, et les entités des autres applications seraient des enfants.
Nous nous posons quelques questions sur les performances des relations parents/enfants, sur la pérennité de ce choix, ainsi que sur les contraintes que ce choix implique. Par exemple, qu'en est-il de la possibilité de définir des "petits-enfants", des "petits-petits-enfants" ? Les relations parents/enfants doivent-elles être utilisées avec parcimonie ?
De plus, nous avons pensé à deux autres possibilités :
- Utiliser des types "à plats" : les applications agrégées définissent leurs propres types ES et chaque type contient l'ensemble des données de l'entité "core" et les données liées à l'application.
- Utiliser des recherches multi-types, où le core définit ses types ES et les applications agrégées définissent des types avec leurs données propres uniquement.
Est-ce que les index "à plats" seraient plus performants et plus recommandés ? Est-ce que la mise à jour des données ne deviendrait pas trop gourmande ?
La recherche multi-types permet-elle de récupérer l'ensemble des informations des types recherchés ? (Pour reprendre l'exemple du Membre, il faudrait récupérer à la fois le nom, le prénom et l'adresse professionnelle du membre en une seule requête)