DB Plugin Architecture Proposal

This document outlines a mechanism for stacking RocksDB database implementations in novel and interesting ways. A means of layering different databases and related functionality by compilation or configuration will be described.

RocksDB provides many different database implementations that provide different extended functionality. The TTL database provides a means of expiring older values. The TransactionDB provides a means of adding transaction support to RocksDB. All of these databases are extensions of the basic RocksDB database and are examples of Stackable DBs.

Each database implementation (including the base implementation) follows a basic pattern. The database is created via a static Open method in the base class (eg, DB::Open, DBTtl::Open) that takes a set of arguments -- including an “options” structure specific to that type of database -- and returns a database.

There are a few problems with this approach. First, this approach means that the type of database must be decided at compile-time (since the specific static Open call must be determined invoked). A compile-time decision limits the ability of an end-user to potentially choose a different implementation at a later date. For example, a user could not choose to use the Cloud, Blob, or TTL databases in their application. Additionally, there is no mechanism of stacking databases more than one deep. For example, it is not possible to create a “Blob TTL” database. Finally, because there is no clear interface for how to extend all of the database characteristics -- such as Clone, Destroy, Repair -- , not all databases implement these functions in the same way (if at all).

Our approach to solving this problem is to introduce a DBPlugin class. This class will have methods that do the following:
-> PrepareDB: Changes any options (DBOptions, ColumnFamilyOptions) to be suitable for this database implementation
-> SanitizeDB: Checks that the database options are valid for this database implementation
-> WrapDB: Wraps the input database with one for this implementation
-> RepairDB: Does a “Repair” on this database as appropriate
-> DestroyDB:
Other methods will be added as appropriate. All methods will have a “no op” default implementation.

The DBOptions structure will be extended to have a vector of DBPlugins. When a “constructive” operation is invoked, the plugins will be invoked in ascending order of the vector. When a “destructive” operation (close, destroy) is invoked, the plugins will be invoked in descending order. This logic would be handled by the base DB class methods.

Each type of database will have its own plugin implementation (e.g. TtlDBPlugin). The plugins will be created with the options structure that is currently passed to the static Open call for this database implementation. The plugin classes will be Configurable and Customizable, meaning that they can be created and stored in Options files.

For compatibility, the existing DB APIs would remain. These APIs would be changed to create and register the appropriate DBPlugin class. The existing APIs would continue to function as they do now with no API changes.

Note that there may be other uses for the Plugin. For example, there could be a CassandraPllugin. This plugin will make certain that the proper MergeOperator and CompactionFilter are specified when using Cassandra. There may be other “database validation” use cases for DBPlugins as well.