필사 모드: 時系列データベース 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 は完全に別道。オプション:

1. **Big-bang マイグレーション** — 短時間 (夜間) にデータを export → import。小規模データのみ可能。

2. **Dual-write** — 一定期間両方に同時書き込み、検証後 cutover。

3. **読み取り専用保存** — 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 の失敗整理。

1. **user_id をラベルに突っ込む。** カーディナリティ爆発の #1 原因。

2. **Prometheus を長期保管庫として使う。** 30日を超えるとディスク不足。Mimir/Thanos/VictoriaMetrics へ送れ。

3. **PostgreSQL に raw 時系列。** TimescaleDB 拡張無しなら10倍コスト高。

4. **OLTP DB と TSDB を混ぜる。** 時系列ワークロードが OLTP 性能を殺す。

5. **ラベルに timestamp/UUID を突っ込む。** 全 row が新シリーズ。

6. **バックアップ無し。** Prometheus は単一ノードディスクに全て。ノード死ねば0。

7. **ダウンサンプリング無しに全て raw 保持。** ディスク爆発。

8. **カーディナリティのモニタリング無し。** `prometheus_tsdb_head_series` の追跡は必須。

9. **Flux/Influx 1.x で新規プロジェクトを開始。** 3.x へ行け。

10. **カード上限を無視した Datadog 導入。** 「Custom metric」で請求書が爆発。ラベルポリシーのガードレールが必要。

26章 · 参考 / References

- [InfluxDB 3 — 公式ドキュメント](https://docs.influxdata.com/influxdb3/)

- [InfluxDB GitHub — influxdb_iox (Rust コア)](https://github.com/influxdata/influxdb)

- [Apache Arrow — 公式](https://arrow.apache.org/)

- [Apache DataFusion — 公式](https://datafusion.apache.org/)

- [Apache Parquet — 公式](https://parquet.apache.org/)

- [TimescaleDB / TigerData — 公式](https://www.tigerdata.com/)

- [TimescaleDB GitHub](https://github.com/timescale/timescaledb)

- [QuestDB — 公式](https://questdb.io/)

- [QuestDB GitHub](https://github.com/questdb/questdb)

- [ClickHouse — 公式ドキュメント](https://clickhouse.com/docs)

- [ClickHouse GitHub](https://github.com/ClickHouse/ClickHouse)

- [Prometheus — 公式](https://prometheus.io/)

- [Prometheus 3.0 — リリースノート](https://prometheus.io/blog/2024/11/14/prometheus-3-0/)

- [VictoriaMetrics — 公式](https://victoriametrics.com/)

- [VictoriaMetrics GitHub](https://github.com/VictoriaMetrics/VictoriaMetrics)

- [Grafana Mimir — 公式](https://grafana.com/oss/mimir/)

- [Grafana Mimir GitHub](https://github.com/grafana/mimir)

- [Cortex — 公式](https://cortexmetrics.io/)

- [Thanos — 公式](https://thanos.io/)

- [TDengine — 公式](https://tdengine.com/)

- [GreptimeDB — 公式](https://greptime.com/)

- [CrateDB — 公式](https://crate.io/)

- [Apache Druid — 公式](https://druid.apache.org/)

- [Apache Pinot — 公式](https://pinot.apache.org/)

- [StarRocks — 公式](https://www.starrocks.io/)

- [Grafana Loki — 公式](https://grafana.com/oss/loki/)

- [VictoriaLogs — 公式ドキュメント](https://docs.victoriametrics.com/victorialogs/)

- [OpenObserve — 公式](https://openobserve.ai/)

- [Datadog — 公式](https://www.datadoghq.com/)

- [New Relic — 公式](https://newrelic.com/)

- [Splunk — 公式](https://www.splunk.com/)

- [Honeycomb — 公式](https://www.honeycomb.io/)

- [OpenTelemetry — 公式](https://opentelemetry.io/)

- [OpenTelemetry Metrics スペック](https://opentelemetry.io/docs/specs/otel/metrics/)

- [Gorilla 論文 — Facebook 2015](https://www.vldb.org/pvldb/vol8/p1816-teller.pdf)

- [Awesome Time-Series Databases — GitHub](https://github.com/xephonhq/awesome-time-series-database)

- [NHN Cloud Time Series — 公式](https://www.nhncloud.com/kr/service/database/time-series)

- [Naver Cloud — Cloud DB for InfluxDB](https://www.ncloud.com/product/database/cloudDbForInfluxdb)

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