Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
58 lines (31 sloc) 4.15 KB
title tags
トランザクションレス
database
application architecture

http://martinfowler.com/bliki/Transactionless.html

数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。

トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって(私もそうだが)トランザクションはデータベースを使う利点のひとつだ。

eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテション分割しており、 それがトランザクションを使わない理由に拍車をかけていた。 その状況でトランザクションを使うとなると、分散トランザクションを使わざるを得ないからだ。

高度にパーテショニングするというのがパフォーマンス問題におけるデータベースの中心的な役割であり、eBayではその他のデータベース機能を使っていなかった。 参照整合性やソートなどはすべてアプリケーションコード側で行っており、トリガーやストアドプロシージャも使っていなかった。

その話を聞いたとき、私はすぐに「アプリケーションプログラマへの影響はどうだった?トランザクションがないことについてはどんな感じだった?」と質問した。 答えは「最初は変な感じだったけど、あまり問題にならなくなった。考えていたほどの問題はなかった。データベースコミットの順番については、より重要なものを先に処理するなどして、注意を払う必要がある。また、各コミットが成功したかどうかを確認する必要があるし、失敗した場合にどう対処すればよいかも決めておかなければならない」というものだった。

このプログラミングスタイルは非常に興味深いものだった。 だがその時はおとなしく話を聞いていて、誰かに言いふらしたりはしなかった。 今になってこの話ができるのは、Dan Pritchettが今週のQConでeBayのアーキテクチャについて講演したからだ。そこではこのトランザクションレスの話についても述べられていた。(インタビューだけでなく、彼の講演もInfoQに掲載されるといいのだけれど)

私はこのようなトランザクションレスのプログラミングについて、もっと詳しく知りたいと思っている。 代替案を考えることは重要だという意味もあるが、それよりもこれは、トランザクションレスは多くの人たちが考えている以上に普通のことなんだという事例である。 複数のリソースを使ってマルチステップビジネスプロセスを実行するのはよくあることだ。 そこでは長時間の分散トランザクションやトランザクションをサポートしないリソースが必要となる。

この話を深読みしてはいけない。 誰もトランザクションをツールボックスから叩き出せと言っているわけではない。 eBayが、少なくとも彼らにとって、トランザクションを使用しない手法が正しいと判断した理由を私は与り知らない。 だがeBayの事例は、トランザクションなしでやっていくことは思っているほど不可能なことではないことを示している。

参考

You can’t perform that action at this time.