Ordered Key-Value Store

An Ordered Key-Value Store (OKVS) is a type of data storage paradigm that can support multi-model database. An OKVS is an ordered mapping of bytes to bytes. It is a more powerful paradigm than Key-Value Store because OKVS allow to build higher level abstractions without the need to do full scans. An OKVS will keep the key-value pairs sorted by the key lexicographic order. Some OKVS provide a way to customize the sorting algorithm. OKVS systems provides different set of features and performance trade-offs. Most of them are shipped as a library without network interfaces, in order to be embedded in another process. Most OKVS support ACID guarantees. Some OKVS are distributed databases. Ordered Key-Value Store found their way into many modern database systems including NewSQL database systems like Google Spanner, CockroachDB and TiDB.

The origin of Ordered Key-Value Store stems from the work of Ken Thompson on dbm in 1979. Later in 1991, Berkeley DB was released that featured a B-Tree backend that allowed the keys to stay sorted. Berkeley DB was said to be very fast and made its way into various commercial product.^[1] It was included in Python standard library until 2.7.^[2] In 2009, Tokyo Cabinet was released that was superseded by Kyoto Cabinet that support both transaction and ordered keys. In 2011, LMDB was created to replace Berkeley DB in OpenLDAP. There is also Google's LevelDB that was forked by Facebook in 2012 as RocksDB. In 2014, WiredTiger, successor of Berkeley DB was acquired by MongoDB and is as of 2019 the primary backend of MongoDB database.

Other notable implementation of the OKVS paradigm are Sophia^[3] and SQlite LSM extension.^[4] Another notable use of OKVS paradigm is the multi-model database system called ArangoDB^[5] based on RocksDB.

Some NewSQL databases are supported by Ordered Key-Value Stores. JanusGraph, a property graph database, has both a Berkeley DB backend and FoundationDB backend.

There are algorithms that encode basic data types (string, integer, float) and composition of those data types using containers like tuples, lists or vectors that preserve their "natural" ordering. That is, one can work with an Ordered Key-Value Store without having to fiddle with bytes directly. In FoundationDB, it is called the tuple layer.^[6]

One can construct key spaces to build higher level abstractions. The idea is to construct keys, that takes advantage of the ordered nature of the top level key space. When taking advantage of the ordered nature of the key space, one can query ranges of keys that have particular pattern.

De-normalization, as in, repeating the same piece of data in multiple subspace is common practice. It allows to create secondary representation (also called indices) that will allow to speed up queries.

As of 2019, the following abstraction or databases were built on top Ordered Key-Value Stores:

• Timeseries database^[7],
• Record Database^[8], also known as Row store databases, they behave similarly to what is dubbed RDBMS,
• Tuple Stores, also known as Triple Store or Quad Store but also Generic Tuple Store^[9][10],
• Document database^[11], that mimics MongoDB API,
• Full-text search
• Geographic Information Systems^[12]
• Property Graph^[13]
• Versioned Data^[14]

All those abstraction can co-exist with the same OKVS database and when ACID is supported, the operations happens with the guarantees offered by the transaction system.

• Wide Column Store
• Multi-model database