図解で学ぶシステム設計 〜ACID編〜
ACIDとは
ACID原則は、データベースのトランザクション処理に関する4つの基本的な特性を示すもので、データの整合性と信頼性を確保するために重要です。ACIDは以下の4つの特性の頭文字を取ったものです。
1. Atomicity（原子性）
トランザクション内の全ての操作が 『完全に成功するか・完全に失敗するか』 のいずれかであるべきです。つまり、トランザクションが途中で失敗した場合は、そのトランザクションで行った全ての変更が取り消され、データベースはトランザクション開始前の状態に戻ります。
銀行口座の例：
ユーザーが自分の口座から別の口座に$100を送金する場合、このトランザクションは2つの操作から成り立つ。
- 操作1: 送金元 (User A) 口座から$100を送金。
- 操作2: 送金先 (User B) 口座に$100を入金。
原子性の適用：
- 両方の操作が成功すれば、トランザクション全体が成功。
- どちらか一方の操作が失敗した場合、もう一方の操作も取り消され、システムは元の状態に戻る。
例えばUser Aの送金だけ成功し、User Bへの入金が失敗した場合、AtomicityがないとUser Aの口座から$100だけ引き落とされた状態となってしまうため、データの不整合が発生してしまいます。これらを避けるためにも、２つの操作は1つのトランザクション内で管理し、両方が成功する or 失敗する状態(All or Nothing)となるようにします。
2. Consistency（整合性）
トランザクションが実行されると 『データベースは一貫した状態に保たれるべき』 です。トランザクションが完了することで、データベースのルールや制約が常に満たされる状態でなければなりません。
銀行口座の例：
送金前に、送金元口座と送金先口座の合計残高が$1000とする。
-
送金操作後:
- 送金元 (User A) 口座: $500 → $400 (-$100 送金)
- 送金先 (User B) 口座: $500 → $600 (+$100 入金)
- 合計: $400 + $600 = $1000
一貫性の適用：
- トランザクション後も、全体の合計が変わらず$1000であることを保証。
- データベースの制約（例：口座残高が負にならない）も維持。
トランザクション実行前後で、データベースの一貫性が保たれるようにします。また、銀行口座などの特有の制約(送金した結果、口座が負の値にならないこと)を維持します。
3. Isolation（独立性）
複数のトランザクションが同時に実行される場合 『それぞれのトランザクションは他のトランザクションから隔離されているべき』 です。つまり、あるトランザクションの変更は、他のトランザクションがその変更を読み取る前に完全に完了していなければなりません。
銀行口座の例：
同時に2人のユーザーが引き落としを行う場合
- ユーザーA: 口座から$100を引き落とし。
- ユーザーB: 同じ口座から$200を引き落とし。
独立性の適用：
- 各トランザクションは互いに干渉せず、データの整合性が保たれる。
- たとえば、送金元口座が$500の場合、ユーザーAとユーザーBの送金が同時に行われても、最終的な残高は正しく計算される。
たとえば、複数のトランザクションが独立していない状態でUser AとUser Bが同時に引き落とし、その合計金額が$500以上でも引き落とすことが可能です。なぜなら両者とも引き落とし時の残高が$500だからです。これはシステム的に正しくなく、User Bの引き落とし時の残高はUser Aが引き落とした後の残高になっていることが正しいです。そのため、互いのトランザクションを独立させ、正しいデータで取引が行われるようにする必要があります。
4. Durability（永続性）
トランザクションが完了した後、その 『変更は永続的であるべき』 です。システムの障害やクラッシュが発生しても、完了したトランザクションの変更は失われず、データベースに保存され続けるべきです。
銀行口座の例：
ユーザーが$100を送金し、トランザクションが正常にコミットされた場合、その結果は永続的に保存される。
永続性の適用：
- 送金が完了した後、サーバーがクラッシュしても、送金の結果（$100が送金先に入金された）は失われない。
- データベースのログやリカバリ機能を通じて、トランザクションの状態が保持される。
たとえデータコミット後に障害が発生しても、その前に行った変更は保存され続ける必要があります。
参考文献
ACID データベースと BASE データベース - データベースの違い - AWS
Discussion