CouchDB第一印象

9th Jan, 2010 | couchdb

普通にRDBMSをデータベースとして使っているのだが、最近の流行りに乗ってKey-Value型のデータベースもちょっと見てる。

そんな中、少し前にCouchDBで遊んでたときに書いたメモ。ほんとにメモだけど公開してみよう。

最初の一歩

色々ググったりブログ見たりするより、とりあえず http://books.couchdb.org/relax/ を読むのオススメ。日本語翻訳が始まってるようです（私は参加してないですけど）。

CouchDBの魅力

最近あちこちでCouchDBの紹介を見るのでいまさら感はあるけど、その中でも自分が特にいいなと感じるCouchDBの魅力は、

スキーマレス

これはKey-Value型DBでは当然の機能っぽいけど、RDBMSと違いテーブルのカラム情報をDB側にあらかじめ持っておく必要がない。なんでも格納できる。このため、テーブルの情報みたいのをアプリケーション側だけに持たせられり。RoRとかで言うとMigrationスクリプトをしこしこ書く必要がない。もちろんデータ移行/更新が必要な場合は別だけど。

柔軟なViewとインデックス

Key-Value型ですが、Valueを検索KeyとしてViewを定義するとかも簡単にできる。また、作ったViewはデータの更新にあわせてインデックスが張られる。たとえば、複数ユーザが同一のViewの情報を欲しい場合にもView自体は同じ実体を見るので２度目からは非常に早いはず。また、データ追加/更新時にはすべてのViewが作り直されるわけではなく、変更になった部分だけ自動的に更新される（でもこのため？にViewはB treeで格納できるように作らないといけないので、そこがちょっと難しい）。このためデータの更新が激しい場面でも向いてそう。

マルチマスタな非同期レプリケーションが標準装備

レプリケーションが簡単にできる。また非同期かつマルチマスタなので書き込み時のスケーラビリティも高そう。もちろんデータの衝突後の処理はプログラマ側が書かないといけないけど。

制限

データを分割して分散できない

大量なデータがあって、それを分割して複数のサーバに分散する、と言ったようなことは今のところできないっぽい。レプリケーションは単純にデータベース全体をコピーみたい。

Viewは何でも作れるわけではない

例外も色々あるが、RDBMSでいうテーブルを３つJoinみたいなことはできない。２つならできます。（全般に言えることですが、RDBMSのことはきれいさっぱり忘れて考えた方がいい。が、どうしてもRDBMS脳なんで比べてしまう。）

そんなわけで、

ちょっとまだアプリケーションで使うのは辛いという印象。特にViewを作るのに手間がかかりすぎる感がある。ちょっとしたアプリケーションを作るにもいちいちViewをいくつか作って、それを使ってさらにアプリケーション側も実装する、というのはいまどきのスピード感から言うとちょっときつい。

そんなわけでmongoDBに流れてしまった自分であったのでありました。


記事の内容についての質問、苦情、間違いの指摘等なんでもtwitterでどうぞ。