仕事で新しいサービスのDBを何にするか検討していて、MongoDBと同じような使い方ができてサーバコストが抑えられるものがないか探していたときにCouchbaseのことを思い出してハンズオンセミナーなど受けてきました。結局Couchbaseは使わないことにしたのですが、主にMongoDBと比べてどうだったかといったあたりを書いておきます。

Couchbaseについてざっくりと

　まずCouchbaseがどういったものかをざっくり説明しておくと、MongoDBと同じようなドキュメント指向のNoSQL製品で、JSONデータを格納します。
　売りにしている特徴としては下記のような点が挙げられています。

• 容易なスケーラビリティ
• 安定したハイパフォーマンス
• 24時間365日安定稼働
• 柔軟なデータモデル

MongoDBと似ているところ

　また、下記のような思想はMongoDBと共通しています。

• データは全部メモリに載せる
• パフォーマンス出すにはサーバを追加する（スケールアウト）

　データが100GBあれば、masterノードのメモリの合計がそれ以上になるようにしましょう、という点では両者とも同じ思想で、サーバスペック的にもCPUよりもメモリを多く積んだサーバを必要とします。

比較して気になったところなど

　逆にMongoDBと比較して違う点で気になったところ等は下記のようなところです。

|caption=MongoDB/Couchbase比較
|
|項目,MongoDB,Couchbase
|
|レプリケーション,master-slaveレプリケーション,master-masterレプリケーション
|ノード追加,コマンドで設定変更,Webの管理画面から操作可能
|自動Failover,台数制限なし,同時に一台まで
|クエリ,SQLライクな柔軟なクエリ,MapReduceのみ
|ドキュメント削除時,ドキュメント削除時にすべて消える,メタデータが残ってしまう
|商用版と無償版,違いはサポートの有無,商用版がベースなのでバージョンアップなどもまず商用版から

　それぞれ簡単に説明していきます。

• master-masterレプリケーション

  MongoDBではレプリケーションの構成はmaster-slaveになりますので、masterノードのレプリカはslaveサーバが保持します。なのでシャーディング構成をとっている場合で１レプリカセット３台で構成している場合は、１シャード増やす場合には１レプリカセット追加ということになって３ノード増やす必要があります。これに対してCouchbaseはmaster-masterレプリケーションなので、あるmasterノードのレプリカは他のmasterノードが保持します。なので１シャード追加する場合にも１ノード増やすだけでOKです。masterが他のmasterのレプリカを持つ分、１ノードあたりのデータ量はMongoDBと比べると多くなりますが、レプリカデータは普段は非Activeになっていてアクセスされないので、その分のメモリは足りていなくても運用できるとのことでした。（実際の動作検証はしてません。。）

• 管理画面からノード追加

  MongoDBではクラスタへノードを追加する場合、コマンドラインから操作する必要がありますが、CouchbaseではWebの管理画面から操作することができます。追加後のリバランスもそのまま管理画面から実行可能で、データ量が増えてもリバランスの所要時間はあまり変わらないとのことです。また、Mongoではシャードキーを自分で設定しますが、Couchbaseでは自動で振り分けが行われるので、データの内容から置かれているサーバを特定することはできません。リバランス処理の負荷はやはり高いので、すでに負荷でいっぱいいっぱいの状態のクラスタでノード追加、リバランスを行うのはつらいものがあります。

• 自動Failoverは一台まで

  MongoDBではレプリケーションがmaster-slave構成ということもあり、Failoverは同時に何シャードで起こっても大丈夫ですが、Couchbaseでは自動Failoverは１ノードまでなので、最初の１ノードを復旧する前にもう一台落ちた場合には、クラスタが停止します。管理画面から手動でFailoverさせることは可能です。

• クエリはMapReduceのみ

  今回Couchbaseの採用を見送った最大の理由はこれなのですが、MongoDBではSQLライクな柔軟なクエリが使用できるのに対して、CouchbaseではクエリはすべてMapReduceで行う必要があります。前もってMapReduceの処理を定義しておき、アプリケーションなどからはどのMapReduce処理かを指定して結果を参照します。開発時の効率を考えるとすべての処理をMapReduceで書くのはつらいものがあるので今回は見送りました。来年出るバージョン3.0ではSQLライクなクエリであるN1QL（ニッケル）が実装されるそうですので、期待したいところです。

• ドキュメントを消してもメタデータが残る

  Couchbaseではドキュメントを消した場合にもドキュメントのメタデータは消されずに残ってしまうので、容量を圧迫します。この残ったメタデータを削除する処理の実行頻度を管理画面から指定できるのですが、削除処理は負荷が高いようなので、運用時にはこういった点も考慮する必要があります。

• 商用版ありき

  OSSには元々オープンソースとして始まったものに商用のサポートなどがつくケースが多いですが、Couchbaseは元々商用製品として始まったもののソースを公開している形になります。なのであくまでメインは商用版で、バージョンアップやパッチの公開等もまず商用版に対して行われ、Couchbaseのエンジニアの手が空いたときにOSS版がメンテナンスされることになります。現状バージョンアップについては商用版の半年遅れぐらいでOSS版が追随しているようですが、今後はさらに間隔が開いたり、機能やデータ容量の制限がかかってくることもあるかもしれません。無償で利用できるものを探している場合はこの辺りがネックになりそうです。現在の商用版の最新バージョンは2.2ですが、OSS版はまだ2.1です。次のバージョンの3.0はOSSではいつ公開されるのか。。

　今回は実際に性能の検証等を行うまでに使わないという判断をしてしまいましたが、いくつか公開されているベンチマークではCouchbaseがMongoDBなどより良い結果を出しているものもあるので、N1QLが利用できるようになったらパフォーマンス検証等行ってみたいと思います。ただ無償版の状況を考えるとなかなか難しいかもしれませんが。。

MongoDB Advent Calendar 2013 の ５日目です。

　先日、MongoDB University M101P コースのTAをさせていただく機会に恵まれました。MongoDB University というのはMongoDB社が提供している、MongoDBを使用したプログラミングについてオンラインで学習できるコースです。

　TA(Teaching Assistant) というのはコース内のフォーラムで、受講している生徒からの質問等に回答するのが主な役割です。以前は英語版のコースのみだったのですが、Pythonを使用したプログラミングの学習コース(M101P)のビデオが日本語でも提供されることになり、日本語を話す受講者のために日本人のTAが必要ということになりました。MongoDB University の各コースでは修了時にアンケートをとっていて、以前私が英語版で受講したときのアンケートで、TAや翻訳等の機会があれば協力しても良いか、という質問にYesと回答していたためにオファーをいただいたようです。TAを努めたそのコースも先日終了したので、感じたことや気づいたこと等書いてみたいと思います。MongoDBの技術的な話とはちょっと違ってしまいますが、ご容赦ください。

1. 日本語での生徒からの投稿ゼロ

   　まず結果として日本語でのフォーラムへの投稿数はというと、残念ながら0でした。日々フォーラムをチェックしていると、英語でのポストはどんどん増え、活発にやりとりされていくのですが、日本語でのポストはないまま終わってしまいました。そもそもJapanese Speakerの受講者がEnglish Speakerに比べてかなり少ないということはあると思いますが、こういったところでの積極性はやはり日本人よりも欧米の方々の方が強いのかなぁと思いました。

2. 使用しているバージョンや環境などによる違いが大きい

   　M101PはPythonを使用したプログラミングについてのコースで、前提としているPythonのバージョンは2.7であることも記載されているのですが、3系を使用しているために提供されているコードが正しく動作しないというポストがかなり多く見られました。また、シンプルにローカルのPC上で動かす意外にも、OpenShift などのクラウド環境で動かそうとしているがうまくいかない、というような内容もありました。私自身はローカルのPC上で動かす意外には業務でAWS上のMongoDBのクラスタ環境に触れる機会はあるのですが、それ以外に多くの環境で動作させた経験はなく、さらにOSもLinux, MacOS, Windowsなどによって細かい点はだいぶかわってくるので、様々な環境の理解や、MongoDBがどのように動作するかの詳細の理解が全く足りていないなぁと感じました。コースの範囲としてどこまでカバーするかというのはありますが、TAとして関わる以上はできるだけ助けになるような回答をしたいと思っています。

3. MongoDBの詳細な仕様について理解することが重要

   　質問では、コースのビデオの中では解説していない細かい点についても質問がくることがあります。例えばexplainの出力のこの項目はこっちの項目とどう違うんだ、とか、こういう用途でMongoDBを使う場合は、モデリングはどっちが向いているのか、など。自分がユーザとして使う分には知らなくても特に困らないような問題でも、やはりTAとして回答するには色々理解している必要があります。また、前項の内容に関連して、詳細を理解していないと他の環境で使ったときの動作がわからないということも出てきます。

4. 英語力重要

   　TAとしては一応日本語担当なのですが、日本語でのポストもありませんでしたし、TAである以上は英語のポストにも回答していきたいと思うのですが、まだまだ自分の英語力は不足していて、質問の意図を理解しきれなかったり、理解するまでに時間がかかってしまうことが多く、他のTAの方にお任せするということになって悔しい思いをしました。もちろん英語力だけでなく前述の技術的なところの不足に起因する部分も多いのですが、やはり英語ができないことでのデメリットを痛感しました。TAのオファーをいただいたときにも、最初にMongoDBの方とSkypeでミーティングをしたのですが、もちろん英語でのミーティングで、私の受け答えもかなり怪しかったので、MongoDBの方を不安にさせたのではないかと思っています。。

   　受講する側で考えたときも、今回のコースについてはビデオは日本語でのボイスオーバーが提供されているものの、各週のホームワークや最終試験はすべて英語ですので、技術的には理解していても設問が理解できないと回答できません。フォーラムでのやりとりも参考になるものも多いので、やはり英語ができることでのメリットは大きいです。

5. アウトプット重要

   　TAのオファーをいただいたとき、受けるかどうかかなり迷いました。MongoDBの知識に自信があったわけでもありませんでしたし、ユーザグループで積極的に活動していたわけでもなかったので、務まるだろうかとかなり不安でした。でも逆にこれによってMongoDBのことをさらに知る機会にもなるかもしれないし、英語力をアップさせるためにも英語を使う機会を増やしたいと思っていたので、思い切って受けることにしました。結果としてはやって良かったと思っています。コース期間中は日々フォーラムをチェックする必要がありましたし、受講者の方は回答を待っているので気が休まりませんでしたが、おかげでアウトプットの機会も増え、また、このAdvent Calendarにも参加するためのネタにもなりました。もちろん自分で黙々とスキルアップに励む時間も大切なのですが、アウトプットすることによって得られることも多いので、今後も機会があれば積極的にアウトプットする場を作っていきたいと思っています。

　M101Pコースは11/25からまたスタートしています。MongoDBについて一通り学習するにはとても良いコンテンツだと思いますので、興味のある方は是非受講してみてください。前回のコースで日本語での質問がなかったので今回のコースでは日本語対応のTAはアサインされていませんが、ビデオは日本語対応されていますので、英語が不安な方も大丈夫だと思います。

　以上、MongoDB Advent Calendar 2013 5日目でした。

インストール

shell>>
% gem install mongo_mapper
<<--

mongomapper (古いバージョンのgem)も存在するので注意

セットアップ

ruby>>
require 'mongo_mapper'
MongoMapper.database = "app1" # DB名
<<--

• 各モデル内で明示されない場合に利用されるデフォルトのDB名

モデル

ruby>>
class Player
include MongoMapper::Document
key :name, String, :required => true
key :policy, Integer
key :renkei, String
key :note, String
timestamps!

validates_uniqueness_of :name
end
<<--

• pkeyのidが勝手に定義される
• 文字列は長さに制限がないので全てString

検索

ruby>>
Player.count
=> 822

Player.count(:renkei=>'萩原型')
=> 135

Player.first
=> #<Player label: "萩原 忠志" ... >

Player.all(:label=>/^河本/).map{|p| [p.pos, p.label]}
=> [["FW", "河本 鬼茂"], ["GK", "河本 龍将"]]
<<--

高度な設定

• ARで言うテーブルをMongoDBではコレクションと呼ぶ
• table を collection に変えるだけでAR風のAPIが使える

ruby>>
class Pref
include MongoMapper::Document

set_database_name "usei" # app1でなく usei DBを利用
set_collection_name "zip" # prefs でなく zip コレクションを利用
...
<<--

長所

• MongoDB自体の性能がよい
• インタフェースが AR と DM のよい点を取り込み (CRUDはAR, SearchはDM)
• バリデーションや関連もサポート
• 正規表現による検索

短所

• サーバ(MongoDB)への再接続などのコネクション機能が弱い(mongo_mapper でなく mongo の問題かも)