TimescaleDB の圧縮：仕組み、設定、パフォーマンス向上ガイド

TimescaleDB は時系列データを最大 98% 圧縮する独自の技術を持っています。本稿では、その仕組み、設定方法、そして PostgreSQL 標準機能との違いを整理します。

1. TimescaleDB の圧縮 vs. PostgreSQL TOAST

PostgreSQL に内蔵されている

TOAST

基本の違い

TOAST_TUPLE_THRESHOLD

text

jsonb

bytea

numeric

圧縮比率の比較（推定）

注意: TOAST は浮動小数点や固定長整数には効きません。IoT ワークロードなどで TOAST が使えない場合、TimescaleDB は 10-100 倍の圧縮を実現します。

2. Hypercore エンジンとカラム指向ストレージ

TimescaleDB は新しいデータが高速な「行指向」形式で蓄積される一方、古いデータは自動的にカラム指向に変換されます。これを

hypercore

ハイブリッド動作のメリット

• 高速な INSERT/UPDATE: 新規データは行指向で保存され、OLTP に最適化されています。
• 高速な分析クエリ: 古いデータ（チャンク）はカラム指向圧縮形式に変換され、読み取り I/O を最小化します。

行からの変換プロセス

圧縮処理では、行を最大 1000 行ずつのバッチにグループ化し、各バッチを圧縮された単一のエントリとして保存します。

【カラム指向バッチの特徴】

• 配列化: カラムごとに最大 1000 個の値を持つ配列として格納されます（例：

  temperature[1000]

  ）。
• カラムマジョリティ: 同一列の値を連続して配置するため、特定の列のみを参照する際のスキャンが高速化します。
• 高度なアルゴリズム適用: デルタ符号化やランレングス符号化 (RLE) を列レベルで適用し、I/O コストを削減します。

3. 主要な圧縮アルゴリズムの仕組み

TimescaleDB は各データ型の特性に応じて最適なアルゴリズムを選択します。代表的な手法は以下の通りです。

① デルタ符号化 (Delta Encoding)

値の変化分（Delta）のみを保存し、絶対値を削減します。

• 原理: 前の値からの差分 (

  +0.2

  ,

  -0.1

  ) を保存する。
• 適用対象: 浮動小数点データ（温度、圧力など）、数値が変動する場合。

② デルタ・オブ・デルタ符号化 (Delta-of-Delta Encoding)

時間間隔が規則的な場合、変化分の差分をさらに圧縮します。

• 原理: 「+5 秒」の変化が続く場合は

  +0 秒

  と表せるため、データ量が急減します。
• 適用対象: タイムスタンプ、定期的なサンプリングデータ。

③ ランレングス符号化 (Run-Length Encoding, RLE)

重複する値を「値」×「回数」として保存します。

• 原理:

  MACHINE_001

  が 5 回続く場合、文字列を 5 回書く代わりに

  MACHINE_001 × 5

  と保存します。
• 適用対象: デバイス ID (

  machine_id

  )、センサー種別 (

  sensor_type

  ) などの重複が多いカラム。

圧縮技術サマリー

12:00:00

+5s

0

0

MACHINE_001 × 5

temp × 5

72.5

+0.2

-0.3

重要: アルゴリズムは万能ではありません。高エントロピー（一意な値が多い）なカラム（例：UUID）では辞書圧縮が効果的ですが、逆に単純に不変なデータであっても適切な手法が選ばないと圧縮効率は下がります。TimescaleDB は自動的に最適な組み合わせを選定します。

4. 重要な設定パラメータ

圧縮機能の有効化には、以下の 2 つのパラメータを適切に設定することが不可欠です。これらは**「チャンクの分割基準」と「ソート順」**を決めるためです。

パラメータ定義

1. segmentby

   : チャンク全体で値が共有されるカラム（例：

   machine_id

   ）。
   • 同じ

     segmentby

     値を持つ行は物理的に近接して保存されます。
   • プランナーはこの情報を使って、対象外のチャンクをスキップします（全走査回避）。

2. orderby

   : チャンク内のソート順序（通常は

   time DESC

   ）。
   • データを時間順に並べることで、デルタ符号化や RLE の効用を最大化します。

SQL 設定例

ALTER TABLE iot_sensor_data SET (
  timescaledb.compress = true,
  timescaledb.segmentby = 'machine_id', -- 分割基準カラム
  timescaledb.orderby   = 'time DESC'   -- ソート順（過去からのソート推奨）
);

-- 7 日以上経過したデータを自動的に圧縮するポリシー適用
SELECT add_columnstore_policy(
    'iot_sensor_data', 
    after => INTERVAL '7 days'
);

設定時のルール（基数制約）

アルゴリズムが機能するためには、圧縮対象のチャンク内で十分な「類似した値」が必要です。

• 推奨範囲: チャンクごとに

  segmentby

  のユニーク値数が 100 - 10,000 程度あること。
• 最低ライン: セグメント（バッチ）あたりの行数が 100 行以上。
• 注意点: センサー数（基数）が高すぎると、各センサーのデータ量が少なくなりすぎるため圧縮効率が落ちます。

5. パフォーマンスへの影響

「圧縮はクエリを遅くするか？」という疑問に対して、答えは状況によって異なります。

✅ 高速化するケース（ワークロードの過半数）

• 集計処理: 時間範囲内の

  SUM

  ,

  AVG

  ,

  MAX

  など。
• 範囲スキャン: 大規模な日付範囲検索。
• フィルタ済みクエリ:

  segmentby

  カラム（例：特定の ID）で絞る場合。

理由: I/O コストが 10-20 倍削減されるため、ディスク読み込みとメモリ使用量が大幅に減少します。

例: 圧縮前の 1 GB データ読み取り vs. 圧縮後の 50 MB 読み取り = 圧倒的に高速。

⚠️ 低速化するケース（時系列では稀）

• 単一行ポインタルックアップ:

  time = '...' AND id = X

  のような極めて限定された検索。
• 更新・削除操作 (UPDATE/DELETE): デコンプレッション → 変更 → リコンプレッションという処理コストがかかります。
• 高基数フィルタなし:

  segmentby

  カラムを指定しない場合の全テーブルスキャン。

6. 実際のデータベースへの設定と検証

以下は IoT センサー監視システムへの適用例です。

① 自動圧縮の設定

-- 7 日以上前のデータを自動的にカラムストレージに変換するポリシー
SELECT add_columnstore_policy(
    'iot_sensor_data', 
    after => INTERVAL '7 days'
);

-- チャンクの詳細確認（圧縮状態の確認）
SELECT chunk_name, is_compressed, range_start,
       pg_size_pretty(total_bytes) AS size
FROM chunks_detailed_size('iot_sensor_data')
WHERE timescaledb_hypertable = true 
  AND is_compressed = true;

② 圧縮による高速化の実績（例）

ある MQTT データセットでの比較結果（Rowstore vs Columnstore）：

• 理由:

  segmentby

  に基づくメタデータインデックスにより、対象チャンクのみを読み取ることが可能になりました。

③ クエリプラン分析 (

EXPLAIN ANALYZE

)

圧縮されたチャンク（Columnstore）では、B-tree インデックスの代わりに、TimescaleDB が自動生成した

(segmentby_col, min_val, max_val)

7. 適用前のチェックリスト

設定を行う前に、現在のデータ分布を確認することをお勧めします。

segmentby

の適性確認方法

-- チャンク内の各行の行数分布を確認
WITH per_id AS (
    SELECT id, count(*) AS n
    FROM _timescaledb_internal._hyper_X_Y_chunk -- 実際のチャンク名を指定してください
    GROUP BY id
)
SELECT 
    SUM(count) FILTER (WHERE n < 100)  AS low_volume_count,
    SUM(count) FILTER (WHERE n >= 100) AS high_volume_count
FROM per_id;

• 結果:

  low_volume_count

  が非常に多い場合（例：ID ごとの行数が 100 未満）、現在の

  segmentby

  設定では圧縮効率が下がる可能性があります。

まとめ

TimescaleDB の圧縮機能は、単なるサイズ削減だけでなく、時系列データの分析クエリを劇的に高速化させる技術です。

• 仕組み: 古いデータは自動的にカラム指向のハイブリッド形式（

  hypercore

  ）へ変換され、10-100 倍の圧縮を実現します。
• 設定の鍵:

  timescaledb.segmentby

  と

  timescaledb.orderby

  を正しく設定し、データ分布がアルゴリズムに適した範囲にあるか確認してください。
• 効果: IoT や生産性モニタリングなどで長期間データを保持する際、ストレージコストとクエリ速度の両面で優れています。

具体的な導入設計やアーキテクチャサポートが必要な場合は、お気軽にご相談ください。