Définition de types : parent/enfant, à plat ou multi-types?


(Amandine B) #1

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)


(David Pilato) #2

Une remarque d'abord. La notion de type disparait en 6.0. Il sera donc impossible de créer des multi-types par index. Parent/child doit être adapté d'ailleurs pour continuer à être supporté.

Ensuite sur p/c vs structure à plat, je préfère définitivement la structure à plat.
Elle a des inconvénients c'est certain mais elle est beaucoup beaucoup plus efficace.

Notamment elle évite de faire des joins donc de stocker des id en HEAP et de colocaliser les documents dans les même shards.

Je copierais donc les données utiles des parents et grands-parents dans les enfants.

Ca t'aide ?


(Amandine B) #3

Merci beaucoup pour cette réponse !
Oui, ça m'aide sur la solution à privilégier.

Concernant les index à plat, à partir de combien de champs peut-on considérer qu'un document est trop volumineux ? Si notre document contient entre 50 et 100 champs de type chaines de caractère ou entier, est-ce acceptable ?
Le volume d'un document a t'il beaucoup d'impact sur les performances de recherche ?

Merci pour votre aide.


(David Pilato) #4

Oui. Il y a une limite hard à 1000 champs je crois par type.

50 à 100 champs me semble raisonnable.


(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.