Skip to content

Optimize grouping for segment concurrent search by ensuring that documents within each group are as equal as possible#18451

Merged
jainankitk merged 5 commits intoopensearch-project:mainfrom
kkewwei:optimize_group
Jul 31, 2025
Merged

Optimize grouping for segment concurrent search by ensuring that documents within each group are as equal as possible#18451
jainankitk merged 5 commits intoopensearch-project:mainfrom
kkewwei:optimize_group

Conversation

@kkewwei
Copy link
Copy Markdown
Contributor

@kkewwei kkewwei commented Jun 5, 2025

Description

Druing segment concurrent search, we adopt a round-robin approach to distribute slices. However, this may lead to a significant imbalance in the number of documents across groups. For instance, consider a scenario with segment document counts as follows: 10, 8, 7, 6, 5, 4 and a slice size of 4.

Current grouping results (with a max-min document difference of 9):
group0: 10, 5
group1: 8, 4
group2: 7
group3: 6

Optimized grouping results (reducing the max-min difference to 3):
group0: 10
group1: 8
group2: 7,4
group3: 6,5

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Jun 5, 2025

❌ Gradle check result for 6967a61: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@kkewwei kkewwei marked this pull request as draft June 6, 2025 00:45
…ments within each group are as equal as possible

Signed-off-by: kkewwei <kkewwei@163.com>
Signed-off-by: kkewwei <kewei.11@bytedance.com>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Jun 6, 2025

❌ Gradle check result for 12b64ba: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@kkewwei kkewwei closed this Jun 6, 2025
@kkewwei kkewwei reopened this Jun 6, 2025
@kkewwei kkewwei marked this pull request as ready for review June 6, 2025 02:54
@github-actions
Copy link
Copy Markdown
Contributor

❌ Gradle check result for 17a02f6: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@github-actions
Copy link
Copy Markdown
Contributor

❕ Gradle check result for 17a02f6: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

@github-actions
Copy link
Copy Markdown
Contributor

✅ Gradle check result for c36c8ca: SUCCESS

@kkewwei
Copy link
Copy Markdown
Contributor Author

kkewwei commented Jul 29, 2025

@asimmahmood1 @expani It's ok now, please help merge in your spare time.

@expani
Copy link
Copy Markdown
Contributor

expani commented Jul 30, 2025

@jainankitk please review this as we need another maintainer to merge it.

Copy link
Copy Markdown
Contributor

@jainankitk jainankitk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kkewwei for making this change. I was initially wondering if greedy approach gives the most optimal solution for this problem, but after running few cases/permutations in my head, I am indeed convinced. Should also have a simple proof using contradiction. Having the leaves reverse sorted is important!!

@jainankitk
Copy link
Copy Markdown
Contributor

While this holds true for lots of workloads, there can be cases where it can be sub-optimal which IMO is difficult to prove via benchmarks as it can keep getting skewed with data distribution for one case to another.

That's a fair point, but even the existing implementation doesn't necessarily account for this.

A more optimal way could be work stealing via a shared queue amongst all Search Threads but it would require changes in Lucene's IndexSearcher ( more discussion on this at #18338 (comment) ) or in ContextIndexSearcher at OpenSearch.

This is probably the right approach IMO, to assign the work lazily instead of eagerly. That should account for all the scenarios including the ones where few segments might have many more matches compared to other segments. The objective is to balance the amount of actual work done across different threads and not the number of indexed documents processed by each thread

@jainankitk jainankitk merged commit b53b446 into opensearch-project:main Jul 31, 2025
31 checks passed
sunqijun1 pushed a commit to sunqijun1/OpenSearch that referenced this pull request Aug 4, 2025
… document distribution (opensearch-project#18451)

Signed-off-by: kkewwei <kkewwei@163.com>
Signed-off-by: kkewwei <kewei.11@bytedance.com>
Signed-off-by: sunqijun.jun <sunqijun.jun@bytedance.com>
tandonks pushed a commit to tandonks/OpenSearch that referenced this pull request Aug 5, 2025
… document distribution (opensearch-project#18451)

Signed-off-by: kkewwei <kkewwei@163.com>
Signed-off-by: kkewwei <kewei.11@bytedance.com>
@asimmahmood1 asimmahmood1 added v3.2.0 Performance This is for any performance related enhancements or bugs Search:Performance labels Aug 19, 2025
@github-actions
Copy link
Copy Markdown
Contributor

Hello!
We have added a performance benchmark workflow that runs by adding a comment on the PR.
Please refer https://github.com/opensearch-project/OpenSearch/blob/main/PERFORMANCE_BENCHMARKS.md on how to run benchmarks on pull requests.

1 similar comment
@github-actions
Copy link
Copy Markdown
Contributor

Hello!
We have added a performance benchmark workflow that runs by adding a comment on the PR.
Please refer https://github.com/opensearch-project/OpenSearch/blob/main/PERFORMANCE_BENCHMARKS.md on how to run benchmarks on pull requests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Performance This is for any performance related enhancements or bugs Search:Performance v3.2.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants