8000 Understand and simplify CometBFT database backend · Issue #48 · cometbft/cometbft · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Understand and simplify CometBFT database backend #48

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

Closed
3 of 5 tasks
Tracked by #44
lasarojc opened this issue Dec 23, 2022 · 1 comment
Closed
3 of 5 tasks
Tracked by #44

Understand and simplify CometBFT database backend #48

lasarojc opened this issue Dec 23, 2022 · 1 comment
Labels
breaking A breaking change P:storage-optimization Priority: Give operators greater control over storage and storage optimization storage tracking A complex issue broken down into sub-problems

Comments

@lasarojc
Copy link
Contributor
lasarojc commented Dec 23, 2022

Supersedes tendermint/tendermint#6032, breaking that issue down into more concrete, clearly separated deliverables/sub-tasks.

It's ultimately expensive and painful for the team to have to cater to many different use cases that require different underlying storage engines, and we would rather converge on a single database that meets our core requirements well. We do, however, want to simultaneously provide ways for integrators to access and transform core data into whatever storage system suits their use case.

Problems

  1. Through cometbft-db, CometBFT currently supports multiple database backends. As such:
    1. CometBFT does not make extensive use of database-specific optimizations.
    2. Storage behavior is not consistent across different databases, potentially resulting in more troubleshooting and bug fixing work for the team (e.g. genesis file may go over the recommended maximum value size tendermint/tendermint#8416, Remove genesis persistence in state db #1017 ).
  2. While we could just decide to only support GoLevelDB (as per use only goleveldb tendermint/tendermint#9741), one of the most commonly used underlying databases for CometBFT, it seems to struggle with pruning (see Add in-process compaction support to LevelDB tendermint/tendermint#9743, Investigate why Tendermint disk storage keeps growing over time informalsystems/interchain#1). It's also not clear, given our typical storage workloads for the most common use cases, whether the underlying data structure that LevelDB provides is even suitable for CometBFT. Current problems experienced by operators seem to suggest otherwise.
  3. We currently do not have a very clear set of requirements for an underlying database for CometBFT.

RFC-001 provides some more detail around the problem space.

Work Breakdown

In order to achieve our overall goal of storage simplification, we need to complete the following work.

Original issue: tendermint/tendermint#9749

@lasarojc lasarojc added storage breaking A breaking change tracking A complex issue broken down into sub-problems labels Dec 23, 2022
@lasarojc lasarojc mentioned this issue Dec 23, 2022
21 tasks
@thanethomson thanethomson moved this to Todo in CometBFT 2023 Jan 21, 2023
@lasarojc lasarojc changed the title Simplify Tendermint database engine support Simplify CometBFT database engine support Mar 27, 2023
@jmalicevic jmalicevic moved this from Todo to In Progress in CometBFT 2023 Mar 29, 2023
@thanethomson thanethomson added the P:storage-optimization Priority: Give operators greater control over storage and storage optimization label Jun 20, 2023
@jmalicevic jmalicevic changed the title Simplify CometBFT database engine support Understand and simplify CometBFT database backend Jun 27, 2023
@jmalicevic jmalicevic modified the milestone: 2023-Q3 Jun 27, 2023
@faddat
Copy link
Contributor
faddat commented Jan 9, 2024

cometbft/cometbft-db#112 (comment)

So that's my reasoning. I'm happy to try to make goleveldb faster, too. You will need a beefy machine for the benchmarks.

Here is a branch with benchmarks:

@melekes melekes closed this as completed Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking A breaking change P:storage-optimization Priority: Give operators greater control over storage and storage optimization storage tracking A complex issue broken down into sub-problems
Projects
No open projects
Status: In Progress
Development

No branches or pull requests

32B0
5 participants
0