時系列DB比較：InfluxDB vs TimescaleDB vs VictoriaMetrics でメトリクスを管理する
オープンソースラボ編集部 ・ 2026年6月14日
時系列DB比較：InfluxDB vs TimescaleDB vs VictoriaMetrics でメトリクスを管理する
IoTセンサーデータ・システムメトリクス・アプリケーションKPI・金融OHLC（株価）など時刻と値のペアで継続的に蓄積するデータを効率的に管理するのが**時系列データベース（TSDB）**です。InfluxDB（OSS・IOxアーキテクチャ）・TimescaleDB（PostgreSQL拡張）・VictoriaMetrics（Prometheus互換・高圧縮）の3つが2026年のTSDBデファクトスタンダードです。
時系列DBを使う理由
- 高インジェスト性能: 毎秒数百万ポイントを効率的に書き込む（PostgreSQL/MySQLより10〜100倍高速）
- 自動データ圧縮: タイムスタンプとデルタ値の圧縮でストレージを90%削減
- データ保持ポリシー: 直近データは高解像度・古いデータは自動ダウンサンプリング（1分→1時間平均）で管理
- Prometheus互換: 既存のPrometheusエコシステム（Grafana・AlertManager）をそのまま活用
主要TSDBの概要
InfluxDB
2013年公開、Go/Rust製のOSSです。GitHubスター29k+。時系列データ特化の代表的なOSS TSDBで、Flux（クエリ言語）・Tasks（定期集計）・Dashboards・Alertingが統合された時系列データプラットフォームです。v3でIOxアーキテクチャ（Apache Arrow・Parquet）に移行してS3ベースの無制限ストレージを実現しました。
# docker-compose.yml: InfluxDB v2 + Grafana
version: "3.8"
services:
influxdb:
image: influxdb:2.7
restart: unless-stopped
ports:
- "8086:8086"
environment:
DOCKER_INFLUXDB_INIT_MODE: setup
DOCKER_INFLUXDB_INIT_USERNAME: admin
DOCKER_INFLUXDB_INIT_PASSWORD: ${INFLUX_PASSWORD}
DOCKER_INFLUXDB_INIT_ORG: myorg
DOCKER_INFLUXDB_INIT_BUCKET: metrics
DOCKER_INFLUXDB_INIT_RETENTION: 30d # 30日後に自動削除
DOCKER_INFLUXDB_INIT_ADMIN_TOKEN: ${INFLUX_TOKEN}
volumes:
- influxdb_data:/var/lib/influxdb2
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
environment:
GF_SECURITY_ADMIN_PASSWORD: admin
volumes:
- grafana_data:/var/lib/grafana
volumes:
influxdb_data:
grafana_data:
# Python: InfluxDB v2 でサーバーメトリクスを収集・分析
from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS
import psutil
import time
from datetime import datetime, timezone
INFLUX_URL = 'http://localhost:8086'
INFLUX_TOKEN = 'your-token'
INFLUX_ORG = 'myorg'
INFLUX_BUCKET = 'metrics'
client = InfluxDBClient(url=INFLUX_URL, token=INFLUX_TOKEN, org=INFLUX_ORG)
write_api = client.write_api(write_options=SYNCHRONOUS)
query_api = client.query_api()
def collect_system_metrics():
'''システムメトリクスを収集してInfluxDBに書き込む'''
cpu_percent = psutil.cpu_percent(interval=1)
mem = psutil.virtual_memory()
disk = psutil.disk_usage('/')
net = psutil.net_io_counters()
points = [
Point('system_metrics')
.tag('host', 'web-server-01')
.tag('region', 'ap-northeast-1')
.field('cpu_usage_percent', cpu_percent)
.field('memory_used_bytes', mem.used)
.field('memory_total_bytes', mem.total)
.field('disk_used_bytes', disk.used)
.field('network_bytes_sent', net.bytes_sent)
.field('network_bytes_recv', net.bytes_recv)
.time(datetime.now(timezone.utc))
]
write_api.write(bucket=INFLUX_BUCKET, record=points)
# Flux クエリ: 過去1時間のCPU使用率を5分間隔で平均化
def query_cpu_trend():
flux_query = '''
from(bucket: "metrics")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "system_metrics")
|> filter(fn: (r) => r._field == "cpu_usage_percent")
|> filter(fn: (r) => r.host == "web-server-01")
|> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
|> yield(name: "cpu_trend")
'''
tables = query_api.query(flux_query)
for table in tables:
for record in table.records:
print(f'{record.get_time()} | CPU: {record.get_value():.1f}%')
# Flux アラート設定（CPU > 80%で通知）
def setup_alert():
tasks_api = client.tasks_api()
flux_task = '''
import "slack"
import "influxdata/influxdb/monitor"
option task = {name: "cpu-alert", every: 1m}
data = from(bucket: "metrics")
|> range(start: -5m)
|> filter(fn: (r) => r._measurement == "system_metrics")
|> filter(fn: (r) => r._field == "cpu_usage_percent")
|> mean()
data
|> filter(fn: (r) => r._value > 80.0)
|> slack.message(
url: "https://hooks.slack.com/services/YOUR/WEBHOOK",
text: "CPU使用率が80%を超えました: " + string(v: r._value) + "%",
color: "danger"
)
'''
tasks_api.create_task_by_flux(flux_task)
# メトリクス収集ループ
while True:
collect_system_metrics()
time.sleep(10) # 10秒ごとに収集
TimescaleDB
2017年公開、C製のOSSです。GitHubスター18k+。PostgreSQL拡張として動作する時系列DBで、既存のPostgreSQLエコシステム（psql・pgAdmin・標準SQL・Prisma・SQLAlchemy）をそのまま使いつつ時系列最適化（ハイパーテーブル・チャンク分割・圧縮・継続的集計）を追加します。
-- TimescaleDB: PostgreSQLに拡張として追加
CREATE EXTENSION IF NOT EXISTS timescaledb;
-- ハイパーテーブル作成（自動チャンク分割）
CREATE TABLE sensor_data (
time TIMESTAMPTZ NOT NULL,
device_id TEXT NOT NULL,
temperature DOUBLE PRECISION,
humidity DOUBLE PRECISION,
pressure DOUBLE PRECISION
);
-- ハイパーテーブルに変換（7日ごとにチャンク分割）
SELECT create_hypertable('sensor_data', 'time', chunk_time_interval => INTERVAL '7 days');
-- 圧縮ポリシー設定（7日経過データを自動圧縮）
ALTER TABLE sensor_data SET (timescaledb.compress, timescaledb.compress_segmentby = 'device_id');
SELECT add_compression_policy('sensor_data', INTERVAL '7 days');
-- 継続的集計（1時間平均を自動計算）
CREATE MATERIALIZED VIEW sensor_hourly_avg
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
device_id,
AVG(temperature) AS avg_temp,
AVG(humidity) AS avg_humidity,
MAX(temperature) AS max_temp
FROM sensor_data
GROUP BY hour, device_id
WITH NO DATA;
-- 自動更新ポリシー（30分ごとに更新）
SELECT add_continuous_aggregate_policy('sensor_hourly_avg',
start_offset => INTERVAL '3 hours',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '30 minutes');
-- データ保持ポリシー（90日以上のデータを自動削除）
SELECT add_retention_policy('sensor_data', INTERVAL '90 days');
-- 時系列クエリ（標準SQL）
SELECT time_bucket('15 minutes', time) AS bucket,
device_id,
AVG(temperature) AS avg_temp
FROM sensor_data
WHERE time > NOW() - INTERVAL '24 hours'
GROUP BY bucket, device_id
ORDER BY bucket DESC;
VictoriaMetrics
2019年公開、Go製のOSSです。GitHubスター13k+。Prometheus互換の超高速・高圧縮な時系列DBで、PrometheusのRemote Write APIとPromQLをサポートするためPrometheusのドロップイン代替として使えます。Prometheusの5〜10倍のスループット・同等データを10倍の圧縮率で格納します。
# docker-compose.yml: VictoriaMetrics + Grafana + vmagent
version: "3.8"
services:
victoriametrics:
image: victoriametrics/victoria-metrics:v1.106.0
restart: unless-stopped
ports:
- "8428:8428"
command:
- '--storageDataPath=/storage'
- '--retentionPeriod=6' # 6ヶ月保持
- '--httpListenAddr=:8428'
volumes:
- vm_data:/storage
vmagent:
image: victoriametrics/vmagent:v1.106.0
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
- '--promscrape.config=/etc/prometheus/prometheus.yml'
- '--remoteWrite.url=http://victoriametrics:8428/api/v1/write'
volumes:
vm_data:
機能比較表
| 比較項目 | InfluxDB | TimescaleDB | VictoriaMetrics |
|---|---|---|---|
| バックエンド | 専用IOx | PostgreSQL拡張 | 専用Go |
| 標準SQL | ❌（Flux/SQL） | ✅ | △（PromQL） |
| Prometheus互換 | △ | △ | ✅ 完全 |
| 圧縮率 | 高 | 高 | ✅ 最高 |
| セットアップ | 中 | ✅ 容易 | ✅ 容易 |
時系列DBはDevOpsカテゴリ/categories/devopsのPrometheus・Grafana・AlertManagerと組み合わせてインフラ監視スタックの中核を担います。LLM Toolsカテゴリ/categories/llm-toolsのClaude API使用量（コスト・レイテンシ・エラー率）をInfluxDBまたはVictoriaMetricsで収集してGrafanaダッシュボードで可視化するAI API監視パターンが普及しています。
FAQ
Q. InfluxDBとTimescaleDBの選択基準は？
A. 時系列専用機能・IoT高インジェストならInfluxDB、既存PostgreSQL環境・標準SQL・ORM対応ならTimescaleDBが向いています。TimescaleDB優位: ①既にPostgreSQLを使っているプロジェクトはCREATE EXTENSIONだけで時系列最適化が追加②SQLAlchemy・Prisma・DjangoなどのORMがそのまま動作③JOINでユーザーテーブル等とデータを結合できる（InfluxDBは他DBとのJOIN不可）。InfluxDB優位: ①Flux言語でウィンドウ関数・ダウンサンプリング・アラートをパイプラインとして定義②Tasks機能で定期集計をサーバーサイドで実行③IoT向けのmultilineプロトコル（Line Protocol）でシンプルなデータ投入。
Q. VictoriaMetricsをPrometheusの代替として導入するには？
A. prometheus.ymlにremote_writeを追加するだけでVictoriaMetricsへのデータ転送が開始されます。段階的移行: ①既存のPrometheusを残しながらremote_write: - url: "http://vm:8428/api/v1/write"を設定②VictoriaMetricsに全データが複製される③Grafanaのデータソースを追加でVictoriaMetrics（Prometheusタイプ・URLを指定）を追加④既存のPrometheus PromQLダッシュボードがVictoriaMetricsでもほぼそのまま動作⑤Prometheusの保持期間を短縮してVictoriaMetricsを長期保存メインに。長期保存コスト: VictoriaMetricsはPrometheusより5〜10倍高い圧縮率でデータ量・コストを大幅削減します。
Q. TimescaleDBの継続的集計（Continuous Aggregate）とは何ですか？
A. 定義したSQLクエリを自動的に計算してマテリアライズドビューとして最新状態に保つ機能です。通常のマテリアライズドビューとの違い: 通常はREFRESH MATERIALIZED VIEWを手動実行するのに対し、Continuous Aggregateはポリシーで指定したスケジュール（例: 30分ごと）で自動更新されます。差分更新: 全データを再計算するのではなく追加・変更されたチャンクのみを再計算するため更新が高速。活用例: ①1秒単位の生データ→1分・1時間・1日の平均値を継続的集計で自動生成②クエリ時はマテリアライズドビューを参照するため集計クエリが高速（生データのSCANなし）③real_agg = OFF設定でリアルタイムデータも合わせて返す完全リアルタイム集計が可能。
Q. InfluxDBのLine Protocolでデータを高速に投入するには？
A. Line Protocol（テキスト形式）のバッチHTTP POSTが最高スループットを出します。Line Protocol形式: measurement,tag1=val1,tag2=val2 field1=1.0,field2=2.5 timestamp_nanoseconds。バッチ投入（Python）: write_api.write(bucket='metrics', record=[Point(...), Point(...), ...], write_precision=WritePrecision.NANOSECOND)。最大スループット: ①バッチサイズ5000〜10000ポイントを1リクエストで送信②write_options=WriteOptions(batch_size=5000, flush_interval=1000)の非同期Writerを使用③InfluxDB v3（IOx）はApache Arrowベースで書き込みスループットがv2比3〜5倍向上。IoT接続: MQTT Broker（Mosquitto）→Telegraf（MQTTインプットプラグイン）→InfluxDBの構成でIoTデバイスのセンサーデータを自動収集できます。
まとめ
| ユースケース | 推奨ツール |
|---|---|
| IoT・高インジェスト・Flux・ダッシュボード統合 | InfluxDB |
| PostgreSQL既存環境・標準SQL・ORM対応 | TimescaleDB |
| Prometheus代替・高圧縮・PromQL・大規模 | VictoriaMetrics |