On Thu, 2014-02-06 at 10:22 +0100, Luis Cappa Banda wrote: > I knew some performance tips to improve search and I configured a very > low merge factor (<mergeFactor>2</mergeFactor>) to boost search > operations instead of indexation ones.
That would give you a small search speed increase and a huge penalty on indexing speed (as it will perform large merges all the time) and replication speed (as all file data will be updated frequently instead of just a subset of them). Unless you are absolutely sure that you need the small search speed increase, you should set this to a higher number. > I haven't got a deep knowledge of internal Lucene behavior in this > case, but I thought that somehow an optimization operation may rebuild > the index checking and fixing corrupted segments, To my knowledge, there are not attempts to repair corrupted segments during merge. I hope you speak of corruption as a precaution and not because it is something that happens to your setup. If you have corrupted indexes at any time, you should investigate how that happens, instead of trying to repair them. > One last question: do you think that this kind of scenario where I > continuously index and replicate data will corrupt the index? Lucene is used in a lot of places with massive updates. Aside for JVM-related bugs, it has proven to be very stable under these conditions. So not, the indexing will not corrupt anything. - Toke Eskildsen, State and University Library, Denmark
