Blobdb for static data

[fab-10]

PR description

This PR is built on top of #5471, so check it first.
To only show the diff against #5471

This PR introduces optimizations for RocksDB column families that contain static data, i.e. key value entries that are never changed, but only added, like an append log storage, the best example is the blockchain storage, that benefit if BlobDB is used for them, since the write amplification is highly reduced, with the result of faster initial sync and less wear out of SSD.

Enabling BlobDB for a column family does not make the db incompatible with a previous version of Besu, however before downgrading Besu you need to run the subcommand storage revert-variables to revert changes done in PR #5471

Preliminary test shows that checkpoint sync is faster with BlobDB enabled, more tests are ongoing, and will share the results later.

Fixed Issue(s)

fixes #4607

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I have considered running ./gradlew acceptanceTestNonMainnet locally if my PR affects non-mainnet modules.
• I thought about the changelog and included a changelog update if required.
• If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[jflo]

So far so good. Have you considered re-using the DataStoreModule from evmtool? We might be able to pull that up into Besu, and use that to provide VariablesStorage to anything that needs it, via BesuComponent.

[fab-10]

So far so good. Have you considered re-using the DataStoreModule from evmtool? We might be able to pull that up into Besu, and use that to provide VariablesStorage to anything that needs it, via BesuComponent.

Not analyzed that part, and given my little knowledge of that part, I will check with you what is necessary for that.

[garyschulte]

the diff from 5471 looks good to me. I am not sure why the failing unit and acceptance tests.

[fab-10]

the diff from 5471 looks good to me. I am not sure why the failing unit and acceptance tests.

unnecessary stubbing, fixed

[ahamlat]

Adding some metrics on this PR

Sync and block block processing timings

Sync Time

We can also see the difference in block import time, especially from some block number where the node running this PR has a much better block import time.

Block processing (post sync)
Block processing time is very close between both nodes.

We can notice also the same performance regarding Forkchoice update (FCU)

System metrics

Block import time is better because with BlobDB there is less compaction and thus less write amplification.

Without PR #5475

We can notice below a huge IO activity with a lot of IO waits, 28 ms on average on writes.

With PR #5475

With this PR, there is less IO activity with less IO waits, 9 ms on average on writes.

[garyschulte]

🚢