Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

23.2.6. Réglage de l'indexation de Lucene

23.2.6.1. Optimiser la performance d'indexation de Lucene

Hibernate Search est utilisée pour optimiser les performances d'indexation Lucene en spécifiant un ensemble de paramètres qui sont passés à l'IndexWriter de Lucene sous-jacent, comme mergeFactor, maxMergeDocs et maxBufferedDocs. Spécifiez ces paramètres soit en tant que valeurs par défaut pour tous les index, sur une base par index ou par partition.
Il existe plusieurs configurations d'IndexWriter de bas niveau qui peuvent être ajustées suivant les cas d'utilisation. Ces paramètres sont regroupés sous le mot clé indexwriter :
hibernate.search.[default|<indexname>].indexwriter.<parameter_name>
S'il n'y a pas de valeur pour indexwriter de déterminée pour une configuration de partition, alors Hibernate Search regardera dans la section de l'index, puis dans la section par défaut.
La configuration dans la table suivante s'applique à la seconde partition de l'index Animal :
  • max_merge_docs = 10
  • merge_factor = 20
  • ram_buffer_size = 64MB
  • term_index_interval = Lucene default
Toutes les autres valeurs utiliseront les valeurs par défaut utilisées dans Lucene.
Les valeurs par défaut de Lucene sont les valeurs de configuration par défaut. Les valeurs listées dans Tableau 23.5, « Liste des propriétés de comportement et de performance d'indexation » dépendent de la version de Lucene utilisée. Les valeurs indiquées se rapportent à la version 2.4. Pour plus d'informations sur la performance d'indexation de Lucène, voir la documentation de Lucene.

Note

Les versions précédentes d'Hibernate Search avaient la notion de propriété batch (lot) et de transaction. Ce n'est plus le cas car le backend effectuera toujours les travaux avec les mêmes paramètres.

Tableau 23.5. Liste des propriétés de comportement et de performance d'indexation

Propriété Description Valeur par défaut
hibernate.search.​[default|<indexname>].​exclusive_index_use
Définir à true quand aucun autre processus n'aura besoin d'écrire le même index. Cela permet à Hibernate Search de fonctionner en mode exclusif sur l'index et d'améliorer la performance quand on fait des modifications dans l'index.
true (meilleure performance, débloque les verrous uniquement lors de la fermeture)
hibernate.search.​[default|<indexname>].​max_queue_length
Chaque index a un « pipeline » séparé qui contient les mises à jour à appliquer à l'index. Quand cette file d'attente est pleine, ajouter des opérations supplémentaires à la file d'attente se traduit en opération de blocage. Cette configuration de paramètre n'est pas très logique à moins que worker.execution soit configuré à async.
1000
hibernate.search.​[default|<indexname>].​indexwriter.max_buffered_delete_terms
Détermine le nombre minimum de d'expressions à supprimer avant que les expressions à supprimer en mémoire tampon s'appliquent et soient vidées. S'il y a des documents en mémoire tampon à ce moment là, ils sont fusionnés et un nouveau segment est créé.
Désactivé (vidages par utilisation RAM)
hibernate.search.​[default|<indexname>].​indexwriter.max_buffered_docs
Contrôle le nombre de documents présents en mémoire tampon lors de l'indexation. Plus il y en a, plus il y a de RAM utilisée.
Désactivé (vidages par utilisation RAM)
hibernate.search.​[default|<indexname>].​indexwriter.max_merge_docs
Définit le nombre maximum de documents autorisés par segment. Les petites valeurs fonctionnent mieux sur les indexes changeant fréquemment; les valeurs plus élevées permettent une meilleure performance de recherche si l'index ne change pas trop souvent.
Illimité (Integer.MAX_VALUE)
hibernate.search.​[default|<indexname>].​indexwriter.merge_factor
Contrôle la taille et la fréquence des fusions de segments.
Détermine le nombre de fois que les indexes de segments sont fusionnés quand un insertion a lieu. Pour les petites valeurs, on utilise moins de RAM lors de l'indexation, et les recherches sur indexes non optimisés sont plus rapides, mais la vitesse d'indexation est lente. Ainsi, les valeurs plus elevées, (> 10) sont plus appropriées pour la création d'index de lots, et les plus petites valeurs (< 10) sont plus appropriées pour les indexes maintenus de façon interactive. La valeur doit être inférieure à 2.
10
hibernate.search.​[default|<indexname>].​indexwriter.merge_min_size
Contrôle la taille et la fréquence des fusions de segments.
Les segments inférieurs à cette taille (en Mo) sont toujours pris en compte pour la prochaine opération de fusionnement de segments.
Si vous configurez une taille trop elevée, vous obtiendrez d'énormes opérations de fusionnement, même si elles sont moins fréquentes.
Voir également org.apache.lucene.index.LogDocMergePolicy. minMergeSize.
0 Mo (en réalité ~1K)
hibernate.search.​[default|<indexname>].​indexwriter.merge_max_size
Contrôle la taille et la fréquence des fusions de segments.
Les segments inférieures à cette taille (en Mo) ne sont jamais fusionnés en segments plus importants.
Cela fait des économies de mémoire et évite les opérations de fusionnement qui ont lieu aux dépends d'une vitesse optimale de recherche. Quand on optimise un index, cette valeur est ignorée.
Voir également org.apache.lucene.index.LogDocMergePolicy. maxMergeSize.
Illimité
hibernate.search.​[default|<indexname>].​indexwriter.merge_max_optimize_size
Contrôle la taille et la fréquence des fusions de segments.
Les segments supérieurs en taille à ceci (en Mo) ne sont pas fusionnés en segments plus importants même quand on optimise l'index (voir la configuration merge_max_size également).
S'appliquant à org.apache.lucene.index.LogDocMergePolicy. maxMergeSizeForOptimize.
Illimité
hibernate.search.​[default|<indexname>].​indexwriter.merge_calibrate_by_deletes
Contrôle la taille et la fréquence des fusions de segments.
Définir à false afin de ne pas considérer les documents supprimés quand on estime la stratégie de fusionnement.
S'appliquant à org.apache.lucene.index.LogMergePolicy. calibrateSizeByDeletes.
true
hibernate.search.​[default|<indexname>].​indexwriter.ram_buffer_size
Contrôle le montant de RAM en Mo qui est utilisé pour les tampons de docments. Quand ils sont utilisés avec max_buffered_docs, on assiste à un vidage, selon qu'un événement a lieu avant l'autre.
Normalement, pour augmenter la performance d'indexation, il vaut mieux vider par l'utilisation RAM et non pas le nombre de documents, et utiliser le plus grand tampon RAM possible.
16 Mo
hibernate.search.​[default|<indexname>].​indexwriter.term_index_interval
Expert : définir l'intervalle entre les expressions indexées.
Avec les valeurs élevées, IndexReader utilise moins de mémoire, mais l'accès au hasard aux termes est plus lent. Avec les valeurs moins élevées, IndexReader utilise plus de mémoire, et la vitesse d'accès aux termes est plus élevée. Voir la documentation Lucene pour obtenir plus d'informations.
128
hibernate.search.​[default|<indexname>].​indexwriter.use_compound_file
L'avantage d'utiliser un format de ficher composite, c'est qu'il y a moins de descripteurs de fichiers utilisés. L'inconvénient, c'est que l'indexation prend plus de temps et d'espace de disque temporaire. Vous pouvez définir ce paramètre à false en vue d'améliorer le temps d'indexation, mais vous pourriez manquer de descripteurs de fichiers si mergeFactor est trop élevé.
Pour le paramètres booléens, utiliser "true" ou "false". La valeur par défaut pour cette option est true.
true
hibernate.search.​enable_dirty_check
Tous les changements d'entité ne nécessitent pas une mise à jour d'index Lucene. Si toutes les propriétés d'entité mises à jour (propriétés dirty) ne sont pas indexées, Hibernate Search évitera le processus de ré-indexation.
Désactiver cette option si vous personnalisez des FieldBridge qui ont besoin d'être évoqués à chaque mise à jour d'événement (même si la propriété pour laquelle le pontage de champ est configuré n'a pas changé).
Cette optimisation ne sera plas utilisée sur les classes qui utilisent un @ClassBridge ou un @DynamicBoost.
Pour le paramètres booléens, utiliser "true" ou "false". La valeur par défaut pour cette option est true.
true

Avertissement

Le back end blackhole n'est pas conçu pour être utilisé en production, sauf en tant qu'outil pour identifier les étranglements d'indexation.