Recherche « plein texte » vs. recherche « classique »

Dans une application, le besoin de réaliser des recherches se fait régulièrement sentir. La manière classique de répondre à ce besoin est de proposer un écran de recherche proposant un certain nombre de critères, techniquement traduit par une requête en base de données.

Ce type de recherche aboutit à une grande complexité des requêtes de recherche :

  • Clause select de n colonnes
  • Clause where avec jointure de m tables
  • Clause like afin de gérer les recherches de mots partiels
  • ...

Ces requêtes permettent d’effectuer des recherches sur des critères précis, mais ont leurs limites. En effet, avec les moteurs de recherche sur internet tels que Google, les utilisateurs ont pris l’habitude d’effectuer des recherches sur des mots clés et d’obtenir des résultats prenant en compte des variantes des mots clés et classés par pertinence.

La recherche « plein texte » à la rescousse

La recherche « plein texte » permet d’effectuer des recherches à l’aide de mots clés en se basant sur un index construit à l’aide de différents algorithmes afin de gérer les problématiques de synonymes, fautes de frappe, etc.

Différentes solutions existent afin d’implémenter des recherches « plein texte » : recherche intégrée à la base de données ou à l’aide d’API indépendante de la base telle que Lucene.

Lucene

Lucene est un moteur de recherche libre de la fondation Apache. Ce moteur, écrit en Java, permet :

  • d’effectuer des recherches ordonnées par pertinence selon différents critères : importance d’un champ sur un autre, nombre de mots clés présents dans un document, etc.
  • de réaliser une analyse des mots clés afin de filtrer les mots courants (conjonctions …), détecter les anagrammes, effectuer des approximations (afin de gérer les fautes de frappes), réaliser une recherche phonétique, rechercher par synonymes, rechercher par mots de la même famille (aimer / aimera / aimeront / ...), etc.
  • de ne pas se soucier de la casse
  • ...

Cependant la complexité de l’API de Lucene et sa liaison forte avec la couche de persistance ne permet pas de l’intégrer simplement à une application.

Les API d’encapsulation de Lucene

Hibernate Search permet de s’affranchir de la complexité de Lucene et s’intègre directement à Hibernate. Un des principaux concurrents de Hibernate Search est Compas qui permet de plus de s’intégrer à Spring. L’intérêt de ces frameworks est d’ajouter à Lucene la notion d’objet et de conserver une séparation entre la couche de persistance et le code de synchronisation de l’index de Lucene.

Architecture Lucene

Tandis qu’Hibernate Search s’intègre directement et uniquement à Hibernate, Compass permet d’utiliser différents frameworks ORM (Hibernate, JPA, JDO, OJB, iBATIS, JDBC) et peut à l’aide de Spring s’intégrer de manière transparente à l’aide de l’AOP.

Le principal avantage de ces frameworks est de masquer la complexité de Lucene. De plus, Lucene travaillant avec un index totalement indépendant des données indexées, cela permet de garder un découpage fort entre la couche de données et la couche de recherche.

Le principal inconvénient vient de la façon de fonctionner en interne de Lucene. En effet, l’API doit être avertie à chaque ajout / modification / suppression d’éléments en base. C’est le rôle d’Hibernate Search ou de Compass de réaliser ce travail. C’est justement là les limites de ce  modèle dans le cas où les bases de données utilisées par le framework ORM sont aussi accédées par d’autres programmes.

Laisser un commentaire

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

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.