エバンジェリストのdoryokujinさんの能力の高さもあって、注目度の高いMongo DBの勉強会を見ながら書いている記事。

 1. MongoDB機能解説

アーキテクトとして、システムのDBの選択する際に、下記の迷いが生じます。

・RDBかKVSか?

・KVSならばどれなのか?

・KVSにはOnMemory DBいるか?

MongoDB使ってアプリ作りたいけど、なんでMongoDBなのかに答えを出さなでせんたくするのがいやなんだよなあ・・・。

パフォーマンス良さそうだけど、SQL Serverの開発環境の素晴らしさと比べちゃうと、そのあたりの貧弱さが気になる。

2．NijiBox「ソーシャルアプリのプロトタイプ制作にMongoDBを活用」〜PHP+Sleepy.Mongooseでお手軽永続化〜

アプリ開発のXP開発をつづけるため、DBの変更がたくさん発生する。開発スタッフ間でスキーマ共有するのにもコストがかかる。

 発表者

ログ分析にはMongoDB使う予定だったが、プロトタイプ揮発にも使うことにした。

スキーマがないので、最初はMongoDBでアプリをつくって、最終的にはDBに移行する。(予定)

プロジェクトへの効果は、ソースコードだけ共有すればいいので、DBのスキーマ共有コストが減った。

また複雑なクエリがかけないので、あとでRDBに変更したときにO/R Mapperがスロークエリーを発行する可能性が低い。

スキーマーレス ＋ クエリが協力 ＝ ストレスフリーなアプリ開発。

Cassandraなどに比べて、MongoDBはRDBに近くて使いやすい。

アプリ開発者にとってはShardingやReplicaはおまけ。

悪い点: 信頼性が低い。安定性が全然ない。(・・・えっ?)

つまり、信頼性や安定性を犠牲に出来る部分で使うと良い。認証、課金系では使う気がおきない。

信頼性を担保しようとすると、パフォーマンスが落ちる・・・という本末転倒な、闇MongoDBワールドに陥る。

Capped Collectionはログ解析のためにあるといっても過言ではない。

キャッシュとしても使えるかもしれないが、他のキャッシュDBのほうが良い。

--------------------------------------------

最後の雑談が凄く興味深い:

・開発スタッフはMySQLにもMongoDBにも詳しくない。DBスキルが低いので、MySQLにしても高度な事ができない。

・割りきって、単純な使い方だけでアプリを開発してしまおう・・・。

3．MongoDBのチューニング

並列に実行計画を実行して一番早いプランを採用する・・・っていいなwww

4. MongoDBを使ったモバイルゲーム開発

・東京ガールズスナップ 3ヶ月で開発4月リリース。実写を使用して画像合成。

・「Java+MongoDBに絶望した」を追体験してやるぜ・・・という気持ちでやってみた。(node.jsがいいらしい)

・Web2台、DB3台 (Shardingせずに、Primary、Secondary、Secondary)

・カラム追加せずに機能追加できるのが良い。最初のノウハウ貯めるオーバヘッドを除けば開発効率はいい。

・秒間500UpdateでLockが4％程度

・1台でCPU1個しか使わないのはもったいない。

・Memcachは使わない予定だったが、TokenやSessionでは使ってしまった。

・決済はAPIで別サーバ呼び出しなので、MongoDBでも問題なかった

・CPU(コア)が複数あったとしても、一つのプロセスがメモリが幾らのっていても使いきってしまうので、1サーバ1プロセスにすべき。