Mongoと比較

http://blog.madoro.org/mn/35 という記事を読みました。ここ数ヶ月CouchDBで作ったアプリをMongoに移してみたりしたりとかもあったので、もちょっとコメントします。

複雑なViewを作ろうとすると挫折する。(例えば、A:B=1:N と B:C=1:N のような構造で、Cをキーとして、BとAも持ってくるView、とかはたぶん無理。RDBMS的に言うとJoin2回以上は無理、な感じ。)

これは、RDBMS的にやろうとするとはまりますね。でも、Webは巨大なデータベースである、と考えるとハイパーリンク先のハイパーリンク先をジョインしたい、という場面はそうそうあるものではない、と思います。そもそもN-Nのような構造とかを作る必要性を感じないので、Viewが複雑になる段階で、データ設計間違えとるやん！と自覚します。一方で、Mongoのほうは、間違えた、という状況が発生しないので、つっきれるのがいいのですが、どう設計すべきが、的なプラクティスが積みにくそうな気がしています。

各言語のライブラリ(mapper)では独自にそういうことをしているが、mapper間でそのメタ情報の互換性がない。

確かに、ライブラリ開発者の人には、なるべく他のライブラリも調べて、というかCouchRestを参考に作ってほしいなぁ、と思うものの、そもそもライブラリ使う必要性がないことに注意。CouchDBをやりたい人は、今までのWeb+DBのアーキテクチャー捨てる覚悟が必要です。っていうかCouchDBからMongoに移すときに、なんでまたプログラミング言語とフレームワーク選ぶ必要があるの、めんどくせー、とかそう思ったのは確か。今の仕事でも、DBに接続する、その1行がめんどくさい、と思ってます。

ただ、CouchDBが目指しているところはデータベースとアプリケーションがセットになったオールインワンなものなのかな、と感じる。

「スケールダウン」を達成するためにはアプリケーションの移動可能性を確保する必要があるので、アプリケーション自体をデータに紛れ込ませることになって、すなわちApp+DBのオールインワン、という結論に。

MongoDBの公式ページの最初の宣伝文句が「Combining the best features of document databases, key-value stores, and RDBMSes」だ。KVSとドキュメント指向データベースとRDBMSのいいとこ取りのデータベースを目指すと言った感じだろうか。

古典的なWeb+DBのアーキテクチャーの続きとしてのDocument DBを考えるのであれば、Mongoのほうがお勧めですね。

• データを直接コマンドラインから操作できるシェル的な物が付属されていたりと言った環境面

これはMongoがすばらしい。CouchDBはシェル環境が貧弱すぎ、ってかcurlでいいっちゃいいけど、クエリパラメーターとか覚えるの面倒だからhelpとかで出したいじゃん。など。で、Erlangで作ってみれば？という宿題もでているのでなんとかします。

そうなってくると、「なんでMongoDB？ "RDBMS"でいいんじゃない？」ということにもなってしまうので、その辺のバランスについては今後見ていきたいと思っている。

そうなんですよね。MongoDBはよさそうだなぁと思いつつも、CouchDBに比べて守備範囲が広いので、その分プラクティスを積むのに時間がかかりそう。

まったく新しいデータベースを目指しているCouchDB

これは誤解で、Lotus Notes/Domino をクラサバモデルから解き放つ実装です。

ということで、OSCのほうは、Notes/Domino の専門家にお越しいただく了解が得られました。時間は少ないですが、もうちょっと、ドキュメント指向って何よ、的なディスカッションを楽しめればいいかなぁと思ってます。問題は自分自身の参加可能性が結構怪しいこと。。。

CouchDBは、公式ドキュメントはいまいちだが、このドキュメント(本？)がすごくよくまとまっているので、最初にこれを読むのがおすすめ。

日本語版翻訳も少し。http://dl.dropbox.com/u/673631/couchdb/html/index.html。

この本の問題は、CouchDBじゃなくてCouchAppの事が書いてあったり、Loungeの事が書いてあったりすることで、その辺の話をCouchDBの話だと勘違いして読んでしまうと、実際に使おうとすると、つかえねーじゃん、と期待していただけにとっても残念な気分になることです。。