-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
core: separated databases for block data #2227
Conversation
a8efd8e
to
3c82f4b
Compare
node/node.go
Outdated
|
||
if config.SeparateDB { | ||
log.Info("SeparateDB is enabled, open block database, %s", config.DatabaseBlock) | ||
blockStore, err = n.OpenBlockDatabase(name, config.DatabaseHandles-chainDataHandles, config.DatabaseBlock, namespace, readonly) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
config.DatabaseHandles-chainDataHandles euqals zero , it it no meaning.
You can consider allocating 1/10 of the handlers to the block store
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a new Resource allocation rules:
- Allocate a fixed percentage of memory for chainDb based on chainDbMemoryPercentage & chainDbHandlesPercentage.
- Allocate a fixed size for blockDb based on blockDbCacheSize & blockDbHandlesSize.
- Allocate the remaining resources to stateDb.
node/node.go
Outdated
@@ -73,10 +74,13 @@ const ( | |||
initializingState = iota | |||
runningState | |||
closedState | |||
blockDbCacheSize = 256 | |||
blockDbHandlesSize = 2000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if handler/10 < 2000 {
blockDbHandlesSize = 1000
}else {
blockDbHandlesSize = 2000
}
Adjust this variable
afc3eac
to
89b7d3a
Compare
3e6149f
to
7e3e660
Compare
8ce0dcc
to
5ecce29
Compare
5640825
to
288c534
Compare
* core: use finalized block as the chain freeze indicator * core/rawdb: use max(finality, head-90k) as chain freezing threshold * core/rawdb: fix tests * core/rawdb: fix lint * core/rawdb: address comments from peter * core/rawdb: fix typo
288c534
to
fb15b37
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
O
Description
This pull request uses the finalized block tag as the indicator for chain freezing and introduces the separation of block data into a dedicated blockdb. The principle support of PR: BEP-365: Support multi-database based on data pattern
uses the finalized block tag as the indicator for chain freezing
Originally, the latest 90K blocks will be retained in the key-value store by default, which is regarded as "non-finalized" in the context of Proof-of-work. However, in Proof-of-Stake, we do have the concrete finalized block tag from the consensus client. Therefore, it makes more sense to directly rely on the Finalized for chain freezing.
By deploying it on a full node, we can see there are only 23 blocks left in the key-value store.
![image](https://private-user-images.githubusercontent.com/11239387/300371161-48a2c07f-2c38-49df-bccc-681fd2a51e85.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg4NjA3NTEsIm5iZiI6MTczODg2MDQ1MSwicGF0aCI6Ii8xMTIzOTM4Ny8zMDAzNzExNjEtNDhhMmMwN2YtMmMzOC00OWRmLWJjY2MtNjgxZmQyYTUxZTg1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMDYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjA2VDE2NDczMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWIzNTFjZTg3YmU3YTFiYWQyMjE5Njk5YTM5MDVhYzg1YzZjMWI2ZjgzMThlZGRkZTcyYjQwNzMxYmNkMWQ0ZWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.GXBskIzqVGvHI3VWrOk34u5Fn6c4Cfj1da0UEwSzdzY)
introduces the separation of block data into a dedicated blockdb
recent blocks are first stored in a key-value (KV) database. Once they reach the ancient threshold, they will be moved to the ancient database, which wastes some disk bandwidth. Another thing that we should be aware of is EIP-4844. Once BSC supports EIP-4844, the block size will increase due to the inclusion of blobs. The size of the blob storage may not increase over time, but it will still demand extra disk space from the node operators.
Split database by data pattern will make disk bandwidth usage more reasonable and improve the whole performance.
Rationale
tell us why we need these changes...
Example
add an example CLI or API response...
Changes
Notable changes: