ACID
ACID特性という言葉がよく使われるがACIDの実装はDBごとに異なり、例えば分離性の意味にはあいまいな部分がある 高いレベルでは分離性の概念は適切に思えるが、分離性の実際の問題は細部にあり、そこではあいまいさが残る
あるシステムがACID準拠と主張するとき実際にどういう保証を期待できるかははっきりしない
ACIDでないシステムをBASEと呼ぶことがあるが、これはよりあいまいなもので意味はほとんどない
ACIDでない以上の定義は無いように見える
原子性 Atomicity
マルチスレッドプログラミングなどの分野と異なり、ACIDの文脈における原子性は並行性とは無関係である
複数のプロセスが同じデータに同時にアクセスしようとしたときに起こることの説明は分離性(Isoration)で与えられる
あるクライアントがいくつかの書き込みをしている最中に、それを中断するような障害が生じたとき、トランザクションが障害のために成功(commit)しなかったらトランザクションは中断され、トランザクション中の書き込みはすべて破棄・取り消しされるというのが原子性を定義づける特徴である
原子性はクラッシュリカバリ用のログを使って実装できる
一貫性 Consistency
一貫性はあまりに色々な意味で使われてしまっている
ACIDの文脈における一貫性でないものの例(かつ本書内で登場するもの)
レプリケーションにおける一貫性 p.172
コンシステントハッシュ法
CAP定理における一貫性(=線形化可能性) p.354
ACIDの文脈における一貫性はデータについて常に真であるべきステートメント(不変性)があるということ
不変性が保たれた状態のデータベースで実行されるトランザクション中のどの書き込みも不変性が保たれていれば一貫性があるということになる
不変性はデータベースではなくアプリケーションの責任では?→はい
外部キー制約やユニーク制約など、DBで検証できる仕組みもあるが、不変性を定義しチェックする大部分はアプリケーションに権利と責任がある
分離性 Isolation
複数のプロセスが同じデータに同時にアクセスしようとしたときに起こることの記述で、複数の選択肢がある
古典的には直列化可能性として形式化されているが、パフォーマンス上の問題からこれがそのまま用いられることは多くない Oracleには直列化可能という分離レベルがあるが、実際実装されているのはスナップショット分離である(!)
分離性はそれぞれのオブジェクトでロックを使うことで実装できる
永続性
トランザクションのコミットが成功したあとハードウェアの故障やソフトウェアの障害があったとしてもそのトランザクションによる書き込みが失われないこと
永続性と言っても実際には冗長度の違いがある
素朴に単一ノードでの議論だと不揮発ストレージへの書き込み
ディスク上のデータが破損したときのリカバリの仕組みを含めることもある
WALなど
レプリケーションされている場合一定ノード数のレプリカが書き込まれたデータに追いついたことを含意する
完全な永続性は存在しないため、コスパと要件の設定が大事