-
Notifications
You must be signed in to change notification settings - Fork 745
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
Modularize beacon node backend #4718
base: unstable
Are you sure you want to change the base?
Conversation
…dularize-beacon-node-backend
I'm currently working on adding Redb to the beacon node backend. Here are some notes I've taken so far on my work RedbTheres a few difference's between LevelDB and Redb that I'll describe below fsyncInfo about redb transaction durability can be found here For now I translate We could decide to use CompactionLevelDB allows for compacting over a range of values. Redb only allows for compacting the full db. It seems like our LevelDB implementation compacts across all keys in the DB. If thats the case we should be all good here. TablesRedb introduces the concept of tables. We can either use one table for everything, or spin up tables by column name. I'm currently going down the path of spinning up tables by column name. This causes issues with |
key.matches_column(column) && predicate(trimmed_key, trimmed_start_key) | ||
}) | ||
.map(move |(bytes_key, value)| { | ||
let key = bytes_key.remove_column_variable(column).ok_or_else(|| { |
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.
You should add the metric here and increase DISK_DB_READ_BYTES
with value to have the same meaning as the the usage with the per-item gettter
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.
Ok(Box::new( | ||
iter.take_while(move |key| key.matches_column(column)) | ||
.map(move |bytes_key| { | ||
metrics::inc_counter_vec(&metrics::DISK_DB_READ_COUNT, &[column.into()]); |
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.
I think it's not ideal to count reads of keys (this function) as reads of entries (other uses of DISK_DB_READ_COUNT
). If this iterators just read keys, maybe we should use a different metric DISK_DB_KEY_READ_COUNT
or similar
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.
yep makes sense, I've added separate metrics for db key read
…serilev/lighthouse into modularize-beacon-node-backend
I've opened a separate issue around temp state cleanup performance for Redb. I'm going to handle that in a separate PR if thats ok with you guys |
Compaction in redb v2.1.2 is craaazy slow: cberner/redb#852 For now lets just make sure we stay on 2.1.1 until the issue is resolved |
…serilev/lighthouse into modularize-beacon-node-backend
…dularize-beacon-node-backend
…dularize-beacon-node-backend
…dularize-beacon-node-backend
Issue Addressed
#4669
Proposed Changes
Modularize the beacon node backend to make it easier to add new database implementations
Additional Info
The existing
KeyValueStore
trait already does some abstraction, however the codebases assumes the KV store is always LevelDB.I created a
BeaconNodeBackend
type that implements theKeyValueStore
andItemStore
traits. I then replaced all references ofLevelDb
to the newBeaconNodeBackend
type. Within theBeaconNodeBackend
type I used thecfg
macro which should allow us to switch between different database implementations via config changes.