直交するStealとForceの軸
ディスクの一部を適宜メモリに写し取って編集するページモデルのデータベースの設計上の選択肢として、StealとForceの2軸がある。
Steal
トランザクション側の都合で任意のページをメモリから追い出せるシステムの場合、それを「Steal」と呼ぶ。（任意といっても流石にWALのルールに違反はできないが）
それはつまり、トランザクションが認知しないタイミングでも任意のページが他のトランザクションの手によってメモリから追い出される事を意味するので、書き換わった(ダーティな)ページが未コミットのまま永続化される可能性がある。なのでリカバリ時にそのための配慮（Undo操作）が必要となり複雑度が増す。トランザクションからすると自分が触っているページが「盗まれる」のでStealと呼ぶのだろうと思う。
Stealを許さないシステムの場合（No-Stealと呼ぶ）トランザクションは未コミットのデータを永続化できない。
そのシステムではメモリに入りきらないテーブルに対してWHERE句無しのUPDATE文は永久に成功しない。
また、他のトランザクションが触っているからという理由でメモリからページを追い出せないので、ロングトランザクションが走るとそれだけ他のトランザクションが好きなように使えるページが減る。性能・機能の両面からStealが望まれる事が多く、実際のところMySQLやPostgreSQLなど有名ドコロのDBはみんなStealに分類される。
Force
トランザクションが完了時にそのトランザクションが更新した内容をディスクに反映させるシステムの場合、それを「Force」と呼ぶ。
それはつまり、トランザクションが完了する度に大量のランダムIOが走る事を意味するのでパフォーマンスに多大な影響を与える。
Forceする場合、完了したトランザクションは必ずディスクに全て反映されているのでリカバリ時のRedoが不要になる（リカバリ時の挙動に付いては後日詳しく）。
コミット時に複数のページを更新する途中で電源が落ちた場合、ディスク上のDBから一貫性が失われてしまうのでUndoするか、もしくは複数のページを一括で更新するシャドーページング等のテクニックを使う事になる。
性能の観点からForceを選択しないシステムの方が近代ではよく見かける（昔のDBでは割とForceしていたようだが）。有名ドコロのDBはみんなNo-Forceに分類される。
これら2つの軸は直交しており、DBを設計する際にはStealかNo-Stealかという観点とForceかNo-Forceかという点はそれぞれ独立している。つまり四象限どこかを選ぶ事になる。
2軸とログに望まれる情報
前述したように、StealとForceをどう選ぶかによってログに求められる情報も変化する。
トランザクションシステムを設計する際に、Stealを選んだ場合、未コミットのデータが書き込まれる可能性があるのでUndo情報が必要となる。
No-Forceを選んだ場合、コミット済み（つまりクライアントに完了を報告した）トランザクションがディスク上のB+ツリー等に反映されていない可能性があるので、Redo情報が必要となる。
Forceを選んだ場合であってもディスク上の複数ページ更新がAtomicに行われていない場合はディスク上のデータの一貫性が取れないのでUndo情報が必要となる。
そのあたりの情報をまとめたのがTheo HaerderとAndreas ReuterらのPrinciples of Transaction-Oriented Database Recoveryである。
以下の図はこの論文から引用する。
Propagation Strategyは複数のページ更新をアトミックに行えるか否か。
Page ReplacementがStealするか否か。
EOT(End of Transaction) ProcessingがForceするか否か。
Checkpoint Schemeは後日解説する。
そして一番下にその当時でのDBシステムの実施例が書かれている。
IMS/FPは歴史の古いインメモリDBで、グループコミットを実装したDBとして先日のアドベントカレンダーにも書いた。
当時はこのように多様性に富んだ選択が行われていたが、結局現代のWebの世界で広く使われているDBの多くは¬Atomic ∧ Steal ∧ ¬Force ∧ fuzzyの組み合わせであり、その組み合わせのDBを作る際のベストプラクティスをまとめた金字塔がこの論文の9年後に公開されたARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead loggingである。
この論文はディスクベースなDBの設計を語る上で欠かせない重要な知見が詰まっているのでおいおいこのアドベントカレンダーで話していく。