トランザクションとは【ACID vs BASE】

ここでは、以下の観点で、データベース処理について解説します。

• トランザクションとは
• ACID
• BASE
• CAP定理

トランザクションとは

トランザクションは一般的には商取引を意味しますが、情報システムの分野では、
分けることのできない一連の情報処理の一単位
を指します。

ACID

トランザクションの信頼性をデータベース上で実現するために不可欠な性質がACIDで、次の要素から構成されます。

• 原子性（Atomicity）
  トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質。
  口座Aから口座Bに対し1万円送金する場合を考えたとき、送金操作は次の2つのタスクによって行われます。
  口座Aの残高から1万円を引く
  口座Bの残高に1万円を加える
  原子性が保証されるとは、上のタスク1、2が全て行われるか、あるいは全く行われないことを指します。
• 一貫性(Consistency)
  トランザクション開始時と終了時に予め与えられた条件を一貫して満たすことを保証する性質 。
  開始時は満たしているが終了時は満たしていない場合、一貫しえて条件を満たしているとはいいません。
  なので、一貫性条件を満たさない状態を起こすようなトランザクションは実行が中断されます。
  なお、一貫性ですが、与えられた条件にたいしてい矛盾がない（整合している）必要があることから整合性とも言われます。
  また、処理の開始時から終了時まで一貫して満たすべき条件のことを不変条件（Invariant）といいます。
  先の送金の例でいうと、トランザクションの開始時、各口座の状態が
  口座Aに１００万円
  口座Bに１００万円
  であった場合、処理の終了時には
  口座Aに99万円
  口座Bに１０1万円
  という状態でないと一貫性が保証されていないことになります。
• 独立性(Isolation)
  各トランザクションがそれぞれ独立していることを保証する性質。
  先の例の送金トランザクションと同時に、口座Aから１００万円現金を引き出すトランザクションが実行された場合を考えてみましょう。
  それぞれのトランザクションが独立していないと
  口座Aに１００万円←送金トランザクションと引出しトランザクションが同時に発生
  口座Aに０円←引出しトランザクションの実行
  口座Aに-1万円←送金トランザクションの実行
  口座Bに１０１万円←送金トランザクションの実行
  結果、
  口座Aに-1万円
  口座Bに１０1万円
  という状態になる可能性があります。
  なので、一方のトランザクションが終了してから、他方のトランザクションを実行する必要があります。
  この独立性を保証するためにデータベースに設けられた機構が、トランザクションの排他制御、あるいは、同時実行制御です。
• 永続性(Durability)
  トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを保証する性質。
  先の送金の例でいうと、ユーザーがトランザクション操作の通知を受けた時点で、別のトランザクションが発生しない限り、永続的に以下の状態になっている必要があります。
  口座Aに99万円
  口座Bに１０1万円

BASE

大量で多様なデータを高速に処理することを求められるビッグデータの時代、ACIDを保持することが困難になってきました。
そこで、カリフォルニア大学バークレー校の計算機科学の教授エリック・ブリュワーによって、よりビッグデータに適したデータベース処理の性質、BASEが提唱されました。
BASEはNoSQLの設計思想になります。
BASEは、次の要素から構成されます。

• Basically Available
  基本的にいつでも利用できるという性質。
  例えば、ACIDのトランザクションの場合、独立性を保持するために処理Aのために処理Bがロックされ待たされることがあります。
  Basically Availableの場合、処理Aのために処理Bが待たされることはなく、処理Aの最中でも処理Bが実行されます。
  例えば、キューによる非同期メッセージングや、RDBの楽観ロックなどでBasically Availableを実現することができます。
• Soft-State
  常に整合性（一貫性）を保っている必要はないという性質。
  ACIDのトランザクションのように、常にに整合性（一貫性）を保持できていなくても良いということです。
  例えば、分散されたシステムでデータの整合性（一貫性）を確保する場合、一時的に整合していない（矛盾している）状態があり得ます。
• Eventual Consistency
  最終的には整合性（一貫性）が保証されるという性質。結果整合性といいます。
  ACIDのトランザクションのように、原子性を持って確実に整合性（一貫性）を保証しなっくても、結果的（最終的）に整合性（一貫性）が保証できていれば良いということです。
  例えば、分散されたシステムでデータの整合性（一貫性）を確保する場合、一時的に整合していない（矛盾している）状態があっても、最終的に整合させることはできます。
  結果整合性を実現する方法には、Sagas、CQRS、非同期メッセージングなどがあります。

このように、BASEを受け入れることによって、厳しい制約がない分、大量のデータを分散させ、高速に処理することができます。

CAP定理

BASEのエリック・ブリュワーによって提唱された定理で、分散システムの場合、同時に次の2つの性質を保証することはできるが、同時に３つの性質を保証することはできないというものです。

• 一貫性(Consistency)
  全てのノードで同時に同じデータを確認することができるという性質。
• 可用性(Availability)
  どのノードで障害が起きても処理の継続性が失われない性質。
  単一障害点（システムを構成する要素のうち、そこが停止するとシステム全体が停止してしまう部分）がないということです。
• 分断耐性(Partition-tolerance)
  どのような通信障害が起きてもネットワークが分断されることがないという性質。
  ネットワークの分断にたいする耐性が高いといういことです。

分散システムの場合、複数サーバにデータの複製を持つことで可用性や分断耐性を上げることができますが上の３つを同時に実現することはできないということです。
それでは、同時に上の2つの性質を保証する場合を考えてみましょう。

• CとA(C:一貫性とA:可用性を重視)
  データはいつでも利用可能で一貫している必要があります。
  システムを分散させず、単一のデータベースサーバーで実現することは可能です。
  テーブルの結合、トランザクション、参照整合性を含むリレーショナル機能を持つリレーショナルデータベースは、通常、このパターンで、データを複数のサーバーに分散させず、単一のサーバーにさらにリソースを追加することで垂直方向にスケーリングします（スケールアップ）。
• CとP(C:一貫性とP:分断耐性を重視)
  データを分散し、かつ、整合性を確保する必要があります。
  整合性保持のため、複製中は全てのノードでデータ更新されるまで　ロックをかけて不整合を阻止する必要あります。
  なので、ロックがかかっている最中は利用可能（Available）ではありません。
  リレーショナルデータベースでは、分散トランザクションを２フェーズコミットなどの技術を使って実現しますが、パフォーマンスが低下します。
• AとP(A:可用性とP:分断耐性を重視)
  データを分散し、かつ、いつでもデータに利用可能である必要があります。
  データの複製中は一時的に不整合な状態になり得ます。
  BASEのSoft-StateとEventual consistency（結果整合性）を受け入れる必要があります。
  テーブルの結合、トランザクション、参照整合性など複雑な機能を持たないNoSQLは、通常、このパターンで、複数のサーバー間でデータをパーティション分割してレプリケートすることで、冗長性とフォールト・トレランスを確保します（スケールアウト）。
  ※フォールト・トレランス
  システムや機器の一部が故障・停止しても、予備の系統に切り替えるなどして機能を保ち、正常に稼働させ続ける仕組み。

以上、今回はトランザクションと、それに関わるデータベース処理の性質について解説しました。