Speed Up Your Search: Concurrency and Merge Policies to the Rescue
summary
OpenSearch 2.1 introduces merge on refresh and a merge on flush policy that cut segment counts about 3x in benchmarks, improve search percentiles slightly, but double merge CPU/IO time; they trade index-time work for faster reads. A sandbox concurrent segment traversal plugin injects a thread pool to search segments in parallel, improving phrase and scroll queries but not uniformly — mixed-size indexes still suffer because a single large segment is not searched in parallel, aggregations fall back to sequential, and a single shared thread pool can cause contention; plugin isn’t yet distributed but is easy to build.
AI-written summary · about
chapters (5)
- 0:00Introduction
- 2:21OpenSearch storage basics
- 5:23Optimizing with merges
- 8:54Concurrent segment search
- 14:44Limitations and future work
related talks
31mMaximize Resource Efficiency with Separated Index and Search Workloads
30mCaching for Speed: Practical Performance Optimization in OpenSearch & Lucene
31mSharding 2.0: Unlocking Infinite Search Scalability in OpenSearch
30mBoosting OpenSearch Performance: Lucene Bulk Collection and gRPC Search in Action
16mSo many results... Give them to me!
40mLeveraging Lucene Skip Indexes for Faster Aggregations in OpenSearch
24mReimagining Search : Scaling OpenSearch Across an Enterprise - Platform C...
48mUnlocking Next-gen Semantic Search With OpenSearch 3.x