～ 遺伝子組み換え野菜をたっぷり添えて ～
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を同じ感覚で使うと痛い目見そうな感じは理解しました。

で、なんなのさ？ †

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

では、データベース（以下、ＤＢ）を使う人・システムに組み込む人の立場からですが。

ＤＢは、そもそも上記の性質を兼ね備えているのだから、使う側が意識する必要はない。
・・・という訳にもいかないのがシステムを設計構築する人々の悩ましい話です。
個人的に、ありがちだな～と思うのが

• 「Isolation（独立性）」が保てなくなること。
  複数のトランザクションを同時に実行すると、排他制御がなくて、失敗する。
  ＤＢに入れる「前」に、データの扱いをしくじって、独立性が保てないケース。
• 「Consistency（一貫性）」がない事。
  意制約やNotNull制約を、そもそもＤＢを設計する段階で、付け忘れるケース。

など、など

では、これらを見逃さないために、どんな対策が有効なのかというと、
経験上は、動作確認テストです。ただし、

• 負荷試験
• 複合試験

と呼ばれる類のやつです。色んなパターンの入力を高負荷で同時に行う。
しかし、
この手の試験は実施するのに非常にコストがかかります（実行する手間、環境、機材の値段 etc）、
だから意図的に計画に入れないと、まず、実施されることの無い試験項目になります。
言い換えると、計画に入れる or 入れないを明確にしないと、後で必ず揉めることになるので注意が必要です。
（なんで試験で検出できなかったんだ～、予算上やる計画はなかった～、とか）

あと、さらに余談ですが、
「性能試験」やると、だいたい「性能以外の問題」が噴出します。上記のような。
１秒間に何リクエスト処理できるか、以前に、同時にリクエストを受けたらシステムダウンしました、とか。
元性能試験担当として何度痛い目にあったか・・・ゴホゴホ・・

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