Yes, I see thousands of segment merges while bulk indexing. Time-based sharding is not making indexing or queries automatically faster - in fact, the less segments, the less CPU/IO is required and the faster the search and merging, as long as segments files fit into memory and CPU cores are able to run threads on segments concurrently.
Sharding is an easy method to achieve scaling out, but scaling out does not necessarily mean all things go faster. Many servers with many CPU cores can easily handle small segments, but the higher the number of segments, and the higher the segment tiers size,, the slower is search, and also indexing gets slower if segment merging is not able to keep up with bulk indexing. Jörg On Sun, Apr 27, 2014 at 12:53 AM, Otis Gospodnetic < [email protected]> wrote: > Yeah, I think the long-running indexing is where you start seeing segment > merges is action. Time-based sharding is not good only for making queries > faster. It's essential for keeping indexing fast as well. > > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF%2BmMGx22G%2B2r%3DD23%3Ds7khpRH6a4-VsnMjhFAnbG_maaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
