[中級者向け!] Epochをわかりやすく解説![ロギングその③]
はじめに
前回の記事では ARIES 系の Undo/Redo とチェックポイントまでを扱いました。
今回はEpoch ベース設計(例:Silo)の比較とUndo を不要にする仕組みについて解説します。
この記事の対象者
・Siloの論文を読んでる人
・トランザクションの研究をする人
目次
- なぜ通常のコミットが遅いのか
- epochとはなにか
- epochによるグループコミット
こちらを読んだ人向けの記事になっています。↓
1. なぜ通常のコミットが遅いのか
・1トランザクション=1fsync(メモリ上にあるデータをディスクに書くシステムコール)だと、ログの永続化がボトルネックになってしまいます。(下の図参照↓)
2. epochとはなにか
epochとは時間を区切った論理的な時間 (e.g.40ms)です。
同じエポック内のtxnは「同時にコミットした」とみなされます。
3. epochによるグループコミット
通常のコミット

グループコミット

このように、ログをepochごとにまとめてフラッシュし、durabilityを「epoch単位」で保証します。すると、少しのレイテンシ増加と引き換えにスループットを高めることができます。つまり、もしPCが壊れたとき、復旧できるのは『個別のトランザクション単位』ではなく、『最後にfsyncが完了したEpoch単位』になります。Epochが40msなら、最悪でも直近40ms分のデータが失われる可能性があるというトレードオフを選択していることになります。
4. Siloの例:Validation成功のその先
ここまでで、epoch によるグループコミットの考え方を説明しました。
では、この仕組みが Silo では実際にどのように使われているのかを見ていきます。
Siloでは、Validation(検証フェーズ)に成功して共有メモリを書き換えても、すぐに「完了!」とは言いません。 そこから永続性が保証されるまでには、以下の3つのステップがあります。
例
T0: r(A) w(A) r(B) w(B) commit
とします。
① Validationに成功したスレッドは、ローカルバッファの内容を本体(共有メモリ)へ反映します
注意点: この時点ではまだ「メモリ上」の話です。今停電したらデータは消えてしまいます。

② Validationに成功したスレッドは、更新内容(Redo情報)を現在の Epoch に対応するログバッファに書き込みます
ここが 2PL との決定的な違いです。
2PL(即時更新)では、各トランザクションが「自分の commit のため」にログを書き、fsync が終わるまで待つ必要がありました。つまり、durability を各スレッドが個別に背負っている設計です。
一方 Silo では、ワーカースレッドは共有メモリにログを置いた瞬間に仕事が終わります。
その後の fsync は Epoch 単位でまとめて行われ、各トランザクションは durability を「Epoch に委ねる」形になります。
これが、Silo が高い並列性を保てる大きな理由です。

2PL(ARIES)と Silo のログ処理の違い
| 比較項目 | 伝統的な 2PL(ARIES) | Silo(Epoch) |
|---|---|---|
| ログのフラッシュ | 各スレッドが自分で fsync | Epoch 管理者がまとめて fsync |
| スレッドの状態 | ディスク I/O を待って停止(Block) | 待たずに次の処理へ進む |
| durability が担保できる瞬間 | fsync が完了した瞬間 | Epoch が更新された瞬間 |
このように、Silo では durability の責任主体が「各トランザクション」から「Epoch」へと移っています。
③ エポックの時間が終了すると、バッファに溜まったEpochの全ログを一括で fsync します
fsync が完了し、Epochが終了します。そして、Epochに更新された瞬間に、初めてユーザーへ「コミット完了」の通知を送ります。重要なのは、ここで初めて durability が保証される点です。Validation に成功していても、この fsync が完了するまではコミットしていない扱いになります。

データ本体はいつディスクに書かれるのか?
Siloにおいてデータ本体のフラッシュ(ディスクへの書き出し)は、チェックポイントを用いて、数分おきなどに行われ、リカバリを高速化するために実施されます。
Siloのリカバリ
Siloのリカバリではanalysis phase, undo phaseがなく、redoのみ行われます。フラッシュされるログ内にあるトランザクションは必ずコミットかアボートをしているためです。以下の例を見てみましょう。データbの操作前にチェックポイントがあり、T0がコミットされてからクラッシュしていると考えます。

こちらは、チェックポイントからログに書かれている確定エポックまでのログを順に上書き(Redo)すればリカバリができます。

最後まで読んでくださりありがとうございました!
Discussion