Apache Solr Reference Guide Covering Apache Solr 6.0

number A Velocity NumberTool instance
sort A Velocity SortTool instance
display A Velocity DisplayTool instance
resource A Velocity ResourceTool instance
engine
page
debug
content
[custom
tool(s)]
The current VelocityEngine instance
An instance of Solr's PageTool (only included if the response is a QueryResponse where paging
makes sense)
A shortcut to the debug part of the response, or null if debug is not on. This is handy for having
debug-only sections in a template using #if($debug)...#end
The rendered output of the main template, when rendering the layout (v.layout.enabled=true and
v.layout=).
Tools provided by the optional "tools" list of the VelocityResponseWriter registration are available
by their specified name.
Near Real Time Searching
Near Real Time (NRT) search means that documents are available for search almost immediately after being
indexed: additions and updates to documents are seen in 'near' real time. Solr does not block updates while a
commit is in progress. Nor does it wait for background merges to complete before opening a new search of
indexes and returning.
With NRT, you can modify a commit command to be a soft commit, which avoids parts of a standard commit
that can be costly. You will still want to do standard commits to ensure that documents are in stable storage, but
soft commits let you see a very near real time view of the index in the meantime. However, pay special
attention to cache and autowarm settings as they can have a significant impact on NRT performance.
Commits and Optimizing
A commit operation makes index changes visible to new search requests. A hard commit uses the transaction
log to get the id of the latest document changes, and also calls fsync on the index files to ensure they have
been flushed to stable storage and no data loss will result from a power failure.
A soft commit is much faster since it only makes index changes visible and does not fsync index files or write
a new index descriptor. If the JVM crashes or there is a loss of power, changes that occurred after the last hard
commit will be lost. Search collections that have NRT requirements (that want index changes to be quickly
visible to searches) will want to soft commit often but hard commit less frequently. A softCommit may be "less
expensive" in terms of time, but not free, since it can slow throughput.
An optimize is like a hard commit except that it forces all of the index segments to be merged into a single
segment first. Depending on the use, this operation should be performed infrequently (e.g., nightly), if at all, since
it involves reading and re-writing the entire index. Segments are normally merged over time anyway (as
determined by the merge policy), and optimize just forces these merges to occur immediately.
Soft commit takes uses two parameters: maxDocs and maxTime.
Parameter
Description
Apache Solr Reference Guide 6.0
400