-
Notifications
You must be signed in to change notification settings - Fork 980
Description
There are some basic implementations of "stores" here:
https://github.com/sigp/lighthouse/tree/master/lighthouse/db/stores
The goal of the stores concept is to abstract database operations away from "higher-level" parts of the application. Each store is initialized with some underlying database implementing the ClientDB trait. The store provides read/write access to specific parts of the database. Stores are separated by topic (e.g., blocks, validations) for two main reasons (a) it's nice to separate things and have smaller files and, (b) having separate stores helps to communicate which parts of the database some function might access to.
In the near future, stores may implementing caching, bloom filters and other whiz-bang things to speed up data access.
The ClientDB trait has a concept of "columns" to help separate the key space between stores. It's up to the underlying database as to how it implements these columns. MemoryDB just adds a prefix to each key in order to separate columns. DiskDB (RocksDB) might choose to implement some columns as actual RocksDB columns and others as just prefixes in the same physical column.
Presently, the tests for the stores are pretty dismal. It would be great to have some tests comprehensive tests. We only need to test against MemoryDB, using DiskDB is cumbersome and the two should always perform identically -- if they don't it's an issue for the databases ClientDB implementation.
Happy to assist anyone who wants to work on this :)