Prometheus Query Language is a powerful tool to that lets the user select and aggregate time series data efficiently. https://prometheus.io/docs/prometheus/latest/querying/basics/

Use case

• Prometheus is a de-facto standard for metrics;
• The primary use case is to query data stored in ClickHouse using PromQL.
• Optimized columnar storage.
• Optimized table structure for Prometheus migration use case (drop-in replacement).

Describe the solution you'd like

The task is divided into several sub-tasks:

PromQL interpreter

The biggest challenge are several functions like rate , increase - functions which take possibly huge range-vector and depend on the order of elements in this vector.
PromQL parser and other functions (simple, aggregate and window ones) are doable.

We can support even different "dialects" of this language e.g. support MetricsQL or Grafana's LogQL.

Table structure

Similar to what we have right now for Kusto or PRQL we can put it under the setting sql_dialect. When the sql_dialect is set to promql ClickHouse will read only from the tables with the specified structure. Specifically:

• The main table with schema like (timestamp, value, fingerprint) . Fingerprint could be just a hash of all the tags associated with the metric.
• Index table which will be used for filtering the series by tags. We can pick one of proposed schemas:
  • (tag_key, tag_value, fingerprint)
  • (date, fingerprint, tags_array)

The way how to define the name for these tables can be different - it could be another user-level setting or part of the configuration file.

Native integration with Prometheus API:

What needs to be done for the native integration with Prometheus and drop-in replacement?

• Support for Prometheus HTTP API
• Support for Prometheus Remote Read API (Write?)
• InfluxDB Line Protocol ?