using-timeseries-databases

時系列データベース

メトリクス、IoT センサー、金融ティックデータ、ログなどのタイムスタンプ付きデータを効率的に保存し、クエリを実行します。

データベースの選択

主なユースケースに基づいて選択します。

TimescaleDB - PostgreSQL 拡張機能

• 使用するケース：すでに PostgreSQL を使用していて、SQL と JOIN が必要な場合、またはハイブリッドワークロードの場合
• クエリ：標準 SQL
• スケール：毎秒 100K～1M 件の挿入

InfluxDB - 専用に構築された TSDB

• 使用するケース：DevOps メトリクス、Prometheus との統合、Telegraf エコシステム
• クエリ：InfluxQL または Flux
• スケール：毎秒 500K～1M ポイント

ClickHouse - カラム型分析

• 使用するケース：最速の集計が必要な場合、分析ダッシュボード、ログ分析
• クエリ：SQL
• スケール：毎秒 1M～10M 件の挿入、クエリでは毎秒 100M～1B 行

QuestDB - 高スループットの IoT

• 使用するケース：最高の書き込み性能が必要な場合、金融ティックデータ
• クエリ：SQL + Line Protocol
• スケール：毎秒 4M 件以上の挿入

基本パターン

1. ハイパーテーブル（TimescaleDB）

時間ベースのパーティショニングを自動化します。

CREATE TABLE sensor_data (
  time        TIMESTAMPTZ NOT NULL,
  sensor_id   INTEGER NOT NULL,
  temperature DOUBLE PRECISION,
  humidity    DOUBLE PRECISION
);

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

メリット：

• データの効率的な期限切れ（古いチャンクを削除）
• クエリを並列実行
• 古いチャンクを圧縮（10～20 倍の容量削減）

2. 継続的集計

ダッシュボードのクエリを高速化する、事前計算済みのロールアップです。

-- TimescaleDB: hourly rollup
CREATE MATERIALIZED VIEW sensor_data_hourly
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour,
       sensor_id,
       AVG(temperature) AS avg_temp,
       MAX(temperature) AS max_temp,
       MIN(temperature) AS min_temp
FROM sensor_data
GROUP BY hour, sensor_id;

-- Auto-refresh policy
SELECT add_continuous_aggregate_policy('sensor_data_hourly',
  start_offset => INTERVAL '3 hours',
  end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '1 hour');

クエリ戦略：

• 短期間（直近 1 時間）：生データ
• 中期間（直近 1 日）：1 分単位のロールアップ
• 長期間（直近 1 か月）：1 時間単位のロールアップ
• 非常に長い期間（直近 1 年）：日単位のロールアップ

3. 保持ポリシー

データの期限切れを自動化します。

-- TimescaleDB: delete data older than 90 days
SELECT add_retention_policy('sensor_data', INTERVAL '90 days');

一般的なパターン：

• 生データ：7～90 日
• 時間単位のロールアップ：1～2 年
• 日単位のロールアップ：無期限に保持

4. 可視化のためのダウンサンプリング

LTTB（Largest-Triangle-Three-Buckets）アルゴリズムを使用して、チャート用のポイント数を減らします。

問題：ブラウザーでは 1M ポイントを滑らかに描画できません。 解決策：視覚的な忠実度を保ちながら、500～1000 ポイントにダウンサンプリングします。

-- TimescaleDB toolkit LTTB
SELECT time, value
FROM lttb(
  'SELECT time, temperature FROM sensor_data WHERE sensor_id = 1',
  1000  -- target number of points
);

しきい値：

• 1,000 ポイント未満：ダウンサンプリングなし
• 1,000～10,000 ポイント：LTTB で 1,000 ポイントにする
• 10,000 ポイント以上：LTTB で 500 ポイントにするか、事前集計済みデータを使用

ダッシュボードとの統合

時系列データベースは、リアルタイムダッシュボードの主要なデータソースです。

コンポーネント別のクエリパターン：

コンポーネント	クエリパターン	例
KPI カード	最新の値	SELECT temperature FROM sensors ORDER BY time DESC LIMIT 1
トレンドチャート	時間バケット単位の平均	SELECT time_bucket('5m', time), AVG(cpu) GROUP BY 1
ヒートマップ	複数メトリクスのウィンドウ	SELECT hour, AVG(cpu), AVG(memory) GROUP BY hour
アラート	しきい値チェック	SELECT COUNT(*) WHERE cpu > 80 AND time > NOW() - '5m'

データフロー：

1. メトリクスを取り込む（Prometheus、MQTT、アプリケーションイベント）
2. 継続的集計を設定して時系列 DB に保存する
3. 保持ポリシーを適用する（生データ：30 日、ロールアップ：1 年）
4. クエリレイヤーで最適なポイント数にダウンサンプリングする（LTTB）
5. フロントエンドで Recharts/visx を使って描画する

自動更新間隔：

• 重要なアラート：1～5 秒（WebSocket）
• 運用ダッシュボード：10～30 秒（ポーリング）
• 分析ダッシュボード：1～5 分（キャッシュ）
• 履歴レポート：オンデマンドのみ

データベース固有の詳細

実装ガイドについては、以下を参照してください。

• references/timescaledb.md - セットアップ、チューニング、圧縮
• references/influxdb.md - InfluxQL/Flux、保持ポリシー
• references/clickhouse.md - MergeTree エンジン、クラスタリング
• references/questdb.md - Line Protocol、SIMD 最適化

ダウンサンプリングの実装については、以下を参照してください。

• references/downsampling-strategies.md - LTTB アルゴリズム、集計方法

例：

• examples/metrics-dashboard-backend/ - TimescaleDB + FastAPI
• examples/iot-data-pipeline/ - IoT 向け InfluxDB + Go

スクリプト：

• scripts/setup_hypertable.py - TimescaleDB のハイパーテーブルを作成
• scripts/generate_retention_policy.py - 保持ポリシーを生成

パフォーマンスの最適化

書き込みの最適化

バッチ挿入：

データベース	バッチサイズ	予想スループット
TimescaleDB	1,000-10,000	100K-1M rows/sec
InfluxDB	5,000+	500K-1M points/sec
ClickHouse	10,000-100,000	1M-10M rows/sec
QuestDB	10,000+	4M+ rows/sec

クエリの最適化

ルール 1：まず時間で必ずフィルタリングします（インデックス付き）

-- BAD: Full table scan
SELECT * FROM metrics WHERE metric_name = 'cpu';

-- GOOD: Time index used
SELECT * FROM metrics
WHERE time > NOW() - INTERVAL '1 hour'
  AND metric_name = 'cpu';

ルール 2：ダッシュボードのクエリには継続的集計を使用します

-- BAD: Aggregate 1B rows every dashboard load
SELECT time_bucket('1 hour', time), AVG(cpu)
FROM metrics
WHERE time > NOW() - INTERVAL '30 days'
GROUP BY 1;

-- GOOD: Query pre-computed rollup
SELECT hour, avg_cpu
FROM metrics_hourly
WHERE hour > NOW() - INTERVAL '30 days';

ルール 3：可視化にはダウンサンプリングを使用します

// Request optimal point count
const points = Math.min(1000, chartWidth);
const query = `/api/metrics?start=${start}&end=${end}&points=${points}`;

ユースケース

DevOps の監視 → InfluxDB または TimescaleDB

• Prometheus のメトリクス、アプリケーションのトレース、インフラストラクチャ

IoT センサーデータ → QuestDB または TimescaleDB

• 数百万台のデバイス、高い書き込みスループット

金融ティックデータ → QuestDB または ClickHouse

• 1 ミリ秒未満のクエリ、OHLC 集計

ユーザー分析 → ClickHouse

• イベント追跡、日次アクティブユーザー数、ファネル分析

リアルタイムダッシュボード → 任意の TSDB + 継続的集計

• 事前計算されたロールアップ、WebSocket ストリーミング、LTTB ダウンサンプリング