Thanks to all for thinking about this question. Otis: could you say a
bit more about per segment readers. This is new to me.
I gather that there is a way to specify that the number of readers
should correspond (or automatically correspond) to the number of segments?
I suppose this gives each reader a set of smaller files to process and
there is some sort of result merge over readers to produce a final result?
So you gain through use of parallelism in a multi cpu environment?
Under what conditions can this perform as well as a single reader on an
optimized index?
Phil
Otis Gospodnetic wrote:
That's right. mergeFactor=1 is an even more extreme case. However, with the
new per-segment readers, having an optimized index is no longer the best index
state to go for in some cases.
Otis
--
Sematext is hiring -- http://sematext.com/about/jobs.html?mls
Lucene, Solr, Nutch, Katta, Hadoop, HBase, UIMA, NLP, NER, IR
----- Original Message ----
From: Lance Norskog <goks...@gmail.com>
To: solr-user@lucene.apache.org
Sent: Monday, September 28, 2009 2:42:29 PM
Subject: Re: Writing optimized index to different storage?
The optimize operation happens in place.
I've been told that if you set "mergeFactor=2" when indexing, it will
be slower but you will always have a "mostly optimized" index.
On Mon, Sep 28, 2009 at 10:22 AM, Jason Rutherglen
wrote:
Hmm... Interesting question, not that I know of. The only way
one could do this would be to intercept the newly optimized
files via a FileSwitchDirectory like implementation that knows
which new files are optimized and should "underneath" go to a
different physical path.
On Mon, Sep 28, 2009 at 7:57 AM, Phillip Farber wrote:
Is it possible to tell Solr or Lucene, when optimizing, to write the files
that constitute the optimized index to somewhere other than
SOLR_HOME/data/index or is there something about the optimize that requires
the final segment to be created in SOLR_HOME/data/index?
Thanks,
Phil
--
Lance Norskog
goks...@gmail.com
