# ARIES ## 定義 ARIES(Algorithm for Recovery and Isolation Exploiting Semantics)は、Mohan ら(1992、ACM Trans. Database Syst.)が提案したデータベース復旧アルゴリズムである。細粒度ロックと部分ロールバックを支援しつつ、書き込み前ロギングを用いてトランザクションの耐久性を保証する。ARIES はリレーショナルデータベースの**復旧の金字塔**(gold standard)とされてきた。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) **生理ロギングの仕組み**: - トランザクションが行う各操作(挿入・更新・削除)に対し、変更前後のデータ(ビフォアイメージ・アフタイメージ)をログレコードとして書き込む - 各ログレコードは一意の LSN(Log Sequence Number)を持つ - ダーティページテーブルと取引テーブルを維持し、チェックポイント時にディスクへ書き出す **復旧の 3 フェーズ**: 1. **分析フェーズ**: ログを前から読み、Redo 開始 LSN を特定する 2. **Redo フェーズ(物理)**: 分析で特定した LSN 以降の全ログエントリを順番に再適用する 3. **Undo フェーズ(論理)**: クラッシュ時点で未コミットだったトランザクションの変更を逆順に取り消す **メインメモリ向け適応**(Malviya+ 2014 での実装): - ページ指向の構造(page#, slot#)を(table-id, primary-key)ペアに置き換え - ダーティページテーブルを廃止し、タプルのダーティビットで代替(トランザクション整合チェックポイント採用によりこれも不要に) - Redo フェーズをパーティション間で並列化(線形スケールアップ達成) - 差分ロギング最適化: 更新された列のみビフォア・アフタイメージを記録(TPC-C で 5× のサイズ削減、ただし CPU コスト増加) ## 横断的知見 - **ARIES が「金字塔」だった歴史的文脈**: ARIES が 1990 年代に開発されたとき、OLTP スループットは 1 コアあたり数百 TPS 程度であり、生理ロギングのオーバーヘッドは全体の小さな割合だった。メインメモリ OLTP が 4,000 TPS/コア 超を達成する現代では、同じロギング手法がトランザクション実行時間の無視できない割合を占めるようになる。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **生理ロギングの CPU オーバーヘッドはディスク I/O 量より支配的**: Malviya+ 2014 の制御実験で、TPC-C における生理ロギングのログレコードを人工的に 100 バイトに切り詰めてもスループット改善は 1% にとどまった。これはディスク I/O 量が原因でなく、差分ログレコード構築の CPU コストが支配的要因であることを示す。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **復旧速度では ARIES がコマンドロギングを凌駕する**: ビフォア・アフタイメージを直接記録するため、復旧時にトランザクションロジックを再実行する必要がない。Voter では 5× 高速、TPC-C では 1.5× 高速。レプリケーションが普及した現代では復旧速度の重要性は低下しているが、高分散トランザクション比率や複雑なワークロードでは依然として有利。(Source: [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **教科書(詳説 データベース)の記述は、Malviya 2014 が前提とするページ指向 ARIES の「原型」を確認できる基準点になる**: 詳説 データベース5章は ARIES を分析・redo(物理)・undo(論理)の3フェーズとして説明し、「steal/no-force ポリシーを採用し、物理的 redo でリカバリを高速化しつつ論理的 undo で同時実行性を改善する」と明示する。Malviya 2014([[@2014__ICDE__Rethinking Main Memory OLTP Recovery]])のメインメモリ向け適応(page#/slot# を table-id/primary-key ペアに置換、ダーティページテーブルを廃止しタプルダーティビットで代替)は、この教科書的な3フェーズ構造自体は変えず、ディスク指向の内部データ構造だけをメインメモリ向けに置き換えたものであることが、教科書の一般定義と突き合わせるとより明確になる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.2.4, [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) - **steal/no-force という教科書的なポリシー分類が、ARIES の性能特性(トランザクション実行は高速・undo/redo ログ保持コストは高い)を説明する語彙を与える**: 詳説 データベース5章の steal/force 分類(§5.2.3)によれば、steal はコミット前のダーティページフラッシュを許容し(no-steal よりページキャッシュ圧を下げる)、no-force はコミット前の全ページフラッシュを要求しない(force より高速コミットを可能にする)。ARIES が steal/no-force を選んだことは、Malviya 2014 が実測した「生理ロギングの CPU オーバーヘッドが支配的要因」という結果と矛盾しない。steal/no-force はディスク I/O コストを避ける代わりにログレコード構築(差分イメージの計算)という CPU コストを支払う設計であり、教科書のポリシー分類と論文の実測オーバーヘッドの内訳が同じ設計選択の異なる側面を指している。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] §5.2.3, §5.2.4, [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]]) ## 未解決の問い - 差分ロギング最適化(更新列のみ記録)と全タプル記録の CPU コスト・ログサイズの収支は、CPU アーキテクチャ(SIMD・キャッシュ階層)の進化でどう変化するか？ - ARIES の Undo フェーズはロックベースの並行性制御(S2PL)を前提とするが、MVCC や楽観的並行性制御と組み合わせる場合に実装はどのように変わるか？ - 分散 ARIES(複数ノードにまたがるトランザクションの Undo)では 2PC との組み合わせが必要になるが、メインメモリ環境では並列 Redo がどの程度まで有効か？ - 詳説 データベース5章はロックベースの並行性制御(2PL)を前提に ARIES の undo/redo を説明する。ARIES の分析・redo・undo という3フェーズ構造そのものは、MVCC ベースの並行性制御(→ [[スナップショット分離とMVCC]])と組み合わせる場合にどこまで変更が必要か。 ## 関連 - [[Write-Ahead Logging (WAL)]] — ARIES が実装する基本原則 - [[コマンドロギング]] — ARIES と対比される軽量復旧手法 - [[クラッシュリカバリ]] — ARIES が解決する問題 - [[チェックポイント]] — ARIES がファジーチェックポイントと組み合わせる - [[メインメモリデータベース]] — ARIES の適用環境の変化 - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]] — ARIES の3フェーズとsteal/no-forceポリシーの教科書的定義 ## 出典 - [[@2014__ICDE__Rethinking Main Memory OLTP Recovery]](ARIES 生理ロギングとコマンドロギングの詳細比較) - [[@2021__OReillyJapan__詳説 データベース - Chapter 5 トランザクション処理とリカバリ]](§5.2.4 — ARIESの3フェーズ復旧とsteal/no-forceポリシーの教科書的定義) - 原典: Mohan et al. "ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging." ACM Trans. Database Syst. 17:94–162, 1992.