Ask questionsEngine abstraction tracking issue
This issue is to organize and track progress on abstracting TiKV over generic storage engines (previous issue: https://github.com/tikv/tikv/issues/4184). There are many tasks to be done and contributions are welcome.
In scope: the process of abstracting the entire RocksDB engine API into the
engine_rocks crates, decoupling TiKV and its test suite from RocksDB., and prototyping new engine bindings. Out of scope: refactoring
engine_traits to better support with non-RocksDB engines.
engine_traits crate docs describe the design and
The issue is updated to contain a checklist of tasks that definitely need to happen, along with name of who is working on it. When you decide to take a task, say so on the issue before attempting it so that someone else doesn't duplicate your work.
It's hard to know in what order these need to happen, nor exactly how to
complete each of them, as each tends to present new challenges. Instead I have
documented here, in the
engine_traits crate docs, and in a status report, my experiences so far and suggestions for how to proceed.
The most important thing to keep in mind is:
Make small changes: small commits, small PRs. When you find that something else needs to change first, stop what you are doing, and make that change, and submit that PR. Don't let your patches grow out of control. Don't be afraid to throw away your work and try something else.
Take some abstraction defined in
engine, implement it in
engine_rocks, change all callers to use the new version, delete the old
version. This abstraction can be a single function, an implementation of a
trait, a type, or an entire trait.
engine reexports many types from
rocksdb. Find one of those types, add an
equivalent abstraction to
engine_traits, implement it for
migrate all callers to use
engine_rocks, delete the reexport so that it cannot
be used again.
Find the concrete users of these types and make them generic over the appropriate traits.
This is easiest to do by crate/subsystem
engine_testcrate that simply wraps
engine_rocks. Don't use typedefs. Actually define wrapping types. This creates a layer of indirection between TiKV test cases and RocksDB so that TiKV can be fully-decoupled from RocksDB.
engine_test(TODO expand this)
engine_traitstest suite that is parameterized over implementations
engine_paniccrate that contains no behavior but may be used as a template for creating new engines, avoiding the time it takes to redifine all the impls required by an engine and keeping engine organization consistent. (brson) (https://github.com/tikv/tikv/pull/6383)
engine_mem, a simple in-memory engine. Use
engine_panicas a template.
Answer questions brson
Now that raftstore is its own crate (thanks @overvenus), we have a nice intermediate goal: remove the
engine dependency from
raftstore. That simplifies the problem quite a bit.