なぜCouchDBなのか。
私もRailsいらねーや、ってくちなので、殆ど同じです。というか、自分で作ったRailsアプリは、仕事のものも含めて、CouchDB への移行したし。
そういうのが嫌で、RDBMSとして正しく使おうと、find()で:includeとか:joinsとか使いだすと、今度はどんどんRoR(Ruby)のコードのSQL成分が増していく。全然楽しくない。
それに加えて、私の周りだとXMLDBサポート、なんてものが入って混沌としていました。XMLいいたいだけだろ的な。XQueryとか、全然人に優しくない。
あとは、RESTの議論というかアプリケーションをみていて、多くのアプリが sql://example.com/ をブラウザでやりたかっただけじゃね？ってところで*1、CouchDBはGood Enough Technologyだと思ったわけです。
数あるKVSの中でCouchDBの何がよかったのかと言うと、、、
- どうぜ画面駆動でしか開発できないでしょ？*2。だったら、HTMLで書いた画面をそのままCouchDBにおいて動かせばいいじゃん。MongoDB含め、他のNoSQLだと、どうしても、PHPとかRubyとかJavaとか、面倒なレイヤーがはいっちゃう。
dW の第2回で書いたRailsのサンプルアプリでmodelとcontrollerで150行ぐらいあるのですが、CouchDBだけでやれば、(経験上) 1/3 以下に圧縮できるので、ドキュメント指向でやる場合に、アプリケーションサーバーは不要、とはいわないまでも必須ではない、という話。そりゃ、そもそもユーザーが扱う"ドキュメント"をそのまま格納しているんだから、アプリケーションサーバーでやることは極端に減るわけですよ*3 *4。
- Hadoop の "Moving Computation is cheaper than moving data" を拡大解釈して、必要に応じてアプリケーションまるごとユーザーの手元に飛ばしといて、できる限り計算させておけばいいじゃん、という方法がとれそう。
これは、最近感じていることで、ユーザーがほしいComputationは自分の周りの数ホップぐらいなので、その数ホップをサーバーで丸ごとやるぐらいだったら、手元でごりゃっとやっちゃえばいいじゃない、とか。ビジネス用途に向くかどうかは不明ですがね。
そんな話をじっくり誰かとしたいのですが、OSCは時間もないので、さわりだけ話してその当たりの議論をしたい方を探したいです。KVSがスケーラビリティの側面で注目を集めているのは事実だと思いますが、自分の興味としてはスケーラビリティよりも、データモデルとか開発手法とか、その辺の方が興味の対象。スケーラビリティへの要求はアプリケーションによると思うので。
そんなわけで、CouchDB始めてみようという人がいたら、以下を試してみて、直感で感じ取ってください。銀の弾丸じゃないので合わない人には合わないと思います。
http://dl.dropbox.com/u/219436/CouchDB/PythonHackathon3/handson/_build/html/90_quickmaster.html
*1:それがRESTなのかどうかは自分にとってはどうでもいい
*2:これは技術者として認めたくないんだが、事実は事実ってことで
*3:Web で画面駆動開発されると結構しんどいのは経験のある人も多いかと思いますが、MS Access の画面駆動開発は全然苦になりませんでした。というか、ユーザーの目の前で画面とクエリとコード書いて、これでいいですよね、ができるのがAccess。その辺りの感性も働いたんだと思います
*4:問題は Server Side JavaScript が未成熟というか、JavaScriptをPHPやRuby、Javaのようなものと同等に使うのに違和感を覚える人がかなりいるようなので、そこはしばらく様子を見る必要があると思います
