If you're going to do frequent commits or refreshes it means you care less
about performance and more about durability and low-latency searching.
In that case, it's best to index with only 1 thread: then every
commit/refresh will only write one segment and you minimize the merge
pressure.
Adrien
IIUC, segments are actually written the first time when the
ramBufferSizeMB is exceeded. If you can afford it you might increase
that number. NOTE: I'm going from memory here so you should check
That doesn't really address merging segments with deleted docs though.
I do wonder what happens if
Optimizing for frequent changes sounds like a caching strategy, maybe “LRU
merging”. Perhaps prefer merging segments that have not changed in a while?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Aug 1, 2017, at 5:50 AM, Tommaso Teofili wrote:
>
Il giorno mar 1 ago 2017 alle ore 14:04 Adrien Grand ha
scritto:
> The trade-off does not sound simple to me. This approach could lead to
> having more segments overall, making search requests and updates
> potentially slower and more I/O-intensive since they have to iterate over
> more segments?
The trade-off does not sound simple to me. This approach could lead to
having more segments overall, making search requests and updates
potentially slower and more I/O-intensive since they have to iterate over
more segments? I'm not saying this is a bad idea, but it could have
unexpected side-effec
Hi all,
lately I am looking a bit closer at merge policies, of course particularly
at the tiered one, and I was wondering if we can mitigate the amount of
possibly avoidable merges in high commit rates scenarios, especially when a
high percentage of the commits happens on same docs.
I've observed