[opt](point query) Optimize backend path collection for point queries - #67151
Open
zyp-V wants to merge 1 commit into
Open
[opt](point query) Optimize backend path collection for point queries#67151zyp-V wants to merge 1 commit into
zyp-V wants to merge 1 commit into
Conversation
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Point-query planning built alive disk path sets for every backend even though tablet pruning leaves only a small set of replica backends. This made planning work grow with cluster size. Build the full map for regular scans and collect paths only for the selected tablet replica backends for point queries. Use the current backend snapshot API so the backport remains compatible with cloud and remote OLAP tables.
Backport of a209ce4b876c38aea0ea7d1f6c84e6e7b14c5a39.
### Release note
Reduce point-query planning overhead in clusters with many backends.
### Check List (For Author)
- Test: Unit Test
- ./run-fe-ut.sh --run org.apache.doris.planner.OlapScanNodeTest#testPointQueryBackendAlivePathsOnlyUseSelectedTabletBackends
- Behavior changed: No. Only point-query planning work is reduced.
- Does this need documentation: No
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
morrySnow
changed the title
Contributor
Author
|
run buildall |
Contributor
|
/review |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Automated review result: request changes.
I found two actionable issues in the new point-query-only collection path:
- The helper and
Tablet.getQueryableReplicas()can observe different replica snapshots after planning locks are released, allowing a newly published distinct-backend replica to bypass the dead-path tier. - Cloud replicas have no disk path hash, but the helper still performs an additional compute-group/backend placement resolution whose result cannot affect cloud queryability.
Critical checkpoint conclusions:
- Goal and proof: The patch does reduce stable local/remote point-query collection from all cluster backends to selected replica backends, and the regular-scan path remains unchanged. The new unit test correctly proves helper-level narrowing and alive/offline disk-set construction, but it does not cover the accepted concurrency interval or cloud call count.
- Scope and clarity: The source change is focused, but the two issues above need correction before the optimization is safe and complete across supported modes.
- Concurrency and lifecycle: New maps/sets are method-local and introduce no ownership, lock-order, or release problem. The material concurrency issue is the unlocked point-query reevaluation using two independently mutable
LocalTabletsnapshots. - Correctness and error handling: Visible-version checks, replica state/version checks, backend availability, resource tags, and downstream error propagation are otherwise preserved. Stable local/remote identity and missing-backend behavior match the previous path; cloud dynamic identity does not change disk-path correctness because
CloudReplica.pathHashis always-1. - Compatibility and parallel paths: Non-point scans retain the full backend path map. Remote OLAP uses its catalog-scoped backend snapshot. No FE/BE protocol, storage-format, rolling-upgrade, configuration, persistence/EditLog, transaction, data-write, or master-failover change is involved.
- Performance: The main asymptotic improvement is valid for local/remote point queries. The extra cloud resolution is nevertheless provably unused hot-path work; this review does not claim the whole PR is net slower than its baseline.
- Tests and observability: Existing logs/retries remain available, but retry only mitigates the newly admitted dead-path candidate. Add a latch-based snapshot-publication test and a cloud resolution call-count test. No local build or test was run because the review runner instructions prohibit builds.
- User focus: No additional focus point was supplied; the complete PR was reviewed.
Review convergence completed in two rounds. The second full review and both focused rechecks returned NO_NEW_VALUABLE_FINDINGS; no other unresolved issue remains.
| Map<Long, Backend> backends, List<Tablet> tablets) { | ||
| Map<Long, Set<Long>> backendAlivePathHashes = Maps.newHashMap(); | ||
| for (Tablet tablet : tablets) { | ||
| for (Replica replica : tablet.getReplicas()) { |
Contributor
There was a problem hiding this comment.
[P2] Keep path filtering on the same replica snapshot
Point queries call lazyEvaluateRangeLocations() after the planning table lock has been released. This helper snapshots tablet.getReplicas() here, but Tablet.getQueryableReplicas() snapshots it again later. If a replica on a distinct backend B is added and receives its reported offline path between those reads, B is absent from this narrowed map; the later lookup gets null and treats B as a normal candidate. The previous full-backend map would have demoted B to deadPathReplica, so shuffle or fixed-replica selection can now put it ahead of a healthy replica (retry only mitigates that). Please carry one replica snapshot through both path collection and queryability filtering, and cover the two-stage publication interval with a latch-based test.
| Map<Long, Set<Long>> backendAlivePathHashes = Maps.newHashMap(); | ||
| for (Tablet tablet : tablets) { | ||
| for (Replica replica : tablet.getReplicas()) { | ||
| long backendId = replica.getBackendIdWithoutException(); |
Contributor
There was a problem hiding this comment.
[P2] Skip backend resolution for pathless cloud replicas
For a CloudTablet, this call dispatches through CloudReplica.getBackendId() and getCurrentClusterId(), including compute-group privilege/status/auto-start checks and potentially colocate or multi-replica backend scans. But CloudReplica always has pathHash == -1, so Tablet.getQueryableReplicas() never consults the alive-path set for it; the result built here is unused, and the downstream path resolves the backend again. This adds pure work to the latency-sensitive cloud point-query path. Please skip CloudReplica/CloudTablet in this disk-path helper, or resolve the cloud placement once and reuse it through scan-location construction; a cloud-mode call-count test would pin this behavior. (A generic pathHash == -1 skip would be unsafe for local replicas whose reported path is populated later.)
Contributor
TPC-H: Total hot run time: 16628 ms |
Contributor
TPC-DS: Total hot run time: 81550 ms |
Contributor
ClickBench: Total hot run time: 14.43 s |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: Point-query planning built alive disk path sets for every backend even though tablet pruning leaves only a small set of replica backends. This made planning work grow with cluster size. Build the full map for regular scans and collect paths only for the selected tablet replica backends for point queries. Use the current backend snapshot API so the backport remains compatible with cloud and remote OLAP tables.
Release note
Reduce point-query planning overhead in clusters with many backends.
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)