RocksDB

The default storage engine for MariaDB is InnoDB, in (MySQL) version 5.7. Thus, most of its features are also available under MariaDB. In version 10.3, minor improvements and numerous bug fixes have been made.

The MyRocks MariaDB storage engine is based on RocksDB, the open source storage engine that was originally (and probably still is) developed by Facebook. RocksDB uses a log-structured merge (LSM) tree, which has an advantage over B-tree indexes for write-intensive workloads and is optimized for solid state drives (SSDs).

The RocksDB compression ratio is about twice as good as compression under InnoDB and is therefore particularly memory efficient. RocksDB offers better write performance than InnoDB for the same workload, accelerating data loading and reducing replication bottlenecks. However, given a read-heavy workload, the RocksDB results are not quite on par with InnoDB.

RocksDB comes with 129 configuration variables, and 105 items of status information can be queried. The output of the command

SHOW ENGINE ROCKSDB STATUS;

is just as complex as it would be from InnoDB. MyRocks configuration seems to be much more complicated than that for InnoDB; therefore, some examples from the RocksDB developers could prove useful for an easy start [3].

OQGRAPH

The Open Query GRAPH (OQGRAPH) computation engine [4] is not an actual storage engine but simulates a graph database with relational tables (InnoDB). OQGRAPH lets you query hierarchies (tree structures, Figure 1) and complex graphs.

Figure 1: A tree-like model of the system of Swiss rivers can be modeled with OQGRAPH and later queried by SQL.

The OQGRAPH computation engine in MariaDB 10.3 still has gamma status, so it is not yet recommended for production use. The Leaves algorithm has been implemented. In contrast to the RocksDB storage engine, the user does not need to reinstall the OQGRAPH computation engine, just activate it.

Spider

Another exotic animal is the Spider storage engine. It, too, is not really a storage engine, but a kind of sharding layer that consolidates data from different instances (Figure 2). Specifically, if a table is partitioned and the individual partitions are moved to separate instances on different servers, the whole construct behaves like a single large instance.

Figure 2: The Spider storage engine distributes data across different instances but offers it to the client as a unit.

The Spider storage engine has been tagged stable in MariaDB 10.3.7 [5]. At the same time, the partition engine has been extended to support condition pushdown (WHERE clause is already evaluated in the partition), multi-range read, full-text search, and aggregation pushdown, as well as bulk update and delete operations.