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 fe
hm okay, reasonable :)
never used it, but maybe a pointer into the right direction?
http://wiki.apache.org/solr/DataImportHandler#Scheduling
On Wed, Feb 16, 2011 at 2:27 PM, Renaud Delbru wrote:
> Mainly technical administration effort.
>
> We are trying to have a solr packaging that
> - minimis
Mainly technical administration effort.
We are trying to have a solr packaging that
- minimises the effort to deploy the system on a machine.
- reduces errors when deploying
- centralised the logic of the Solr system
Ideally, we would like to have a central place (e.g., solrconfig) where
the lo
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
Renaud,
just because i'm interested in .. what are your concerns about using
cron for that?
Stefan
On Wed, Feb 16, 2011 at 2:12 PM, 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 d
