Uh oh!
There was an error while loading. Please reload this page.
[fix](mow) reduce mow delete bitmap count: agg and remove delete bitmap of pre rowsets when cu compaction - #49383
Conversation
Thearas
commented
Mar 24, 2025
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
mymeiyi
commented
Mar 24, 2025
run buildall |
doris-robot
commented
Mar 24, 2025
TPC-H: Total hot run time: 34480 ms |
doris-robot
commented
Mar 24, 2025
TPC-DS: Total hot run time: 194000 ms |
doris-robot
commented
Mar 24, 2025
ClickBench: Total hot run time: 31.14 s |
hello-stephen
commented
Mar 24, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
2643fe4 to
2c5da11Comparemymeiyi
commented
Mar 28, 2025
run buildall |
doris-robot
commented
Mar 28, 2025
TeamCity cloud ut coverage result: |
doris-robot
commented
Mar 28, 2025
TPC-H: Total hot run time: 34206 ms |
doris-robot
commented
Mar 28, 2025
TPC-DS: Total hot run time: 192722 ms |
doris-robot
commented
Mar 28, 2025
ClickBench: Total hot run time: 31.79 s |
doris-robot
commented
Mar 28, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
6a68198 to
9a434ecComparemymeiyi
commented
Apr 3, 2025
run buildall |
doris-robot
commented
Apr 3, 2025
TeamCity cloud ut coverage result: |
doris-robot
commented
Apr 3, 2025
TPC-H: Total hot run time: 34384 ms |
doris-robot
commented
Apr 3, 2025
TPC-DS: Total hot run time: 186397 ms |
doris-robot
commented
Apr 3, 2025
ClickBench: Total hot run time: 31.18 s |
hello-stephen
commented
Apr 3, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
mymeiyi
commented
Apr 3, 2025
run buildall |
doris-robot
commented
Apr 3, 2025
TeamCity cloud ut coverage result: |
doris-robot
commented
Apr 3, 2025
TPC-H: Total hot run time: 34483 ms |
doris-robot
commented
Apr 3, 2025
TPC-DS: Total hot run time: 194753 ms |
doris-robot
commented
Apr 3, 2025
ClickBench: Total hot run time: 31.74 s |
doris-robot
commented
Apr 3, 2025
BE UT Coverage ReportIncrement line coverage Increment coverage report
|
zhannngchen
commented
May 26, 2025
run buildall |
PR approved by at least one committer and no changes requested. |
hello-stephen
commented
May 26, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
doris-robot
commented
May 26, 2025
TPC-H: Total hot run time: 33972 ms |
doris-robot
commented
May 26, 2025
TPC-DS: Total hot run time: 193320 ms |
doris-robot
commented
May 26, 2025
ClickBench: Total hot run time: 29.8 s |
dataroaring
commented
May 29, 2025
run buildall |
hello-stephen
commented
May 29, 2025
Cloud UT Coverage ReportIncrement line coverage Increment coverage report
|
doris-robot
commented
May 29, 2025
TPC-H: Total hot run time: 33570 ms |
doris-robot
commented
May 29, 2025
TPC-DS: Total hot run time: 186221 ms |
doris-robot
commented
May 29, 2025
ClickBench: Total hot run time: 29.34 s |
…ap of pre rowsets when cu compaction (apache#49383) ### What problem does this PR solve? This PR reduce delete bitmap count of mow tables #### Basic idea 1. when do cumulative compaction [start_rowset, end_rowset], which version is [start_version, end_version] 2. agg pre_rowsets'(version less than start_version) delete bitmap between [start_version, end_version] to end_version, 3. when all of the rowsets of [start_rowset, end_rowset] are deleted, delete pre rowsets' delete bitmap between [start_version, end_version). #### One example suppose the rowset and delete bitmap layout is: ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7: v8, v9 r8: v9 r9: ``` if do cumulative compaction for {r7, r8, r9} before this pr, the delete bitmap layout is (there is 7 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7-9: ``` after this pr (there is 3 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, new_v9 // new_v9 is agged by the previous v7, v8, v9 of r1-3 r4-6: new_v9 // new_v9 is agged by the previous v7, v8, v9 of r4-6 r7-9: ``` #### The implementation of local mode ##### delete bitmap in BE memory 1. agged when delete stale rowset path 2. removed when delete unused rowsets ##### delete bitmap in BE local storage `save_meta` to store delete bitmap after remove unused rowsets related delete bitmap #### The implementation of cloud mode ##### delete bitmap in BE memory 1. agged when delete stale rowset path 2. removed when delete unused rowsets ##### delete bitmap in Meta Service 1. agged when finish compaction 2. send `update_delete_bitmap` to ms to modify and remove pre rowsets delete bitmap ### Release note None
### What problem does this PR solve? now, the delete bitmap is removed when move stale rowsets to unused rowsets, but if some queries is still read the stale rowsets, the query result may get duplicated keys. this pr change the remove of delete bitmap when remove unused rowsets. this pr is based on #49383
…ap of pre rowsets when cu compaction (apache#49383) This PR reduce delete bitmap count of mow tables 1. when do cumulative compaction [start_rowset, end_rowset], which version is [start_version, end_version] 2. agg pre_rowsets'(version less than start_version) delete bitmap between [start_version, end_version] to end_version, 3. when all of the rowsets of [start_rowset, end_rowset] are deleted, delete pre rowsets' delete bitmap between [start_version, end_version). suppose the rowset and delete bitmap layout is: ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7: v8, v9 r8: v9 r9: ``` if do cumulative compaction for {r7, r8, r9} before this pr, the delete bitmap layout is (there is 7 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7-9: ``` after this pr (there is 3 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, new_v9 // new_v9 is agged by the previous v7, v8, v9 of r1-3 r4-6: new_v9 // new_v9 is agged by the previous v7, v8, v9 of r4-6 r7-9: ``` 1. agged when delete stale rowset path 2. removed when delete unused rowsets `save_meta` to store delete bitmap after remove unused rowsets related delete bitmap 1. agged when delete stale rowset path 2. removed when delete unused rowsets 1. agged when finish compaction 2. send `update_delete_bitmap` to ms to modify and remove pre rowsets delete bitmap None
…ap of pre rowsets when cu compaction (apache#49383) This PR reduce delete bitmap count of mow tables 1. when do cumulative compaction [start_rowset, end_rowset], which version is [start_version, end_version] 2. agg pre_rowsets'(version less than start_version) delete bitmap between [start_version, end_version] to end_version, 3. when all of the rowsets of [start_rowset, end_rowset] are deleted, delete pre rowsets' delete bitmap between [start_version, end_version). suppose the rowset and delete bitmap layout is: ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7: v8, v9 r8: v9 r9: ``` if do cumulative compaction for {r7, r8, r9} before this pr, the delete bitmap layout is (there is 7 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7-9: ``` after this pr (there is 3 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, new_v9 // new_v9 is agged by the previous v7, v8, v9 of r1-3 r4-6: new_v9 // new_v9 is agged by the previous v7, v8, v9 of r4-6 r7-9: ``` 1. agged when delete stale rowset path 2. removed when delete unused rowsets `save_meta` to store delete bitmap after remove unused rowsets related delete bitmap 1. agged when delete stale rowset path 2. removed when delete unused rowsets 1. agged when finish compaction 2. send `update_delete_bitmap` to ms to modify and remove pre rowsets delete bitmap None
…ap of pre rowsets when cu compaction (apache#49383) This PR reduce delete bitmap count of mow tables 1. when do cumulative compaction [start_rowset, end_rowset], which version is [start_version, end_version] 2. agg pre_rowsets'(version less than start_version) delete bitmap between [start_version, end_version] to end_version, 3. when all of the rowsets of [start_rowset, end_rowset] are deleted, delete pre rowsets' delete bitmap between [start_version, end_version). suppose the rowset and delete bitmap layout is: ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7: v8, v9 r8: v9 r9: ``` if do cumulative compaction for {r7, r8, r9} before this pr, the delete bitmap layout is (there is 7 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, v7, v8, v9 r4-6: v7, v8, v9 r7-9: ``` after this pr (there is 3 delete bitmap left): ``` [rowset_id]: [delete bitmap] r1-3: v6, new_v9 // new_v9 is agged by the previous v7, v8, v9 of r1-3 r4-6: new_v9 // new_v9 is agged by the previous v7, v8, v9 of r4-6 r7-9: ``` 1. agged when delete stale rowset path 2. removed when delete unused rowsets `save_meta` to store delete bitmap after remove unused rowsets related delete bitmap 1. agged when delete stale rowset path 2. removed when delete unused rowsets 1. agged when finish compaction 2. send `update_delete_bitmap` to ms to modify and remove pre rowsets delete bitmap None
### What problem does this PR solve? Issue Number: None Related PR: apache#49383 Problem Summary: The MOW version-count promotion protects against excessive delete bitmap metadata, but its default threshold of 1000 can promote tiny cumulative output rowsets and trigger frequent base compactions. Retain the local and cloud promotion logic as an operational fallback, while changing the default threshold to the maximum int64 value so version count alone does not promote rowsets by default. Operators can lower compaction_promotion_version_count if the fallback is needed. ### Release note MOW cumulative compaction no longer promotes output rowsets by version count under the default configuration. The existing configuration remains available as a fallback. ### Check List (For Author) - Test: Unit Test - ./run-be-ut.sh --run --filter=TestSizeBasedCumulativeCompactionPolicy.*:TestCloudSizeBasedCumulativeCompactionPolicy.* -j80 - build-support/check-format.sh - build-support/check-build-hygiene.sh - Behavior changed: Yes. Version-count promotion is disabled by default but remains configurable. - Does this need documentation: No
What problem does this PR solve?
This PR reduce delete bitmap count of mow tables
Basic idea
One example
suppose the rowset and delete bitmap layout is:
if do cumulative compaction for {r7, r8, r9}
before this pr, the delete bitmap layout is (there is 7 delete bitmap left):
after this pr (there is 3 delete bitmap left):
The implementation of local mode
delete bitmap in BE memory
delete bitmap in BE local storage
save_metato store delete bitmap after remove unused rowsets related delete bitmapThe implementation of cloud mode
delete bitmap in BE memory
delete bitmap in Meta Service
update_delete_bitmapto ms to modify and remove pre rowsets delete bitmapRelease note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)