lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky" <j...@basetechnology.com>
Subject Re: Overlapping onDeckSearchers=2
Date Mon, 27 May 2013 14:04:27 GMT
As the wiki does say: "if at all ... Segments are normally merged over time 
anyway (as determined by the merge policy), and optimize just forces these 
merges to occur immediately."

So, the only real question here is if the optimize really does lie outside 
the "if at all" category and whether "Segments are normally merged over time 
anyway" is in fact not good enough.

This is why I referred to "the intent" - whether the actual reality of a 
specific Solr application does align with the expectation that "Segments are 
normally merged over time anyway". But, start with the presumption that 
merge policy does eliminate the need for optimize.

As a general proposition:

1. Try to avoid using optimize "if at all" possible. Let merge policy do its 
thing.
2. Try to take a server out offline while optimizing if an optimize is 
really absolutely needed.
3. Try to understand why #1 is not sufficient and resolve the cause(s), so 
that optimize is no longer needed.

-- Jack Krupansky

-----Original Message----- 
From: Yonik Seeley
Sent: Monday, May 27, 2013 9:46 AM
To: solr-user@lucene.apache.org
Subject: Re: Overlapping onDeckSearchers=2

On Mon, May 27, 2013 at 7:11 AM, Jack Krupansky <jack@basetechnology.com> 
wrote:
> The intent is that optimize is obsolete and should no longer be used

That's incorrect.

People need to understand the cost of optimize, and that it's use is 
optional.
It's up to the developer to figure out of the benefits of calling
optimize outweigh the costs in their particular situations.

The wiki currently says:
"""
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.
"""

-Yonik
http://lucidworks.com 


Mime
View raw message