Fonctionnalités de recherche avancée dans les applications existantes (legacy)


Recherche avancée

L’évangéliste David Pilato de la société Elastic, via sa présentation très bien faite, nous démontre rapidement les avantages à ajouter des fonctionnalités de recherche avancée dans les applications legacy (vidéo à la fin de l’article).

C’est à dire, dans les SI (système d’information) des grandes entreprises, on a souvent de très nombreuses applications qui fonctionnent bien et que l’on ne compte pas refaire complètement.
Par contre, il est possible grace à des technologies qui n’avaient pas été mise en oeuvre au départ, d’ajouter des fonctionnalités intéressantes pour les utilisateurs, les « métiers ».
Parmi ces technologies, on va voir le gain apporté par l’ajout d’un moteur d’indexation comme Elasticsearch ou Solr notamment, sans recoder l’application entièrement et sans se séparer des bases de données historiques.

Il ne s’agit pas de basculer dans le NoSQL. Dans sa démo, David ajoute Elasticsearch sur une application Java / Hibernate / BDD classique (MySQL).
Il ne change pas l’architecture, rajoute juste l’indexation des données lors des inserts et des updates sur la BDD, puis reroute les recherches sur le moteur d’indexation.

Première question : Y a-t-il une perte de performance?
– en lecture (recherche), bien au contraire, c’est plus performant et avec des fonctionnalités avancées
– en écriture (insert et update), pratiquement pas grace au client bulk qui bufferise les indexations par paquet et qui flush automatiquement au bout d’un certains délai.

Concrètement, on ajoute une librairie (dépendance Maven), quelques lignes de java et un cluster Elasticsearch à côté.

Côté IHM, on peut passer d’une recherche multi-champs à une recherche avec un champ unique façon « Google ».
On ajoute la recherche approchante, à une lettre près, phonétique, etc…
Le plus gros changement, c’est que le résultat est trié par pertinence.
Le moteur donne des scores de pertinence à chaque résultat et présente en premier ce qu’il pense être le plus pertinent.
Cela implique que le moteur ne retourne plus juste les résultats qui correspondent strictement à la recherche, mais bien tout ce qui est approchant mais trié par pertinence.

L’exemple classique c’est la recherche de produits dans un catalogue.
Si je cherche avec la référence numérique, le moteur va me sortir la fiche produit exacte.
Si je cherche avec le nom du produit, le moteur va me sortir en priorité les produits qui ont ces termes dans le titre de la fiche. Mais aussi, en second résultat, ceux qui ont ces termes dans la descriptions.
Pour ce faire simplement, il faut préciser dans le moteur un poids de pertinence décroissant sur les champs référence puis titre puis description.

Comme on le voit dans la démo, David nous montre un autre critère qui joue sur le classement de pertinence.
Avec sa recherche sur le prénom « France », France Gall sort en premier devant tous les contacts qui habitent en France car le prénom France est plus rare que les adresses en France.

Voilà, je ne vous raconte pas toute la démo, elle vaut le coup d’être visionnée, elle montre aussi un début de recherche facettée (faceted search / aggregation) pour aller encore plus loin…
Et en cherchant, j’en ai trouvé une deuxième version où David ne montre pas tout à fait les même choses.
Je vous mets les 2 versions ci-dessous.

Codemotion 2018, Amsterdam

JUG.ru, Joker 2016, Saint Petersburg

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *