Le 18 nov. 2009 à 20:17, Jon Schneider a écrit :

> While I digest Nicolas' novel :) (thanks for the additional insight on
> Lucene by the way), I will suggest one other idea.
> 
> We could allow for the option of a Solr instance collocated with the
> repository on one machine to serve up the index stored on the repository.
> IvyDE could be configured by the user to either read the index directly
> from the remote filesystem or send its requests via HTTP to a Solr server.
> The Solr server would not be responsible for maintaining the index in the
> same way that Archiva/Nexus/Artifactory do, but would simply be a querying
> tool.  In the case where Solr is serving the index, the index would still be
> maintained through some combination of the index ant task and the publish
> proxy.
> 
> This way we don't get into the complexity of pushing out index updates to
> clients.
> 
> The rsync strategy is a very intriguing idea though, especially in light of
> how Lucene segments its index in multiple files.  What happens when optimize
> is called on the index and the segments are combined into one file?

yep, it merges them all in one.

>  In this
> case, any search slaves would essentially have to download the whole index
> right?

exactly. The publisher of the indexes shouldn't do any optimization on the 
indexes. The receiver shouldn't do either to have the same files as the 
publisher. On the client side it may be interesting to optimize the index for 
performance: it will just maintain two indexes, one for synchronizing with the 
publisher, and a clone which is then optimized.

>  How much segmentation is considered too much segmentation before we
> optimize the index to cater to search speed over index publishing speed?

It is done automatically by Lucene itself with the merge policy:
http://lucene.apache.org/java/2_9_1/api/core/org/apache/lucene/index/MergePolicy.html

Nicolas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to