# コマンドロギング ## 定義 コマンドロギング(command logging)は、データベース復旧のための書き込み前ロギング(WAL)手法の一種であり、**論理ロギングの極端な形態**である。ARIES のような物理生理ロギング(ビフォア・アフタイメージを記録)とは異なり、コマンドロギングはトランザクションが実行される前にそのコマンド(ストアドプロシージャ名とパラメータ)のみをログに書き込む。復旧時は、トランザクション整合性のあるチェックポイントから出発し、コマンドログを順番に再実行することでデータベースを復元する。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) **ログレコード構造**: ``` [check-sum | LSN | record-type | xaction-id | partition-id | xaction-type | params] ``` コマンドロギングが成立するための前提条件: 1. すべてのトランザクションがストアドプロシージャとして事前登録・コンパイルされていること 2. 復旧の出発点としてトランザクション整合性のあるチェックポイントが存在すること 3. コマンドログのリプレイ順序が元の直列等価実行順序と一致すること(S2PL 等で保証) ## 横断的知見 - **コマンドロギングの優位性はトランザクション複雑度と分散比率に依存する**: Malviya+ 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])は、TPC-C(複雑・多タプル更新)では 1.5× のスループット向上、Voter(単純・単一タプル更新)では 1.2× の向上を示した。分散トランザクション比率が増えるとトランザクション長が伸び、ロギングオーバーヘッドの相対的比率が下がるため差が縮小する。100% 分散では生理ロギングとほぼ差がなくなる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **H-Store が WAL を「除去」した設計とは、コマンドロギングへの置き換えである**: [[H-Store]] の設計論文([[@2007__VLDB__The End of an Architectural Era (It's Time for a Complete Rewrite)]])は WAL の除去を 4 コンポーネント除去の 1 つとして示したが、具体的にはコマンドロギング(トランザクション呼び出しの記録のみ)への置き換えを意味していた。Malviya+ 2014 はその実装と定量評価を初めて行った論文である。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]], [[H-Store]]) ## 未解決の問い - コマンドロギングをストアドプロシージャ非使用(アドホック SQL)のシステムに適用するとログレコードサイズが増大するが、実行時性能への影響はどの程度か？ - SSI(Serializable Snapshot Isolation)や SI(Snapshot Isolation)などのアイソレーションプロトコルでは、コマンドログのリプレイ順序と直列等価実行順序が一致しない場合があるが、これを解決する手法は存在するか？ - ディスクベース DB へのコマンドロギング適用では、トランザクション整合スナップショット取得のコスト(2 コピー必要)が大きな制約になる。MVCC を活用した効率的な実現方法はあるか？ - コマンドログの復旧時間はトランザクション再実行に依存するため、スループットが高いほど復旧データ量が増える。将来の 100K+ TPS システムでは復旧時間が問題にならないか？ ## 関連 - [[Write-Ahead Logging (WAL)]] — コマンドロギングは WAL の特殊形態 - [[ARIES]] — 対比される生理ロギング手法 - [[クラッシュリカバリ]] — コマンドロギングが解決する問題領域 - [[チェックポイント]] — コマンドロギング復旧の出発点として必須 - [[メインメモリデータベース]] — コマンドロギングが最も効果的な環境 - [[VoltDB]] — コマンドロギングを実装・採用したシステム - [[H-Store]] — コマンドロギングの概念的提案元 ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](コマンドロギングの実装と ARIES 生理ロギングとの詳細比較)