Storage optimizations: Q1 2024 tracking issue #2058
Assignees
Labels
P:storage-optimization
Priority: Give operators greater control over storage and storage optimization
tracking
A complex issue broken down into sub-problems
Milestone
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Q1 storage optimizations plan
This issue serves as a meta-tracking issue, outlining a subset of items from #44 that will be done and covered in Q1 2024.
In Q4 2023, we have implemented 2 database key representations that are different from what CometBFT is currently using, along with in-process compaction of the database. Compaction can be explicitly triggered to force the backing database to reduce the storage footprint.
In Q1 we need to evaluate whether the new layout introduces overheads or it reduces the database access time and has any impact on the efficiency of pruning and compaction.
At the end of Q1 we expect the following PRs to be merged:
Documentation updates:
Docs: Add information about changes to key layout in UPGRADING.md #2406
A report on the findings will be included as part of Benchmark current storage improvements #1044.
Benchmark current storage improvements #1044
We are running experiments using metrics in feat(storage/metrics): Metrics to measure storage #1974 and DB specific metrics from a branch in the cometbft-db repo.
The DB metrics will not be merged as is because they introduce some overhead and should not be used in production.
The text was updated successfully, but these errors were encountered: