History[04][05]

ReductStore is a personal project started by Alexey Timin in 2021 with no publicly stated derivations or inspirations from other existing database systems. It has since received monthly releases and bug fixes. Alexey Timin remains the sole major contributor to this project. The project is currently undergoing a major rewrite with Rust and is actively seeking new collaborators to join.

Checkpoints

ReductStore currently does not support checkpoints.

Compression[06][07][08]

ReductStore directly writes blobs to disk using MessageLite::SerializeToOstream(std::ostream * output) function from Protocol Buffers (Google), which by default does not do any compression.

Concurrency Control[09]

Queries can either be submitted from ReductStore's C++/Python/JavaScript client SDK, or an HTTP API. Query strings are parsed and passed in as protobuf messages. Executor tasks are created from query strings strictly in FIFO order of their arrival time. There is no guarantee that tasks will run in the same order as they arrive.

Data Model[10][11]

ReductStore maintains three Data abstractions: Entry (logical), Block (physical), and Bucket (logical). Each Entry is a blob associated with a key and a timestamp. Each Block physically contains one or multiple Entries of the same timestamp and is backed by a single file on the file system. Entries that are within the same bucket and smaller than the file system's minimum file size are grouped and stored together into a single Block (backed by one file) to reduce the storage overhead of small files. A Bucket logically contains one or multiple physical blocks and is typically used to separate time series data by topic or user.

Buckets enforce storage limits (the total blob size and the total number of entries within the Bucket) and write behavior (reject write or delete earliest) when the storage limit is reached.

Deleting a single Entry or a Block is not supported. The minimum deletion level is a Bucket.

Foreign Keys

ReductStore does not have the concept of a table.

Indexes[12]

Index is not supported. A BRIN-like storage hack is implemented.

Block begin time is defined as the creation time of the block, with microsecond precision. Multiple logical blocks with the same begin time are grouped and stored as a single file on disk. Block start timestamp is embedded in the filename for range queries to perform binary search to locate the first relevant block.

Isolation Levels

ReductStore is not a transactional database. No isolation control mechanism is implemented.

Joins[13]

Only range queries and continuous queries are supported.

Logging

No logging mechanism is implemented. Pending writes are all lost on system crash.

Parallel Execution

Not supported. Each query will only be assigned to a single executor.

Query Compilation

Query Execution

Each executor scans blocks from files one entry at a time. Executors are allowed to read/write blocks that reside in different files concurrently.

Query Interface

Provides HTTP methods for Entry level read, write, and range query. Provides HTTP methods for Bucket level metadata read, metadata update, create, and remove. Provides HTTP methods for Server level statistics read, bucket statistics read, and engine health check. Provides HTTP methods for token-based access control.

Storage Architecture

Storage Format

ReductStore only supports a custom storage format. Entries with sizes smaller than the file system's minimum file size are grouped as a block. Blocks with the same microsecond level begin time are grouped and stored as a single file on disk.

Storage Model

Storage Organization

Blocks are sorted by timestamp, grouped by microsecond level begin time, and stored as individual files on disk. Binary search is used to locate starting entry for range queries.

Stored Procedures

System Architecture

ReductStore is intended for single node deployment.

Views