# コマンドロギング ## 定義 コマンドロギング(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]]) - **教科書(詳説 データベース)は「コマンドロギング」を WAL の4分類(物理・生理・論理・コマンド)の1つとして正式に位置づけており、Malviya 2014 の実装・命名がその後の標準的な教科書用語として定着したことを裏付ける**: 詳説 データベース5章§5.2.2は「コマンドロギング(Command Logging)―― 論理ロギングの極端な形態。トランザクション名とパラメータのみを記録する」と明記し、Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])が実装・定量評価した用語定義とほぼ同一の説明を与える。教科書がこの用語を独立した分類項目として採用していることは、Malviya 2014(および H-Store 設計論文)が提案した概念が2010年代のうちに教科書レベルの標準語彙として確立したことを示す一次証拠になる。ただし詳説 データベースは Malviya 2014 のような TPC-C/Voter での定量比較(1.2×〜1.5×のスループット差)には触れておらず、教科書は分類上の位置づけまでにとどまり、性能特性の定量評価は原論文に依存する構図が確認できる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.2.2, [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) ## 未解決の問い - コマンドロギングをストアドプロシージャ非使用(アドホック SQL)のシステムに適用するとログレコードサイズが増大するが、実行時性能への影響はどの程度か？ - SSI(Serializable Snapshot Isolation)や SI(Snapshot Isolation)などのアイソレーションプロトコルでは、コマンドログのリプレイ順序と直列等価実行順序が一致しない場合があるが、これを解決する手法は存在するか？ - ディスクベース DB へのコマンドロギング適用では、トランザクション整合スナップショット取得のコスト(2 コピー必要)が大きな制約になる。MVCC を活用した効率的な実現方法はあるか？ - コマンドログの復旧時間はトランザクション再実行に依存するため、スループットが高いほど復旧データ量が増える。将来の 100K+ TPS システムでは復旧時間が問題にならないか？ - 詳説 データベースが与える WAL の4分類(物理・生理・論理・コマンド)のうち、純粋な論理ロギング(コマンドロギングほど極端ではない、操作単位の論理記録)を採用する実システムの事例はまだ本 wiki にない。物理ログ・生理ログ・コマンドロギングとの中間的な性能特性を持つはずだが、実測データは存在するか。 ## 関連 - [[Write-Ahead Logging (WAL)]] — コマンドロギングは WAL の特殊形態 - [[ARIES]] — 対比される生理ロギング手法 - [[クラッシュリカバリ]] — コマンドロギングが解決する問題領域 - [[チェックポイント]] — コマンドロギング復旧の出発点として必須 - [[メインメモリデータベース]] — コマンドロギングが最も効果的な環境 - [[VoltDB]] — コマンドロギングを実装・採用したシステム - [[H-Store]] — コマンドロギングの概念的提案元 - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] — コマンドロギングをWALの4分類の1つとして位置づける教科書的定義 ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](コマンドロギングの実装と ARIES 生理ロギングとの詳細比較) - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]](§5.2.2 — WALの4分類の中でのコマンドロギングの教科書的定義)