トランザクション from DDIA
DDIA7章の勉強ログ
情報量が多すぎるので一旦ここでまとめて、分割は後から考える
ページ表記は断りなければ和訳版データ指向アプリケーションデザインより
トランザクションはソフトウェア開発者にとって当たり前の工学的レイヤとして扱われることがあるが、そうではない
トランザクションが提供できる安全性とコストには多数の選択肢があり、多数のケースを見ながらトレードオフを把握しておく必要がある
ACID
単一オブジェクトトランザクションと複数オブジェクトトランザクション
オブジェクトとは行、ドキュメント、レコードなどのこと
複数オブジェクトトランザクションとは、BEGIN TRANSACTION文からCOMMIT文までの間で複数のオブジェクトを読み書きできるトランザクションのこと
多くの分散データストアは複数オブジェクトのトランザクションを放棄している
パーティションをまたいで実装するのが難しいため
可用性やパフォーマンスの要求が高い状況では難題となるため
とはいえ根本的に分散データベースのトランザクションを実現することが不可能なわけではない（9章で扱われる）
そもそもkey-value型データモデルと単一オブジェクトトランザクションのみで任意のアプリを実装できないのか？
これができるなら複数オブジェクトトランザクションを捨てることができる
結論をいうと難しい
リレーショナルデータモデルやグラフデータモデルでテーブルの参照関係を除去することは難しい
ドキュメントデータモデルはまとめて更新しなければならないフィールド群が同じドキュメント内にあることが多い。しかしドキュメントDBは結合の機能を持たないので非正規化が推奨される。非正規化された情報を更新するには複数オブジェクトトランザクションが有効である。
セカンダリインデックスを持つDBは値を変更する度インデックスを更新しなければならず、これはトランザクションから見れば実質的に複数オブジェクトトランザクションである
純粋なkey-valueストアを除けばほぼ全てのDBがセカンダリインデックスを持つ
エラーと中断処理
トランザクションは原子性、分離性、永続性を保証できない場合処理を完全に破棄する
一部システムは例外がある、特にリーダーレスレプリケーションを行うデータストアはベストエフォート動作することが多い。エラーが起きた場合でもそれまでの処理を取り消さないため、リカバリはアプリケーションの責任になる。
RailsのActiveRecord、DjangoなどのORMフレームワークは中断されたトランザクションのリトライを行わない（！）
ギャップロック