プロローグ — 「時系列DBひとつで全部こなす時代は終わった」

2017年頃まで「時系列DB?」と聞けば、InfluxDB 1.xの名前ひとつしか出てこなかった。2020年にはPrometheusがメトリクスの標準になり、TimescaleDBがSQLを武器にPostgres上で登場した。2023年にはClickHouseがOLAP側から時系列領域を侵食しはじめ、QuestDBがJavaで高速ingestを引っ提げて現れた。

2026年現在、私たちが「時系列データ」と呼んでいるものの中には、**少なくとも4つの異なるワークロード**が含まれている。

1. **メトリクス (metrics)** — CPU・メモリ・QPSのような時間あたりの数値。カーディナリティ爆発が主な敵。

2. **ログ (logs)** — タイムスタンプ + メッセージというテキスト1行。全文検索 + 時間フィルタ。

3. **トレース (traces)** — 分散システムのspan。span-id・trace-idでつながったグラフ構造。

4. **IoT / センサー (telemetry)** — デバイス・車両・工場のセンサー時系列。圧縮率と取り込みスループットが重要。

この4軸の上に、OLAP（分析クエリ）とAPM（アプリケーション性能管理）という応用カテゴリが重なる。つまり同じ「時系列DB」というラベルでも、TimescaleDB・VictoriaMetrics・ClickHouseはそれぞれ違う市場を狙っている。

この記事では、2026年5月時点の主要候補9つ — TimescaleDB、InfluxDB 3 Core/Enterprise、QuestDB、ClickHouse、VictoriaMetrics、Prometheus + Grafana Mimir、M3DB、GreptimeDB、TDengine / OpenTSDB — の立ち位置と強み・弱みを整理する。最後に「私たちのチームは何を選ぶべきか」を4つのドメイン（IoT・観測・金融・OLAP）別に答える。

1. 2026年の時系列DB地図 — メトリクス・ログ・トレース・IoTの4軸

まずは大きな絵から。2026年の時系列DBは大きく3つのファミリーに分類される。

| ファミリー | 特徴 | 代表 |

| --- | --- | --- |

| Postgresファミリー | 標準SQL、トランザクション、JOINに強い | TimescaleDB |

| 専用TSDBファミリー | 時系列最適化の圧縮・インデックス、メトリクス特化 | InfluxDB 3、VictoriaMetrics、Prometheus、M3DB、GreptimeDB |

| カラムストアファミリー | OLAP出身で時系列も得意 | ClickHouse、QuestDB、Apache Druid、Apache Pinot |

ワークロード別に見ると。

| ワークロード | 推奨候補 | 理由 |

| --- | --- | --- |

| Kubernetesメトリクス | Prometheus + Mimir、VictoriaMetrics | 標準互換、カーディナリティ管理ツール |

| APMメトリクス + トレース | OTel + ClickHouseまたはGreptimeDB | OTLPを直接受信、カラム圧縮 |

| IoTセンサー（数十万デバイス） | InfluxDB 3、TDengine、TimescaleDB | 圧縮率、ダウンサンプリング、エッジ統合 |

| 金融ティックデータ | QuestDB、ClickHouse、TimescaleDB | ナノ秒精度、高速時系列JOIN |

| 一般分析 + 時系列 | ClickHouse、TimescaleDB | SQLの親しみやすさ、非時系列との結合 |

| ログ（メトリクスと一緒に） | ClickHouse、GreptimeDB | 全文 + 時間フィルタ |

ひとつ重要な洞察 — **時系列DBをひとつに統一しようとする試みはほとんど失敗する**。k8s観測とIoTを同じDBに押し込むとカーディナリティモデルが根本的に異なるため、どちらかが壊れる。チームのワークロードをまず定義し、適切なツールを選ぶ。

2. TimescaleDB — Postgresの上の時系列

TimescaleDBは時系列DBというより**時系列フレンドリーなPostgres拡張**だ。2017年に登場して以来、「SQLは大好きだが時系列の圧縮とパーティショニングは自動化したい」というチームの圧倒的1番手。

コアコンセプト

- **Hypertable** — 時間カラムで自動パーティション分割されたテーブル。ユーザーには普通のテーブルに見える。

- **Chunk** — Hypertableの時間チャンク（例：7日単位）。古いチャンクは圧縮・移動・削除可能。

- **Continuous Aggregate** — マテリアライズドビュー + 自動リフレッシュ。事前集計の結果を高速に読む。

- **Compression** — 行ベース → カラムベースに変換してから圧縮（通常90%以上節約）。

強み

- 標準PostgreSQL — JOIN、ウィンドウ、CTE、外部キー、JSON、地理情報まで全部使える。

- フルスタック — 時系列だけでなくリレーショナルデータも1つのDBで扱える。

- 運用者がPostgresに慣れている — バックアップ・レプリケーション・監視ツールがそのまま。

- Timescale Cloud（マネージド）も成熟。

弱み

- メトリクスのカーディナリティ面ではPrometheus・VictoriaMetricsより重い。

- 100万series以上になるとインデックスコストが急増。

- 大規模OLAPクエリではClickHouseほど速くない。

いつ選ぶか

- すでにPostgresを使っており、時系列が副次的なワークロードのチーム。

- SQL JOINが頻繁に必要な場合（例：デバイスメタデータとセンサーデータの結合）。

- 金融分析のように精度とトランザクションが重要な場合。

-- TimescaleDB hypertable作成

CREATE TABLE metrics (

time TIMESTAMPTZ NOT NULL,

device_id TEXT NOT NULL,

temperature DOUBLE PRECISION,

humidity DOUBLE PRECISION

);

SELECT create_hypertable('metrics', 'time');

-- 時間チャンクの自動圧縮ポリシー

ALTER TABLE metrics SET (

timescaledb.compress,

timescaledb.compress_segmentby = 'device_id'

);

SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- 連続集計

CREATE MATERIALIZED VIEW metrics_hourly

WITH (timescaledb.continuous) AS

SELECT

time_bucket('1 hour', time) AS bucket,

device_id,

AVG(temperature) AS avg_temp,

MAX(temperature) AS max_temp

FROM metrics

GROUP BY bucket, device_id;

3. InfluxDB 3 (DataFusion + Arrow) — 完全に生まれ変わったInfluxDB

InfluxDB 1.x → 2.x → 3.xと進む過程で、内部は2度書き直された。2.xのFlux言語はほぼ廃止扱いで、3.xは**Apache DataFusionクエリエンジン + Apache Arrowメモリフォーマット + Apache Parquetストレージ**の上に作り直された。実質「InfluxDBという名のArrow時系列データベース」。

コアの変化

- **言語** — InfluxQLとSQL両対応。Fluxは事実上非推奨。

- **エンジン** — Rustで書かれたIOxエンジン。DataFusionがクエリプランナ。

- **ストレージ** — Parquetファイル + オブジェクトストレージ（S3、GCS）ベース。

- **エディション** — Core（OSS、シングルノード）、Enterprise（クラスタ + HA）、Cloud（マネージド、サーバーレス）。

強み

- 標準SQL対応 — FluxやInfluxQLの学習負担が消える。

- Arrow Flight SQLによるクライアント通信 — 高速で標準化。

- オブジェクトストレージへの直接書き込み — 実質無制限保管、安価。

- IoTワークロード向けの圧縮率・取り込みスループットが優秀。

弱み

- 2.x → 3.xの移行パスがきれいでない。2.xを運用中なら痛みを伴う。

- クラスタ（Enterprise）は有料。大規模なOSSオプションが弱い。

- エコシステムがTelegraf・Chronograf時代に比べて分散している。

いつ選ぶか

- IoT / センサーデータ — 数十万デバイス、圧縮が肝の場合。

- 既にInfluxDB 1.x / 2.xを使っているなら移行先として。

- オブジェクトストレージに時系列をフラットに積みたい場合。

-- InfluxDB 3 SQL例 (DataFusion)

SELECT

date_bin('1 hour', time) AS hour,

device_id,

AVG(temperature) AS avg_temp

FROM metrics

WHERE time > now() - INTERVAL '7 days'

GROUP BY 1, 2

ORDER BY 1 DESC;

4. QuestDB — SQLと高速ingestの出会い

QuestDBはJavaで書かれた**時系列特化のカラムストア**だ。コアの売り文句は「Postgresワイヤープロトコル + InfluxDB Line Protocolを同時に受ける」。SQLを使いつつInfluxDB互換クライアントでingestできるという意味。

コアコンセプト

- **SYMBOL型** — 繰り返される文字列をdictionary encodingで保存。カーディナリティ管理に効果的。

- **PARTITION BY** — DAY/MONTH/HOUR単位パーティション。古いパーティションは保持ポリシーで自動削除。

- **DEDUP** — 同じtimestamp + キーの重複を自動除去。

- **ILP (InfluxDB Line Protocol)** — TCP/HTTPで行単位ingest。

強み

- 取り込みスループットが非常に高い — シングルノードで数百万行/秒可能。

- SQLが標準に近い — PGワイヤーで一般クライアントがそのまま接続。

- 高速な時系列JOIN — ASOF JOIN（最も近い時間）への深いサポート。

- 金融ティックデータ界隈での評判。

弱み

- クラスタ（分散）はEnterprise有料。OSSはシングルノード。

- エコシステムが小さい — 運用ツール・サンプル・SI人材が他候補比で少ない。

- 一般データ（トランザクション）には向かない。

いつ選ぶか

- 金融市場データ（ティック） — 高速ASOF JOINと精度が必須。

- シングルノードで非常に高い取り込みスループットが必要な場合。

- SQLを使いつつInfluxDBクライアント互換が欲しい場合。

-- QuestDB ASOF JOIN — 時系列特化

SELECT

trades.timestamp,

trades.symbol,

trades.price,

quotes.bid,

quotes.ask

FROM trades

ASOF JOIN quotes

WHERE trades.symbol = quotes.symbol

AND trades.timestamp > '2026-01-01';

5. ClickHouse — カラムストアの圧倒的性能

ClickHouseは厳密には時系列DBではなく**OLAPカラムストア**だ。だが時間カラムでソート・パーティション分割すれば時系列DBとして使え、他の時系列DBを圧倒する分析性能を出す。2024-2026年で観測領域で最も採用されたバックエンドの1つ。

コアコンセプト

- **MergeTreeエンジンファミリー** — ORDER BYでソート、PARTITION BYで分割。ReplicatedMergeTreeで複製。

- **カラム圧縮** — LZ4（デフォルト）、ZSTD、Delta、DoubleDelta、Gorillaなどのコーデックを選択可能。

- **Materialized View** — トリガベース事前集計。continuous aggregateに類似。

- **Projection** — 同じデータを別ソートでもう1度保存 → 別のクエリパターンにも高速。

強み

- 分析クエリ速度が圧倒的 — 同級のOLAP DBと比べても上位。

- 多様なコーデック — Gorilla（浮動小数点）、DoubleDelta（時間）など時系列特化。

- ほぼ全ての入出力 — JDBC、ODBC、HTTP、Kafka統合、Parquet外部テーブル。

- 巨大データ（数十〜数百TB）でも動く。

弱み

- 単件UPDATE/DELETEに弱い（バッチマージモデル）。トランザクションワークロードには不向き。

- 運用が複雑 — マージ・複製・ZooKeeper（またはClickHouse Keeper）の学習が必要。

- メトリクスのカーディナリティ面でInfluxDB・VictoriaMetricsほど自動化されていない。

いつ選ぶか

- OpenTelemetryバックエンド — OTelトレース/ログ/メトリクス統合保存。

- 大規模ログ分析。

- BI + 時系列結合（アナリストがSQLで自由にクエリ）。

- ユーザー行動イベント + 時系列統合DW。

-- ClickHouse: 時系列 + Gorilla圧縮

CREATE TABLE metrics (

time DateTime64(3, 'UTC') CODEC(DoubleDelta, ZSTD),

device_id LowCardinality(String),

metric LowCardinality(String),

value Float64 CODEC(Gorilla, LZ4)

) ENGINE = MergeTree

PARTITION BY toYYYYMM(time)

ORDER BY (device_id, metric, time);

-- 事前集計マテリアライズドビュー

CREATE MATERIALIZED VIEW metrics_hourly

ENGINE = AggregatingMergeTree

PARTITION BY toYYYYMM(hour) ORDER BY (device_id, metric, hour) AS

SELECT

toStartOfHour(time) AS hour,

device_id,

metric,

avgState(value) AS avg_v,

maxState(value) AS max_v

FROM metrics GROUP BY hour, device_id, metric;

6. VictoriaMetrics — Prometheus互換 + 軽量

VictoriaMetrics（VM）を1文で言うと「**Prometheusと互換性があるが、より速く、軽く、ディスク効率が良い**」。PromQLをほぼそのまま受け、その上にMetricsQLという拡張を載せる。2020年から着実に成長し、2026年には大規模メトリクスバックエンドの標準オプションの1つになった。

コアコンセプト

- **vmstorage / vmselect / vminsert** — クラスタで責務分離されたコンポーネント。

- **vmagent** — Prometheusのスクレイプ代替。remote_writeも対応。

- **vmalert** — Prometheusアラートルール互換。

- **MetricsQL** — PromQL上位互換 + 拡張（rollup関数、histogram_quantile改善など）。

強み

- Prometheus互換 — ダッシュボード（Grafana）とアラートルールがそのまま。

- ディスク使用量が小さい — Prometheus比で7倍以上節約の事例が普通。

- 運用がシンプル — シングルバイナリOSS、クラスタオプション両方明快。

- カーディナリティ管理ツールがよくできている（cardinality explorer）。

弱み

- 「Prometheus + 軽量」以外の差別化は薄い。その価値が明確でなければわざわざ?

- ログ・トレースは別（VictoriaLogs、VictoriaTraces）。統合ソリューションではない。

- 分散クラスタ運用はそれなりに手間がかかる。

いつ選ぶか

- 既にPrometheusを使っており、保持期間 / カーディナリティの限界にぶつかった時。

- シングルノードで大規模メトリクス負荷を受ける場合。

- カーディナリティ可視性が必要な場合。

vmagentでPrometheusスクレイプを代替

vmagent \

-promscrape.config=/etc/scrape_config.yml \

-remoteWrite.url=http://vmstorage:8480/insert/0/prometheus/

PromQLそのまま

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

MetricsQL拡張

rollup_rate(http_requests_total[5m]:1m)

7. Prometheus + Mimir — Kubernetesメトリクスの標準

Prometheusは2026年でもKubernetesメトリクスの事実上の標準だ。CNCF Graduatedプロジェクトでどこでも動く。限界は明確 — **長期保管と水平スケール**。これを解決するオプションの中で最も普及しているのが**Grafana Mimir**（Cortexの後継）。

Prometheusの位置

- pullベースメトリクス — `/metrics`エンドポイントを定期スクレイプ。

- PromQL — メトリクスクエリの事実上の標準言語。

- ローカルディスクのTSDB。通常15日程度保持。

Mimirが解決すること

- **長期保管** — オブジェクトストレージ（S3/GCS）にフラットに蓄積。1年+保管が普通に。

- **水平スケール** — distributor / ingester / store-gateway / querierなどコンポーネント分離。

- **マルチテナント** — 1クラスタで複数チームのメトリクスを隔離。

- **グローバルビュー** — 複数のPrometheusインスタンスを1つに合わせてクエリ。

競合

| オプション | 特徴 |

| --- | --- |

| Grafana Mimir | Cortex後継、Grafana Labs主導 |

| Thanos | サイドカーモデル、同じ問題への別解 |

| VictoriaMetrics cluster | よりシンプル、MetricsQL拡張 |

| Cortex | 事実上Mimirに吸収 |

強み・弱み

強み：Kubernetes・CNCFエコシステムと完璧に統合、exporterプール、標準PromQL。

弱み：メトリクス以外（ログ・トレース）は別スタック、カーディナリティ爆発時の運用が重い。

いつ選ぶか

- Kubernetesクラスタのインフラ / アプリケーションメトリクスがメインの時。

- 既にPromQLとGrafanaで標準化されたチーム。

- マルチテナント観測プラットフォームを構築する時（Mimir選択）。

8. GreptimeDB — Rust基盤の新鋭

GreptimeDBは2022年に登場したRust基盤の時系列DBで、2024-2026年に急成長した。目標は野心的 — **メトリクス・ログ・トレースを1つのDBで、クラウドネイティブに**。

特徴

- **Rust製** — メモリ安全性と性能。

- **SQL + PromQL + InfluxQL同時対応** — 移行フレンドリー。

- **ローカル + オブジェクトストレージ分離** — コンピュートとストレージ分離、S3に直接書き込み。

- **OpenTelemetryネイティブ** — OTLP受信を1級として。

強み

- 1つのDBでメトリクス・ログ・トレース — 統合観測ソリューションとして魅力。

- オブジェクトストレージ分離 — 安価な長期保管。

- 活発なOSSコミュニティ、クラウドオプションもあり。

弱み

- まだ成熟度の面でPrometheus・ClickHouseほど検証されていない。

- 運用経験のプールが小さい。

- 大規模production事例が相対的に少ない。

いつ選ぶか

- 新しい観測スタックをゼロから組む時。

- OTel標準に沿ったメトリクス / ログ / トレース統合が目標の時。

- Rust基盤の軽量さとシンプルさを好む時。

9. M3DB / TDengine / OpenTSDB — その他候補

M3DB

- Uberが作ってオープンソース化した分散TSDB。

- メトリクス・インデックス・集計のコンポーネント分離。

- Uber内部規模（数億series）で検証済み。

- 弱み：外部採用は狭く、運用が複雑。

TDengine

- 中国Taos DataのIoT特化TSDB。

- デバイス1つあたり1テーブルモデル — IoTカーディナリティに効率的。

- 独自SQLとクラスタオプション。

- 弱み：英語圏コミュニティが小さく、一部機能はEnterprise。

OpenTSDB

- HBase上に時系列インデックスを載せた第1世代TSDB。

- 安定性は良いがエコシステムが停滞。

- 新規プロジェクトでは選ばれない。

Apache Druid / Pinot

- 厳密にはTSDBではないが、時間次元が大きいOLAPで頻出。

- リアルタイムダッシュボード・イベント分析に強い。

- 時系列メトリクスバックエンドとしては重い。

10. 圧縮戦略 — Gorilla、ZSTD、Snappy

時系列DBではディスク使用量がそのままコストだ。だから2026年のあらゆるメジャーTSDBは**複数のコーデックを組み合わせる**。

時系列特化コーデック

- **Gorilla (Facebook)** — 浮動小数点時系列特化。XOR + 可変長符号化で平均1.37バイト/ポイント。

- **Delta encoding** — 整数シーケンスで隣接値の差分のみ保存。timestampに特に好適。

- **DoubleDelta** — DeltaのDelta。時間カラムのようにほぼ一定間隔で非常に有効。

- **RLE (Run-Length Encoding)** — 同じ値が繰り返されるシーケンスを圧縮。

- **Dictionary encoding** — 繰り返し文字列をIDに（QuestDB SYMBOL、ClickHouse LowCardinality、Parquet dictionary）。

汎用コーデック（上の段の後に）

- **LZ4** — 最速、圧縮率は普通。ホットデータに適合。

- **Snappy** — Google製。LZ4と類似の位置。

- **ZSTD** — Facebook製。圧縮率と速度のバランスが優秀。コールドデータに頻用。

- **gzip** — 古い標準。圧縮率は良いが速度は落ちる。

組み合わせパターン

ほとんどの時系列DBは「**時系列特化コーデック → 汎用コーデック**」をパイプライン適用する。例えばClickHouse：

- 時間カラム：`DoubleDelta + ZSTD`

- 測定値（float）：`Gorilla + LZ4`

- カテゴリ文字列：`LowCardinality + ZSTD`

この組み合わせで通常原本比5〜20倍圧縮。ディスクコストは1/10以下に下がる。

11. カーディナリティ爆発 — 時系列DBの1番の敵

「カーディナリティ」は時系列DBで最も頻繁に爆発する項目だ。定義はシンプル — **ユニークな時系列の個数**。

何がカーディナリティを爆発させるか

各時系列は通常以下のように定義される。

metric_name{label1=value1, label2=value2, ...}

ラベルの値の組み合わせ数がそのままseries数だ。危険なラベルの例：

- **ユーザーID** — ユーザー100万人ならseries100万倍。

- **リクエストID・セッションID・trace ID** — ほぼ無限。

- **IPアドレス** — 動的IPなら爆発。

- **パラメータ付きURLパス** — `/user/12345/order/67890`。

- **生のエラーメッセージ** — 可変部分が入ると爆発。

爆発すると何が起きるか

- インデックスがメモリに収まらない → クエリ詰まり。

- ディスク使用量急増。

- ingestが遅くなりメトリクス欠損。

- Grafanaダッシュボードがタイムアウト。

解決方法

1. **ラベル衛生** — 爆発ラベルを特定してメトリクスから外す、もしくはトレース / ログに移す。

2. **カーディナリティ可視性** — VictoriaMetricsのvmui cardinality explorer、Prometheusのカーディナリティクエリ、Grafana Mimirの分析。

3. **カーディナリティ制限** — 1 seriesあたりのラベル値上限をingest側で強制。

4. **Drop / Rewriteルール** — スクレイプ段階で危険ラベルを除去。

5. **サンプリング・集計** — 全seriesを保管せず、コア集計のみ。

「トレースに送れ」原則

高カーディナリティのディメンション（ユーザー・リクエストID・トレースID）は**メトリクスではなくトレース**に送るのが、2026年の標準答え。メトリクスは集計、トレースは詳細。

12. 標準 — Prometheus exposition、OpenMetrics、OTel

異なる時系列DBを使っていても、データを流し込む標準は徐々に統合されている。

Prometheus exposition format

HELP http_requests_total Total HTTP requests

TYPE http_requests_total counter

http_requests_total{method="GET",status="200"} 1234 1715814000000

http_requests_total{method="POST",status="201"} 56 1715814000000

- 最も普遍的。すべてのTSDBが受けるか変換する。

- counter、gauge、histogram、summaryの4種。

OpenMetrics

- Prometheus形式のIETF標準化版。

- ExemplarLinkでトレースとリンク可能。

- 基本的にPrometheus形式と互換。

OpenTelemetry (OTel)

- メトリクス・ログ・トレース統合標準。

- OTLPプロトコルでcollectorまたは直接バックエンドへ送信。

- 2026年事実上のマルチシグナル標準。

InfluxDB Line Protocol

measurement,tag1=value1 field1=1.0 1715814000000000000

- InfluxDB・QuestDB・一部のIoTバックエンドが受ける。

- IoTゲートウェイで軽量オプションとして頻繁に。

推奨アプローチ

新規プロジェクトなら**OTel（OTLP）を1級シグナルに**、バックエンドに応じてPrometheus形式またはOTLPを直接受信。メジャーTSDBはすべて両方サポート。

13. IoT vs APM vs 金融 — 誰が何を選ぶべきか

総合へ。ドメイン別の2026年5月時点の推奨。

Kubernetes / 観測（メトリクス中心）

- **第1選択**：Prometheus + Grafana Mimir（またはVictoriaMetricsクラスタ）。

- **理由**：PromQL標準、豊富なエコシステム、成熟したカーディナリティ管理ツール。

- **トレース / ログも必要なら**：+ Tempo + Loki、またはClickHouseで統合。

マルチシグナル観測（メトリクス + ログ + トレース統合）

- **第1選択**：ClickHouse（OTelバックエンドとして）またはGreptimeDB。

- **理由**：1つのDBでSQLで3つのシグナル、カラム圧縮で費用節約。

- **欠点**：運用負担はPrometheusより重い。

IoT / センサー（数十〜数百万デバイス）

- **第1選択**：InfluxDB 3またはTDengineまたはTimescaleDB。

- **理由**：圧縮率、取り込みスループット、ダウンサンプリング、エッジ統合。

- **選択基準**：圧倒的な取り込みが必要ならTDengine / QuestDB、SQLと一般データの結合ならTimescaleDB、オブジェクトストレージ統合ならInfluxDB 3。

金融市場データ（ティック・気配値）

- **第1選択**：QuestDBまたはClickHouseまたはkdb+。

- **理由**：ナノ秒timestamp、ASOF JOIN、高速時系列分析。

- **kdb+の位置**：一部ヘッジファンドの最上位選択は今も。コスト・人材プールが参入障壁。

一般OLAP + 時系列

- **第1選択**：ClickHouseまたはTimescaleDB。

- **理由**：SQLでBI・時系列結合。

- **選択基準**：トランザクション / リレーショナル結合が大きいならTimescaleDB、大規模分析クエリがメインならClickHouse。

アンチパターン7つ

1. 「時系列DB1つで全部」 — ワークロードを分けないとカーディナリティモデルが壊れる。

2. メトリクスにユーザーID・リクエストIDを入れる — カーディナリティ爆発。

3. 圧縮コーデックをデフォルトのまま — カラム特性に合わせれば5倍差。

4. 保持ポリシーなしで無限蓄積 — ディスクコストが1年で暴走。

5. continuous aggregateを使わない — 毎回rawから集計。

6. Prometheus単独で1年+保管 — Mimir / VictoriaMetrics / Thanosのどれかを。

7. メトリクスとトレースの責務混同 — 詳細はトレース、集計はメトリクス。

次の記事予告

- 次候補：**OpenTelemetry深掘り — Collector・Processor・Exporter実戦**、**Grafanaダッシュボード設計ガイド**、**カーディナリティ爆発の事例分析と運用パターン**。

> 「時系列は1つのワークロードではない。メトリクス・ログ・トレース・IoTは同じ形に見えても違う問題だ。違うツールで解くのが正解だ。」

— 時系列データベース 2026、了。

参考 / References

- [TimescaleDB Documentation](https://docs.tigerdata.com/)

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

- [InfluxDB 3 Documentation](https://docs.influxdata.com/influxdb3/)

- [InfluxDB 3 Core/Enterprise — InfluxData](https://www.influxdata.com/products/influxdb/)

- [InfluxDB IOx — GitHub](https://github.com/influxdata/influxdb)

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

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

- [QuestDB Documentation](https://questdb.io/docs/)

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

- [ClickHouse Documentation](https://clickhouse.com/docs)

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

- [ClickHouse Codecs](https://clickhouse.com/docs/en/sql-reference/statements/create/table#codecs)

- [VictoriaMetrics Documentation](https://docs.victoriametrics.com/)

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

- [Prometheus Documentation](https://prometheus.io/docs/)

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

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

- [Thanos — long-term Prometheus](https://thanos.io/)

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

- [GreptimeDB GitHub — GreptimeTeam/greptimedb](https://github.com/GreptimeTeam/greptimedb)

- [M3DB GitHub — m3db/m3](https://github.com/m3db/m3)

- [TDengine GitHub — taosdata/TDengine](https://github.com/taosdata/TDengine)

- [OpenTSDB](https://opentsdb.net/)

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

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

- [OpenMetrics specification](https://openmetrics.io/)

- [OpenTelemetry specification](https://opentelemetry.io/docs/specs/otel/)

- [Gorilla — Facebook in-memory TSDB paper](https://www.vldb.org/pvldb/vol8/p1816-teller.pdf)

- [Facebook ZSTD](https://github.com/facebook/zstd)

- [Snappy compressor](https://github.com/google/snappy)

- [Prometheus high-cardinality guidance](https://prometheus.io/docs/practices/naming/)