lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Trivial Update of "UpdateXmlMessages" by YonikSeeley
Date Sun, 19 Feb 2012 19:16:19 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "UpdateXmlMessages" page has been changed by YonikSeeley:
http://wiki.apache.org/solr/UpdateXmlMessages?action=diff&rev1=38&rev2=39

Comment:
make sure users know optimize is expensive

  
  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 near-real-time requirements (that want index changes to be quickly visible to searches)
will want to soft commit often but hard commit less frequently.
  
- 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 cases, this operation should
be performed infrequently, 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.
+ 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 cases, this operation should
be performed infrequently (like nightly), if at all, since it is very expensive and 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.
  
  Example:
     {{{

Mime
View raw message