プログラマー必須知識！ ACID 特性をマスターして、安全なシステム開発を
データベースにおける ACID と現実世界の例
- Atomicity（原子性）：トランザクション内の操作はすべて単一の操作として実行され、部分的に実行されることはありません。 成功するか失敗するか、いずれか一方です。
- Consistency（一貫性）：トランザクションが完了すると、データベースは常に整合性のある状態になります。 データベースの整合性規則は常に守られます。
- Isolation（独立性）：同時に行われる複数のトランザクションは互いに影響を与えず、独立して実行されます。 他のトランザクションの処理内容が見えたり、影響を受けたりすることがありません。
- Durability（耐久性）：トランザクションが完了したら、その結果はコミットされ、永続的に保存されます。 ハードウェアやソフトウェアの障害が発生しても、データは失われません。
これらの特性は、データベースの信頼性と整合性を保証するために重要です。
ACID の現実世界の例
以下、ACID の各特性を説明する現実世界の例です。
原子性
- ATM でのお金の引き出し: お金の引き出しは、原子性トランザクションとして処理されます。 残高照会、引き出し、残高更新という操作がすべて正常に完了するか、すべて失敗します。 途中でエラーが発生し、一部のお金だけが引き出されるようなことはありません。
一貫性
- 銀行口座への振り込み: 口座Aから口座Bへのお金の振り込みは、一貫性のあるトランザクションとして処理されます。 A口座から引き落とされた金額は、必ずB口座に振り込まれます。 途中でエラーが発生し、お金が消失したり、二重に振り込まれたりするようなことはありません。
独立性
- 複数のユーザーによるオンラインショッピング: 複数のユーザーが同時に同じ商品を購入しようとしても、それぞれ個別のトランザクションとして処理されます。 在庫管理システムは、各トランザクションを独立して処理し、他のユーザーの購入操作の影響を受けないようにします。
耐久性
- 航空券の予約: 航空券の予約は、耐久性のあるトランザクションとして処理されます。 予約が完了したら、たとえシステム障害が発生しても、予約情報は失われることはありません。
これらの例は、ACID 特性が現実世界のシステムでどのように重要であるかを示しています。 データベースシステムは、ACID 特性を保証することで、データの整合性と信頼性を保ち、ユーザーにとって安全で信頼できるシステムを提供することができます。
def transfer_funds(from_account, to_account, amount):
"""
口座 `from_account` から口座 `to_account` へ `amount` 金額を振り込む
Args:
from_account (int): 送金元口座番号
to_account (int): 送金先口座番号
amount (float): 送金額
Raises:
ValueError: 送金額が負の場合
InsufficientFundsError: 送金元口座の残高が不足している場合
"""
if amount < 0:
raise ValueError("送金額は負の値であってはいけません")
# 送金元口座の残高を取得
from_account_balance = get_balance(from_account)
# 送金可能かチェック
if from_account_balance < amount:
raise InsufficientFundsError(f"残高不足: 送金元口座の残高は {from_account_balance} ですが、送金額は {amount} です")
# 送金元口座の残高を更新
update_balance(from_account, from_account_balance - amount)
# 送金先口座の残高を更新
update_balance(to_account, get_balance(to_account) + amount)
def get_balance(account_id):
"""
口座の残高を取得する
Args:
account_id (int): 口座番号
Returns:
float: 残高
"""
# 実際のデータベースから残高を取得する処理を実装
pass
def update_balance(account_id, amount):
"""
口座の残高を更新する
Args:
account_id (int): 口座番号
amount (float): 新しい残高
"""
# 実際のデータベースに新しい残高を更新する処理を実装
pass
このコードは、以下の ACID 特性を示しています。
transfer_funds関数は、送金処理全体を単一のトランザクションとして実行します。 残高の更新操作はすべて同時に実行され、部分的に実行されることはありません。 成功するか失敗するか、いずれか一方です。
- 送金処理が完了すると、口座の残高は常に整合性のある状態になります。 送金元口座の残高が減少し、送金先口座の残高が増加する、という制約が常に守られます。
- 複数のユーザーが同時に
transfer_funds関数を呼び出しても、各トランザクションは互いに干渉しません。 他のユーザーのトランザクションの影響を受けずに、個別に処理されます。
- 送金処理が完了したら、その結果はコミットされ、永続的に保存されます。 ハードウェアやソフトウェアの障害が発生しても、送金結果は失われません。
ロックは、排他制御と呼ばれる手法を使用して、トランザクションが互いに干渉しないようにする方法です。 トランザクションがデータにアクセスする前に、そのデータに対してロックを取得します。 ロックが解除されるまで、他のトランザクションはそのデータにアクセスできません。
ジャーナリング
ジャーナリングは、トランザクションのログを別途記録しておく方法です。 トランザクションが失敗した場合、ジャーナリングを使用してデータベースを以前の状態に復元することができます。
コミットログ
コミットログは、トランザクションが完了したことを記録するログです。 コミットログを使用して、障害発生後にデータベースを復元することができます。
分散トランザクション
分散トランザクションは、複数のデータベースにまたがるトランザクションを処理する方法です。 分散トランザクションコーディネーターと呼ばれるコンポーネントを使用して、ACID 特性を保証します。
データベースの種類
ACID 特性を保証する方法には、データベースの種類によって違いがあります。 以下、一般的なデータベースの種類と、それぞれが ACID 特性をどのように保証するかについて説明します。
リレーショナルデータベース
リレーショナルデータベースは、ACID 特性を保証するためにロックやジャーナリングなどの手法を使用します。
NoSQL データベース
NoSQL データベースは、ACID 特性を保証する方法が様々です。 一部の NoSQL データベースは、ACID 特性を完全に保証しますが、他のデータベースは CAP 定理と呼ばれる制約に基づいて ACID 特性を部分的にのみ保証します。
CAP 定理
CAP 定理は、分散システムにおける一貫性、可用性、耐障害性の 3 つの特性のトレードオフを定めたものです。 この定理によると、3 つの特性をすべて完全に保証することはできません。 NoSQL データベースは、CAP 定理に基づいて、どの特性を優先するかを決定します。
database acid
