CouchDBその他について思うところ徒然
ある人にCouchDBの潮流ってどうよ？と聞かれたので，興味をもって多少調べてみたら結構いろいろ言いたいことが出て来てしまい，自分の考えもなかなかまとまらないなーと思いつつ，とりあえず書いてみた文をそのまま載せてみる．
CouchDB に関して，名前は知っていましたが，中身は知りませんでした．DBLPで検索しても，論文らしきものは見付かりませんでした．アカデミアでは注目されていないのではないかと思います．
せっかくなので，少し調べて，色々考察してみました．公式サイトの説明が一番詳しいようです．
http://couchdb.apache.org/docs/intro.html
http://couchdb.apache.org/docs/overview.html
・データベースシステムとしての特徴について
Relational DBMS に対して，Google や Amazon がデータインフラのレイヤで何を犠牲にしているかといいますと，ACID特性のうち，Consistency と Isolation の部分です．CouchDB も同様です．各社微妙に違うのですが，Conflict の解決を Application に委ねるようになっていたり，Secondary index 的なものが使えなかったりします．Google や Amazon は，彼等のメインアプリケーションのために，Relational DBMS で出来ることのうち必要十分な機能のみを，コモディティ分散環境で高速，大規模に動くようにしたものであると言えます．逆に，今の Relational DBMS の全機能を既存の技術でGoogle や Amazon のような分散環境での巨大なデータベースに対して適応しようとすると，簡単に性能面で破綻します．全然スケールアウトしません．CouchDB はどちらかというと，ソースコードマネジメントシステムのGit などと同じようなコンセプトに見えます．(git push を自動でやるようなイメージ)データベース規模ですが，一台のサーバ上に格納できるサイズ以上のデータベースは作れません．つまり，データベースの仮想化は出来ません．また，せっかく replica があるのに，読み込みの負荷分散もデータベースシステムとしては現状では意識していないのではないかと思われます．
CouchDB でも採用されている Conflict の解決をApplication が行うべき，というコンセプトは従来の Relational DBMS よりも柔軟性があると言えます．Google や Amazon でもデータの versioning をすることで似たようなことをやっています．
・データ形式について
CouchDB で扱う半構造データというのは，データの関係性の定義をアプリケーションに依存するということの裏返しでもあります．データセマンティクス(Relation や Constraints) がデータベース側で完結していない，アプリケーション内にしか記述されていない情報があるということです．すなわち，アプリケーションによって，同じデータの扱いにぶれが生じる恐れがあります．これは，XMLでも同じですね．複数のアプリケーョンで同じデータを扱うときは注意する必要があります．
個人的には，データのセマンティクスは可能な限りデータベース側に集約させて，かつ柔軟性があるものを実現することは可能であり，また，そうするべきだと思っています．それは今の Relational Database でも，XML Database でもありません．本質的なデータ構造の表現形式があり，そのサブセットとして，Relational Database とXML Database を表現できるはずです．(近年アカデミアで起こっている RDB と XML DBの闘争は私からは不毛な争いに見えます．)この辺の話はきちんとやれば論文になるのではと思っているのですが．．．
XMLなどのようにテキストのままデータを格納する，というのは性能面で問題があります．ポータビリティが必要なのであれば，それは，View として表現すべきで，実際の data representation は，コンピュータにやさしい形式にすべきです．CouchDB はこの考えに近くてちょっとうれしいです．
・データアクセスインターフェースについて
インターフェースは，これも解釈にぶれがなければ何を使っても問題ないと思います．CouchDB の場合は，RESTという標準(？)でデータアクセスできるわけですが，wrapper を書けば他のDBMSでも同じことは出来るわけですから．そういう意味では，SQLという言語は結果にぶれはないのですが，高速な実行メソッドが，データの分布やそのレイアウトなどに依存し，オプティマイザが大変という側面があります(大変なのはほとんどJoin)．MapReduce は高速な実行メソッドがほぼ一意に決まります．
・MapReduce について
CouchDB の MapReduce 処理は，全ての Replica に対して，処理を分散させているのかどうか，ちょっと確認できていません．Replica が増えればその分 MapReduce の速度が上がるようになっていれば良いのですが．．．MapReduce は，Relational 演算のうち，Projection，Selection，Grouping，Sorting，Aggregation，しかサポートしません．Product や Joinは，MapReduce を直列に実行することでエミュレートできますが，本来はもっと高速に実行できるはずです．ただし，これは上で述べたように難しい問題だと思いますから，みんな避けているのだと思います．Microsoft も Dryad とかいう cloud フレームワークで頑張っているみたいですが．．．
・まとめ
ドキュメントから想像される CouchDB の設計のシンプルさはインフラ屋としては好感が持てます．彼等がターゲットにしている，オフライン時でもアプリケーションを動かせて，オンラインになったら勝手にデータをサーバと同期する用途に使う分にはいいかも知れません．データベースシステムとしてはあまり期待できません．
とりあえず思ったことをつらつらと書いてしまいました．考察が足りず，勘違いしているところがあるかも知れませんが，ご参考になりましたら幸いです．
