# Write-Ahead Logging (WAL) ## 定義 書き込み前ロギング(Write-Ahead Logging、WAL)とは、データベースシステムにおいて、実際のデータ変更をデータページに反映する前に、変更内容をログに書き込む耐久性保証の基本原則である。WAL によって、クラッシュ発生後もコミット済みトランザクションの変更を再適用(Redo)し、未コミットのトランザクションの変更を取り消す(Undo)ことが可能になる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) WAL の実現方式には主に以下の種類がある: - **物理ロギング(Physical Logging)**: ディスクページのビフォア・アフタイメージを記録する。ページ ID・オフセット・変更前後のバイト列 - **生理ロギング(Physiological Logging)**: ページ内で物理的に変更を記録し、タプル間では論理的に記録する。ARIES が代表。ディスクページのスロットではなく論理的な操作(Insert/Update/Delete)の単位でログを書く - **論理ロギング(Logical Logging)**: 操作の効果を論理的に記録する。SQL 文や操作の意味でログを書く - **コマンドロギング(Command Logging)**: 論理ロギングの極端な形態。トランザクション名とパラメータのみを記録する ## 横断的知見 - **WAL 方式の選択がメインメモリ OLTP のスループット天井を決める**: Malviya+ 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])は、生理ロギング(ARIES 方式)がメインメモリ OLTP で TPC-C の最大スループットを 1.5× 低下させることを示した。これは Shore での先行研究([[@2008__SIGMOD__OLTP through the looking glass, and what we found there]])が 10–20% のオーバーヘッドを定量化したことの延長として位置づけられ、「スループットが上がるほどロギングの相対コストが増大する」という仮説を実験的に確認した。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]]) - **WAL オーバーヘッドは I/O と CPU の両方が原因**: 生理ロギングのオーバーヘッドはログデータのディスク書き込み量(TPC-C で 10× 多い)だけでなく、差分ログレコード構築の CPU コストにも起因する。ログレコードを人工的に 100 バイトに切り詰めた制御実験でも、スループット改善はわずか 1% にとどまった。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **「ログがデータベース」——WAL をストレージ層に押し出した場合、エンジン視点での Redo 責任の境界が消える**: Aurora([[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]])は WAL の Redo ログレコードのみをネットワーク越しに書き込み、ストレージ層のログアプライヤが非同期でデータページを実体化する。エンジンから見るとログレコードを書いた時点でコミットが成立し、物理ページは「ログ適用結果のキャッシュ」にすぎない。これは伝統的な WAL の「ログ → ページ」という二段階モデルを「ログ = データベース」という単段階に還元する設計であり、Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])が議論したメインメモリ OLTP での WAL コスト問題とは別のアプローチで I/O を削減する。(Source: [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]], [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **SCL/PGCL/VCL/VDL は分散 WAL における LSN 一貫性ポイントの自然な拡張である**: 単一ノードの WAL では LSN と SCN が「ディスクにフラッシュした最高水位」を示す。Aurora 2018([[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]])はこれを分散化し、SCL（セグメント）→PGCL（Protection Group）→VCL（ボリューム全体）→VDL（ミニトランザクション境界）の 4 層階層で「分散 WAL のフラッシュ水位」を表現する。各水位は局所状態のみから計算でき、2PC のようなラウンドトリップ合意が不要。「ログだけが前進する」という不変条件がコンセンサス不要の基盤。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) - **VDL による MTR 原子性保証はレプリカの構造一貫性に直接つながる**: WAL の Mini-Transaction（MTR）は B-Tree スプリット等の複数ブロック変更をアトミックに記録する論理単位。Aurora ライターは VDL を「最後の MTR 完了 LSN」として定義し、このポイントをレプリカのレプリケーションストリームに通知する。レプリカは VDL 以上の MTR チャンクのみをキャッシュに適用するため、B-Tree の中途状態がレプリカに見えることがない。(Source: [[@2018__SIGMOD__Amazon Aurora - On Avoiding Distributed Consensus for I Os, Commits, and Membership Changes]]) ## 未解決の問い - NVRAM(不揮発性メモリ)が普及した場合、WAL のログをディスクでなく NVRAM に書き込むことで、I/O レイテンシ・CPU コストの両方が変化する。コマンドロギングと生理ロギングの優位性はどう変化するか？ - グループコミット最適化の最適パラメータ(バッチ間隔・バッチサイズ)はワークロードによって異なる。実行時に動的に最適化する手法は存在するか？ - Aurora の「ログのみ送信」設計はページ書き込みのネットワークコストを削減するが、ストレージ層でのログ適用 CPU コストはどの程度増加しているか？スケールアウトによる並列化がそれを相殺するかの実測は？ ## 関連 - [[ARIES]] — WAL を実装した代表的な生理ロギング方式 - [[コマンドロギング]] — 論理 WAL の極端な形態 - [[クラッシュリカバリ]] — WAL が解決する問題 - [[チェックポイント]] — WAL と組み合わせてログ再適用範囲を制限する - [[メインメモリデータベース]] — WAL 設計選択が最も重要な環境 - [[OLTPシステムアーキテクチャ]] — WAL はログコンポーネントの一部 - [[コンピュートストレージ分離]] — ログ処理をストレージ層に移す Aurora 設計の文脈 ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](コマンドロギングと生理ロギングの詳細比較) - [[@2017__SIGMOD__Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases]](「ログがデータベース」——Redo ログのみ送信・ストレージ層での非同期ページ生成)