【2022年保存版】気になるTSDBプロダクトを比較してみました

はじめに

こんにちは。エンジニアの takayuki です。

最近、とあるプロジェクトで大量の時系列データを投入し解析する必要性が出てきたため、 TSDB プロダクトについて比較を行いました。
もともとはプロジェクト内で留めるつもりの資料でしたが、せっかく作ったので公開したいと思います。

TSDB の概要など基本的な情報については割愛します。

比較の方法

各プロダクトのドキュメントを読み、後述する観点で比較を行いました。
比較にあたって、実際に各プロダクトを動かしての検証は行っていません。

比較の観点

今回の比較は、プロジェクトの要件に特化しているため、観点は網羅的ではありません。
比較した観点は下記です。

  1. 数百万のデータポイントを15分以内に投入できるか
  2. 1ヶ月間の集計されたデータを30分ごとにデータストアから取り出せるか
  3. オンプレで構成を完結できるか
  4. スケールアップ、スケールアウトできるか
  5. 欠落したデータを後から投入できるか
  6. 1台のデータストアに障害が発生しても継続してデータの投入・取得が行えるか
  7. REST APIなどで操作できるか

観点1, 2 については実際に検証してみないとわからない部分だと思いますので、観点 3 以降を調べて比較しました。

比較対象の選定

TSDB プロダクトの選定は、下記のように行いました。
まず、Prometheus の長期保存ストレージ系として、 Thanos, Cortex, Grafana Mimir を選択しました。Prometheus + Thanos 構成は弊社の別プロジェクトでも運用実績があります。
次に TSDB プロダクトで、比較的よく目にするということで VictoriaMetrics, InfluxDB, TimescaleDB を選択しました。
今回は、この 6 プロダクトに対して比較を行いました。

さっそく、比較

下記の画像をクリックするとPDFで開きます。

実際に動作して確認したものではないため、一部内容に誤りがある場合があります。その際はご指摘いただけると嬉しいです。
総評に記載されているポイントは、あくまでも今回のプロジェクトの要件に特化した値であるため、網羅的なものではありません。
それでは、それぞれの観点について細かく見ていきたいと思います。

オンプレで構成を完結できるか

最近ではクラウドサービスを利用することが多いと思います。今回のプロダクトでは機微情報を扱うため、オンプレで構成を組むことができるかについて調べました。

結果は、 VictoriaMetrics, InfluxDB, TimescaleDB, Thanos, Cortex, Grafana Mimir の6つすべてのプロダクトで、オンプレで構成の完結ができるようです。

スケールアップ、スケールアウトできるか

InfluxDB を除く、VictoriaMetrics, TimescaleDB, Thanos, Cortex, Grafana Mimir ではスケールアップ、スケールアウト共に対応しているようです。
InfluxDB は、 OSS 版ではスケールアップはできますが、クラスター構成を組むためには Enterprise 版の利用が必要であるため、スケールアウトはできません。

欠落したデータを後から投入できるか

一般的に backfill と呼ばれる機能です。
これができるものは、 VictoriaMetrics, TimescaleDB, InfluxDB となりました。
任意の過去の時間帯にデータを投入できます。
Cortex, Grafana Mimir, Thanos については、ドキュメント上は backfill についての記載は見つからず、できないようです。この機能については、各 GitHub Issue にて議論が進められています。

1台のデータストアに障害が発生しても継続してデータの投入・取得が行えるか

VictoriaMetrics, Thanos, Cortex, Grafana Mimir ができる、 TimescaleDB はできるが懸念あり、 InfluxDB はできないという結果となりました。
VictoriaMetrics, Thanos, Cortex, Grafana Mimir は、各コンポーネントを冗長化でき、ストレージも重複保存が可能です。
前段に nginx や keepalived などを設置すれば、ロードバランシングやフェイルオーバー構成を組むことができます。
TimescaleDB は、 PostgreSQL をベースに開発されています。 PostgreSQL は標準で自動フェイルオーバーに対応していないため、 TimescaleDB もこの影響を受けます。 TimescaleDB で自動フェイルオーバー構成を組みたい場合は、 Patroni などを構築する必要があります。また、この方法はドキュメント上では実験的機能とされています。

REST APIなどで操作できるか

プラグインを入れるなどすれば、すべてのプロダクトで HTTP 経由で PromQL でデータを取得できます。

その他の比較観点

プロジェクトでの比較観点は以上になるのですが、その他の観点も追加で調べました。
主なものを紹介します。

任意の時間帯のデータの更新・削除ができるか

TimescaleDB, Influx DB では、更新・削除ができ、それ以外のプロダクトの VictoriaMetrics, Thanos, Cortex, Grafana Mimir ではできない結果となりました。
なお、 VictoriaMetrics については、現在「更新」機能が実装中のようです。
https://github.com/VictoriaMetrics/VictoriaMetrics/pull/2885

データストアのバックアップ・リストアができるか

VictoriaMetrics, TimescaleDB, InfluxDB はバックアップ・リストアツールを提供しており、可能です。 Thanos, Cortex, Grafana Mimir については、そもそもストレージの管理が関心の対象外のようです。環境構築者自身が長期保存用のブロックストレージを用意し、バックアップ・リストアをする手法も自身で確立して運用する必要があります。

終わりに

DB-Engines Ranking によると、 InfluxDB が TSDB プロダクトで最も人気のようです。
たしかにInfluxDBは、調査した限りほとんどの観点で要件を満たす機能が提供されていました。
ただ、 OSS 版ではクラスタ構成を組めないのが難点です。素直に Enterprise 版を利用するのも1つの選択肢ではあります。
今回は、ほとんど同様の機能を提供している VictoriaMetrics をプロジェクトで採用することにしました。

各プロダクトで機能の追加がありましたら、しばらくして新しい記事にて執筆させていただこうとおもいます。
もし、今回の内容に誤りがありましたら、修正しますので、ご指摘いただけると嬉しいです。