Views

Not Supported

Query Compilation

Not Supported

Storage Model

Custom

Since the underlying data representation of each series in Prometheus is a list of key-value pair, the storage model of Prometheus is quite similar to normal key-value databases, e.g. LevelDB and RocksDB. Actually, prior to Prometheus 2.0, its storage engine was LevelDB.

Data Model

Key/Value

Prometheus stores data as time series. A time series is defined by a metric and a set of key-value labels. A data sample is a data point at a given timestamp, including a float64 value and a unix timestamp. Therefore a time series can be formally defined as <metric>{<label_1>=<value1>, <label_2>=<value2>...}.

Prometheus supports the following metric types:

• Counter: monotonically increasing/decreasing data
• Gauge: numeric data point that has no correlation with timestamp
• Histogram: samples in a given time range
• Summery: similar to histogram, but only stores quantile data

Compression

Delta Encoding

Prometheus has an efficient data compression format due to the fact that data samples in the same series often change very little. One of the compression algorithms that Prometheus uses is similar to that of Facebook's Gorilla time-series database, called delta-of-delta compression algorithm. Prometheus also has other customized compression algorithms.

With regard to integration with remote storage engines, Prometheus uses a snappy-compressed protocol buffer encoding over HTTP for both read and write protocols.

Query Interface

Custom API

Prometheus has a custom query language called PromQL, which is specially designed to query time-series data. Prometheus query interface also implements math/datetime related functions as well as aggregation. Prometheus also provides a RESTful interface over HTTP.

Concurrency Control

Not Supported

Similar to many time-series databases, Prometheus is log-structured and is not designed for ACID transactions.

System Architecture

Embedded

Prometheus supports flexible configuration to choose backend storage service. Prometheus itself maintains a on-disk checkpoint of series data and also supports remote read/write to other storage systems, making Prometheus's integration with other systems much easier. Also, Prometheus supports custom Webhook receivers to send alert notifications, e.g. AWS SNS and IRC bot.

Joins

Not Supported

Query Execution

Tuple-at-a-Time Model

Since the query in Prometheus is quite similar to that in key-value databases, thus the query execution model is tuple-at-a-time model.

Indexes

Not Supported

Prometheus does not have complex data structures for maintaining indexes. Indexes are simply symbol tables that maps metrics/labels to offsets in Prometheus trunk files.

Checkpoints

Fuzzy

Prometheus supports periodic checkpointing, which is done every two hours by default. Checkpointing in Prometheus is done by compacting segments in a given WAL. Therefore when Prometheus recovers from failure, it can replay the WAL to restore its status before crash.

Storage Architecture

Disk-oriented

Prometheus has two storage architectures:

• local disk storage: write ahead logs are compressed and stored on local disk
• remote storage: Prometheus supports third-party storage (e.g. Kafka, PostgreSQL) via ProtoBuffer adaptor

Stored Procedures

Not Supported

Storage Organization

Log-structured

Logging

Physical Logging

Prometheus ensures data durability by write ahead logging (WAL). The format of how logs are stored on disk in Prometheus is largely borrowed from LevelDB/RocksDB. A typical data point record in Prometheus's WAL is a triple (series_id, timestamp, value).