Red Hat Training

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

14.5. Index Optimization

From time to time, the Lucene index needs to be optimized. The process is essentially a defragmentation. Until an optimization is triggered Lucene only marks deleted documents as such, no physical are applied. During the optimization process the deletions will be applied which also affects the number of files in the Lucene Directory.
Optimizing the Lucene index speeds up searches but has no effect on the indexation (update) performance. During an optimization, searches can be performed, but will most likely be slowed down. All index updates will be stopped. It is recommended to schedule optimization:
  • On an idle system or when searches are least frequent.
  • After a large number of index modifications are applied.
MassIndexer (see Section 14.4.3.2, “Using a MassIndexer”) optimizes indexes by default at the start and at the end of processing. Use MassIndexer.optimizeAfterPurge and MassIndexer.optimizeOnFinish to change this default behavior.

14.5.1. Automatic Optimization

Hibernate Search can automatically optimize an index after either:
  • a certain amount of operations (insertion or deletion).
  • a certain amount of transactions.
The configuration for automatic index optimization can be defined either globally or per index:

Example 14.67. Defining automatic optimization parameters

hibernate.search.default.optimizer.operation_limit.max = 1000
hibernate.search.default.optimizer.transaction_limit.max = 100
hibernate.search.Animal.optimizer.transaction_limit.max = 50
An optimization will be triggered to the Animal index as soon as either:
  • the number of additions and deletions reaches 1000.
  • the number of transactions reaches 50 (hibernate.search.Animal.optimizer.transaction_limit.max has priority over hibernate.search.default.optimizer.transaction_limit.max)
If none of these parameters are defined, no optimization is processed automatically.
The default implementation of OptimizerStrategy can be overridden by implementing org.hibernate.search.store.optimization.OptimizerStrategy and setting the optimizer.implementation property to the fully qualified name of your implementation. This implementation must implement the interface, be a public class and have a public constructor taking no arguments.

Example 14.68. Loading a custom OptimizerStrategy

hibernate.search.default.optimizer.implementation = com.acme.worlddomination.SmartOptimizer
hibernate.search.default.optimizer.SomeOption = CustomConfigurationValue
hibernate.search.humans.optimizer.implementation = default
The keyword default can be used to select the Hibernate Search default implementation; all properties after the .optimizer key separator will be passed to the implementation's initialize method at start.

14.5.2. Manual Optimization

You can programmatically optimize (defragment) a Lucene index from Hibernate Search through the SearchFactory:

Example 14.69. Programmatic Index Optimization

FullTextSession fullTextSession = Search.getFullTextSession(regularSession);
SearchFactory searchFactory = fullTextSession.getSearchFactory();

searchFactory.optimize(Order.class);
// or
searchFactory.optimize();
The first example optimizes the Lucene index holding Orders and the second optimizes all indexes.

Note

searchFactory.optimize() has no effect on a JMS backend. You must apply the optimize operation on the Master node.

14.5.3. Adjusting Optimization

Apache Lucene has a few parameters to influence how optimization is performed. Hibernate Search exposes those parameters.
Further index optimization parameters include:
  • hibernate.search.[default|<indexname>].indexwriter.max_buffered_docs
  • hibernate.search.[default|<indexname>].indexwriter.max_merge_docs
  • hibernate.search.[default|<indexname>].indexwriter.merge_factor
  • hibernate.search.[default|<indexname>].indexwriter.ram_buffer_size
  • hibernate.search.[default|<indexname>].indexwriter.term_index_interval