Chapitre 23. Hibernate Search

Hibernate Search fournit la fonctionnalité de recherche de texte brut aux applications d'Hibernate. Cette fonctionnalité est particulièrement adaptée aux recherches de demandes pour lesquelles des solutions basées SQL ne sont pas adaptées, c'est à dire les recherches de texte brut, approximations, et géolocalisation. Hibernate Search utilise Apache Lucene comme moteur de recherche de texte intégral, mais est conçu pour minimiser la charge de maintenance. Une fois configuré, l'indexation, le clustering et la synchronisation de données sont maintenus en toute transparence, ce qui vous permet de mettre l'accent sur les besoins de votre entreprise.

Hibernate Search se compose d'un composant d'indexation, ainsi que d'un composant de recherche d'index, tous deux soutenus par Apache Lucene. Chaque fois qu'une entité est insérée, mise à jour ou supprimée de la base de données, Hibernate Search assure le suivi de cet événement (par le système d'événements d'Hibernate Search) et planifie une mise à jour de l'index. Toutes ces mises à jour sont gérées sans que vous ayiez à interagir directement avec les API d'Apache Lucene. Au lieu de cela, l'interaction avec les indexes de Lucene sous-jacents est gérée par l'intermédiaire d'un IndexManager.

Une fois que l'index est créé, vous pouvez rechercher des entités et retourner des listes d'entités gérées, au lieu de vous pencher sur l'infrastructure sous-jacente de Lucene. Le même contexte de persistance est partagé entre Hibernate et Hibernate Search. La classe FullTextSession est construite au-dessus de la classe Hibernate Session afin que le code d'application puisse utiliser les API unifiés org.hibernate.Query ou javax.persistence.Query exactement de la même manière qu'une requête native, HQL, ou JPA-QL le ferait.

Chaque fois qu'une entité est insérée, mise à jour ou supprimée de la base de données, Hibernate Search assure le suivi de cet événement à travers le système d'événements d'Hibernate et planifie une mise à jour de l'index. L'interaction avec les index de Lucene sous-jacents est gérée par un IndexManager, qui les identifie chacun par son nom. Par défaut, il existe une relation one-to-one entre l'IndexManager et l'index de Lucene. L'IndexManager extrait la configuration d'un index spécifique, dont le backend sélectionné, la reader startegy (stratégie de lecteur) et le DirectoryProvider choisi.

Apache Lucene, qui fait partie de l'infrastructure d'Hibernate Search, possède un concept de répertoire pour le stockage d'index. Hibernate Search gère l'initialisation et la configuration d'une instance d'un répertoire de Lucene via un Fournisseur de répertoires.

La propriété directory_provider indique le fournisseur de répertoires à utiliser pour stocker les index. Le fournisseur de répertoires de système de fichier par défaut est filesystem, qui utilise le système de fichiers local pour stocker les index.

Les mises à jour aux indexes de Lucene sont gérées par le worker d'Hibernate Search, qui reçoit toutes les modifications de l'entité, les met en files d'attentes de contexte et les applique une fois qu'un contexte se termine. Le contexte le plus courant est la transaction, mais peut dépendre du nombre de modifications de l'entité ou de certains autres événements de l'application (cycle de vie).

Pour une plus grande efficacité, les interactions sont groupées et sont généralement appliquées une fois que le contexte se termine. En dehors d'une transaction, l'opération de mise à jour d'index est exécutée juste après l'opération de base de données réelle. Dans le cas d'une transaction en cours, l'opération de mise à jour d'index est prévue pour la phase de validation de la transaction et sera ignorée en cas de restauration de transaction. Un worker peut être configuré avec une limite de taille de lot spécifique, après quoi l'indexation se produit quel que soit le contexte.

Pour obtenir des informations sur les options de configuration du worker, voir Section 23.2.5, « Configuration d'un worker ».

Il y a deux avantages immédiats à cette méthode de gérer les mises à jour d'indexes :

Les deux modes de lots - no scope vs transactionnel - sont l'équivalent d'autocommit versus comportement transactionnel. D'un point de vue performance, le mode transactionnel est recommandé. Le choix de scoping se fait en toute transparence. Hibernate Search détecte la présence d'une transaction et ajuste le scoping (voir Section 23.2.5, « Configuration d'un worker »).

Lorsque vous exécutez une requête, Hibernate Search, utiliser une stratégie de lecture pour pouvoir interagir avec les indexes d'Apache Lucene. Choisissez une stratégie de lecture basée sur le profil de la demande (mises à jour fréquentes, lecture principalement, mise à jour asynchrone d'index, etc.).

hibernate.search.[default|<indexname>].reader.strategy = not-shared

hibernate.search.[default|<indexname>].reader.strategy = my.corp.myapp.CustomReaderProvider