時系列データベース

タイムスタンプ付きのデータを効率的に保存 / クエリするために最適化されたデータベース

データベースオブザーバビリティ

時系列データベースとは

時系列データベース (Time Series Database, TSDB) は、タイムスタンプ付きのデータ (メトリクス、ログ、IoT センサーデータ) を効率的に保存 / クエリするために最適化されたデータベースである。時間範囲での集計、ダウンサンプリング、データの自動削除に特化している。

RDB との違い

RDB と比べると、データの持ち方と読み書きの前提が次のように異なる。

観点RDB (PostgreSQL)TSDB (Timestream)
データモデルテーブル + 行メトリクス + タイムスタンプ
書き込みランダム追記のみ (Append-Only)
クエリ任意の条件時間範囲 + 集計
更新頻繁ほぼなし (イミュータブル)
圧縮汎用時系列に特化 (高圧縮)
自動削除手動TTL で自動

主要な TSDB

OSS で広く普及している InfluxDB、Kubernetes モニタリングで広く使われる Prometheus、PostgreSQL 拡張の TimescaleDB が代表的。AWS のマネージドサービスとしては Amazon Timestream (for LiveAnalytics) があるが、2026 年 9 月時点で AWS はサポート終了を告知しているため、新規に採用する前に公式の提供状況を確認する必要がある。AWS は同じ告知の中で、類似の機能を持つ代替として Amazon Timestream for InfluxDB を案内している (2026 年 9 月時点)。

Amazon Timestream

Amazon Timestream (for LiveAnalytics) での書き込みと、時間範囲を条件にした集計クエリの形を簡略化して示す。前述のとおりサポート終了が告知されているサービスなので、API の形を把握するための参考例として読む。

// データの書き込み
await timestream.writeRecords({
  DatabaseName: 'metrics',
  TableName: 'cpu',
  Records: [{
    Dimensions: [{ Name: 'host', Value: 'web-1' }],
    MeasureName: 'cpu_usage',
    MeasureValue: '72.5',
    MeasureValueType: 'DOUBLE',
    Time: Date.now().toString(),
    TimeUnit: 'MILLISECONDS',
  }],
});

// クエリ (直近 1 時間の平均 CPU 使用率)
const result = await timestream.query({
  QueryString: `
    SELECT host, AVG(measure_value::double) as avg_cpu
    FROM metrics.cpu
    WHERE time > ago(1h)
    GROUP BY host
  `,
});

AWS リソースのモニタリングは CloudWatch が基本で、SQL で集計したいカスタムメトリクスの分析に Timestream が使われてきた。CloudWatch はメトリクス名と統計でクエリし保持期間は 15 ヶ月 (古いデータは解像度が下がる)、Timestream は SQL ライクなクエリで保持期間を利用者が設定できる。コストは CloudWatch がメトリクス数を基準にした課金、Timestream が書き込み / 保存 / クエリの量に応じた課金で、考え方が異なる。

ユースケース

インフラモニタリング (CPU 使用率、メモリ、ディスク I/O)、アプリケーションメトリクス (レスポンスタイム、エラー率)、IoT (温度、湿度、位置情報)、金融 (株価、為替レート) が代表的な用途。

ダウンサンプリング

古いデータの解像度を下げてストレージを節約する。保持期間ごとに解像度を段階的に落とす設定の一例を示す。

直近 1 時間: 1 秒ごとのデータ
直近 1 日:   1 分ごとの平均
直近 1 ヶ月: 1 時間ごとの平均
直近 1 年:   1 日ごとの平均

実務での判断基準と落とし穴

  • RDB で足りるかを先に判断する。書き込みが追記中心で、主なクエリが時間範囲の集計なら TSDB の効果が大きい。更新や任意条件の結合が多いなら RDB のままの方が扱いやすい。
  • タグ (ディメンション) の組み合わせ数を抑える。ユーザー ID やリクエスト ID のように値が増え続けるものをタグにすると、保存量とクエリ負荷が急増する。
  • 保持期間とダウンサンプリングを設計時に決める。生データを残す期間と粗い集約値を残す期間を先に決め、後から短くしても元の解像度には戻せないことを前提にする。
  • 時刻の基準を揃える。保存は UTC に統一し表示時に変換する。到着が遅れたデータをどこまで過去の時刻で書き込めるかも確認する。
  • マネージドサービスの提供状況を確認する。提供形態やサポート状況は変わることがあるため、採用時点で公式の告知を確認し、データのエクスポート手段を用意しておく。

時系列データベースを扱う関連書籍も多い。

共有:

この記事は役に立ちましたか?

関連用語

関連する記事