Add sort optimization with after from Lucene #64292
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mayya-sharipova
added
the
:Search/Search
|
Pinging @elastic/es-search (:Search/Search) |
mayya-sharipova
added
>enhancement
v7.11.0
v8.0.0
WIP
and removed
Team:Search
Lucene 8.7 introduces numeric sort optimization directly in comparators. This means we don't need to have it in ES. This removes the sort optimization code in ES, and the only thing that is needed is setCanUsePoints on sortField. This also will introduce sort optimization with search_after, as Lucene directly suports sort optimization with search_after.
mayya-sharipova
force-pushed
the
sort-optim-after
branch
from
f796c4e to
8a4c342
Compare
mayya-sharipova
changed the title
|
Rally benchmarking results for geonames (number of docs: 11M, many segments): baseline: master branch; contender: this PR Overall very good results: sort:
sort with after:
|
|
http_logs results with bulk_indexing_clients:1 Multiple segments:
Single segment:
|
Sort reader leaves in ContextIndexSearcher for numeric sort optimizaiton.
This reverts commit ca72e0c.
|
Here are the benchmarks for sorted-reader: baseline: master branch; contender: sorted-reader branch geonames:Overall very good results: sort:
sort with after:
http_logs:Multiple segments:
Single segment:
@jimczi It looks like your approach with a sorted MultiReader worked well, and we have speedups both for desc and asc sort. We can go ahead with this sorted_reader then. |
|
We took another approach for this, hence closing. |
|
@jimczi Do you have any other issue/PR to follow improvements related to this topic ? |
|
@jimczi I am reviving this PR with merging the latest master here, can you please continue the review when you have time. Here are the latest benchmarks for Here are the results of the 99th percentile service time. Surprisingly, this time I also see 17% regression on desc_sort_with_after_timestamp. I will investigate what could be a reason for it. +| Task | Baseline | Contender | Diff | Unit |
+| desc_sort_timestamp | 79.6757 | 66.9085 | -12.7672 | ms |
+| asc_sort_timestamp | 4.51976 | 3.58597 | -0.93378 | ms |
-| desc_sort_with_after_timestamp | 748.949 | 878.057 | 129.108 | ms |
+| asc_sort_with_after_timestamp | 754.128 | 459.698 | -294.43 | ms |
+| desc-sort-timestamp-after-force-merge-1-seg | 1485.43 | 985.803 | -499.632 | ms |
+| asc-sort-timestamp-after-force-merge-1-seg | 4.17577 | 3.23124 | -0.94453 | ms |
+| desc-sort-with-after-timestamp-after-force-merge-1-seg | 866.316 | 519.599 | -346.717 | ms |
+| asc-sort-with-after-timestamp-after-force-merge-1-seg | 790.108 | 604.906 | -185.202 | ms | |
mayya-sharipova
added a commit
to mayya-sharipova/elasticsearch
that referenced
this pull request
Sep 13, 2021
Lucene 8.7 introduces numeric sort optimization directly in comparators. This means we don't need to have it in ES. This removes the sort optimization code in ES, and the only thing that is needed is setCanUsePoints on sortField. This also will introduce sort optimization with search_after, as Lucene directly supports sort optimization with search_after. As previously, we enable sort optimization only when there is Long sort on Long or Date fields. There could be a regression on desc sort, for example on @timestamp desc field. In this case, we suggest to convert these indices to data stream indices, as datatastream indices have their desc sort on @timestamp field optimized.
mayya-sharipova
added a commit
that referenced
this pull request
Sep 13, 2021
Lucene 8.7 introduces numeric sort optimization directly in comparators. This means we don't need to have it in ES. This removes the sort optimization code in ES, and the only thing that is needed is setCanUsePoints on sortField. This also will introduce sort optimization with search_after, as Lucene directly supports sort optimization with search_after. As previously, we enable sort optimization only when there is Long sort on Long or Date fields. There could be a regression on desc sort, for example on @timestamp desc field. In this case, we suggest to convert these indices to data stream indices, as datatastream indices have their desc sort on @timestamp field optimized Backport for #64292
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Lucene 8.7 introduces numeric sort optimization directly in comparators.
This means we don't need to have it in ES.
This removes the sort optimization code in ES, and
the only thing that is needed is setCanUsePoints on sortField.
This also will introduce sort optimization with search_after,
as Lucene directly supports sort optimization with search_after.
As previously, we enable sort optimization only when there is
Long sort on Long or Date fields.
There could be a regression on desc sort, for example on
@timestamp desc field. In this case, we suggest to
convert these indices to data stream indices, as
datatastream indices have their desc sort on
@timestamp field optimized