Apache Solr Reference Guide Covering Apache Solr 6.0

Merging Index Segments
mergePolicyFactory
Defines how merging segments is done. The default in Solr is to use a TieredMergePolicy, which merges
segments of approximately equal size, subject to an allowed number of segments per tier. Other policies
available are the LogByteSizeMergePolicy and LogDocMergePolicy. For more information on these
policies, please see the MergePolicy javadocs.
10
10
Controlling Segment Sizes: Merge Factors
The most common adjustment some folks make to the configuration of TieredMergePolicy (or
LogByteSizeMergePolicy) are the "merge factors" to change how many segments should be merged at one
time. For TieredMergePolicy, this is controlled by setting the and options, while LogByteSizeMergePolicy has a single option (all of which default to " 10").
To understand why these options are important, consider what happens when an update is made to an index
using LogByteSizeMergePolicy: Documents are always added to the most recently opened segment. When
a segment fills up, a new segment is created and subsequent updates are placed there. If creating a new
segment would cause the number of lowest-level segments to exceed the mergeFactor value, then all
those segments are merged together to form a single large segment. Thus, if the merge factor is 10, each
merge results in the creation of a single segment that is roughly ten times larger than each of its ten
constituents. When there are 10 of these larger segments, then they in turn are merged into an even larger
single segment. This process can continue indefinitely.
When using TieredMergePolicy, the process is the same, but instead of a single mergeFactor value, the se
gmentsPerTier setting is used as the threshold to decide if a merge should happen, and the maxMergeAt
Once setting determines how many segments should be included in the merge.
Choosing the best merge factors is generally a trade-off of indexing speed vs. searching speed. Having fewer
segments in the index generally accelerates searches, because there are fewer places to look. It also can
also result in fewer physical files on disk. But to keep the number of segments low, merges will occur more
often, which can add load to the system and slow down updates to the index.
Conversely, keeping more segments can accelerate indexing, because merges happen less often, making an
update is less likely to trigger a merge. But searches become more computationally expensive and will likely
be slower, because search terms must be looked up in more index segments. Faster index updates also
means shorter commit turnaround times, which means more timely search results.
Customizing Merge Policies
If the configuration options for the built-in merge policies do not fully suit your use case, you can customize
them: either by creating a custom merge policy factory that you specify in your configuration, or by configuring
a merge policy wrapper which uses a wrapped.prefix configuration option to control how the factory it
wraps will be configured:
Apache Solr Reference Guide 6.0
441