データストアの方法とか・・・

アリエルの最初の製品はP2P型のグループウェアで、データはXMLとしてファイルシステム上の保存しているとはどこかで書いたような気がします。今の主力製品はP2PではなくてWebアプリケーションとしてグループウェアを作っています。Lotusのころから考えると、グループウェアが好きなのか、一番知っているからたまたまそうなったのか・・・。

そのグループウェアですがデータストアにはOracle様のRDBMSを使っています。言語はJavaで作っているので、結局、いろいろなものがOracleに集約されていくように感じます。XMLではなく、RDBMSを選択したのはパフォーマンス上の理由です。開発が始まった４年か５年前にもオブジェクトデータベースとか、変なデータベースがありました。もっと前のあり得るができる前後の2000年ぐらいには、これからはXMLだと言われていましたが、RDBMSは未だに主流です。RDBMSをXMLにマッピングするのは無理があるとか、蔑まれたりもして、オジェクとデータベースだ、と聞いたこともありますが、やっぱりまだ、RDBMSです。NoSQLでキーバリューストアだと見せかけて、MySQLもPostgresも面白い動きを見せていて、やっぱり目が離せません。この後にインデクシングの話をしようかと思ったのですが、それはまた、別の機会に。

さて、RDBMSを選択しましたが、当初のもくろみから、テーブル構造はころころかわるものを想定していました。 これは、Notes/Dominoを強く意識していたためです。Notesほどエンドユーザコンピューティングじゃなくてもいいのですが、もっと簡単にユーザがアプリケーションを開発できる環境を提供したく、そのためにはテーブル構造が固いのは不都合だったからです。

で、最初の実装では、NoSQLのキーバリューストアのように、キーバリューを保持するテーブルにすべてを保存して、あとはそれらを適当にインデクシングできるようにしてパフォーマンスを稼ごうという戦略でした。この戦略はある程度まではうまくいきましたが、ある一定量のデータを超えると次第に遅くなっていきました。まあ、そりゃそうですね。

で、その次に考えたのが、テーブルをもう少し分割して、データタイプに応じて分割したりするものです。こちらは最初の方法の延長線上なので比較的簡単なのですが、本質的に同じ問題をはらんでいます。以前、とあるシステムで月ごとにテーブルが分割されていてとても扱いにくかったので、それはさけたかったのです。(月ごとにテーブルを分割するのが適切なアプリケーションではなかったのに)

で、その次のものが今の形です。それは、テーブルを動的にどんどん変更してきます。動いている最中にテーブルを変えるので、とってもいやんです。しかも、クラスタリングしてアプリケーションサーバーが複数あると、動いているのが不思議なくらいです。いや、動くように作っているんですがね。で、カラムが増える分には割と問題ないのですが、減るときは、こっちもあんまり問題ないですね。でも、データタイプが変わるときは、うーん、がんばっています。 

で、データの保存の仕方は変わるんですが、その上で動くアプリケーションはほとんど変更を加えていません。アプリケーションはデータストアを全く意識する必要がないのはすてきなことです。データベースをよくわからないエンジニアも、ごりごり何かを書いています。これがフレームワークがすごいところなんですね。

ということで、次はまた、思いついたことを適当に書いています。