Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(storage): cache recent versions and unify batch query and time travel #18477

Merged
merged 8 commits into from
Sep 11, 2024

Conversation

wenym1
Copy link
Contributor

@wenym1 wenym1 commented Sep 10, 2024

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Motivation as described in #18214

Cache the most recent 60 hummock versions which have bumped the committed version of any table.

Unify the logic of batch query and time travel query. The logic of getting a hummock version for query will be

  • if the table does not exist in the latest version, it is dropped, and get a time travel version
  • when epoch > committed_epoch, merge staging data with latest version
  • else when get some version from the recent version cache, read from this version
  • else, get a time travel version, either from cache or via meta rpc

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Copy link
Contributor

@zwang28 zwang28 left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -335,17 +329,14 @@ impl HummockStorage {
.inspect_err(|e| tracing::error!("{}", e.to_report_string()))
.map_err(|e| HummockError::meta_error(e.to_report_string()))?;
let version = HummockVersion::from_rpc_protobuf(&pb_version);
validate_safe_epoch(&version, table_id, epoch)?;
let (tx, _rx) = unbounded_channel();
Ok(PinnedVersion::new(version, tx))
};
let version = self
.simple_time_travel_version_cache
Copy link
Contributor

Choose a reason for hiding this comment

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

May improve the cache implementation in the future.

@zwang28
Copy link
Contributor

zwang28 commented Sep 11, 2024

Notet that the time_travel_retention_ms defined src/common/src/system_param/mod.rs is 0 by default, which means time travel is not enabled.
I recommend to change it to 600000 (10 minutes) by default.

@wenym1
Copy link
Contributor Author

wenym1 commented Sep 11, 2024

Notet that the time_travel_retention_ms defined src/common/src/system_param/mod.rs is 0 by default, which means time travel is not enabled. I recommend to change it to 600000 (10 minutes) by default.

Tried, but in CI we still use the etcd meta store backend, and the non-zero default will fail to start the meta node. Changing the default value may make it incompatible for system upgrading from older version. I think we can still disable it by default, and change to enable it by default after we deprecate the etcd.

@wenym1 wenym1 enabled auto-merge September 11, 2024 12:21
self.get_safe_version_from_recent(table_id, epoch)
}
} else {
None
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does it mean that for dropped table we always go through time travel even if it exists in one of the recent version?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. It is unexpected to query a dropped table, and therefore this is rarely hit.

The reason for the current logic is to ensure that when querying the list of recent versions, the committed epoch of the table id is sorted so that we can easily use binary search. When the table id does not exist in a version, the table is either not created yet or dropped. When comparing a version with a specified query epoch, if the table is not created, the version is less than the query epoch, but if the table has been dropped, the version is greater than the query epoch, which means we cannot know the order between a query epoch and a version without the table_id. Therefore, if we can ensure that when query the list of recent versions the table must exist in the latest version, the list of recent versions is sorted.

@wenym1 wenym1 added this pull request to the merge queue Sep 11, 2024
@graphite-app graphite-app bot requested a review from a team September 11, 2024 12:54
@hzxa21
Copy link
Collaborator

hzxa21 commented Sep 11, 2024

else when epoch >= safe_epoch, read from latest version

Is the correct? Based on the PR, I think we will read from recent version or time travel version if epoch >= safe_epoch and epoch < mce

Merged via the queue into main with commit c882bda Sep 11, 2024
31 of 32 checks passed
@wenym1 wenym1 deleted the yiming/batch-query-time-travel branch September 11, 2024 13:25
@wenym1
Copy link
Contributor Author

wenym1 commented Sep 12, 2024

else when epoch >= safe_epoch, read from latest version

Is the correct? Based on the PR, I think we will read from recent version or time travel version if epoch >= safe_epoch and epoch < mce

The PR description was stale. I just updated it to not using the safe epoch. If epoch < mce, it will check the recent version.

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

Successfully merging this pull request may close these issues.

3 participants