I think you can get far by just optimizing how often you do commits (as seldom as possible), as well as MergeFactor, to get a good balance between indexing and query efficiency. It may be that you're looking for fewer segments on average - not always one fully optimized segment.
If you still feel you need more optimizing, the far easiest is to implement the logic in your client which sends an explicit optimize whenever your logic dictates. One way to hide this inside Solr config could be to change your MergePolicy in solrconfig.xml or implementing your own (http://lucene.apache.org/java/3_0_0/api/all/org/apache/lucene/index/MergePolicy.html) if you cannot find any suitable ones. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 16. feb. 2011, at 14.12, Renaud Delbru wrote: > Hi, > > We would like to trigger an optimise every x hours. From what I can see, > there is nothing in Solr (3.1-SNAPSHOT) that enables to do such a thing. > We have a master-slave configuration. The masters are tuned for fast indexing > (large merge factor). However, for the moment, the master index is replicated > as it is to the slaves, and therefore it does not provide very fast query > time. > Our idea was > - to configure the replication so that it only happens after an optimise, and > - schedule a partial optimise in order to reduce the number of segments every > x hours for faster querying. > We do not want to rely on cron job for executing the partial optimise every x > hours, but we would prefer to configure this directly within the solr config. > > Our first idea was to create a SolrEventListener, that will be postCommit > triggered, and that will be in charge of executing an optimise at regular > time interval. Is this a good approach ? Or is there other solutions to > achieve this ? > > Thanks, > -- > Renaud Delbru
