このブログは、siddontangの"How We Optimize RocksDB in TiKV — SST Compaction Guard"の抄訳です。翻訳はGeminiの翻訳をベースに、@bohnenが担当しました。
TiDB Xがコンパクションを再考する方法
TiKVのSSTコンパクションガードは、RocksDBにおける書き込み増幅を大幅に削減します。
しかし、次世代アーキテクチャである TiDB X では、さらにその先を行きます。なぜなら、ストレージの基盤全体が変わったからです。
TiDB Xはオブジェクトストレージ（Amazon S3など）上に直接構築されており、これによりリージョン、コンパクション、データ移動に対する考え方が根本的に変わります。
リージョンの移動が軽量に
TiKVのシェアードナッシングアーキテクチャでは、ノード間でリージョンを移動するには以下が必要でした。
- ネットワーク経由でのデータ転送
- SSTファイルの書き換え
- コンパクションのトリガー
これはコストがかかります。
しかし、TiDB Xでは：
データはローカルディスクではなく、オブジェクトストレージに存在します。
リージョンの「移動」は、単に新しい計算ノードに同じ基礎データを指し示すことを意味するだけであり、非常に高速で低コストです。
リージョンサイズをはるかに大きくできる
リージョンの移動が安価であるため、リージョンのサイズを劇的に大きくすることができます。
一般的なサイズ：
- 現在のTiKV: ~96MB（v8.4より256MB）
- TiDB X: リージョンあたり最大1GB、あるいはそれ以上
より大きなリージョンは以下を削減します。
- メタデータのオーバーヘッド
- スケジューリングの頻繁な変更（チャーン）
- リージョン分割の頻度
- コンパクションの断片化
この変更だけで、TiKVで観察された多くのテールレイテンシ（長時間の遅延）の問題が解消されます。
各リージョンが独自の専用LSMツリーを持つ
TiKVでは、多くのリージョンが同じRocksDBインスタンスを共有しており、以下の原因となっていました。
- リージョン間のコンパクション干渉
- キーの混在による書き込み増幅
- コストのかかる
DeleteFilesInRanges操作
TiDB Xでは：
各リージョンが専用の、分離されたLSMツリー（またはストレージスペース）を持っています。
これは大きな利点をもたらします。
- あるリージョンのコンパクションが他のリージョンのデータに触れることは決してありません
- SSTパーティショナーは不要です
- リージョン操作はメタデータのみになります
- ホットスポットリージョンは独立してスケールします
- 設計上、リージョン境界との不整合の問題がありません
この設計により、RocksDBレベルのコンパクション問題の全クラスが解消されます。
リージョンの分割/マージはメタデータのみ
各リージョンのデータは分離されているため：
- リージョンの分割 = メタデータの分割
- リージョンのマージ = メタデータのマージ
SSTファイルの書き換えはありません。重いコンパクションもなく、コンパクションはリモートで行うことができます。
これは、リージョンが同じLSMツリーを共有していたため、RocksDBでは効率的にサポートできなかったことです。
積極的な操作のためのリモートコンパクション
データはS3にあるため、TiDB Xはリモートコンパクションジョブを実行できます。
- 非同期に
- コンピュートプレーンの外で
- フロントエンド（ワークロード）のレイテンシに影響を与えずに
リモートコンパクションにより、アクティブな計算ノードに触れることなく、ストレージを積極的に再編成、マージ、クリーンアップ、最適化する自由が得られます。
これは、ストレージとコンピュートの真のクラウドネイティブな分離に向けた大きな一歩です。
TiDB Cloudを試す
これらの最適化が本番環境でどのように感じられるか興味がある方は、TiDB Cloudを無料で試してみてください。