mojix.org
CouchDBとMongoDBの使い分け
CouchDBとMongoDBをしばらく使ってみて、その使い分けのポイントがわかってきたような気がするので、ちょっと書いてみたい。
CouchDBとMongoDBは、広く「NoSQL」と総称されている非SQL型データベースのうち、「ドキュメントデータベース」と呼ばれるカテゴリを代表する２つだ。ドキュメントデータベースとは、かんたんにいうと、JSONデータ（＝ドキュメント）をそのままデータベースに保存できるというもので、従来のRDBのような「スキーマ」がない。複数のテーブルを結合（join）するという使い方をせず、一意キーの指定や比較的単純なクエリーでJSONデータを取り出す。
ここでは詳しい話には踏み込まず、２つのデータベースの違いを私の主観で、ごく大雑把にまとめてみる。
まず、それぞれの強みを私の印象で３つずつ書くと、こんな感じだ。
CouchDBの強み：
１）優れた管理画面「Futon」が付属
２）JavaScriptでWebアプリまで作れて、Webサーバも内蔵するオールインワン環境
３）JSONサーバとしてネットに直接公開し、JavaScriptから利用するという使い方ができる
MongoDBの強み：
１）従来のRDBの感覚で、かつさらにカンタンに使える
２）クエリーが柔軟
３）DBクライアントなどコマンド系が充実
私は最初、CouchDBのほうに強く惹かれた。長年Zopeをやってきた私は、CouchDBを知ったとき、「これこそ新時代のZopeだ」と思った。CouchDBは基本的にはデータベースだが、ブラウザの管理画面を持ち、Webアプリまで作れて、Webサーバまで内蔵するオールインワン環境である。データベースも追記オンリーで、ZopeのZODBにそっくりだ。
しかしCouchDBは、あくまでも基本はデータベースであり、どんな環境からでも使える。それも、アプリケーションとの通信までHTTPを使うという斬新な方式で、言語ごとのDBドライバみたいなものもいらない。Zopeがほぼ完全に閉じた世界だったのに比べて、CouchDBは必要に応じて、さまざまな環境から単なるデータベースとしても使えるし、完結したオールインワン環境としても使える。
そんな感じで、CouchDBは私にとって、「Zopeのいいところを受け継ぎながら、Zopeの限界を超えた」ものに見えたのだ。
しばらくはCouchDBにハマっていて、昨年12月に名称とシステムを変えたこのmojix.orgも、当初はCouchDBを使っていた（いまはMongoDB）。現在は更新が止まっているが、shortcutwebというサイトも、CouchDBで再構築した（いまもCouchDBで稼動中）。CouchDB自体がバーチャルホストつきのWebサーバを内蔵しており、「CouchApp」という仕組みでWebアプリも作れるので、まさにCouchDBだけで動的なサイトができるのだ。
しかし、その後CouchDBを使い続けていくうちに、いろいろカベにブチあたることが増えてきた。主に次の３つである。
CouchDBの弱み：
１）クエリーが柔軟に書けない
２）「テーブル」がない
３）データ更新のたびにデータベースが大きくなる
まず、いちばん困ったのが１）だ。CouchDBのクエリーは、JavaScriptを使って、MapReduce方式でインデックス（「view」と呼ぶ）を作成する。これ自体はよくできた仕組みなのだが、クエリーがいくらか複雑になってくると、だんだん破綻（はたん）してくる。
２）も困った。CouchDBには、RDBなどにもあるいわゆる「データベース」はあるのだが、その下の「テーブル」にあたる概念がない。「データベース」に、いきなりJSONデータを突っ込む方式である。よって、「テーブル」にあたるデータ種別を保持したいときは、JSONデータに「type」などのフィールドを作って入れておき、クエリー時に「type」の値で引き出すことになる。これが面倒なのだ。ただでさえ、複雑なクエリーが作りにくいのに、いつもこのtypeがクエリーに入ってくるので、そのぶんクエリーが複雑になる。MongoDBの場合、クエリーも柔軟に作れる上に、「テーブル」にあたる「コレクション」があるので、このような問題は一切ない。
３）は、データ更新の頻度が大きい場合に問題になる。これはZopeユーザにはおなじみの話で、例えばアクセスカウンタみたいなものをやろうとした場合、アクセスがあるたびにデータベースが更新され、データがだんだん巨大化していく。こういう追記オンリーのデータベースは、過去の履歴が自動的に残るのはいいのだが、「過去の履歴はいらない」という選択ができないのだ。
こうした経験をふまえて、CouchDBではやりにくい場合、MongoDBを使うようになっていった。MongoDBは、ちょうどCouchDBの強みと弱みを反転させたような感じで、CouchDBの持つ弱点はないかわりに、CouchDBの強みを持っていない。つまり、MongoDBの弱みはこんな感じである。
MongoDBの弱み：
１）管理画面が付属していない（コマンド操作が基本）
２）あくまでも「データベース」としての用途のみ
３）ネット越しの操作やレプリケーションなどはできない
これはいずれも、データベースとしてはあたり前の特性であり、普通の意味では「弱点」とは言えない。あくまでも、CouchDBと比べた場合の話である。
MongoDBは、従来のRDBと役割や使用感が似ているので、多くの人にとって違和感がないと思う。いっぽうCouchDBは、いろいろな点で斬新であり、かなりクセが強い。強みと弱みの「振幅」が大きいのだ。
私の場合、もともとZopeというやや特殊な環境になじんでいて、Zopeに似たところがあるCouchDBから入ったので、MongoDBには「欠落」を感じてしまうところがある。ZopeもCouchDBも、インストールしたらすぐにブラウザだけで操作できて、CouchDBなどは、ネット越しにレプリケーション（データの同期）までできる。すべての通信をHTTPで組み立てている強みだ。またデータのバックアップなども、データベースにあたるファイルをコピーすればおわりである。ZODBと同様、ひたすら追記していく方式なので、データファイルが壊れることもまずない。このようなCouchDBの便利さに慣れると、「ただのデータベース」であるMongoDBは、物足りない気がしてしまうのだ。
このように、CouchDBとMongoDBには、それぞれの強みと弱みがある。どちらも経験がなく、これから始めてみたいという人には、オーソドックスなMongoDBのほうをオススメする。人気度でもMongoDBが圧倒的に上のようで、おそらくあと数年もすれば、RDBも含めたすべてのデータベースのなかで、もっともポピュラーなデータベースになると思う。
いっぽうCouchDBは、データの更新が比較的少なく、サイト規模も小さくて、JavaScriptが大好きな人には向いているかもしれない。CouchDBの場合、「JavaScriptの使い方」は主に２つある。ひとつは、WebアプリのサーバサイドロジックをJavaScriptで書く「CouchApp」。もうひとつは、ごく普通のJavaScriptの使い方であるWebクライアントとして、CouchDBを「JSONサーバ」として使う方法。
ちなみにCouchDBは、Ubuntu Linuxに最初から組み込まれていて、一部のデスクトップアプリのデータを保持するのに使われているようだ。CouchDBはスマートフォンでも動くようで、これもいわば「デスクトップ」用途と言えるだろう。サーバ用途に比べて、デスクトップ用途はデータ更新も少ないし、HTTP経由でデータ操作やレプリケーションなどができるCouchDBは、たしかにデスクトップで威力を発揮する余地が大きそうだ。
王道でオーソドックスなMongoDBと、トガっていてクセの強いCouchDB。私にとっては、どちらも捨てがたい魅力があり、今後もケースバイケースで使い分けていくと思う。
関連：
CouchDB
http://couchdb.apache.org/
MongoDB
http://www.mongodb.org/
ウィキペディア - NoSQL
http://ja.wikipedia.org/wiki/NoSQL
関連エントリ：
ブログ名が「Zopeジャンキー日記」から「モジログ」になりました
http://mojix.org/2010/12/05/blog_rename
FriendFeedはどのようにスキーマレスなデータをMySQLに格納しているか
http://mojix.org/2009/02/28/friendfeed_schemaless
サーバの思い出、Zopeの思い出
http://mojix.org/2008/09/22/server_zope
CouchDBとMongoDBは、広く「NoSQL」と総称されている非SQL型データベースのうち、「ドキュメントデータベース」と呼ばれるカテゴリを代表する２つだ。ドキュメントデータベースとは、かんたんにいうと、JSONデータ（＝ドキュメント）をそのままデータベースに保存できるというもので、従来のRDBのような「スキーマ」がない。複数のテーブルを結合（join）するという使い方をせず、一意キーの指定や比較的単純なクエリーでJSONデータを取り出す。
ここでは詳しい話には踏み込まず、２つのデータベースの違いを私の主観で、ごく大雑把にまとめてみる。
まず、それぞれの強みを私の印象で３つずつ書くと、こんな感じだ。
CouchDBの強み：
１）優れた管理画面「Futon」が付属
２）JavaScriptでWebアプリまで作れて、Webサーバも内蔵するオールインワン環境
３）JSONサーバとしてネットに直接公開し、JavaScriptから利用するという使い方ができる
MongoDBの強み：
１）従来のRDBの感覚で、かつさらにカンタンに使える
２）クエリーが柔軟
３）DBクライアントなどコマンド系が充実
私は最初、CouchDBのほうに強く惹かれた。長年Zopeをやってきた私は、CouchDBを知ったとき、「これこそ新時代のZopeだ」と思った。CouchDBは基本的にはデータベースだが、ブラウザの管理画面を持ち、Webアプリまで作れて、Webサーバまで内蔵するオールインワン環境である。データベースも追記オンリーで、ZopeのZODBにそっくりだ。
しかしCouchDBは、あくまでも基本はデータベースであり、どんな環境からでも使える。それも、アプリケーションとの通信までHTTPを使うという斬新な方式で、言語ごとのDBドライバみたいなものもいらない。Zopeがほぼ完全に閉じた世界だったのに比べて、CouchDBは必要に応じて、さまざまな環境から単なるデータベースとしても使えるし、完結したオールインワン環境としても使える。
そんな感じで、CouchDBは私にとって、「Zopeのいいところを受け継ぎながら、Zopeの限界を超えた」ものに見えたのだ。
しばらくはCouchDBにハマっていて、昨年12月に名称とシステムを変えたこのmojix.orgも、当初はCouchDBを使っていた（いまはMongoDB）。現在は更新が止まっているが、shortcutwebというサイトも、CouchDBで再構築した（いまもCouchDBで稼動中）。CouchDB自体がバーチャルホストつきのWebサーバを内蔵しており、「CouchApp」という仕組みでWebアプリも作れるので、まさにCouchDBだけで動的なサイトができるのだ。
しかし、その後CouchDBを使い続けていくうちに、いろいろカベにブチあたることが増えてきた。主に次の３つである。
CouchDBの弱み：
１）クエリーが柔軟に書けない
２）「テーブル」がない
３）データ更新のたびにデータベースが大きくなる
まず、いちばん困ったのが１）だ。CouchDBのクエリーは、JavaScriptを使って、MapReduce方式でインデックス（「view」と呼ぶ）を作成する。これ自体はよくできた仕組みなのだが、クエリーがいくらか複雑になってくると、だんだん破綻（はたん）してくる。
２）も困った。CouchDBには、RDBなどにもあるいわゆる「データベース」はあるのだが、その下の「テーブル」にあたる概念がない。「データベース」に、いきなりJSONデータを突っ込む方式である。よって、「テーブル」にあたるデータ種別を保持したいときは、JSONデータに「type」などのフィールドを作って入れておき、クエリー時に「type」の値で引き出すことになる。これが面倒なのだ。ただでさえ、複雑なクエリーが作りにくいのに、いつもこのtypeがクエリーに入ってくるので、そのぶんクエリーが複雑になる。MongoDBの場合、クエリーも柔軟に作れる上に、「テーブル」にあたる「コレクション」があるので、このような問題は一切ない。
３）は、データ更新の頻度が大きい場合に問題になる。これはZopeユーザにはおなじみの話で、例えばアクセスカウンタみたいなものをやろうとした場合、アクセスがあるたびにデータベースが更新され、データがだんだん巨大化していく。こういう追記オンリーのデータベースは、過去の履歴が自動的に残るのはいいのだが、「過去の履歴はいらない」という選択ができないのだ。
こうした経験をふまえて、CouchDBではやりにくい場合、MongoDBを使うようになっていった。MongoDBは、ちょうどCouchDBの強みと弱みを反転させたような感じで、CouchDBの持つ弱点はないかわりに、CouchDBの強みを持っていない。つまり、MongoDBの弱みはこんな感じである。
MongoDBの弱み：
１）管理画面が付属していない（コマンド操作が基本）
２）あくまでも「データベース」としての用途のみ
３）ネット越しの操作やレプリケーションなどはできない
これはいずれも、データベースとしてはあたり前の特性であり、普通の意味では「弱点」とは言えない。あくまでも、CouchDBと比べた場合の話である。
MongoDBは、従来のRDBと役割や使用感が似ているので、多くの人にとって違和感がないと思う。いっぽうCouchDBは、いろいろな点で斬新であり、かなりクセが強い。強みと弱みの「振幅」が大きいのだ。
私の場合、もともとZopeというやや特殊な環境になじんでいて、Zopeに似たところがあるCouchDBから入ったので、MongoDBには「欠落」を感じてしまうところがある。ZopeもCouchDBも、インストールしたらすぐにブラウザだけで操作できて、CouchDBなどは、ネット越しにレプリケーション（データの同期）までできる。すべての通信をHTTPで組み立てている強みだ。またデータのバックアップなども、データベースにあたるファイルをコピーすればおわりである。ZODBと同様、ひたすら追記していく方式なので、データファイルが壊れることもまずない。このようなCouchDBの便利さに慣れると、「ただのデータベース」であるMongoDBは、物足りない気がしてしまうのだ。
このように、CouchDBとMongoDBには、それぞれの強みと弱みがある。どちらも経験がなく、これから始めてみたいという人には、オーソドックスなMongoDBのほうをオススメする。人気度でもMongoDBが圧倒的に上のようで、おそらくあと数年もすれば、RDBも含めたすべてのデータベースのなかで、もっともポピュラーなデータベースになると思う。
いっぽうCouchDBは、データの更新が比較的少なく、サイト規模も小さくて、JavaScriptが大好きな人には向いているかもしれない。CouchDBの場合、「JavaScriptの使い方」は主に２つある。ひとつは、WebアプリのサーバサイドロジックをJavaScriptで書く「CouchApp」。もうひとつは、ごく普通のJavaScriptの使い方であるWebクライアントとして、CouchDBを「JSONサーバ」として使う方法。
ちなみにCouchDBは、Ubuntu Linuxに最初から組み込まれていて、一部のデスクトップアプリのデータを保持するのに使われているようだ。CouchDBはスマートフォンでも動くようで、これもいわば「デスクトップ」用途と言えるだろう。サーバ用途に比べて、デスクトップ用途はデータ更新も少ないし、HTTP経由でデータ操作やレプリケーションなどができるCouchDBは、たしかにデスクトップで威力を発揮する余地が大きそうだ。
王道でオーソドックスなMongoDBと、トガっていてクセの強いCouchDB。私にとっては、どちらも捨てがたい魅力があり、今後もケースバイケースで使い分けていくと思う。
関連：
CouchDB
http://couchdb.apache.org/
MongoDB
http://www.mongodb.org/
ウィキペディア - NoSQL
http://ja.wikipedia.org/wiki/NoSQL
関連エントリ：
ブログ名が「Zopeジャンキー日記」から「モジログ」になりました
http://mojix.org/2010/12/05/blog_rename
FriendFeedはどのようにスキーマレスなデータをMySQLに格納しているか
http://mojix.org/2009/02/28/friendfeed_schemaless
サーバの思い出、Zopeの思い出
http://mojix.org/2008/09/22/server_zope