時系列データベース 2026 完全ガイド - InfluxDB 3 · TimescaleDB · QuestDB · ClickHouse · Prometheus · VictoriaMetrics · Grafana Mimir 徹底解剖

プロローグ — なぜ時系列に専用 DB が必要か

2026年、バックエンド新人が最初にぶつかる幻想。「メトリクス? Postgres に timestamp カラム足して INSERT すれば良いでしょ」。

3ヶ月後の現実: 毎秒10万件のメトリクスで Postgres がディスク I/O で死に、インデックスが毎日10GBずつ膨張し、SELECT avg(value) FROM metrics WHERE time > now() - interval '1 hour' GROUP BY tag が90秒かかり、30日保持で NVMe 一本では足りなくなる。

時系列データ (time-series data) は通常の OLTP データと根本的に違う。 違いは4つ。

Append-heavy — 99.9% が INSERT、UPDATE はほぼ無い。新しい行は常に「now」に追加される。
時間順序 (time-ordered) — データは時間軸でソート済みで到着し、クエリにもほぼ必ず時間範囲が入る。
ダウンサンプリング (downsample) — 直近1時間は1秒、昨日は1分、去年は1時間解像度。時間が経つほど精度を落として良い。
保持ポリシー (retention) — 30日後に自動削除。365日のロールアップだけ残す。

この4つを活用するために作られたのが 時系列データベース (TSDB) だ。同じ1兆行のメトリクスを Postgres に入れると10TBだが、InfluxDB や ClickHouse なら300GBに収まる。圧縮比30倍、クエリ速度100倍 — これが専用 DB が要る理由だ。

本稿は2026年5月時点の時系列 DB フルスタックを解剖する。InfluxDB 3.0 の Rust リライト、TimescaleDB ハイパーテーブル、ClickHouse MergeTree、Prometheus 3.0、VictoriaMetrics 1.110+、Grafana Mimir · Cortex · Thanos、TDengine · GreptimeDB まで。

1章 · 時系列データの5特性

1. Time-ordered append. ほぼ全ての書き込みが単調増加する timestamp と共に到着する。ソート済みデータは圧縮が効き、B-tree より LSM-tree や column-store の方が向いている。

2. High cardinality. 「毎秒10万件のメトリクス」の正体は (host, region, container, pod, namespace) のようなラベル組み合わせの爆発である。ラベルが5個、それぞれ100種類なら cardinality は 10^10 — これが TSDB の #1 スケーリング問題だ。

3. Compression-friendly. 隣接する値が似ている。CPU 使用率は 73.2, 73.3, 73.1 のように微妙に揺れる。Gorilla XOR、delta-of-delta、ZSTD を組み合わせれば30〜50倍の圧縮が可能。

4. Range queries dominate. 「過去1時間の平均」「昨日9〜10時の max」「今月の percentile 95」 — 時間範囲 + 集計関数がパターンの99%。ポイントルックアップは稀。

5. Downsample-able. 1秒解像度のデータを1分、1時間、1日にロールアップして原本を削除しても分析損失は軽微。これが 連続集約 (continuous aggregate) や マテリアライズドビュー (materialized view) が中核機能である理由だ。

この5つをいかにうまく扱うかが TSDB の差別化ポイントになる。

2章 · TSDB 市場マップ — 6陣営

2026年の時系列 DB 市場を大づかみで6陣営に整理できる。

1. Influx 陣営. InfluxDB 3.0/3.1 (Rust + Arrow + Parquet) と InfluxDB 1.x/2.x (TSM + Flux) のレガシー。最古の専用 TSDB ライン。

2. Postgres 拡張陣営. TimescaleDB 2.18 (Timescale Inc. → 2025年に TigerData リブランディング)。リレーショナル + 時系列のハイブリッド。

3. ClickHouse 陣営. ClickHouse 25.x — 本来は OLAP だが事実上最も多く使われている「非公式」TSDB。Yandex が作って ClickHouse Inc. が商用化。

4. Prometheus エコシステム. Prometheus 3.0 (CNCF) + VictoriaMetrics 1.110+ + Grafana Mimir + Cortex + Thanos。モニタリングメトリクスに特化。

5. 新興陣営. QuestDB 8.x (SIMD)、GreptimeDB (Rust + cloud-native)、TDengine (中国 IoT)、CrateDB (分散 SQL)。

6. OLAP 隣接陣営. Apache Druid、Apache Pinot、StarRocks — 本来は OLAP だが時系列ワークロードもさばく。

加えて 商用 SaaS (Datadog、New Relic、Splunk、Honeycomb、Lightstep) が別レイヤーで存在する。こちらは「DB」というより「オブザーバビリティプラットフォーム」だ。

陣営を頭に入れておくと意思決定が早くなる。メトリクスモニタリングは Prometheus エコシステム、IoT/金融ティックは InfluxDB · QuestDB、BI 分析兼用は ClickHouse · TimescaleDB が基本マッピング。

3章 · InfluxDB 1.x / 2.x — TSM 時代の遺産

InfluxDB は2013年リリースの第1世代専用 TSDB。

1.x (2016〜2020). TSM (Time-Structured Merge tree) エンジン。InfluxQL クエリ言語 (SQL に近い)。単一ノード。Telegraf で収集 → InfluxDB に保存 → Chronograf で可視化 → Kapacitor でアラート。いわゆる TICK スタック。

2.x (2020〜2024). TSM + 独自 KV インデックス。Flux 言語 (関数型データパイプライン)。UI 統合、トークン認証、タスクスケジューラ。第1世代 Cloud。

Flux の例。

from(bucket: "metrics")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "cpu")
  |> filter(fn: (r) => r._field == "usage_user")
  |> aggregateWindow(every: 1m, fn: mean)
  |> yield(name: "mean_cpu")

問題点。 Flux は学習コストが高かった。SQL に慣れたデータエンジニアが Flux を学び直す羽目に。インデックスもカーディナリティが100万を超えると性能が崩れた。Clustering (分散) はエンタープライズ専用。

2024年、InfluxDB Inc. (Influx Data) は TSM と Flux を捨てて一から書き直すことを決断。その成果が 3.0 だ。1.x/2.x はレガシー、新規プロジェクトは 3.0 を使うべき。

4章 · InfluxDB 3.0 / 3.1 — Rust + Arrow + Parquet リライト

InfluxDB 3.0 (2024年6月正式リリース、2026年は 3.1) は完全に別物の DB だ。

アーキテクチャ。

言語: Go → Rust に全面書き直し。
インメモリ形式: Apache Arrow (column-oriented in-memory)。
クエリエンジン: Apache DataFusion (Rust 製 SQL エンジン)。
オンディスク形式: Apache Parquet (column-store, ZSTD 圧縮)。
クエリ言語: SQL + InfluxQL (Flux は deprecate)。
分離アーキテクチャ: ingest、storage、query、compaction が別コンポーネント。

製品 SKU 3種。

InfluxDB 3 Core — オープンソース (MIT)。単一ノード。Edge/IoT 向け。
InfluxDB 3 Enterprise — 商用。クラスタ、HA、セキュリティ。
InfluxDB 3 Cloud (Serverless / Dedicated) — フルマネージド。AWS · GCP · Azure リージョン。

なぜ Arrow + Parquet か。 時系列データは column-oriented が圧倒的に有利。(timestamp, host=A, cpu=73.2) と (timestamp, host=A, cpu=73.3) が連なって来るとき、cpu カラムだけ集めて圧縮すれば、値がほぼ同じなので圧縮比が跳ねる。Parquet はそのモデルの業界標準。

Arrow の真の価値は zero-copy interop にある。InfluxDB 3 のクエリ結果をそのまま Pandas、Polars、DuckDB に流せる。ETL 無しに分析ツールへ刺さる。

マイグレーションの注意。 2.x → 3.x は API とクエリ言語が変わる。 Flux は deprecate、write API エンドポイントのパスも違う。Telegraf 出力プラグインは互換があるが、自前コードはほぼ全部リファクタが必要。2026年に 2.x を使い続けている所が多い理由だ。

5章 · TimescaleDB 2.18 / TigerData — Postgres が TSDB になる

TimescaleDB は2017年リリース。2026年現在 2.18。Postgres extension であることが核心。

核となる概念: ハイパーテーブル。 通常の Postgres テーブルに見えるが、内部的に時間で自動パーティショニングされる。

CREATE TABLE metrics (
  time      TIMESTAMPTZ NOT NULL,
  device_id INT,
  cpu       DOUBLE PRECISION,
  memory    DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

これだけで日次の新チャンク (パーティション) が自動生成される。30日後の自動削除も1行。

SELECT add_retention_policy('metrics', INTERVAL '30 days');

連続集約 (continuous aggregate). 毎分入って来る1秒データを自動で分/時/日単位にロールアップするマテビュー。バックグラウンドジョブが増分更新を行う。

CREATE MATERIALIZED VIEW metrics_1h
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS bucket,
       device_id,
       avg(cpu) AS avg_cpu,
       max(cpu) AS max_cpu
FROM metrics
GROUP BY bucket, device_id;

カラム圧縮。 チャンク単位で row-store → column-store に変換。通常90〜95% 圧縮。

ALTER TABLE metrics SET (timescaledb.compress, timescaledb.compress_segmentby = 'device_id');
SELECT add_compression_policy('metrics', INTERVAL '7 days');

TigerData リブランディング (2025). Timescale Inc. は2025年に社名を TigerData に変更。プロダクト名はそのまま TimescaleDB。クラウド SaaS は Timescale Cloud → Tiger Cloud。理由は「Timescale = 事後分析ツール」のイメージを脱して AI/リアルタイム分析メッセージングを強化するため。

強み。 Postgres と100%互換 — psql、pgAdmin、ORM、BI ツールがそのまま使える。リレーショナル JOIN が自由で SQL が豊か。

弱み。 インジェスト上限が単一ノードで毎秒100万行ほど。これを超えると ClickHouse や InfluxDB の方が速い。Multi-node TimescaleDB は 2.13 で deprecate (クラウドのみ分散)。

6章 · QuestDB 8.x — SIMD で武装したインジェスト怪物

QuestDB は2014年開始のオープンソース TSDB。2026年は 8.x。

特異点。 Java + Native (SIMD intrinsics) で記述。インジェスト速度が常識外れに速い。毎秒400万行ベンチマークが珍しくない。

ストレージ。 カラムベース + 時間パーティショニング。ディスクにカラムファイルが時間順で並ぶ — cpu.d、memory.d、timestamp.d。新データは常に末尾に append-only。

クエリ。 SQL を使用。SAMPLE BY、LATEST ON など時系列専用の拡張文法。

SELECT timestamp, avg(cpu)
FROM metrics
WHERE timestamp > dateadd('h', -1, now())
SAMPLE BY 1m;

SELECT * FROM metrics
LATEST ON timestamp PARTITION BY device_id;

インターフェース。 InfluxDB Line Protocol over UDP/TCP (Telegraf 互換)、PostgreSQL wire protocol (psql で接続可)、REST API。

強み。 単一ノードのインジェスト速度は業界トップ。メモリ使用量が低く (10GB で数百億行)、運用がシンプル。ライセンスは Apache 2.0。

弱み。 分散が弱い (Replication は 8.0 で追加されたが新しい)。カーディナリティが極端に高い (数千万ラベル値) と崩れる。SQL だが標準 JOIN が制限的。

フィット領域。 金融市場データ (ティック)、IoT センサー、ゲームテレメトリ。単一ノードで1兆行を時間順に受け止めるワークロード。

7章 · ClickHouse 24.x / 25.x — OLAP だが事実上 TSDB

ClickHouse は Yandex が2009年に社内用に作った column-store OLAP DB。2016年オープンソース化、2021年に ClickHouse Inc. としてスピンアウト。2026年は 25.x。

なぜ TSDB として使われるか。 Column-store + 時間ソート済みデータで圧倒的に速い。MergeTree エンジンは LSM-tree 風の構造でソート済みチャンクをバックグラウンドマージする。

主要エンジン。

MergeTree — 基本。ORDER BY キーでソートされたチャンクを background merge。
ReplicatedMergeTree — ZooKeeper ベースのレプリケーション。HA 用。
SummingMergeTree / AggregatingMergeTree — マージしながら自動集約 (count, sum, min, max)。
ReplacingMergeTree — 同じキー重複時に最新値を保持。

テーブル定義。

CREATE TABLE metrics
(
  timestamp DateTime,
  device_id UInt32,
  cpu       Float64,
  memory    Float64
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (device_id, timestamp);

ALTER TABLE マテリアライズドビュー。 ClickHouse のマテビューは INSERT トリガだ。入って来る行を変換 · 集約して別テーブルに INSERT する。

CREATE MATERIALIZED VIEW metrics_1h
ENGINE = AggregatingMergeTree()
ORDER BY (device_id, bucket)
AS SELECT
  toStartOfHour(timestamp) AS bucket,
  device_id,
  avgState(cpu) AS avg_cpu,
  maxState(cpu) AS max_cpu
FROM metrics
GROUP BY bucket, device_id;

強み。 圧倒的な分析クエリ速度。10億行 GROUP BY が1〜3秒。圧縮比10〜30倍。SQL が豊か (window function、array、map)。分散クラスタが標準機能。

弱み。 UPDATE/DELETE が高価 (ALTER TABLE ... DELETE は非同期 mutation)。トランザクションが無い。単一行 lookup は弱い。運用複雑度は InfluxDB より高い。

2026年の位置付け。 Cloudflare、Uber、Bloomberg、eBay がメトリクスストアとして利用。Grafana Mimir と競合というより 相互補完で使われる。

8章 · Prometheus 2.x / 3.0 — メトリクスモニタリングの事実上標準

Prometheus は2012年に SoundCloud で開始、2016年 CNCF 加入。2025年に Prometheus 3.0 リリース。メトリクスモニタリング分野の事実上の標準。

アーキテクチャ。

Pull モデル — Prometheus サーバーが対象 (/metrics エンドポイント) を定期スクレイプ。
TSDB エンジン — 自前実装。2時間チャンク、WAL、head · persistent block 構造。
PromQL — 時系列専用のクエリ言語。rate、sum by、histogram_quantile など。
Alertmanager — 別コンポーネント。アラートのルーティング · 重複排除。
Service Discovery — Kubernetes、EC2、Consul などから対象を自動発見。

PromQL 例。

rate(http_requests_total[5m])

sum by (status) (rate(http_requests_total[5m]))

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

3.0 の変更点 (2025)。

UTF-8 ラベル対応 — ラベル名にドット、ハイフン使用可 (OpenTelemetry semantic convention 互換)。
Native histograms — 既存 bucket ヒストグラムのカーディナリティ問題を解決。動的 bucket。
Remote-write 2.0 — 効率的なリモートストレージ転送。
OpenTelemetry インジェスト — OTLP メトリクスの直接受信。

弱み。 単一ノード。長期保持はディスクの限界。HA は federation または外部ツール (Mimir、Thanos、VictoriaMetrics) に委ねる。カーディナリティ爆発に弱い — ラベル組み合わせが100万シリーズを超えるとメモリが急増。

2026年でも標準である理由。 Kubernetes エコシステム統合が完璧。あらゆるインフラツールが Prometheus exposition format をサポート。軽量環境なら単一ノードで十分。

9章 · VictoriaMetrics 1.110+ — Prometheus の効率的代替

VictoriaMetrics は2018年開始のオープンソース TSDB。2026年 1.110+。Prometheus 互換だがより効率的なエンジン。

アーキテクチャ。

vmstorage — データ保存。column-store、ZSTD 圧縮。
vminsert — 書き込み受信プロキシ。
vmselect — クエリルーター。
vmagent — Prometheus 代替スクレイパー。remote-write 送信。
vmalert — Alertmanager 代替。

MetricsQL. PromQL のスーパーセット。追加関数 (keep_last_value、aggr_over_time、running_sum) と、より速い実行エンジン。

Prometheus に対する利点。

圧縮比が10倍良い。 同じデータが Prometheus で100GB、VM で10GB。
メモリが7倍少ない。 1000万 active series が Prometheus で32GB必要、VM では4GB。
インジェスト速度が7倍速い。 カーディナリティ爆発にも強い。
クラスタ版がオープンソース。 Prometheus の HA は federation か Mimir 必要。VM は自前でクラスタ。

vmagent で Prometheus を置換。 Prometheus はメモリ保持 + ディスク flush + remote-write を同時に行う。vmagent はスクレイプ後すぐ remote-write — メモリ使用量が1/10。

フィット領域。 大規模メトリクス (1億+ active series)、コスト削減、オープンソース単一ツールで完結したい場合。

弱み。 Grafana/Prometheus エコシステム統合は99%互換だが1%でエッジケース。Recording rules の文法差。

10章 · Grafana Mimir — 水平スケール Prometheus

Grafana Mimir は2022年に Grafana Labs が発表したオープンソースプロジェクト。Cortex のフォーク + 再設計。 Grafana Cloud Metrics のバックエンド。

核となる価値提案。 「Prometheus を1兆 series まで水平スケール」。

アーキテクチャ。

Distributor — インジェスト受信、ハッシュで ingester に分配。
Ingester — WAL + インメモリ chunk。
Store-Gateway — S3/GCS/Azure Blob から historical データを照会。
Querier — クエリ実行エンジン。
Query-Frontend — クエリキャッシュ · 分割。
Compactor — Block マージ。
Object storage — 全永続データを S3 互換ストレージに保管。

S3 が要。 Mimir は RAM/SSD をキャッシュ用途のみに使い、永続ストレージは S3 (または GCS/Azure Blob)。無限保持、低コスト、ノード追加 · 削除が自由。

PromQL 互換。 Prometheus クエリ、recording rules、Alertmanager をそのまま使える。

フィット領域。 Grafana スタックを既に使っていてメトリクスを1億+ series に拡張する SaaS。Grafana Cloud のセルフホスト版。

弱み。 運用複雑度が非常に高い。8〜10個のコンポーネント。ZooKeeper/Consul 風の KV ストア (memberlist 可) が必要。Helm でデプロイしてもチューニングが難しい。

11章 · Cortex と Thanos — Mimir 以前の2系統

Mimir 登場前、水平スケール Prometheus は2つのソリューションがあった。

Cortex (2017〜). Weaveworks が開始、CNCF Incubating。Multi-tenant Prometheus。S3 オブジェクトストレージベース。Mimir は2021年に Cortex からフォークし、AGPL ライセンス変更で分岐。

Thanos (2017〜). Improbable が開始、CNCF Incubating。別アプローチ — Prometheus インスタンスはそのまま残し、sidecar がデータを S3 にアップロード、クエリ時点で複数の Prometheus + S3 を統合照会。シンプルさが強み。

2026年の位置付け。

Thanos — 依然人気。既存 Prometheus を維持しつつ補強。Multi-cluster · multi-region に強い。
Cortex — Mimir 登場後に影が薄い。一部レガシー運用が残る。
Mimir — 開発が最も活発。Grafana Labs がフルプッシュ。
VictoriaMetrics — 上記3つとは別陣営。よりシンプル。

選択ガイド。 新規なら Mimir または VictoriaMetrics。既存 Prometheus が複数クラスタに散らばっていてそのまま残したいなら Thanos。

12章 · カーディナリティ — TSDB の #1 スケーリング問題

TSDB をある程度運用した者なら誰でも知っている。全ての問題の根源はカーディナリティ (cardinality) だ。

カーディナリティの定義。 ユニークな時系列 (time series) の数。http_requests_total{method="GET", status="200", path="/api/v1/users"} が1シリーズ。ラベルの組み合わせが爆発すればシリーズ数も爆発する。

危険なパターン。

user_id をラベルに — ユーザー100万人ならシリーズ100万個。
request_id をラベルに — リクエストごとに新シリーズ。メモリが即死。
timestamp をラベルに — 同様の自殺行為。
エラーメッセージ全文をラベルに — 変動性が無限。

メモリコスト。 Prometheus 単一ノードで active series 100万あたりおよそ 2GB。1000万 series で 20GB。1億で 200GB — 単一ノードでは不可能。

緩和策。

ラベル正規化。 path を /api/v1/users/:id のように正規化 (id を抜く)。
bucket でまとめる。 latency を ms 単位でラベリングせず、ヒストグラムにする。
高カーディナリティラベルは別保管。 request_id のようなものは log (Loki、Elasticsearch) に送り、メトリクスに入れない。
VictoriaMetrics / Mimir でスケール。 1億 series まではツール選択で解決。

カーディナリティは最初から設計せよ。 一度ラベル schema がコード全体に染み込むと抜き去るのは難しい。TSDB 導入前にラベルガイドを先に作れが業界の鉄則。

13章 · 圧縮 — Gorilla XOR · delta-of-delta · ZSTD

TSDB が通常 DB より30倍圧縮が効く理由は3技法の組み合わせ。

1. Delta encoding (timestamp 用). 絶対値ではなく直前値との差分のみを保存。1秒間隔なら差はほぼ1000(ms)。64-bit 整数の8バイトが可変長の1〜2バイトに縮まる。

2. Delta-of-delta encoding (timestamp 用). さらに一歩。差の差を保存。ほぼ一定間隔なら0が連続して出てさらに圧縮される。Gorilla 論文 (Facebook 2015) の核心。

3. Gorilla XOR encoding (float 値用). 直前値と XOR した結果を保存。近い浮動小数点同士は XOR 結果の leading/trailing zero が多くなり可変長エンコーディングが効く。CPU 使用率のように滑らかに変化するメトリクスに効果絶大。

4. ZSTD compression (ブロック単位). 上記エンコーディングの上に ZSTD で再圧縮。通常さらに2〜3倍。

効果。 16バイト (timestamp + float64) が平均1.5バイトまで縮む。10倍圧縮がベースラインで、30倍は普通。

TSDB ごとの実装。

Prometheus / Mimir / Thanos — Gorilla ベース。
InfluxDB 3 — Parquet (PLAIN_DELTA_ENCODING、RLE_DICTIONARY など) + ZSTD。
TimescaleDB — segment-by カラム単位の圧縮 + ZSTD/LZ4。
VictoriaMetrics — 自前アルゴリズム + ZSTD。同じデータで Prometheus より約10倍効率。
ClickHouse — DoubleDelta + Gorilla + LZ4/ZSTD。

圧縮は単にディスク節約ではなく I/O 節約 だ。SSD 帯域がそのままクエリ性能であり、圧縮が効けば同じ I/O でより多くのデータを読める。

14章 · 連続集約 vs マテリアライズドビュー

ダウンサンプリングと事前集約は2つのパターンに分かれる。

連続集約 (continuous aggregate) — TimescaleDB. マテビューだが 増分更新 される。バックグラウンドジョブが新規データだけを集約してビューに追記。ユーザーは SELECT するだけ。

マテリアライズドビュー (materialized view) — ClickHouse. INSERT トリガ だ。新行が来ると変換 · 集約して別テーブルに INSERT。自動増分ではなく、定義時点以降に到着するデータのみが処理される。

recording rules — Prometheus. PromQL 式を定期的 (例: 1分ごと) に実行して結果を別シリーズとして保存。Grafana で高価なクエリを事前計算する用途。

Tasks — InfluxDB 3. SQL/InfluxQL をスケジューラで定期実行。結果を別 measurement に書く。

continuous query (1.x) — InfluxDB 1. レガシー。3.x では Tasks に置換。

選択ガイド。

自動的かつ正確なバックフィルが必要なら TimescaleDB の連続集約。 過去データの変更が自動反映。
インジェスト時に即集約したいなら ClickHouse マテビュー。 ただしバックフィルは別途。
Prometheus 利用箇所なら recording rules のまま。

15章 · OpenTelemetry メトリクス — 新たな標準

2026年のメトリクス送受信の事実上の標準は OpenTelemetry (OTel) だ。

OTel Metrics モデル。

Counter — 単調増加。http_requests_total のような。
UpDownCounter — 増減両方。goroutines_active のような。
Gauge — 即時値。memory_used_bytes。
Histogram — 分布。request_duration_seconds。
ExponentialHistogram — 動的 bucket ヒストグラム (Prometheus 3.0 の native histogram と互換)。

OTLP — OpenTelemetry Line Protocol. gRPC または HTTP/protobuf でメトリクスを送信。

TSDB のインジェスト。 2026年はほぼ全 TSDB が OTLP を直接受け取る。

Prometheus 3.0 — OTLP receive 内蔵。
VictoriaMetrics — OTLP エンドポイント対応。
InfluxDB 3 — OTLP 互換。
Grafana Mimir — OTLP インジェスト。
ClickHouse — OTel Collector 経由でインジェスト。

転換の意味。 Prometheus exposition format (pull) だけが標準だった時代から、OTLP (push) + Prometheus (pull) が共存する時代へ。SDK コードは OTel SDK 一本で書き、どこへ送るかは設定で切り替える。

韓国 · 日本での適用。 カカオは社内メトリクスを Prometheus → OTel に移行中。NTT は OTel をデフォルト採用。新規プロジェクトでは OTel がデフォルトになった。

16章 · TDengine · GreptimeDB · CrateDB — 新興陣営

2026年に注目すべき新興 TSDB 3つ。

TDengine 3.x. 中国の Taos Data が作ったオープンソース TSDB。IoT 特化。C で記述、軽くて速い。「1 device = 1 table」モデル — デバイスごとに別テーブルを作って時系列を隔離。単一ノードで1億デバイスを処理可能。SQL を使用。クラスタはエンタープライズ。

GreptimeDB 0.10+. 2022年リリース、Rust 製の cloud-native TSDB。Storage-compute 分離、S3 バックエンド、Kubernetes フレンドリー。InfluxDB Line Protocol + MySQL/PostgreSQL wire protocol + PromQL を同時サポート。2025年 v0.10 で安定化。 後発だが InfluxDB 3 と直接競合。

CrateDB. 2014年リリース (Crate.io、オーストリア)。分散 SQL DB だが時系列ワークロードもさばく。Elasticsearch のようにシャーディング、Lucene インデックス活用。SQL が豊富で全文検索も可能。一部 IoT 顧客で人気。

いつ使うか。

TDengine — IoT デバイス数が数億で各デバイスが同一 schema。中国市場。
GreptimeDB — Cloud-native 環境、K8s + S3。InfluxDB 3 の代替を評価中。
CrateDB — 時系列 + 全文 + リレーショナルの組み合わせ。SQL フレンドリーな分散 DB が必要なとき。

この3つはメインストリーム (Prometheus、ClickHouse、InfluxDB、TimescaleDB) を置換するというより 特定 niche を狙う。

17章 · OLAP 隣接 — Apache Druid、Pinot、StarRocks

本来 OLAP だが時系列ワークロードもさばく3つ。

Apache Druid. 2011年 Metamarkets で開始、2018年 Apache。時系列 + OLAP。Real-time インジェスト (Kafka 親和)、columnar storage、bitmap index。Netflix、Airbnb、eBay がユーザー分析 / 広告メトリクスで利用。

Apache Pinot. 2014年 LinkedIn で開始、2019年 Apache。Druid と似た領域 — real-time OLAP。Low-latency (sub-second) クエリに強い。LinkedIn、Uber、Stripe が利用。

StarRocks. 2020年開始 (中国)。MPP query engine。分析ワークロード + 時系列を結合。ClickHouse と直接競合。2026年に急成長中。

OLAP TSDB vs 専用 TSDB。

専用 TSDB は append-heavy + retention + 圧縮 が強み。
OLAP は 任意の GROUP BY + JOIN + 複雑な分析 が強み。

いつ OLAP を使うか。 時系列 + ディメンション分析 (スライス & ダイス、ドリルダウン) が同時に必要なとき。広告アトリビューション、ユーザー行動分析、BI。

いつ TSDB だけで済ますか。 モニタリングメトリクス、IoT センサー、金融ティック — 単純な時間軸集約が99%なら専用 TSDB の方が効率的。

18章 · ログ隣接 — VictoriaLogs、Loki、OpenObserve

メトリクスとログは隣接している。同じツールで束ねようとする試みが多い。

Grafana Loki. 2018年 Grafana Labs。「ログ用の Prometheus」。インデックスはラベルのみ (全文インデックスなし)。LogQL でクエリ。S3 バックエンド。Mimir の姉妹。

VictoriaLogs. VictoriaMetrics のログ版。2023年リリース。単一バイナリ、圧縮比優秀、LogsQL クエリ言語。

OpenObserve. 2023年リリース。Rust 製の all-in-one observability — ログ、メトリクス、トレース。Parquet + S3 バックエンド。Elasticsearch/Splunk 代替を狙う後発。

Elasticsearch / OpenSearch. 依然最も普遍的なログストア。重くて高いが全文検索機能が圧倒的。

ClickHouse for logs. Uber、Cloudflare はログも ClickHouse に保管。ELK より圧縮が効いて速いが、全文検索は弱い。

組み合わせパターン。

Grafana スタック = Prometheus/Mimir (メトリクス) + Loki (ログ) + Tempo (トレース)。
VictoriaMetrics スタック = VM (メトリクス) + VictoriaLogs (ログ)。
OpenObserve 単独。 1ツールで3つ全部。
ELK + Prometheus. 古典的分離モデル。

19章 · 商用 SaaS — Datadog · New Relic · Splunk · Honeycomb

オープンソース TSDB を自前運用せず SaaS を使う所も多い。

Datadog. 2010年創業、時価総額約400億ドル (2026年)。メトリクス + APM + ログ + RUM + Security を一画面に。UX 最高、価格は高いことで有名。シリーズあたり / ホストあたりで課金。

New Relic. Datadog 競合。2020年に価格モデルを単純化 (以前は SKU が多過ぎた)。韓国 · 日本市場でシェア拡大中。

Splunk. 2003年創業。ログ中心 (メトリクスは弱め)。エンタープライズセキュリティ (SIEM) に強い。2024年 Cisco 買収。

Honeycomb. Charity Majors が2016年創業。「Observability 2.0」 — イベントベースの high-cardinality 分析。メトリクスというより trace + event。SRE コミュニティで熱狂的人気。

Lightstep. Ben Sigelman 創業、2021年 ServiceNow 買収。トレーシング中心。

Grafana Cloud. Grafana Labs の SaaS。Mimir + Loki + Tempo をマネージド。

選択ガイド。

フルスタックを素早く — Datadog. 高いが速い。
メトリクスのみ、セルフホストオプション — Grafana Cloud.
High-cardinality デバッグ — Honeycomb.
エンタープライズセキュリティ — Splunk.

コスト罠。 Datadog はカーディナリティ爆発で請求が急増する。「Custom metric」のラベル1個追加が月数十万ドルを加算しうる。

20章 · ハードウェア — NVMe I/O パターンとメモリ予算

TSDB の性能はハードウェア選択に直結する。

NVMe SSD は必須。 SATA SSD 帯域 (550MB/s) ではインジェストが追い付かない。NVMe (3〜7 GB/s read、1〜5 GB/s write) が標準。2026年は PCIe 5.0 NVMe も普及。

時系列の I/O パターン。

Sequential write — 新データは append-only。ほぼ sequential。
Range read — 時間範囲クエリは連続ブロック読み。
Random read は少ない — point lookup は稀。

このパターンは LSM-tree、MergeTree、Parquet のような sequential 親和な構造に有利。

シリーズあたりのメモリ予算。 単純化したルール。

Prometheus 単一ノード — 1.5〜2 KB / active series。100万 series = 2GB。
VictoriaMetrics — 約 400 bytes / series。7倍効率。
TimescaleDB — chunk_cache 設定で可変。
ClickHouse — primary key index + mark cache。明示的にチューニング。
InfluxDB 3 — Arrow インメモリバッファサイズを明示。

S3 バックエンドの含意。 Mimir、Thanos、GreptimeDB は永続ストレージを S3 に置く。ディスクはキャッシュのみ。ノード追加 · 削除が自由でコストも SSD の1/10。短所はクエリレイテンシが SSD 直アクセス比100ms以上追加。

ARM CPU 効果。 AWS Graviton、Ampere Altra のような ARM サーバー CPU で ClickHouse、VictoriaMetrics は x86 比20〜30%のコストパフォーマンス向上。InfluxDB 3 は Rust 製で ARM でも良く動く。

21章 · 韓国 — NHN Cloud、Kakao、Coupang

韓国企業の TSDB 利用事例。

NHN Cloud. NHN Cloud Time Series というマネージド TSDB サービスを提供。内部的に InfluxDB ベース + 独自拡張。ゲームテレメトリ、IoT 用途で訴求。

Kakao. カカオトークのバックエンドメトリクスは Prometheus + Thanos。2024年に一部ワークロードを VictoriaMetrics に移行。メトリクスシリーズ数1億+規模。社内データプラットフォームでは ClickHouse も併用。

Naver. ネイバークラウド (NCP) は Cloud DB for InfluxDB マネージド提供。社内モニタリングは Prometheus + Grafana が基本スタック。AI プラットフォームのメトリクスは ClickHouse。

Coupang. Coupang R&D は ClickHouse を積極利用。検索 · リコメンド · 物流メトリクス。Prometheus はインフラモニタリング用。

Toss / トス. 決済ワークロードのメトリクスは Prometheus + VictoriaMetrics。カーディナリティ管理ガイドを社内で積極展開。

Samsung SDS / LG CNS. エンタープライズは Splunk + Datadog の利用が多いが、クラウドネイティブワークロードは Prometheus + Grafana への移行が速い。

韓国語学習リソース。 Owen Lee の Prometheus 韓国語ガイド、VictoriaMetrics Korean Slack コミュニティが活発。ClickHouse ユーザーミートアップはカカオ · 当根 (Daangn) マーケット主導。

22章 · 日本 — NTT R&D、楽天、CyberAgent、メルカリ

日本は TSDB の導入が活発な方だ。

NTT R&D. Prometheus + Thanos が標準。一部 IoT 研究は InfluxDB。OpenTelemetry の採用に最も積極的な日本企業。

楽天. Rakuten Data Platform は ClickHouse を大規模利用。ユーザー行動分析 + 広告メトリクス。加えて Datadog でインフラモニタリング。

CyberAgent. AbemaTV (アベマ TV) のメトリクスは Prometheus + Grafana Mimir。広告アトリビューションは BigQuery + 独自時系列ツール。社内で Grafana Mimir のカンファレンス発表をたびたび行う。

メルカリ. マイクロサービスが1000+規模。Prometheus + Cortex (Mimir へ移行中)。Datadog APM も並行。

LINE. LINE ヤフー (2023年合併) のメトリクスインフラは Prometheus + 独自拡張。Hadoop/Hive ベースの時系列分析も運用。

SoftBank Robotics、Sony. IoT/ロボティクスは InfluxDB 1.x/2.x レガシーが多く、InfluxDB 3 への移行を評価中。

日本語資料。 O'Reilly Japan の「Prometheus 実践ガイド」、日経 BP の時系列データ処理シリーズが標準。Grafana 東京ユーザーミートアップが四半期ごとに開催される。

23章 · マイグレーションパターン

既存 TSDB から別 TSDB へ移行するシナリオ。

InfluxDB 2 → InfluxDB 3. API 互換無し。 Write API は line protocol 互換だが query API と Flux は完全に別道。オプション:

Big-bang マイグレーション — 短時間 (夜間) にデータを export → import。小規模データのみ可能。
Dual-write — 一定期間両方に同時書き込み、検証後 cutover。
読み取り専用保存 — 2.x を historical データ用に凍結、新データのみ 3.x。

Prometheus → Mimir. 比較的平和。Prometheus の remote-write で Mimir をバックエンドに指定、一定期間 dual 運用後、直接 Mimir クエリを使う。PromQL 互換。

Prometheus → VictoriaMetrics. 同様。vmagent で Prometheus を置換、vmstorage がデータを保持。Recording rules の文法が少し異なる — 事前変換が必要。

PostgreSQL (raw) → TimescaleDB. Postgres extension だから CREATE EXTENSION timescaledb + create_hypertable() で済む。ダウンタイムほぼ無し。既存 SQL はそのまま動く。

Postgres → ClickHouse. SQL 文法の差が大きい。PG のトランザクションを諦める必要あり。通常は dual-write パターン — トランザクションデータは PG に、分析 / 時系列は ClickHouse に。CDC (Debezium) で PG → ClickHouse 複製。

OpenTSDB → 何でも. OpenTSDB は2026年に事実上終焉。HBase 運用負担が大き過ぎる。大半は Mimir、VictoriaMetrics、ClickHouse に移行済み。

マイグレーションの落とし穴。 ラベル schema の差 (特に Prometheus の UTF-8 処理)、timestamp 精度 (ns/μs/ms/s) の差、保持ポリシーのマッピング。事前 dry-run は必須。

24章 · 意思決定マトリクス

ケース別 TSDB 選択ガイド。

ケース A — 単一チーム、メトリクスモニタリング、K8s 環境。

シリーズ1000万未満: Prometheus 3.0 単一ノード。
シリーズ1000万〜1億: VictoriaMetrics または Prometheus + Thanos.
シリーズ1億以上: Grafana Mimir または VictoriaMetrics cluster.

ケース B — IoT センサーデータ。

デバイス数十万、エッジコンピューティング必要: InfluxDB 3 Core (Edge).
デバイス数億、中国市場: TDengine.
デバイス + 全文検索同時: CrateDB.

ケース C — 金融ティック、単一ノードインジェスト最適化。

毎秒100万+行インジェスト、単一ノード: QuestDB.
分散 + 分析クエリ豊富: ClickHouse.

ケース D — ビジネス KPI + 分析。

Postgres 親和環境: TimescaleDB.
分析クエリが圧倒的: ClickHouse.
リアルタイム OLAP: Apache Druid または StarRocks.

ケース E — フルスタックオブザーバビリティ (メトリクス + ログ + トレース)。

Grafana スタック選好: Mimir + Loki + Tempo.
VictoriaMetrics スタック選好: VM + VictoriaLogs.
単一ツール: OpenObserve.
SaaS で素早く: Datadog.

ケース F — AI/ML ワークロードメトリクス。

モデル inference latency、GPU 使用率: Prometheus + Grafana + OpenTelemetry.
学習メトリクスロギングと統合: Weights & Biases / MLflow + メトリクスは Prometheus。

基本の出発点。 よく分からなければ Prometheus + Grafana で始めてカーディナリティ爆発の時点で VictoriaMetrics または Mimir にスケール。

25章 · アンチパターン10個

よく見る TSDB の失敗整理。

user_id をラベルに突っ込む。 カーディナリティ爆発の #1 原因。
Prometheus を長期保管庫として使う。 30日を超えるとディスク不足。Mimir/Thanos/VictoriaMetrics へ送れ。
PostgreSQL に raw 時系列。 TimescaleDB 拡張無しなら10倍コスト高。
OLTP DB と TSDB を混ぜる。 時系列ワークロードが OLTP 性能を殺す。
ラベルに timestamp/UUID を突っ込む。 全 row が新シリーズ。
バックアップ無し。 Prometheus は単一ノードディスクに全て。ノード死ねば0。
ダウンサンプリング無しに全て raw 保持。 ディスク爆発。
カーディナリティのモニタリング無し。 prometheus_tsdb_head_series の追跡は必須。
Flux/Influx 1.x で新規プロジェクトを開始。 3.x へ行け。
カード上限を無視した Datadog 導入。 「Custom metric」で請求書が爆発。ラベルポリシーのガードレールが必要。

26章 · 参考 / References

— 時系列データベース 2026、終わり。