楽天OSは画餅か否か？
単一のアプリケーションで4TByteものファイルデータをメモリにおく需要なんてほとんどありません。もし4Tもファイルがメモリ上に展開されていないとパフォーマンスが発揮できないのだとしたらアプリケーションのアーキテクチャが悪いのです。
その中でどうしても単一のアプリケーションで巨大なファイルを利用する必要があるのがDBです。うっかりしているとDBファイルのボリュームが100GByteを超えることがあります。
おそらく、各社の分散ストレージの開発者達は、DBのファイルの利用を前提に考えているかとおもいます。そうなると、インターフェイスはファイルシステムではなく、SQLをインターフェイスにした、分散DBシステムをつくったほうが需要があります。
Hadoopでは、Write Accessを次のように処理しています。
Files in HDFS are write-once and have strictly one writer at any time.
上書きするとブロック単位で過去のBlockは破棄されて、別のBlockを作成するようです。うーん、ブロックの更新、同期中はファイルにまったくアクセスできないのか、過去のBlockを参照されるのか・・・どっちにしても、Write Shareを許さない場合は、DB的にはアウトですね。
今後を注視。
2009/05/31 追記
ROMAについては以下の指摘がありました。
今後の課題。データを永続化をしてディスクに保存し、障害時のリカバリーに使う技術を考えている。
また、パフォーマンスチューニングも重要。たとえば、RubyのGCにかかるオーバーヘッドが問題なので、解消したい。案としては、Rubyの拡張ライブラリとして実装して、そこにデータを格納し、メモリは自主管理するというの考えもある。パフォーマンス面では、パフォーマンスと一貫性はトレードオフなので、さまざまなモデルを追加し、アプリケーションによって、一貫性をゆるめてパフォーマンスをあげることもできるようにすることも考えている。
