1

At the moment building the Substrate repository requires RocksDB library librocksdb-sys and all its native dependencies to be pulled in, but it also supports testing out the "faster and more efficient" "experimental" embedded ParityDB using the --database paritydb flag, which is also a persistent KV store that uses OS page cache instead of custom data caching, with interesting RAM performance when syncing. However validator documentation still recommends using the RocksDB backend.

Meanwhile in this issue @bkchr mentioned that whilst Substrate compiles on aarch64 there isn't official support for aarch64-linux-android on Android, but @koute and also @gilescope in this issue suggested adding a feature flag to the Substrate CLI so building with RocksDB could be optionally disabled because some restless users want to test Substrate on their mobile devices.

I understand that RocksDB is a Key-Value (KV) database by Facebook and @debris has previously mentioned that it is faster than Google's LevelDB. I also read that at some stage Parity migrated to using blooms-db (an implementation of a Bloom Filter to reduce overall disk reads), where the blooms are a database layer before the kvdb RocksDB. The Substrate documentation explains the different trie layers of abstraction.

In various Cargo.toml files of the Substrate repository, there are dependencies like:

kvdb
kvdb-rocksdb
kvdb-memorydb
parity-db

Previously in an earlier version kvdb = "0.1.0" it was a "Key-Value store abstraction with RocksDB backend", rather than being "generic".

So when I was reviewing the benchmarking code here where they generate a trie using the db type kvdb::KeyValueDB from the kvdb library, I wondered why we weren't benchmarking the generation of a trie with ParityDB too, and how could we use the kvdb Rust library with ParityDB as a key-value store abstraction, or what was the equivalent library that was being used by ParityDB?

1 Answer 1

1

Upon closer inspection of that benchmarking code here where they generate a trie using the db type kvdb::KeyValueDB, I noticed in the Cargo.toml file that we were now using version of kvdb = "0.13.0" which is now a "Generic key-value trait".

Initially I was confused because in an earlier version kvdb = "0.1.0" it was a "Key-Value store abstraction with RocksDB backend". So it appears substantial work has been performed by Parity to make that abstraction generic so that the trait KeyValueDB is a "Generic key-value database" that may be used by ParityDB's embedded in-memory kvdb-memorydb = "0.13.0" library or RocksDB's kvdb-rocksdb = "0.17.0" library.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.