-
Notifications
You must be signed in to change notification settings - Fork 179
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
[State Sync] Experiment with using pebble as the execution datastore db #6180
[State Sync] Experiment with using pebble as the execution datastore db #6180
Conversation
… and badger implementation
…drukhiv/6017-pebble-as-execution-datastore-db
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6180 +/- ##
==========================================
- Coverage 41.49% 41.42% -0.07%
==========================================
Files 2003 2008 +5
Lines 142757 142903 +146
==========================================
- Hits 59232 59196 -36
- Misses 77352 77532 +180
- Partials 6173 6175 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
Added a few comments. I like the direction you're taking, but I think we should separate the tracker updates into a separate PR. That way we could begin to experiment with using pebble as the datastore sooner.
For the tracker changes, I think it would make sense to break it down into 2-3 PRs:
- Split out db code similar to how we've done it for all of the other storage interfaces (e.g. storage.Header)
- Introduce a new common interface similar to what you have that the badger storage implementation should implement. At this point, there should be no badger specific code left in the tracker/pruner.
- Add the pebble version of the storage object.
I think this will help reduce the coupling of the storage and even simplify the interface
…ta storage interface
…of github.com:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6017-pebble-as-execution-datastore-db
…g to go-ds-pebble, updated creating modules according to pebble version of ConsumerProgress
…of github.com:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6017-pebble-as-execution-datastore-db
Co-authored-by: Andrii Slisarchuk <[email protected]>
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.
added a few small comments, but I think this is ready to start testing with. we'll need to get the ipfs change merged first (or we can create a fork in the onflow repo if it's going to take a long time)
I created a fork of |
…of github.com:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6017-pebble-as-execution-datastore-db
Thank you, @peter, for creating the forked repo. I have updated the replace. |
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.
Nicely done!
Close #6017
Note: this PR includes:
go-ds-pebble
which are detailed in PR Add WithPebbleDB configuration option to Datastore implementation ipfs/go-ds-pebble#36ConsumerProgress
from PoC PR ([CI Version] Refactor Protocol State with Pebble-based Storage #6206)Context
In this pull request:
executionDataDBMode
) that controls which db type to use.DatastoreManager
interface that defines the methods for managing a datastore used for handling execution data andbadger
(BadgerDatastoreManager
) andpebble
(PebbleDatastoreManager
) implementations .IPFS PR: ipfs/go-ds-pebble#36