mongodbの真の売りは性能にあらず

最近あんまりmongodb触ってません。

以前の案件でのmongodbは近日停止しちゃうし、現在従事してる案件はredisです。
なんでredis？っと思いましたが、半年も前から決めちゃってる話で、
性能で選んだらしい。色々調べてみるとそれなりには納得。

http://blog.brandonc.me/2011/11/memcached-vs-redis.html
色々まとまってるのは上記ですね。中国語ですが。

#自分で測定する時間と元気は今はありません。済みません。

性能測定上は、redisはmongodbより3倍速いってことなのでしょう。
実際そうなのでしょう。

ただしmongodb経験者からみると、redisは機能が低すぎてビビります。
「データベース番号」とか。考え方が10年ぐらい前。
番号#defineしろってことですかい？
ちょっと待て、今21世紀で、CPUは64ビットだぜ？頑張ってるのはインテルだけど。

---

mongodbの真の売りは性能ではありません。その柔軟さにあります。

表面上は_idをキーにしたKVSとして使えます。しかし、value値の一部で検索することが出来ます。MySQLとかでは普通だしそれが売りですが、KVS(redis)には逆立ちしても無理な話。しかもmongodbには大小比較や集合演算すら可能です。
http://www.mongodb.org/display/DOCS/Advanced+Queries

また、レコードの要素を増減しても怒られません。ALTER TABLEとか要りません。※ただし増減した分のフィールドは、検索には引っかかったり引っかからなかったりするので、これはこれで注意が必要。

何がイイって、「完璧なテーブル構造＆構成」を最初から考える必要がなくなる。もちろんSIerの皆さんは完璧に考えたいに違いない。受注案件ならそうでしょう。ただしクラウドで、SaaS(という呼称は病原体みたいでイヤなのだが)なご時世では、最初から「完璧」は不可能だし、毎日alter tableなんてやってられない。

テーブルに相当する概念が緩いです。コレクションと呼びますが。動的に増やしても怒られません。そのため「(従来で言うところの)テーブルの検索キーの一部を、テーブル名として使う」なんて、MySQLだと面倒臭くて叶わん処理が、アッサリ書けます。
http://www.mongodb.org/pages/viewpage.action?pageId=18448682

おっと、最近はパーティショニングで近いことが出来るらしいですね。

つまり、大量のデータを高速で処理するのを目標に置いてるであろう、とは言えます。
map/reduceの実装にも、それは当てはまります。
http://www.mongodb.org/display/DOCSJP/MapReduce

KVSの延長線上とは交わりません。

MongoDBに限らず、NoSQLは、トランザクションが無いだの、データを破損する危険があるだの言われたりしますが、MYISAMもInnoDBも壊れますよ。という話が抜けてる。不公平な議論です。

MySQL＋memcachedbでやっていたような案件は、全てMongoDB単体でやっていけるんじゃね？と言うのが小生の主張です。

MySQLの性能を引き出したければ、SQLを使っちゃいけない。らしい。

筆者はMySQLで頑張る気がないので、情勢には疎かったのですが、
出稼ぎ先の技術者に教えてもらいました。

近頃はHandlerSocketなる代物があるらしいのです。
https://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL
http://www.slideshare.net/akirahiguchi/handlersocket-plugin-for-MySQL-4664154

またMySQL自身が、memcache互換APIを内蔵するらしい。
http://dev.MySQL.com/tech-resources/articles/NoSQL-to-MySQL-with-memcached.html

いずれも、サーバ＆クライアント双方のSQLパースをバイパスするのが特徴です。
前者についていえば、性能はかなりのものらしい。InnoDB 5.1で75万クエリ/秒。これが本当であれば、裸のInnoDBは十分に高速である、と言えるでしょう。

RDBMの数々の特徴を放棄すればMySQL/InnoDBでも早くなる。ということは、「ストレージエンジン」という設計思想も、結構なオーバーヘッドなのではないか？と言う気もします。

なにしろ、InnoDBは標準でありながら、MySQLにとっては一介のストレージエンジンですから、my.cnfの記述を間違えると、InnoDBはシレっと外れてしまいます。そういう危なっかしさが、筆者がMySQLを信用できない理由の一つですね。

SQLなんてのは、そもそも複雑な検索条件を指定するための言語ですから、他に手段があればそれでも構わないわけです。ブラウザゲームでは、単一select/update/insertが殆どです。リレーションなんて要りません。

それこそがNoSQLのアドバンテージであった訳ですが、MySQL自身がNoSQLを取り込んで来るとは。流石はオラクル、商売上手です。ただどうでせなら、大量のパラメタを自動調整して欲しいんですが、それだったら天下を取れると思いますよ。なんでやらないんだろ。あ、Oracleが売れなくなるからか。

前出の技術者がやってる、別プロジェクトでは、HandlerSocketを使ってみるそうです。どうなることやら？

mysqlかpostgresqlかNoSQLか

postgresqlとmysqlとどっちを使えば良いかは、
いやっちゅーほど繰り返されてきた議論ですが、
両者とも明確なメリット＆デメリットがあり、
極論するなら、消去法で選択するしかありません。

postgresqlの場合

• insertが比較的早い
• updateを繰り返すと、性能が落ちてくる。vacuumが必要。
• vacuumするには、テーブルロックが必要。な場合がある。
• レプリケーションが未実装。
• connectは比較的遅い。

mysqlの場合

• readだけなら早い→そんな案件今時あるの？
• レプリケーションが比較的簡単＆安定→readonlyスレーブ増やして負荷分散、はよくある発想。面倒だが。
• innodb insert/updateが激遅い。
• sqlに方言がやたら多い。
• 複雑なsqlを投入すると、最適化に失敗する。と言うか最適化する気がないっぽい。
• connectは比較的早い。
• myisamは結構壊れる。(しかも普通に使っていて)
• innodbも稀に壊れる。(しかも普通に使っていて)

エンタープライズ業界なら、これの何れか、もしくはOracleでイイヤ、
って話になるでしょうけど、
ソーシャルゲームであると、データ量、時間あたりの処理量が
指数的に増大します。

テーブル分割に対する実装コストも馬鹿になりません。
であれば、NoSQLを使ってしまえ、というのは手です。

NoSQLは数有りますが、近頃実績が増えてるっぽいのが、mongodbでしょう。
http://www.infoq.com/jp/news/2010/10/4square_mongodb_outage
これらのトラブルも、過渡期であるが故です。

それにこのトラブルは、会員数300万人とかのレベルなんで、
仮にmysql/postgresqlで運用していたとしても、
別のトラブルが有ったであろう人数と言えましょう。知らないけど。

シャードの不均一化が原因だって話なんで、
最初から、細かいテーブル(コレクション)に分割してしまえば済む話かも知れません。
メモリ使用的にもその方が有利らしいし。
http://www.mongodb.org/pages/viewpage.action?pageId=18448682

こんな事が出来るのも、スキーマレス、create tableイラズだからです。

もうmongodbでいいんじゃね？

出稼ぎ先の都合で、key value storeのNoSQLを検討する必要が出てきました。

KVSで有名なのは、apache cassandraですが、
http://cassandra.apache.org/
資料を眺めて残念に思ったのが、データベーススキーマの定義がxmlなこと。
http://wiki.apache.org/cassandra/StorageConfiguration

#どうも、javaな人々は、「xmlの設定」に抵抗が無くてアレですが、
#筆者は、人間に優しくない「設定ファイル」は大反対です。
#eclipseがあるからヘッチャラだぜとか、それは何か違うと思う。
#個人的にはもう全部yamlにしようぜと思っています
# http://www.yaml.org/spec/1.2/spec.html
# 2011年11月現在では、定義ファイルは、yamlになってるっぽい。そうだよね。普通はそこに落ち着くでしょう。

それと、設置にはcassandra自身の他にhadoopが必要で、
ぶっちゃけ面倒臭そう。で、筆者はその辺りで心が折れました。

とは言え、
google datastoreで言うところのreferenceproperty入れ子、の様な事も
出来そうな感じなので、今回の「都合」より複雑なニーズであれば
考慮する必要はありそうです。

他の選択肢は色々ありますが、

couchdbは、
http://couchdb.apache.org/
「httpでイイヨ」で売っているのが微妙に引っかかりました。
まあ改めてポートを開けなくて良いのは助かるけど、
実装全体としては、それだけでは助からないので。

couchの語源は、ソファです。http://en.wikipedia.org/wiki/Couch
だらだらしようぜ。って意味らしいけど。
どうなんだこれ。

そして、最後の選択肢、mongodb。
いやもうこれでいいんじゃね？
#「最後」じゃネエだろ、って突っ込みは間に合ってます
http://www.mongodb.org/

一つは内蔵のクエリ言語が、javascriptであること。
クエリに関数をねじこむと、mapreduceしてくれる。ってんじゃありませんか。
http://www.mongodb.org/display/DOCS/MapReduce#MapReduce-ShellExample1
頼もしくね？
いや、今回の「都合」はそこまで要らない筈ではありますが。

もう一つは、起動が簡単過ぎること。

最低限のコマンドラインは、dbpath。意味はご想像通り。
しかもデフォルト値に合わせるんなら設定要りません。

mongod自身のメッセージ表示は、止めた方が良いかも知れません。
限界性能レベルでは、メッセージ出力のI/Oがネックになったりとかするので。

しかも、テーブルのスキーマ定義は不要です。
コマンドライン(?)では、JSONのオブジェクトを受け付けます。
もうそれで済んでしまう話。
しかも、オブジェクトのプロパティに対して、ちゃんとクエリを掛けられます。
PHP等の実装では、多段連想配列を渡します。まあ理屈は一緒なんだが。

しかして、その限界性能レベルでは、実に馬鹿っ速い。
2秒ぐらいで、10万レコードがスルっと入ります。
DBネックの心配は、当面要らないでしょうこれなら。

core i5でした。まあ実施自体は簡単なんで、皆さんもお試し頂ければよろしいかと。

mongodbの「スケール」は、「シャーディング」或いは「レプリケーション」です。

前者は試してませんが、正規のサーバの前段に、シャーディング管理サーバを挟む形態。
http://www.mongodb.org/display/DOCS/Sharding+Introduction

レプリケーションは設定が簡単しかも動作が速い。


コマンドラインで、レプリケーション元サーバのIP等を指定するだけです。
http://www.mongodb.org/display/DOCS/Replication

ubuntu 10.04には一応は標準パッケージがあるので、
apt-get出来ますが、何故かlibmozjs.soのリンクに失敗しますが、
仕方がないので筆者はxulrunnerのモノをld.so.conf.dに書き足してます。

ubuntuのパッケージには、当然/etc/mongodbが有りますが、
前述の通り、基本的にコマンドラインで事足ります。