最近あんまり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単体でやっていけるんじゃね？と言うのが小生の主張です。
