今のデータベースシステムでは、トランザクションはACIDという考え方が基本になってます。
これらの用語の頭文字をとってACIDです。
- Atomicty 原子性：トランザクション中の処理は全部行われるか全く行われないか
- Consistency 一貫性：トランザクションが完了したとき、データの状態が正しい
- Isolation 分離性：複数のトランザクションが実行されても、完了してないトランザクションが他のトランザクションに影響しない
- Durability 永続性：トランザクションが完了したら、その状態は保存される。
ただ、分散システムでACIDを適用しようとすると、複数のサーバーで処理を分担させたときに一台のサーバーがこけてたらトランザクションが全く行えないとか、トランザクションマネージャーがボトルネックになってしまうとか、スケールアウトしにくくなってしまいます。
Brewerという人が、一貫性(Consistency)・可用性(Availavility)・並列性(Partition tolerance)のすべては同時に満たせないということをCAP定理として述べてます。並列性を取るなら、一貫性か可用性の条件を緩和する必要があるということです。
そこで、ACIDに代わるトランザクションの考え方として、BASE(basically available, soft state, eventually consistent)というのをeBayの人が提唱してます。
http://portal.acm.org/citation.cfm?id=1394128&coll=GUIDE&dl=GUIDE&CFID=15360073&CFTOKEN=63811219&ret=1#Fulltext
URL長いので、tinyurlで http://tinyurl.com/base-acid でいけるようにしてみました。
ここでは、連続したトランザクションについて、メッセージキューを間にいれることでトランザクションを分離して、厳密な一貫性を捨てて並列化やりやすいようする例が取り上げられています。トランザクションが処理された時点では一貫性が保たれませんが、メッセージキューが処理された時点で最終的に一貫性を保つということです。
ここでは、メッセージキューの処理を確実に行うために注意が必要であることも例示されています。
CAP定理と、ACIDとBASEの比較は、このPDFの3ページ目後半から図示されてます。
http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
別の文脈からですが、JBossの資料でも「ACID トランザクションは、以下のような理由で 全ての Web サービスには適切ではありません」としてますね。「第2章トランザクションの概要」ここではWebサービスの制御不能性を問題にしています。
JBoss トランザクション Web サービスプログラマガイド
ところで、ACIDは良くパッケージ化されていて、RDBMSを使っていれば何も考えなくても実現ができます。AOPでトランザクション対応できるようなフレームワークを使えば、beginやcommitすら必要ありません。
けど、BASEなどACIDをすてて自分たちでバランスをとる場合には、この記事にもかかれているように「エラーリカバリがアプリケーション開発者の手に委ねられる」のが現状です。CAPのそれぞれの属性について、自分たちが必要なバランスでアプリケーションを組む必要があります。
分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れる
ということで、ACIDに頼れないシステムが増えてくることを考えると、トランザクションを理解するということは重要になってくるんじゃないかなと思っています。
あと、プログラム言語の未来について、今後は並列処理の書きやすさが重要になるといわれていますが、システムでの並列処理を考えたときにはメッセージキューが大事になると思います。
