地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【DB】ACIDの話

Atomicityとは

トランザクションが残す結果が、すべてのトランザクション内操作が成功したか、もしくはすべて無かった事になったかのAll or Nothingになる特性の事をいう。不可分だとかは関係ない(というかトランザクションの個々の操作はインターリーブされることを前提として考えるので可分かどうかは主題ではない)。 複数のデータに読み書きをするにしても、全部のデータに対する更新が成功したか否かが中途半端な結果にならずに終わるという性質である。

Consistencyとは

予めシステムに与えた制約条件(存在しない外部キーを参照してはならないとか)を破るようなトランザクション成功しないという特性である。Atomicに操作が行われてるならConsistencyが破られる事はないんじゃない?という疑問を浮かべる人もいるが、トランザクション操作というのは容易に制約(Constraint)を破る。この用語が提唱された頃はシステムに与える制約条件として詳細なアプリケーションのドメイン知識を埋め込めばトランザクションに乗っかるだけで全部ハッピーというような構想があったようにも見えるが、イマドキの開発ではUNIQUEとかNOT NULLとか結構限定的な制約しかロクに使われていないように見える。 ActiveRecordなどはユーザレベルで制約条件に相当するような仕組みを作りこんでおり、どこまでがDBの責務であるべきかというのは結構難しい問題である。 Peter BailisらによるFeral Concurrency Control: An Empirical Investigation of Modern Application Integrityの論文なんかでは「DB開発者がせっかくトランザクションの仕組みを作りこんだ割にアプリ開発者たち(とORマッパ作者たち)はほとんどトランザクションを使わず、データのValidationやらユーザレベルでの不変条件保護に労力を割いている。本当に必要なのは現状のリレーショナルモデル+トランザクションではないのでは?」と問題提起をしており大変興味深い。長くなってしまったので詳細はまた別の記事で。

Isolation

トランザクションを実行する過程が外のトランザクションから独立して見えないという性質を言う。Atomicityは結果についてしか議論していない一方で、Isolationは過程の可視性に関する議論である点が多くの人にごちゃまぜに認識されやすい箇所である。 さて、トランザクションの実行過程が外のトランザクションから見えてはダメかというと厳密な事を言うと過程が外のトランザクションから見えてしまっても問題はないケースは考えられうる。極端な話、VSRであれば自分以外のトランザクションによる未コミットな値を読んでしまってもそっちのトランザクションがコミットした後に自トランザクションをコミットに持っていくのは有りであるし、Serializableであればどうとでもなる。 また、世の中の一般的なDB(Oracle, MySQL, PostgreSQL, SQL Server, DB2などの有名ドコロ)のデフォルトのIsolation Levelは最弱より1〜2歩強いだけでありこれをもってして「ACIDのすべてが守られています」なんて言うと顰蹙を買うことになる。よってACIDのうち一番ないがしろにされがちな不憫な特性である。 Isolation Levelに関する詳細は明日まとめて書く。

Durability

トランザクションがクライアントに完了をひとたび報告したなら、そのトランザクションの結果は上書きされない限り例え電源が消されようと残る、という性質である。どの永続デバイスにどのように保存されるかは規定しておらず、ディスク上のDBに変更が反映されているかも知れないし、Redoログの形で残っているだけかも知れない。 大学の時この話を聞いて「じゃあHDDが物理的に壊れても残るの?」と素朴な疑問を抱えたものだが、結論から言うとデータベースを格納しているHDDが突然吹き飛んでもメディアリカバリという仕組みで復旧できる所までセットでのDurabilityのようだ。メディアリカバリはログデータを必要なだけリプレイすることでメディアのデータを再生成するわけで、ログデータは常に安全な場所に(永久に)保管されて消失しない前提を暗黙に置くことが多い。とすると「ForceするタイプのDBはRedoログは要らない」と僕は過去に書いたが、ログからのメディアリカバリの為に結局Redoログをアーカイブに保存する必要がある事になる。 このDurabilityという特性はナイーブに実装するとパフォーマンスが全く出ない。それを改善するために人類が積み上げてきた最適化の歴史が面白いからいろんな人に知ってほしいというのがそもそもこの1人アドベントカレンダーを書いている主たるモチベーションであり、いろんな人に伝わったら嬉しいなと思っている。