History[03]

Companies like ELEME Inc. need to monitor all its systems, which calls for DBMS capable of saving multi dimension monitoring metrics for several PB per day. Previously the company use graphite, however its performance downgrades when the dimension of the metrics increases.

LinDB is developed to address this demand. The project is launched at 2016 internally, and has been updated three versions. The open sourced version is a redesign and rewrite in Go since 2019, however is not in production stage yet.

Compression[04][03][05]

LinDB uses a combination of bitmap encoding and data compression. Since it is designed for time-series data, all data entry contains a timestamp and several multi dimensional metrics, such as ip string, shard id, etc. The timestamp is saved with a base timestamp and a bitmap with each bit encoding a time within some time period following the base timestamp. The data blocks are compressed with xor, in reference to Gorilla.

Concurrency Control[03]

Concurrency control is not supported. All writing to the DB is first directed to the specific shard based on its tagKey and tagValue. Within each shard all writing is handled by a single thread.

Data Model[06][07][08]

Similar to other time-series DBMS, the data model contains four main components: timestamp, metrics, tags, and fields. The metric is the name of the measurement attribute. Tags are combinations of dimensions of measurement used during query, and the fields stores metric data. User has to define whether their columns belong to tags or fields.

Foreign Keys

Query Interface[09]

LinDB supports SQL-like query interface.

System Architecture[10][11][03][12]

LinDB is designed to support both fast insert and high throughput read, including mainly aggregation operations such as group by. Meanwhile, it needs distributed storage due to the size of the stored data.

The storage layer mainly stores data with write replication, with shard number configurable to user. Each cluster contains several servers, and data are redundantly stored across servers.

User interacts with the DBMS via brokers. The broker is in charge of receiving query requests, parsing queries, redirect child execute plan to storage layer, and aggregation if needed.

In addition, metadata of the clusters for broker layer and storage layer are stored by ETCD, an external dependency. It servers as a distributed configuration service in Go. The internal Java version LinDB use Zookeeper for the same functionality.