Compression

Naïve (Page-Level) Naïve (Record-Level)

OpenTSDB uses Row Compaction to compress data. Whenever a cell is to be written, its row key is pushed into a compaction queue. There is a separate thread that periodically goes through the queue and aggregate data with the same key into a big cell. It then writes the big cell and deletes the individual cells in the queue. This process is effective because in HBase the row key is repeated for every single cell, and there is no way to efficiently append byte at the end of a cell.

At data level, OpenTSDB uses LZO compression algorithm.

With these two techniques, OpenTSDB is able to reduce the average size of one data point from 12 bytes to 2-3 bytes.

Concurrency Control

Timestamp Ordering

OpenTSDB allows concurrent writes without using locks. OpenTSDB avoids multiple writers creating duplicate rows in the case of writer restart by making writes idempotent. It enforces a fixed timestamp boundary for each row. When a write reconnects to HBase, it will always write to the appropriate row according to the timestamp instead of creating new rows.

Data Model

Key/Value

Data are stored as time series. Each time series is a collection of data points. A data point is a key-value map (time, value). A time series is identified by its metrics and tags. For example, Metrics=proc.loadaverage.1m, Tags=(host: web42, pool: static) is a collection of data points identifying the 1-minute load average of server web42 serving static contents.

Isolation Levels

Read Uncommitted Read Committed

OpenTSDB uses HBase as its storage system. HBase supports both the READ-COMMITTED and READ-UNCOMMITTED isolation levels.

Parallel Execution

Intra-Operator (Horizontal)

OpenTSDB supports running multiple TSDs to handle a single query, allowing parallel read from HBase to speed up data fetching.

Query Interface

Custom API HTTP / REST Command-line / Shell

There are 2 official supported query interfaces: HTTP/REST API and Telnet style command line API. Additionally, there are various open-source front-end clients that encapsulate the official APIs, including a Browser interface and Erlang/Java/Go/Python/R/Ruby clients.

Storage Architecture

Disk-oriented

The back-end storage system is HBase, an open-source non-relational disk-oriented distributed database. It also supports Google Bigtable as its backend.

Storage Model

N-ary Storage Model (Row/Record)

OpenTSDB has a N-ary storage model, each row is of the format Metrics, Tags, Timestamp: data1 : data2: ....

System Architecture

Shared-Disk

OpenTSDB consists of three components: tCollector, Time Series Daemon (TSD), and HBase. One instance of tCollector is deployed on each server. It is responsible to periodically pull metrics data from processes running on the server and the operating system. TSDs receive data from the tCollectors and push data to the HBase backend storage system. Upon receiving queries, TSD scans HBase and retrieves relevant data.

All communications are done via TSD RPC and Hadoop RPC, therefore all components are stateless. There can be as many TSDs as needed to handle the workload as the system scales.