RocksDBのLSM-Tree構造と書き込み増幅
WAL、MemTable、SST、compactionの組み合わせは、耐久性・読み取り負荷・容量に影響します。書き込み増幅や停滞は、設定・バージョン・ワークロードによって変わります。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
RocksDBのLSM書き込み経路とコンパクションの条件
RocksDBは組み込み型キー・バリュー・ストレージエンジンです。LSM構造の書き込み経路ではWALとメモリー上のMemTableを使い、flush後の整列データをSSTファイルに保存します。WALの利用や同期方法はWriteOptionsとDB設定に依存するため、応答済みのすべての書き込みが安定記憶装置へ到達済みとは限りません。flushはmemtableからSSTを作り、コンパクションは複数のSSTを統合して旧バージョンや削除を示すtombstone（削除を示す記録）を除去する場合があります。すべての処理が順次書き込みだけで済むわけではなく、読み取りやコンパクションでデータを繰り返し読み書きします。
専門家の視点：RocksDB engineer Jay Zhuangのコンパクション分析
RocksDB engineerのJay Zhuangは、コンパクション出力ファイルの境界を次のレベルのファイルに合わせることで、特定のレベル化コンパクションで再処理を減らす方法を分析しています。記事によるとこの変更はRocksDB 7.8以降で既定有効ですが、報告された書き込み増幅改善は特定の設計とdb_bench条件の結果です。シミュレーターはキーと値のサイズが均一と仮定し、削除、圧縮、コンパクション中の書き込み停止をモデル化していません。この数値を任意の本番環境の性能保証として一般化できません。
コンパクション方式と読み取り経路
レベル化コンパクションではL0のキー範囲が重なる場合があり、下位レベル内の範囲は通常重ならないよう管理します。一方、universal/tieredなどの方式では重なりと読み取りコストが異なります。すべてのLSMツリーがlevelごとに正確に10倍の容量を持つ、または同じコンパクション規則を使うという説明は正確ではありません。読み取りではmemtable、複数のSST、ブロックキャッシュ、index、フィルターが関与します。ブルームフィルターは存在しないキーの探索を省くのに役立ちますが、偽陽性があり、メモリー・CPU・ストレージを消費します。固定の「I/Oを99%削減」という効果はデータやフィルター設定で変わります。
調整時に見る指標と試験条件
LSMエンジンは書き込み、読み取り、容量増幅のトレードオフを持ちます。入力書き込みがバックグラウンドのコンパクションの処理量を長時間上回ると未処理のコンパクションが増え、書き込み停止が起こり得ます。write_buffer_size、バックグラウンド処理数、レベル容量の倍率、コンパクション方式、圧縮、ブロックキャッシュ、ブルームフィルター bitsを含めて評価します。設定項目名、既定値、効果はRocksDBのリリースで変わるため、利用中のバージョンの文書を参照してください。代表的なキー分布、更新・削除の比率、値のサイズ、読み書きの同時実行で測定し、p95・p99レイテンシ、未処理のコンパクション bytes、停止時間、ディスクへの書き込み量、容量を比較します。
仮想負荷条件の証拠を読み、次の試験を選ぶ
以下の負荷条件と数値は説明用の仮想例であり、RocksDBの実測結果や推奨既定値ではありません。たとえば16バイトのキー、1 KiBの値、ポイント読み取り70%、上書き 25%、削除 5%、同時実行数を固定で30分負荷をかけると定義します。データセットがブロックキャッシュより大きいか、ウォームアップを除外したか、DBへの入力バイト数とストレージへの書き込み量を同じ時間区間で集計したかを記録します。条件が変わると比較しにくくなります。
| 仮想の観測証拠 | 最初に検証する解釈 | 次に行う単一変数の確認 |
|---|---|---|
| 同じ測定時間でDB入力10 MB/s、ストレージへの書き込み量30 MB/s | この仮定では総書き込み/入力は約3です。コンパクションの寄与と決めつける前に、WALや他のプロセスの書き込みを切り分けます。 | DB統計とストレージ指標の区間を揃え、他のプロセスの書き込みを分離して基準値を測ります。まだ設定項目は変更しません。 |
L0ファイル数と未処理のコンパクション バイト数が同時に増え、STALL_MICROSも増える | コンパクションが追いつかず書き込み停止が起きている可能性があります。これだけではバックグラウンド処理数の不足と断定できません。 | 負荷条件と基準値設定を固定し、バックグラウンドのコンパクション ジョブ数だけを一段階変更して再試験します。停止時間、p99書き込みレイテンシ、ストレージ使用率を比較します。 |
| 書き込み停止はほぼない一方、ポイント読み取りのp99レイテンシが悪化しブロックキャッシュのヒット率が低下 | この負荷条件では読み取り経路やキャッシュの圧迫が候補です。コンパクションが原因とはまだ言えません。 | 他条件を固定してブロックキャッシュ容量だけを変更し、ヒット率、物理読み取り、p99を比較します。 |
同じ乱数種とデータセットで各試験を繰り返し、設定、RocksDBのバージョン、ハードウェア、ウォームアップ、測定時間を記録します。ある指標の改善と引き換えに別の指標が悪化することがあるため、目標指標と許容コストを先に決めます。RocksDBの調整ガイドも、負荷条件固有の設定項目を変える前に統計とシステムのボトルネックを調べるよう勧めています（RocksDB Tuning Guide、Compaction Stats and DB Status）。