Add caching of the views on the Database level
#1993
Comments
3 tasks
xgreenx
added a commit
that referenced
this issue
Jun 28, 2024
) Closes #1581 The change finally implements an atomic view of the RocksDB database via the snapshot feature. We use a snapshot (if available) each time we read/iterate over the RocksDB. It guarantees a consistent view even if the data is removed/added/modified. `InMemory` database also implements this feature by simply cloning all `BTreeMap`s. In the future, we need to optimize this behavior and cache views - #1993. ## Checklist - [x] New behavior is reflected in tests ### Before requesting review - [x] I have reviewed the code myself - [x] I have created follow-up issues caused by this PR and linked them here
3 tasks
xgreenx
added a commit
that referenced
this issue
Jul 4, 2024
Closes #451 ## Overview Added support for the state rewind feature. The feature allows the execution of the blocks in the past and the same execution results to be received. Together with forkless upgrades, execution of any block from the past is possible if historical data exist for the target block height. The default size of historical/rewind window is 7 days. Also added support for rollback command when state rewind feature is enabled. The command allows the rollback of the state of the blockchain several blocks behind until the end of the historical window. ## Implementation details The change adds a new `HistoricalRocksDB` type that is the wrapper around regular `RocksDB`. This type has inside another RocksDB instance that is used to duplicate all tables plus has one more column to store the reverse modifications at each block height. The reverse modification is the opposite to the operation that was done during transition from block height X to X + 1. The screenshot below should describe the idea: <img width="723" alt="image" src="https://github.com/FuelLabs/fuel-core/assets/18346821/c4becce0-1669-4938-8dd7-87d274efa224"> The key of duplicated tables is extended with block height, and the value is the reverse operation to reach the state of entry at the previous height. Having the history of reverse operations, we can iterate back from the latest version of the entry to the previous one. Using the main property of the RocksDB(sorting keys by default), lookup operations are fast and we don't need to iterate all modifications. It is just enough to find the nearest reverse operation to the target height. ## Checklist - [x] New behavior is reflected in tests ### Before requesting review - [x] I have reviewed the code myself - [x] I have created follow-up issues caused by this PR and linked them here - #1997 - #1995 - #1993
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the requested storage view doesn't exist, we need to create it and cache it. In the case when someone requests the view at exactly the same height, it should already be ready. The cache can be LRU or timeout-based.
The text was updated successfully, but these errors were encountered: