Hibernate.orgCommunity Documentation
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 deletions are applied. During the optimization process the deletions will be applied which also effects 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 the searches are less frequent
after a lot of index modifications
When using a MassIndexer (see
Section 6.3.2, “Using a MassIndexer”) it will optimize involved
indexes by default at the start and at the end of processing; you can change
this behavior by using respectively
MassIndexer.optimizeAfterPurge
and MassIndexer.optimizeOnFinish.
Hibernate Search can automatically optimize an index after:
a certain amount of operations (insertion, deletion)
or a certain amount of transactions
The configuration for automatic index optimization can be defined on a global level or per index:
Example 7.1. 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
having 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 overriden 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 7.2. 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.
You can programmatically optimize (defragment) a Lucene index from
Hibernate Search through the SearchFactory:
Example 7.3. 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; the second, optimizes all indexes.
searchFactory.optimize() has no effect on a JMS
backend. You must apply the optimize operation on the Master
node.
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_docshibernate.search.[default|<indexname>].indexwriter.max_merge_docshibernate.search.[default|<indexname>].indexwriter.merge_factorhibernate.search.[default|<indexname>].indexwriter.ram_buffer_sizehibernate.search.[default|<indexname>].indexwriter.term_index_intervalSee Section 3.6, “Tuning Lucene indexing performance” for more details.