第3回 MongoDB勉強会に参加＆発表してきました

遅くなりましたが、第３回MongoDB勉強会に参加＆発表してきました。

前回の勉強会後に、doryokujinさんが発表されたshardingについての検証記事を書いてたところ、今回の発表のお話を頂いたので、
折角なのでやらせて頂くことにしました。
次のブログのネタとして考えていた、MongoDBのクエリのチューニングのアプローチ方法は、PostgreSQLなどのRDBMSと比べて
どの程度使えるのかと言う点をまとめて発表させて頂くことにしました。

MongoDB全機能解説1 [twitter:@doryokujin]

２時間ぶっ通しでの発表。充実した内容で本当に頭が下がります。
今回は、MongoDBの全機能解説ということで、MongoDBの構成、Insertとその周辺、Query、Update 、Index 、Replicationの解説です。

  • MongoDBの構成
    • mongod
      • m基本的にシングルスレッドしか使えず、多くのオペレーションに対してロックがかかる（v2.0〜v2.2で改善予定）
      • read/writeに対してDB全体に対してロックがかかる
    • Capped Collection
      • 固定サイズのcollection。古いデータから自動削除されるが、パフォーマンスが良い。
      • collectionを作る際にindexは自動で作成されない。
      • 挿入順で取得するのがパフォーマンス的には最適
      • Sharding不可
      • ログやcacheなどの用途がおすすめだが、一度作成すると容量を増やすには一旦削除する必要があるので注意。
  • Insertとその周辺
    • Bulk Insert
      • 個々のInsertより高速
      • 最適な配列サイズはデータ依存のため、環境に合わせる必要あり。大きすぎるとエラーが発生。
      • デフォルトでは結果を確認していないため、全てのInsertが成功している保証はないので、getLastErrorで確認が必要。
    • fsync
      • メモリ上のデータをディスクに書き込む
      • デフォルトでは60秒毎に実行される
      • 障害発生時には、60秒間のデータロストが発生する可能性がある。
    • Journaling
      • write-ahead-log
      • データ書き込み前に、オペレーションをjournalファイルに記述
      • 障害時にはjournalファイルからオペレーションを再実行し、リカバリを行う
      • journalファイルへの書き込みは100ms毎に実行されるため、100ms間のデータロストの可能性は以前残る。
  • Query
    • Sub Object形式は順序依存
    • Dot Notation形式のクエリが安全
  • Update
    • in-place-update
      • オブジェクトサイズが増えない場合は、その場でupdate されるため高速
      • 領域に収まらない場合は、領域が移動されるため遅くなる
  • Index
    • B-tree indexを採用
    • バックグラウンドでのindex作成が可能
  • Replicationの解説
    • 特徴
      • Master-Slave:1master - N slaveの構成
      • Replica Sets:自動フェイルオーバーなど
      • masterとslaveの間は非同期通信
      • Relicationの設定、管理、メンバー追加、削除は非常に簡単
      • slaveからの読み出しは可能（書き込みは不可）
    • Master - Slave
      • 最低２台からの構成が可能
      • Slaveの追加、撤退は容易
      • Slaveからの読み出しは可能
    • Replica Sets
      • 自動フェイルオーバー
      • メンバーの自動リカバリ
      • 最低３台から構成可能
      • Slaveからの読み出しは可能
「ソーシャルアプリのプロトタイプ制作にMongoDBを活用」〜PHP+Sleepy.Mongooseでお手軽永続化〜 [twitter:@bibrost]

前回に引き続きbibrostさんによる発表。

    • 開発初期にありがちなRDBのスキーマ変更に伴うコストを低減させるために、スキーマレスなMongoDBを活用する。（車のボディ開発で行われている粘土細工に由来）
    • リリース時のタイミングでMySQLなどに移行する
    • MongoDBをそのまま使うには、まだMongoDBを保守できるエンジニアが足らない。
MongoDBチューニング [twitter:@matsuou1]

私の結論としては、MongoDBではRDBMSとほぼ同じチューニングのアプローチ方法が取れます。RDBMSでチューニング経験がある人は、
違和感なくやれると思います。むしろ、JOINがない分、簡単かと。ただ、バックエンドで使う分には十分な方法が提供されているが、
フロントエンドで使うには、実行回数が多い＆ちょっとだけ遅いクエリを特定する方法が現状ないので、注意して見て行く必要があります。
この辺りは今後のバージョンアップに期待しましょう。（PostgreSQLでも8.4辺りからの実装でしたしね）
複合インデックス辺りをもう少し詳しく書く予定でしたが、直前に炎上中のプロジェクトごと投げられて時間が取れなかったので、
仕事が落ち着いたらブログでもう少し詳しく検証して行きたいと思います。

「MongoDBを使用したモバイルゲーム開発について」 [twitter:@ygenki]

既に定番となっているサイバーエージェント枠。
東京ガールズスナップは、勉強会殺しになりうる危険な存在。

  • MongoDBでよかったこと
    • 階層構造と相性が良い
    • 仕様変更に対し柔軟に対応が可能
    • バイナリデータの保存が可能
  • 課題
    • オペレーションミスでデータが消える（updateで$setをつけてないとか）
    • データ型が変わる（int → double）
    • ドキュメント設計
toggter [twitter:@kimukou_26]

まとめ＆所感

全機能解説は本当にすばらしい。気をつける必要があるポイントが多数記載されているため、非常に有用。
Replicationについての検証は後でやってみたいと思う。そろそろ、ちゃんとした検証用サーバが欲しい・・・。

今回、初めて発表させて頂いたが、「発表するとフォロワー増えるよね。ポポポポーン」を実感しました。
まずは、情報を発信することが大事ですね。