時系列データベース比較（2026）：アーキテクチャ・性能・選定ガイド
クイック推奨
唯一の「最良」な時系列データベースは存在しない。正しい選択は、データモデル・クエリパターン・運用熟練度・予算に依存する。本記事は5つの主要エンジンをアーキテクチャ・コード・コスト・選定基準で比較し、実践的な意思決定を支援する。
| 主な要件 | 推奨エンジン | 理由 |
|---|---|---|
| 全文SQLと関係 JOIN が必須 | TimescaleDB | PostgreSQL 拡張——全SQL機能をネイティブに利用可能 |
| オブジェクトストレージ優先＋アドホック分析 | InfluxDB 3 (IOx) / VictoriaMetrics | 列型エンジン＋Arrow Flight——大規模スキャンが高速 |
| 数百万〜数千万の IoT デバイスで高頻度書込 | TDengine | スーパーテーブル＋デバイス単位分割——最大の書込効率 |
| Kubernetes 監視とクラウドネイティブメトリクス | Prometheus + remote-write | 成熟したエコシステム、Operator による自動収集 |
| 高カーディナリティラベル、コスト重視 | VictoriaMetrics | 単一バイナリ、業界トップのメモリ/ディスク効率 |
本番を目指すならスライドの数字だけを見てはいけない。高カーディナリティ下の安定性、スケールアウトの運用複雑度、コミュニティ/ベンダーのサポートを評価せよ。
なぜ専用の時系列データベースが必要か
汎用 RDBMS は時系列ワークロードで以下の4つの理由で限界を迎える。
1. 書き込み増幅
時系列データは 追記主体・高並列・不変——センサ/メトリクスのエントリは更新されず、常に追加される。RDBMS の B-Tree インデックスは INSERT のたびにツリーノードの再平衡化、WAL＋データファイル＋インデックスページの書き込みを行い、毎秒数十万ポイントで IOPS が飽和する。TSDB エンジンは LSM-Tree、TSM（Time-Structured Merge Tree）、または列型追記を用い、ランダム I/O をシーケンシャル I/O に変換する。
2. 時間分割の不可欠性
分析クエリはほぼ常に「直近 N 時間/N 日」を対象とする。時間分割がないと、全件スキャンとなる。TSDB のストレージエンジンはデータを時間チャンク/セグメント/シャードでネイティブに管理し、クエリは無関係な時間範囲を完全にスキップできる。
3. 自動ダウンサンプリングと保持ポリシー
ミリ秒精度を永遠に保持する必要はない。TSDB は Continuous Query（CQ）や Retention Policy（RP）を内蔵し、生データを分/時間粒度に自動集約した後、元データを削除する——cron ジョブなしでストレージコストを大幅に削減できる。
4. 専用圧縮アルゴリズム
タイムスタンプは単調増加——delta-of-delta 符号化がこれを利用する。隣接するセンサ値は極めて類似——XOR/Gorilla 圧縮がこれを利用する。汎用 DB では同等の圧縮率を達成できず、同じデータセットでテラバイト級の差が生じる。
5つのエンジン詳細プロファイル
InfluxDB 3（IOx）
InfluxData は 2023 年に自社開発の TSM エンジンを廃止し、Apache DataFusion 基盤の IOx へ移行した。IOx は 列型ストレージ（Apache Parquet） を用い、S3/MinIO 互換オブジェクトストレージに直接書き込む。
アーキテクチャ：
- Ingester：書き込みをメモリ（WAL）にバッファ、パーティション単位で Parquet ファイルとしてフラッシュ。
- Querier：DataFusion によるベクトル化クエリ（SIMD＋列スキャン）、SQL と InfluxQL に対応。
- Compactor：バックグラウンドで小さな Parquet ファイルをマージし、カタログを更新。
強み：
- ストレージとコンピュートを分離。取り込みノードとクエリノードを独立してスケール可能。
- データはネイティブにオブジェクトストレージ上——S3 Standard 約 $0.023/GB/月。
- Arrow Flight SQL がサブミリ秒のバッチクエリを提供。
弱み：
- v2 からの大幅なエコシステム変更。移行は完全にスムーズではない。
- コミュニティ版では機能が制限される（クラスタ管理は商用）。
最適な用途：「取り込み → オブジェクトストレージ → アドホック分析」パイプラインを必要とし、SQL分析要件が強いチーム。
TimescaleDB
PostgreSQL 拡張。中核の抽象である hypertable が、時間（または独自の次元）で自動分割する。各分割は標準の PostgreSQL テーブル（chunk）であり、全インデックス種別（B-Tree, GIN, GiST, BRIN）に対応。
アーキテクチャ：
- 書込はアクティブ chunk へルーティング。古い chunk は自動圧縮。
- 圧縮：chunk 内の行データを列配列に変換。Gorilla、delta-delta アルゴリズムを適用。圧縮率 10–20× が一般的。
- Continuous Aggregate：時間窓で自動更新されるマテリアライズドビュー。クエリは事前集計結果に直接ヒット。
強み：
- PostgreSQL の全 SQL：CTE、ウィンドウ関数、LATERAL JOIN、JSONB/GIS——すべて利用可能。
- BI ツール（Metabase, Grafana, Tableau）と標準 PostgreSQL プロトコルでネイティブ接続。
- コミュニティ版（Apache-2）は充実。圧縮と継続的集計は無料。
弱み：
- 書込経路は PostgreSQL の WAL 機構に依存。単一ノードの書込スループットは純列型に劣る。
- 水平スケールはマルチノードが必要で、TimescaleDB のマルチノードは商用機能。
最適な用途：PostgreSQL 運用経験があり、「リレーショナル＋時系列」混在クエリが必要で、新しいクエリ言語を学びたくないチーム。
VictoriaMetrics
元 ClickHouse エンジニアが開発。設計哲学は 「シンプル・高性能・低コスト」。単一バイナリ——ダウンロードして起動し、すぐにサービス提供。
アーキテクチャ：
- 書込：まずメモリバッファ、毎秒 LSM（Log-Structured Merge）構造としてディスクへフラッシュ。
- ストレージ：ClickHouse 類似の MergeTree 変種。日付分割、各分割内はメトリクス名＋ラベルでソート。
- クエリ：MetricsQL（PromQL スーパーセット）が rollup, transform, join に対応。Graphite API 互換レイヤも提供。
強み：
- 卓越した単一ノード効率：公式ベンチマークで同等リソース時、InfluxDB 比 7× 書込スループット、Prometheus 比 20× 圧縮。
- 極めて低いメモリ使用量——数百万アクティブ series でも数 GB 以内。
- vmagent は Prometheus スクレイパーをメモリ 1/10 で代替可能。
弱み：
- SQL は第一級市民ではない（実験的サポートはあるが不完全）。
- クラスタモード（vmcluster）は運用負荷が増加。ドキュメントは主に英語/ロシア語。
最適な用途：高カーディナリティ監視（Kubernetes, マイクロサービス）、予算が限られ高スループットが必要なチーム。
TDengine
涛思数据（TAOS Data）が開発した中国発の時系列データベース。中核理念は 「1 デバイス 1 テーブル」 と スーパーテーブル（STable）。
アーキテクチャ：
- スーパーテーブル：デバイスクラスのスキーマテンプレート。各物理デバイスに子テーブルを作成し、STable スキーマを継承。
- 書込：各 vnode（仮想計算ノード）が子テーブルの一部を担当。デバイス単位で分割されるため、書込は自然にロックフリー。
- クエリ：SQL 類似構文。集約クエリは各 vnode でローカル実行され、mnode が結果をマージ——顕著なプッシュダウン最適化。
強み：
- デバイスレベルの書込性能は極めて高い：公式公称 単一ノード 30M+ ポイント/秒。
- ウィンドウ関数、補間、ダウンサンプリング が第一級機能。
- キャッシュ、ストリーム処理、データサブスクリプションを内蔵——IoT エンドツーエンドパイプラインに最適。
弱み：
- SQL 構文が標準 PostgreSQL と異なる（
INTERVALの意味等）、BI ツール連携に摩擦。 - コミュニティ版は AGPL ライセンス。商用利用ではコンプライアンスに注意。
最適な用途：大規模 IoT デバイス群（数万〜数百万台）、製造業/エネルギー産業。
Prometheus
CNCF 卒業プロジェクト。クラウドネイティブ監視のデファクトスタンダード。中核はローカル TSDB＋サービスディスカバリ＋アラート。
アーキテクチャ：
- TSDB：2 時間ごとに新ブロックを作成。各ブロックは chunks（サンプルデータ）＋ index（ラベルインデックス）＋ meta（メタデータ）。
- WAL：書込は先に先行書き込みログへ——クラッシュ時のデータ損失を防止。
- Remote Write：他の TSDB（VictoriaMetrics, Cortex, Thanos）へデータをストリーミングし、長期保存。
強み：
- PromQL は簡潔かつ強力——
rate(),histogram_quantile()等がそのまま使える。 - Kubernetes との深い統合：Prometheus Operator, ServiceMonitor, AlertManager。
- フェデレーション＋Thanos/Cortex でグローバル集計が可能。
弱み：
- ローカル TSDB は長期保持向けではない（デフォルト 15 日）。
- ローカルストレージは高可用ではない——remote-write または Thanos が必須。
- 高カーディナリティでメモリ/ディスクに負荷（新しいラベル組合せごとに新 series 生成）。
最適な用途：Kubernetes/クラウドネイティブ環境の中核メトリクス監視。長期保存とクロスクラスタクエリは下流に任せる。
書き込み性能ベンチマーク
| エンジン | 単一ノード書込速度（pts/s） | 書込増幅 | 対応プロトコル |
|---|---|---|---|
| InfluxDB 3 | ~1.2M（batch 10k） | 中（Parquet 圧縮） | Line Protocol, OTLP |
| TimescaleDB | ~300k（batch 5k） | 高（WAL+B-Tree） | PostgreSQL Wire |
| VictoriaMetrics | ~1.8M（batch 5k） | 極低（LSM 順次追記） | Prometheus RW, InfluxDB Line, Graphite, OTLP |
| TDengine | ~3M+（デバイス分割） | 低（デバイス単位隔離） | SQL-like, RESTful, OTLP |
| Prometheus | ~100k（単一 scrape） | 中（ブロック圧縮） | Prometheus RW, OTLP |
テスト条件：8コア、32 GB RAM、SSD。書込はバッチモード、1ポイント 8 フィールド。実際の結果はラベルカーディナリティとバッチサイズにより変動。
クエリパターン比較
| エンジン | クエリ言語 | ダウンサンプリング | テーブル間 JOIN | 可視化 |
|---|---|---|---|---|
| InfluxDB 3 | SQL + InfluxQL | ✅（SQL） | ❌ | Grafana, Tableau |
| TimescaleDB | PostgreSQL SQL | ✅（Continuous Agg） | ✅（ネイティブ JOIN） | Grafana, Metabase, BI |
| VictoriaMetrics | MetricsQL / PromQL | ✅（rollup） | 限定的（join()） |
Grafana |
| TDengine | SQL-like + ウィンドウ | ✅（INTERVAL） | 限定的（STable JOIN） | Grafana, 独自ダッシュボード |
| Prometheus | PromQL | ✅（rate()/avg_over_time()） |
❌ | Grafana |
センサ値とデバイスメタデータを JOIN する必要がある場合——例えば「過去 1 時間に温度が 80°C を超え、かつファームウェアバージョンが 3.2 未満のコンプレッサーを一覧」——TimescaleDB だけが 1 つの SQL でこれを実現できる。
高カーディナリティ：真の試練
高カーディナリティは「デモでは動く」と「本番で耐える」を分ける。
なぜ問題か
各ラベル組合せ（例：{app="checkout", region="us-east", pod="xxx-1234"}）は TSDB 内で独立したタイムシリーズを生成する。Kubernetes クラスタに 10,000 Pod × 30 指標 = 数百万 series になり得る。
- インデックス膨張：各 series は逆引きインデックス検索を必要とし、巨大なメモリコスト。
- 書込競合：新 series のインデックスエントリにはロックまたはアトミック更新が必要。
- クエリのファンアウト：ラベルフィルタなしの
sum(rate(metric{}[5m]))は全 series を走査。
各エンジンの対応
| エンジン | 高カーディナリティ戦略 | 100万 series での安定性 |
|---|---|---|
| VictoriaMetrics | ラベル値圧縮＋LSM マージ | ✅ 業界トップクラス |
| InfluxDB 3 | 列型＋パーティションプルーニング | ✅ 良好 |
| TDengine | デバイス単位分割（series 数＝デバイス数） | ✅ 良好（デバイス次元に制限） |
| TimescaleDB | PostgreSQL インデックス機構＋圧縮オーバーレイ | ⚠️ 慎重なインデックス設計が必要 |
| Prometheus | TSDB 逆引きインデックス | ⚠️ 単一ノード上限約 10M series |
年間コスト試算
単一 8c32g ノード、10 TB ストレージの概算（2026 年価格参考）：
| エンジン | 計算コスト（月） | ストレージコスト（月） | 運用負荷 | 年間合計 |
|---|---|---|---|---|
| InfluxDB 3 | ~$210 | ~$35（S3 オブジェクトストレージ） | 中 | ~$2,940 |
| TimescaleDB | ~$170 | ~$110（ブロックストレージ） | 中低 | ~$3,360 |
| VictoriaMetrics | ~$140 | ~$55 | 低（単一バイナリ） | ~$2,340 |
| TDengine | ~$170 | ~$70 | 低 | ~$2,880 |
| Prometheus（ローカルのみ） | ~$110 | ~$85 | 中 | ~$2,340 |
移行コスト
- InfluxDB v1/v2 → v3：一部 InfluxQL 構文が非推奨。SQL への移行が必要。Line Protocol 書込は不変——データパイプラインの変更は最小限。
- Prometheus → VictoriaMetrics：Prometheus 設定に
remote_writeURL を 1 行追加するだけ。スクレイプ設定はそのまま。PromQL/MetricsQL クエリ移行はほぼ 1:1。 - 任意 → TimescaleDB：最大の課題は非 SQL クエリロジックを標準 SQL＋TimescaleDB hyperfunction に書き換えること。データインポートは CSV、pg_dump、Kafka Connect 経由。
加重意思決定フレームワーク
チームの優先順位に応じて重み付けせよ：
| 次元 | 重み (1–5) | InfluxDB 3 | TimescaleDB | VictoriaMetrics | TDengine | Prometheus |
|---|---|---|---|---|---|---|
| SQL 要件 | 4 | 5 | 2 | 3 | 1 | |
| 書込スループット | 4 | 3 | 5 | 5 | 2 | |
| クエリ柔軟性 | 4 | 5 | 3 | 3 | 3 | |
| 高カーディナリティ | 4 | 3 | 5 | 3 | 2 | |
| 運用の簡素さ | 3 | 3 | 5 | 4 | 3 | |
| コスト | 4 | 3 | 5 | 4 | 4 | |
| エコシステム統合 | 4 | 5 | 4 | 2 | 5 |
スコア 1–5。相対的な位置づけであり、自前のベンチマークで検証すべき。
実践的デプロイパターン
- IoT ベンダー：TDengine を主ストレージに、Grafana を RESTful インタフェースで接続。
- SaaS / 監視プラットフォーム：Prometheus（スクレイプ）→ VictoriaMetrics（長期保存）、コストパフォーマンスの最適バランス。
- データ分析チーム：TimescaleDB がセンサ時系列＋業務テーブル JOIN を直接処理。BI ツールは PostgreSQL で接続。
- データレイクアーキテクチャ：InfluxDB 3＋オブジェクトストレージ。生時系列データを Parquet として保存し、Spark/Trino で分析。
よくある質問（FAQ）
Q1：MySQL/PostgreSQL に時刻インデックスを張って直接使えますか？
低ボリューム（1日数万〜数十万ポイント）なら可能。しかし毎秒 1 万ポイントを超えると、B-Tree の書込増幅と autovacuum によるレイテンシ変動が顕在化する。自動ダウンサンプリングがないため、履歴クエリは徐々に遅くなる。
Q2：VictoriaMetrics と ClickHouse の比較は？
ClickHouse は汎用 OLAP エンジン——時系列用途では自力でテーブル設計（ORDER BY＋TTL）が必要。VictoriaMetrics は専用 TSDB——圧縮、ダウンサンプリング、PromQL がそのまま使える。ディメンションテーブルとの JOIN や自由分析が多いなら ClickHouse の方が柔軟。メトリクス監視とアラートが主なら VictoriaMetrics の方が手間が少ない。
Q3：TSDB にオブジェクトストレージは必須ですか？
必須ではない。ローカル SSD の Prometheus で十分なケースもある。ただし 30 日を超える保持が必要なら、オブジェクトストレージのコスト優位性は決定的——S3 Glacier Deep Archive は約 $0.00099/GB/月。
Q4：推奨するアラートスタックは？
- Prometheus＋AlertManager（ネイティブ統合、柔軟なルーティング）。
- VictoriaMetrics＋vmalert（PromQL 互換アラートルール）。
- Grafana Alerting（ビジュアル設定、マルチチャネル通知）。
Q5：時系列圧縮の仕組みは？
核となる 3 つの技術：
- タイムスタンプ delta＋delta-of-delta：前のタイムスタンプとの差分を記録。定期的収集では delta が一定、ddelta が 0——ほぼゼロコスト。
- 値 XOR（Gorilla アルゴリズム）：隣接浮動小数点値を XOR。符号ビット、指数、仮数の先行ゼロと後続ゼロを除去。
- 列型レイアウト：同列の隣接値は同行よりはるかに類似——列圧縮が行圧縮を圧倒。
結論
すべての TSDB を自前のデータ量でテストせよ。10 万 active series のベンチマークと 1,000 万 active series のベンチマークは全く異なる世界だ。10 ノードクラスタで動く構成が 1,000 ノードで崩壊することもある。
実践的な評価フロー：
tsbs（Time Series Benchmark Suite）で実際のデータに類似した負荷を生成。- 各候補エンジンに投入し、書込 p99 レイテンシ、CPU、メモリを記録。
- 最も頻繁に使う 10 クエリを実行し、p50/p99 レイテンシを記録。
- 障害をシミュレーション（プロセス kill、ネットワーク切断）し、回復速度とデータ整合性を検証。