📣新登場！TiDB Cloud BYOC、TiDB Cloud Filesystem、PostgreSQL-compatible TiDB Cloud Starter がパブリックプレビュー中。このページは自動翻訳されたものです。原文はこちらからご覧ください。

階層型ストレージの概要

階層型ストレージを使用すると、アクセス頻度の低いテーブルまたはパーティションのデータを、SQL のセマンティクスを変えずに、より低コストなストレージ階層へ移動できます。このページでは、Infrequent Access (IA) ストレージを使用するかどうかを判断できるように、アーキテクチャ、トレードオフ、適用シナリオのガイドラインを説明します。

ノート

階層型ストレージは、TiDB Cloud Premium と TiDB Cloud BYOC 向けに プライベートプレビュー として提供されており、デフォルトでは無効です。使用するには、TiDB Cloudサポートに連絡して、インスタンスで有効化してもらう必要があります。このページで説明する動作は、現在のプレビュー実装に基づいており、一般提供 (GA) 前に変更される可能性があります。

はじめに

階層型ストレージは、TiDB Cloud Premium と TiDB Cloud BYOC で利用できる、テーブルレベルおよびパーティションレベルのストレージ階層化機能です。アクセス頻度の低いデータ向けに設計されています。テーブルまたはパーティションを Infrequent Access (IA) ストレージクラスに割り当てることができます。システムは完全なデータセットをリモートオブジェクトストレージ（Amazon S3 や Alibaba Cloud OSS など）に保存し、ローカルストレージにはメタデータと、必要に応じてキャッシュされるホットデータセグメントのみを保持します。

アプリケーションの観点では、IA テーブルは Standard テーブルと同様に動作します。すべてのクエリ、トランザクション、バックアップ、リカバリのセマンティクスは変わりません。主な違いはコストと性能のトレードオフにあります。ローカルストレージの使用量は大幅に削減されますが、コールドリード（必要なデータがローカルキャッシュにない場合）は、まずリモートオブジェクトストレージからデータを取得する必要があるため、レイテンシーが高くなります。

主な機能:

透過的なセマンティクス: SELECT、INSERT、UPDATE、DELETE を含むすべての SQL 操作は、Standard テーブルと同じように動作します。
低いストレージコスト: データは低コストなオブジェクトストレージに保存され、ホットデータのみがローカルにキャッシュされます。一般的なシナリオでは、ストレージコストを約 50% 削減できます。実際の削減率は、選択した IA キャッシュレベルによって異なります。詳細は TiDB Cloud課金を参照してください。
きめ細かな制御: テーブルレベルとパーティションレベルの両方のストレージ階層化をサポートします。パーティションレベルの設定はテーブルレベルの設定より優先されます。
柔軟な変換: IA と Standard の各ストレージクラス間で、データ損失なく双方向に変換できます。
シームレスな統合: Raft リージョン、MVCC、BR によるバックアップとリストア、TiCDC、およびその他の TiDB コンポーネントと完全に統合されています。
可観測性と調整可能性: 変換の進行状況、IA 読み取りメトリクス、クラスター全体のキャッシュヒット率は SQL 出力および Cloud Console で確認でき、IA キャッシュレベルも設定可能です。

使用シナリオ

このセクションでは、IA ストレージの推奨シナリオと非推奨シナリオ、および IA を使用するかどうかを判断するためのチェックリストを説明します。

推奨シナリオ

ビジネスシナリオ	データ特性	推奨されるコールド/ホット境界
EC の履歴注文 / 金融トランザクション	書き込みが頻繁、直近データの読み書きが多い、履歴データの変更はまれ	6 か月
会計伝票 / 監査ログ / 請求書	一度書き込んだらほとんど変更されず、7～15 年保持	2 年
アプリケーションログ / 監視メトリクス / API 呼び出し	高スループット書き込み、直近のトラブルシューティングで頻繁に参照	90 日
ソーシャルメディアの投稿 / コメント / 写真メタデータ	初期にピークがあり、その後時間とともに減少	30～90 日
産業用センサー / コネクテッドカー	非常に高い書き込みスループット、直近データのリアルタイム監視	1 年
データウェアハウスの履歴分析	バルク書き込み、更新は少ない、履歴トレンド分析	90 日
AI 対話履歴 / メモリ	セッションベースの書き込み、直近アクセスは高頻度、履歴はユーザープロファイリングに利用	180 日
LLM 学習用データセット	学習中は高頻度、完了後は急激に低下	学習終了 + 30 日
AI 推論ログ / 結果	高並行書き込み、直近監視、履歴最適化	90 日
ベクトルデータベース	更新はまれ、直近クエリは頻繁	30～90 日

一般的な目安: データ量が大きい + 時間とともにアクセス頻度が低下する + 応答時間に厳しい要件のないクエリが時々ある → IA に適しています。

非推奨シナリオ

厳しいレイテンシー要件がある ホット OLTP テーブル（ミリ秒単位の遅延にも敏感な中核となるオンライントランザクションテーブル）
広範囲スキャンを頻繁に必要とするデータセット（大量のコールドデータに継続的にアクセスする AP クエリ）
IA と Standard の間で 頻繁な切り替え が必要なテーブル
アクセスパターンが 非常に分散 しており、局所性がほとんどないデータ
アクセスパターンが「時間とともに減少する」傾向に従わないシナリオ

判断チェックリスト

IA を設定する前に、各項目を確認してください。

実装原理

このセクションでは、階層型ストレージのアーキテクチャ、データストレージ階層、読み取り増幅の分析、および LSM-Tree の書き込みパスについて説明します。

アーキテクチャの概要

階層型ストレージの実装は、TiDB → TiKV → Object Store の 3 層アーキテクチャにまたがります。

┌──────────────────────────────────────────────────────────────────┐
│ TiDB Schema Layer                                                │
│ · STORAGE_CLASS / ENGINE_ATTRIBUTE written to TiDB schema        │
└──────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────┐
│ TiKV Region Management Layer                                     │
│ · IA tables/partitions occupy dedicated regions, avoiding        │
│   hot/cold data in the same shard                                │
└──────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────┐
│ TiKV IA Cache Management Layer (IaManager)                       │
│ · Local cache for cold storage data                              │
└──────────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────────┐
│ Remote Object Storage (S3/OSS)                                   │
│ · Full SST data stored as whole objects, not by segment          │
└──────────────────────────────────────────────────────────────────┘

Raft ChangeSet により一貫性を保証: ストレージクラスの変更は、Raft ChangeSet を介してすべてのレプリカに複製されます。これにより、再起動、リカバリ、分割、マージをまたいでも、関連するすべてのシャードが一貫したストレージクラス状態を維持し、リージョントポロジーの変更によるデータ損失や破損を防ぎます。

ローカルキャッシュとキャッシュレベル

IaManager レイヤーは、各 TiKV ノード上に IA データのローカルキャッシュを保持します。どれだけのデータをキャッシュできるかは IA キャッシュレベルによって決まり、キャッシュ用に予約されたローカルディスク容量が上限となります。

キャッシュレベルはクラスター全体の設定で、Economy、Default、Balanced、Deep の 4 つのオプションがあります。レベルが高いほど、より大きな割合の IA データがキャッシュされ、キャッシュヒット率とコストが上がります。エビクションはシステムによって管理されるため、どのデータをキャッシュに残すかを指定できず、個々のテーブルやパーティションごとに異なるレベルを設定することもできません。キャッシュレベルの変更方法については、階層型ストレージの設定と管理を参照してください。

データストレージ階層

SSTable の内部階層は上から下へ次のとおりです。

SSTable ──→ Segment ──→ Block ──→ KV Pair
(file)      (1 MiB)     (32 KiB)    (single record)

レイヤー	デフォルトサイズ	役割
Segment	1 MiB	TiKV がオブジェクトストレージから読み取り、ローカルキャッシュへ書き込む最小単位。API 呼び出しコストや QPS 制限を招く可能性のある過剰な小リクエストを回避します
Block	32 KiB	ローカルファイル読み取り、圧縮、およびメモリ/ディスクキャッシュの基本単位

これは、キャッシュミス時に単一の KV レコードだけを取得するのではなく、Segment 全体をローカルストレージにロードすることを意味します。その後のクエリが同じセグメント内のデータにヒットすれば、ホットリード性能の恩恵を受けられます。一方で、後続アクセスのない一度きりのクエリでは、読み取り増幅のペナルティが比較的大きくなります。

Segment はローカルキャッシュのみを構成します。オブジェクトストレージでは、SST ファイルは単一の完全なオブジェクトとして保存され、セグメントに分割されません。そのため、セグメントサイズを変更しても、オブジェクトストレージ内のデータが再書き込みされることはありません。TiDB Cloud BYOC では、セグメントサイズを設定できます。詳細は階層型ストレージの設定と管理を参照してください。

読み取り増幅の分析

キャッシュミス時の読み取り増幅パス:

User queries 1 record (100 Bytes)
→ Block cache miss
→ TiKV loads segments from 3 LSM levels from object storage
→ Approximately 3 MiB data fetched from object storage to local
→ Read amplification: ~30,000×

キャッシュミスごとに取得されるデータ量は、セグメントサイズに比例して増加します。上記の数値は、デフォルトのセグメントサイズ 1 MiB を前提としています。

この増幅は、次の 2 つのシナリオで異なる形で現れます。

後続の再利用がある場合: ロードされたセグメントは IA キャッシュに保持され、その後のヒットはホットリードになるため、初回の増幅コストが償却されます
一度きりのクエリ: たとえば、大規模な範囲スキャンを実行するアドホック分析では、ロードされたデータが再利用されず、読み取りコストが非常に高くなります。さらに、新たにロードされたデータによってローカルキャッシュから「古いデータ」が追い出されます。この古いデータが実際のホットスポットである場合、その追い出しによって新たなキャッシュミスが発生し、連鎖的な性能影響を引き起こす可能性があります

したがって、階層型ストレージは、頻繁な広範囲スキャンよりも、小さく集中したクエリパターン に最も適しています。

LSM-Tree の書き込みパス

書き込みパスは Standard テーブルと同じです。

INSERT/UPDATE/DELETE
→ Memtable (hot write, unaffected by IA)
→ L0 SST (hot write, unaffected by IA)
→ L1+ SST (after compaction, opened in IA mode based on storage class)

書き込みは引き続き最初に memtable/L0 に入るため、ローカルのホットパスが直接リモート書き込みになることはありません
IA 条件に一致する L1+ ファイルは、リロードまたはコンパクションの後に IA モードで開かれます
memtable や L0 のようなホット書き込みパスは、直接 IA に入ることはありません
IA の主な対象は Write CF の L1+ レイヤーです

このことは、ストレージコスト削減が厳密な値ではなく概算になる理由も説明しています。IA ストレージ領域がカバーするのは、テーブルの L1 以深のレイヤーのみです。memtable と L0 ファイルはローカルディスク上に残り、IA ストレージとしてはカウントされません。そのため、テーブル全体の容量は memtable、L0、L1+ データの合計になります。テーブルのどの程度が実際に IA ストレージへ移動したかは、書き込みレートとコンパクションの進行状況に依存します。

変換効率

STORAGE_CLASS 形式でも ENGINE_ATTRIBUTE 形式でも、ストレージクラスを変更する ALTER TABLE 文は、スキーマメタデータを更新するだけなので数秒で完了します。その後、リージョンレベルのデータ移行が TiKV で非同期に実行されるため、全体の所要時間はデータ量と変換方向に依存します。

Standard → IA

テスト参考値: 約 1 TB の論理データ（インデックスを含む）は 5 分以内に変換が完了し、その間の QPS とレイテンシーへの影響はごくわずかでした。単一 TiKV の CPU 使用量は約 0.5c 増加し、約 5 分以内に回復しました。

TiDB schema takes effect → Schema Manager sync (30s) → TiKV broadcast
→ Region alignment / Split → ChangeSet updates Shard → Reload files

IA → Standard

テスト参考値: 2.09 TB の論理データ（インデックスを含む）は約 3 時間 10 分を要しました（TiKV あたり約 1.61k リージョン/時）。オブジェクトストレージの GET スループットは約 1.6 GiB/s でした。変換中、Standard パーティションの QPS は約 3.78% 低下し、P99 は約 18.63% 増加し、単一 TiKV の CPU 使用量は約 0.5c 増加しました。

Same chain as above + full object storage data download to local

ノート

これらの数値はテスト環境から得られたものであり、実際の本番シナリオを表すものではありません。正確なデータは、自身の業務テストに基づいて取得してください。

進行中の変換を SHOW STORAGE_CLASS TRANSITIONS で追跡する方法、または過去の変換時間を mysql.tidb_storage_class_transition_history で確認する方法については、階層型ストレージの可観測性を参照してください。