時系列データベース入門——ホームサーバー監視から分散AIメトリクスまで、VictoriaMetrics・TimescaleDB・InfluxDBをどう選ぶか

時系列データベース（TSDB）とは何か？ 基本のキと仕組み

「ProxmoxのCPU使用率やvLLMのトークン生成速度を毎秒記録したいんだけど、普通のPostgreSQLやMySQLじゃダメなの？」――監視やAIメトリクス収集を始めるとき、誰もがぶつかるこの疑問こそが、時系列データベース（TSDB）を選ぶ理由の入口です。本記事では、ホームサーバー監視から分散AI基盤のメトリクス収集までを題材に、VictoriaMetrics・TimescaleDB・InfluxDBをどう使い分けるかを解説します。

時系列データの特性がRDBと決定的に違う

CPU使用率・温度・トークン速度（tokens/sec）のような測定値は、時刻をキーとして高頻度で「追記」され続けます。更新や削除はほぼ起こらず、読み取りは「直近1時間の平均」「過去30日の傾向」といった時間範囲の集計が中心。さらにデータは無限に増え続けるため、古いデータを自動削除する保持期間（retention）管理と、ディスクを圧迫しない高圧縮が必須になります。汎用RDBでも原理的には実現できますが、書き込みスループット・ダウンサンプリング・retention自動削除の3点で、TSDBはこの用途だけに最適化された構造を持っています。

監視パイプラインの全体像

TSDBは単体で使うものではなく、定番の監視スタックの一部として機能します。全体像は次の4層です。

1. Exporter層: node_exporter（OSメトリクス）、Proxmox exporter、dcgm-exporter（GPU）、vLLMの/metricsエンドポイントなどが測定値を公開
2. 収集層: Prometheus・vmagent・TelegrafなどがPull/Pushでメトリクスを取得
3. 保存層: TSDB（VictoriaMetrics、TimescaleDB、InfluxDBなど）が長期保存と集計を担当
4. 可視化層: Grafanaがダッシュボードとアラートを提供

主要プレイヤーの地図

2026年時点の主要候補は次の4つです。VictoriaMetricsは単一バイナリで動く軽量・PromQL互換の定番。TimescaleDB（Tiger Dataへブランド移行中）はPostgreSQL拡張としてSQLをそのまま使えるのが強み。InfluxDB 3はParquet＋SQL基盤に刷新され、IoT・Telegrafエコシステムとの親和性が高い。Grafana Mimirは大規模・マルチテナント向けの水平スケール選択肢です。次章でこの4つを詳細に比較します。

4つのTSDBを徹底比較——VictoriaMetrics・TimescaleDB・InfluxDB 3・Mimir の違いは?

まずは4製品を一言でまとめます。

• VictoriaMetrics: Go製・単一バイナリで動く軽量TSDB。PromQL互換のMetricsQLを話し、Prometheusの保存先（remote write）として定番。公式は「Prometheus/InfluxDBと比べ少ないRAM・ストレージで動作する」と主張しています（公式ベンチマーク参照。特定条件・特定バージョンでの測定結果であり、絶対値ではありません）。この低リソース性から、Raspberry Piクラスのマシンでも構成次第で実用になりやすいとされています。
• TimescaleDB（Tiger Data）: PostgreSQL拡張型のTSDB。hypertableによる自動パーティショニング、列指向圧縮（95%超を主張）、継続集計を備え、最大の強みは普通のSQLがそのまま使えること。業務データとメトリクスを1つのDBで分析できます。なお2025〜26年にかけてTiger Dataへのブランド移行が進んでいると報じられています（移行の現状は公式発表を確認してください）。
• InfluxDB 3: Apache Arrow / DataFusion / Parquetを基盤に刷新された新世代エンジン。SQLクエリに対応し、Fluxの後方互換は縮小方向とされています（公式移行ガイド参照）。OSS版の「InfluxDB 3 Core」は単一ノード向けの無償エディションです（公式ドキュメントでは直近データの保持を主用途とし、長期保存には有償エディションやCloudを案内しています。詳細・最新の制限は公式ドキュメントで確認してください）。Telegrafエコシステムとの相性が抜群です。
• Grafana Mimir: Prometheus（およびOpenTelemetry）向けの水平スケール可能な長期保存バックエンド。マルチテナント・HA・オブジェクトストレージ活用が特徴で、チーム横断・大規模監視向け。

比較表

選定フロー

どれを選ぶべきかは、迷ったらこのフローチャートの順で判断すると失敗が少ないです。

flowchart TD
    A[TSDB選定スタート] --> B{PromQL/Prometheus中心?}
    B -- いいえ --> C{SQLで業務データと統合したい?}
    C -- はい --> D[TimescaleDB]
    C -- いいえ --> E{IoT/Telegraf資産がある?}
    E -- はい --> F[InfluxDB 3]
    E -- いいえ --> D
    B -- はい --> G{低リソース・軽運用重視?}
    G -- はい --> H[VictoriaMetrics]
    G -- いいえ --> I{複数チーム・大規模?}
    I -- はい --> J[Grafana Mimir]
    I -- いいえ --> H

ポイントを箇条書きにすると:

• 軽さ重視→VictoriaMetrics: 1バイナリ・低メモリで、ホームラボ（Proxmox/Raspberry Pi）監視の第一候補。
• SQL資産活用→TimescaleDB: PostgreSQLで運用・分析できるのが決め手。メトリクスとリレーショナルデータを同一DB上で結合しやすい代表格。
• IoT/Telegraf→InfluxDB 3: センサーデータ収集エージェントの実績が豊富。ただしバージョン（1.x/2.x/3）間の差異とCore版の保持期間制限は要確認。
• 大規模マルチチーム→Mimir: マルチテナントと水平スケールを備え、大規模環境で有力な選択肢です。ただし容量設計・可用性・認証基盤の前提が揃う環境向きで、分散システムの運用負荷は小さくありません。

出典: VictoriaMetrics公式 / docs.timescale.com / InfluxDB Overview / Grafana Mimir

ホームサーバー監視の実践——Proxmox & Raspberry PiにVictoriaMetricsを導入する手順

ホームラボにVictoriaMetricsが向く理由はシンプルです。単一バイナリで動き、低メモリ・高圧縮であり、Raspberry Pi 5のようなARMマシンでも実績があるからです。ここではDocker ComposeでProxmoxホストとRaspberry Piを監視する最小構成を、4ステップで構築します。

Step 1: VictoriaMetricsの起動

監視サーバー（ここではRPi 5）に docker-compose.yml を用意します。

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics
    volumes:
      - ./vmdata:/storage
    command:
      - -retentionPeriod=1y
      - -httpListenAddr=:8428
    ports:
      - "8428:8428"
    restart: always

-retentionPeriod=1y は保持期間の一例です。実際の値はディスク容量・サンプル数・ラベル基数・バックアップ要件から決め、増えてきたらダウンサンプリングや保持期間の短縮を検討しましょう。

Step 2: vmagentの設定とスクレイプ

vmagentが各ノードのexporterからメトリクスを収集し、VictoriaMetricsへ送信します。

  vmagent:
    image: victoriametrics/vmagent
    volumes:
      - ./vmagent.yml:/etc/vmagent.yml
    command:
      - -promscrape.config=/etc/vmagent.yml
      - -remoteWrite.url=http://victoriametrics:8428/api/v1/write
    restart: always

vmagent.yml には収集先を列挙します。

global:
  scrape_interval: 30s
scrape_configs:
  - job_name: node-rpi
    static_configs:
      - targets: ["192.168.1.10:9100"]
  - job_name: proxmox
    static_configs:
      - targets: ["192.168.1.20:9100"]

Step 3: exporterの設置

各監視対象ノードで node_exporter（CPU・メモリ・ディスク・温度）、Proxmoxホストではコミュニティ製の PVE exporter（prometheus-pve-exporter、PVE APIトークンが必要）を起動し、 vmagentのtargetsに登録します。これでVM/LXCごとのリソース使用量も取得できます。

Step 4: Grafanaでの可視化

Grafanaのデータソースに http://victoriametrics:8428 をPrometheus互換データソースとして登録するだけです。PromQLがそのまま使えるため、公開されているNode Exporter Fullなどのダッシュボードを流用できます。アラートはGrafana Alertingまたはvmalert + Alertmanagerでレイテンシ・ディスク残量などの通知を設定しましょう。

導入チェックリスト

• [ ] retentionPeriodを決めた（まず1年が目安）
• [ ] node_exporter / pve-exporterが各ノードで稼働している
• [ ] vmagentのtargetsに全ノードが登録されている
• [ ] Grafanaデータソース登録とダッシュボード流用が済んでいる
• [ ] ディスク残量・ノードダウンのアラートを設定した

もしPostgreSQLに業務データを集約したいならTimescaleDB、Telegraf資産があるならInfluxDB 3 Coreという対抗構成もありますが、まずはVictoriaMetricsで監視の基盤を作るのがおすすめです。

LLM推論ジョブのメトリクス収集——vLLMのトークン速度とGPU使用率を見える化する

LLMをセルフホストし始めると、次第に気になり始めるのが「いまの推論サーバー、本当に性能が出ているのか?」という問いです。生成速度の体感だけでなく、tokens/sec・初トークンまでの遅延（TTFT）・GPUメモリ使用量・キューの滞留状況を数値として記録し、時系列で追えるようにしておくことで、プロンプト長や同時リクエスト数が変化したときの劣化要因を特定しやすくなります。

vLLMは/metricsを標準で露出する

幸い、代表的な推論エンジンであるvLLMは、Prometheus形式の/metricsエンドポイントを標準で公開しています（公式ドキュメントのObservability/Metrics参照。系列名はバージョンにより変わる場合があるため、実際の出力で確認してください）。つまり特別なエージェントを入れなくても、Prometheusやvmagentからこのエンドポイントをスクレイプするだけで、アプリケーションレイヤーの指標が手に入ります。

一方でGPUそのものの使用率・VRAM・温度を得るには、NVIDIA環境なら DCGM exporter をサイドカーとして立てるのが定番です。GPU利用率やFB（フレームバッファ）使用量などのメトリクスを公開し、スクレイパーから収集します。Raspberry Pi等のCPU推論環境なら、node_exporter＋推論エンジン自身のメトリクスで足りるケースがほとんどです。

構成例と代表的なメトリクス

構成はホームサーバー監視と同じパイプラインで、vLLM → Prometheus/vmagent → VictoriaMetrics → Grafanaという一本道です。分散推論クラスタに育つなら保存先をGrafana Mimirへ差し替えるだけでスケールできます。

ダッシュボードとアラートの設計

Grafanaダッシュボードには「TTFTのパーセンタイル（p50/p95/p99）」「同時実行数とTPOTの相関」「KVキャッシュ使用率とGPUメモリの推移」を並べるのがおすすめです。アラートは「TTFTのp95が平常時の2倍を5分超過」「KVキャッシュ使用率が90%超」あたりを設定しておくと、レイテンシ劣化とVRAM逼迫を実害が出る前に検知できます。

こうして収集したメトリクスこそ時系列DBの主役です。次章では、同じ課題でも規模と前提によって最適なTSDBが変わることを、3つのケーススタディで確認します。

ケーススタディ——同じ課題でも最適解は変わる

ここまでの比較で「どれが優れているか」ではなく「何を優先するか」で選択肢が変わることは見てきました。実際に3つのシナリオで、判断の理由と失敗しがちな選択を具体的に見ていきましょう。

ケース1: Raspberry Pi 1台のホームラボ → VictoriaMetrics単一ノード

Raspberry Pi 5にProxmoxやDockerでサービスを詰め込み、node_exporterのメトリクスを保存したい——これが最も典型的な個人環境です。ここではVictoriaMetricsの単一ノード版が第一候補になります。単一バイナリで動き、公式が「Prometheusと比べ少ないRAM・ストレージ」と主張する（ベンチマーク、条件依存）リソース効率は、メモリ8GB前後の小型マシンで他サービスと同居させるときに有利に働きやすいです。PromQL（MetricsQL）がそのまま使えるため、ネット上のGrafanaダッシュボード資産もそのまま流用可能です。

失敗しがちな選択: InfluxDBの古いチュートリアルを真似て1.xを導入すること。1.xは軽量ですがバージョン体系の混乱（後述のFAQ参照）で将来の移行コストが残ります。また、保存先がローカルSDカード1枚であることを忘れずに、-retentionPeriodで保持期間を絞るか、定期的なバックアップを仕組み化しておきましょう。

ケース2: 業務データとセンサーデータを1つのDBで分析 → TimescaleDB

PostgreSQLで受注データや設備マスタを運用していて、そこにIoTセンサーの測定値も加えて「SQLで結合・集計したい」ケースです。TimescaleDBならCREATE EXTENSION timescaledbの一言で既存PostgreSQLが時系列DBに変わり、hypertableによる自動パーティショニング、continuous aggregatesによる事前集計、保持ポリシーによる自動削除が揃います。 メトリクスと業務データを別システムに分けずに済むのが最大の価値です。

失敗しがちな選択: 監視メトリクスの保存先としてTimescaleDBを選ぶこと。PromQL非対応のため、Prometheusエコシステムのダッシュボードやアラート資産が使えず、結局GrafanaのPostgreSQLデータソースでクエリを自作する羽目になります。「分析したいデータ」ならTimescaleDB、「見守るためのメトリクス」ならVictoriaMetrics、と分割するのが現実的です。

ケース3: 複数ノードのLLM推論クラスタをチーム横断で監視 → Mimirのマルチテナント構成

vLLMを複数ノードで運用し、チーム横断でGPU利用率やトークン速度を共有するケースです。ノード数が増え、閲覧者も複数チームに広がる段階で、単一ノード構成は保存容量・可用性・アクセス管理のすべてで限界が来ます。Grafana MimirはPrometheus互換の長期保存向けTSDBで、水平スケールとマルチテナントが前提の設計です。テナントごとのデータ分離により「推論チームにはGPU指標を、インフラチームにはノード指標を」といった権限制御が可能です。

失敗しがちな選択: 規模がまだ小さい段階でMimirやVictoriaMetricsクラスタ版を選ぶこと。分散構成はコンポーネント数が増え、運用負荷が単一ノード比で桁違いになります。まずVictoriaMetrics単一ノードで始め、保存容量・クエリ遅延・組織的な必要性が揃ってから分散構成へ移行するのが定石です。

3シナリオの比較サマリ

つまり選定の本質は、規模・クエリ言語・運用負荷の3点を自問すること。次章のFAQで残る疑問を潰していきます。

よくある質問（FAQ）

Q: Prometheus単体ではだめなの?

A: 短期監視なら十分です。ただしPrometheus本体はローカルディスク前提で長期保存に向かず、retentionを延ばすとRAM・ストレージ消費が急増します。数か月以上のデータを残したいなら、remote writeでVictoriaMetricsなどの保存先に転送するのが定番です。

Q: InfluxDBのFluxはもう使えないの?

A: Fluxは縮小方向とされています。InfluxDB 3ではArrow/Parquet基盤の新エンジンに移行し、クエリもSQL中心になっています。新規構成ではFlux前提の設計は避けるのが無難です（最新の公式移行ガイドを確認してください）。

Q: TimescaleDBとTiger Dataは別物?

A: 別物ではなくブランド移行です。TimescaleDBはTiger Dataへと名称・提供形態が変わるとされていますが、hypertable・圧縮・継続集計という技術的方向性は続いています（確認日: 2026-09、公式発表参照）。

Q: VictoriaMetricsとMimirはどちらを選べばいい?

A: 目安は規模です。シングルバイナリで済むうちはVictoriaMetricsが圧倒的に楽です。マルチテナント・チーム横断・大規模クラスタが必要になったらGrafana Mimirが本領を発揮します。

Q: Raspberry Piでも動く?

A: 動きます。VictoriaMetricsの単一ノード版は低メモリ設計で、RPiレベルのマシンでもnode_exporterとの組み合わせで実用的に動かしている報告がコミュニティに多く見られます（実際の適合性は収集メトリクス量と保持期間に依存します）。

まとめ——ユースケース別の最終選択基準

選定の本質は「クエリ言語・規模・運用負荷」の3点に集約されます。PromQL資産と低リソース最優先ならVictoriaMetrics、SQLで業務データとメトリクスを統合したいならTimescaleDB、IoT/TelegrafエコシステムならInfluxDB 3、マルチテナントの大規模運用ならMimir——これが基本方針です。

今日から始める3つのアクション:

1. まずVictoriaMetrics単一ノードを1台に入れてみる——バイナリ1つで起動し、Grafana接続まで短時間で体験できます（所要時間は環境依存）。
2. node_exporterを既存サーバーに展開し、remote writeで集約——ProxmoxやRPiのメトリクスをまず可視化します。
3. SQL分析の需要が出たらTimescaleDBを試験導入——既存PostgreSQLに拡張を足すだけなので初期コストが最小です。

迷ったら軽い構成から始め、要件が成長してからスケール先を再考するのが後悔しないコツです。

参考文献

• VictoriaMetrics 公式ドキュメント: https://docs.victoriametrics.com/
• VictoriaMetrics ベンチマーク: https://docs.victoriametrics.com/benchmarks/
• TimescaleDB 公式ドキュメント: https://docs.timescale.com/
• Timescale ブログ（Tiger Data関連発表）: https://www.timescale.com/blog
• InfluxDB 3 公式ドキュメント: https://docs.influxdata.com/influxdb3/
• Grafana Mimir 公式ドキュメント: https://grafana.com/docs/mimir/latest/
• node_exporter: https://github.com/prometheus/node_exporter
• prometheus-pve-exporter: https://github.com/prometheus-pve/prometheus-pve-exporter
• DCGM exporter: https://github.com/NVIDIA/dcgm-exporter
• vLLM Metrics: https://docs.vllm.ai/en/latest/serving/metrics.html

関連記事

• DuckDB 2.0が切り開くデータ基盤の新潮流：QuackプロトコルとDuckLakeが変える「インプロセスOLAP」の未来