～ 居合の達人だが、得物は防犯ブザー ～
null-i.net

トランザクションの性質について(2014-09-03)

データベースに対して様々なトランザクション（作成、読み取り、更新、削除*1）を行うにあたって、データベースが実装しなければならない性質についてのお話です。

ACID特性 †

RDB（リレーショナルデータベース）*2に使われる概念

Atomicity（原子性） †

DBに対する更新が「された」か「されていない」かのどちらかになること。
トランザクション完了後の状態はそれ以上には分解できないから原子性と呼ぶ。

Consistency（一貫性） †

実行結果が定められたルールに沿って正しいことが保障されること。
いわゆる一意制約やNotNull制約とか。銀行のDBなら預金残高がマイナス値になったりしないとか。

Isolation（独立性） †

複数のトランザクションを同時に実行しても、個々の処理結果が正しくなること。

Durability（永続性） †

トランザクション完了後の結果は永続して失われないこと。
例えばある日突然、預金残高が０になったりしないこと。

BASE特性 †

NoSQL*3の場合はACIDは適用されません。
例えばビックデータを扱うには性能重視だから？優先順位が変わってくるようです。

Basically Available（基本的に利用可能） †

可用性って大事だよね

Soft-state（柔軟な状態） †

状態の厳密な整合性は抜きにしようぜ。

Eventually consistent（結果整合性） †

結果的に合っていれば良いでしょ。
（処理途中での整合性、一貫性は問わない）

・・・という、自分で書いてても何だかモヤモヤする解説です。
特にsoft-stateはググっても、諸説有ってさっぱり分かりません。
分散ノードとか、NoSQLの設計思想を理解していないからでしょうか｡
ただ、RDBとNoSQLを同じ感覚で使うと痛い目見そうな感じは理解しました。

で、なんなのさ？ †

試験対策としては、以上の単語覚えるだけですね。

実際に作るor使う人の話としては、
ＤＢは、そもそも上記の性質を兼ね備えているのだから、使う側が意識する必要はない。
...という訳にもいかず、
上記を踏まえてつくってくださいor運用してくださいという話になります。
複数のトランザクションを同時に実行すると、排他制御がなくて、「Isolation（独立性）」が保てなくなったり、
一意制約やNotNull制約を、そもそもＤＢを設計する段階で付け忘れて、「Consistency（一貫性）」がなくなったり。

では、これらを見逃さないために、動作確認テストとかやるわけですが... 複合試験、負荷試験 と呼ばれる類の（色んなパターンの入力を高負荷で同時に行う）試験、
この手の試験は実施するのに非常にコストがかかります（実行する手間、環境、機材の値段 etc）、
だから意図的に計画に入れるor外すしないと、あとで揉めることになるので注意が必要です。
（なんで検出できなかったんだ～、予算上やる計画はなかった～、とか）

ACIDの理屈はシンプルですが、
シンプルなものを作るって難しいですね。