ちょっと前にFBで述べたDBMS不要論ですが、現時点のまとめをしておきます。(酒匂さん、野村さん、石橋さん、ありがとう)
発端は、コストは無視できないが、クラウドでオートスケールにした場合、DBMSを持たずに、オンメモリで処理できるかもという疑問から。
もちろん、メモリは無限ではないため、メモリスワップは発生する。また、DBMSは持たないが障害対応のために永続メカニズムは必要である。これはスナップショットとトランザクション単位のジャーナルで対応する。つまり、なんらかの不揮発性記録媒体は利用する。これらは、将来的にはクラウドに任せるとしても、いまは、さすがにクラウドに任せておくには不安がある。Hadoopに展開していたらどうなるかはいまは考えない。
リファレンスアーキテクチャとして、Object Prevalenceパターン(db.Prevalence)であり、リファレンス実装には以下がある。
- Common Lisp →CL-PREVALENCE
- .NET →Bamboo.Prevalence
- Ruby →Madeleine
- Python →Pypersyst
- Java →prevayler →
prevaylerは、インメモリDBに分類されるので、インメモリDBというならばそれは否定しない。
これは、商売として、DBMSは不要と言ってしまうと、ライセンスフィーがもらえなくなることに加えて、ユーザもDBがなくなるという不安があるからとうがったみかたをしている。
DBMSがない場合の懸念点として以下がある(もっと洗い出したい)。
KVSの欠点と同様と考えた(これらを解決すべくインメモリDBが生まれた)
・トランザクション管理
・排他制御
トランザクション管理については、prevaylerはJavaライブラリであるので、JTAで行える。つまり、実装言語の問題。ロングランニングトランザクションの問題は、本件に限った問題ではない。ジャーナル生成でどこまで耐えられるのかは不明。結果として、トランザクションDBが必要になるかも。いまのところは、変更するものではなく変更そのものを記録すれば、トランザクションオブジェクトの生成は必要ないと考える。
同様に、排他制御についても、ロック処理をプログラム上で、記述する必要がある。ロックについてもっと調べたい(MySQLのロックいいかも)。
ロックしないReThinkDBの考え方は面白いと思う。永続クラス(仮称)配下のインスタンスは、言語仕様として、ロック制御できればいいんじゃないか。永続クラスをMapとして、reduceにつなげるようにして、スケーラブルにしておくと面白いんじゃないかなぁ。
なお、参照されていないオブジェクトはGCの対象となる。つまり、永続化するためには、参照しておく必要がある。クラウドコンピューティングのためのGCを考えた方がよいのかもしれない。
こんなの面倒だから、DBMSを使おうよというのが現実なのかもしれない。まぁ、GLASSが流行らないのもこのあたりなんだろうな。
