1. 勉強会の補足
質問の回答等
© CROOZ,Inc
1

2. アジェンダ
• mongoDBのソケット通信
• Mongosサーバーの負荷
• ChunkSizeの影響
• 集計機能概要
© CROOZ,Inc
2

3. MongoDB Wire Protocol
mongoDBのソケット通信
© CROOZ,Inc
3

4. ソケット通信概要
• Mongoではソケットレベルの通信プロトコルを用意している。
• 各言語のドライバの基底実装として設計されている。
• MongoDB Meta DriverとMongoDB Wire Protocol二種類ある。
• MongoDB Meta Driverはカレント実装だがまだ0.1のドラフト状態で
ドキュメントもない。
• MongoDB Wire Protocolは機能として利用できるが、ドキュメント
がレガシーに分類されていて、利用が推奨されていない。
© CROOZ,Inc
4

5. MongoDB Wire Protocol
Cの構造体ライクのデータを作成してソケットに流す。
struct OP_UPDATE {
MsgHeader header; // standard message header
int32 ZERO; // 0 - reserved for future use
cstring fullCollectionName; // "dbname.collectionname“
int32 flags; // bit vector.
document selector; // the query to select the document
document update; // specification of the update to perform
}
• ここでのdocument型はBSONオブジェクト。JSONをBSONに予
め変換して送信する。
• 基本的な機能しかサポートされていないため、書き込み確認など
は自前ハンドリングする必要がある。
© CROOZ,Inc
5

6. ソケット通信まとめ
• 機能は用意されているが、微妙な時期にある。
• MongoDB Wire Protocolは利用できるが問題も多い。
• 長期的に完全に非推奨になる上、低いレイヤの実装のた
め利用しにくい。
• Mongosが介在しない単純のレプリケーション構成では
レプリカセットに対するハンドリングは自前実装になる。
© CROOZ,Inc
6

7. mongosサーバーの負荷
© CROOZ,Inc
7

8. mongosサーバーの負荷
Mongosサーバーの負荷についてネット上の情報を漁ってみた。
Mongosのパフォーマンスが話題に上がるケースは珍しい。
• 集計機能(Aggregate)でより多くのCPUリソースを消費。
• Mongosによる異常なCPUリソース消費や、瞬間的な単一CPUコア
占有などの現象は報告されている。
• 実際のパフォーマンスは実環境でベンチするしかない模様。
© CROOZ,Inc
8

9. ChunkSizeの影響
© CROOZ,Inc
9

10. ChunkSizeの影響
• 大きいChunk：
– 不均等なバランシング、低い頻度のChunk分割、より小さい
mongos負荷、Chunk移動時に集中的かつ長時間の高IO負荷
• 小さいChunk：
– より均等なバランシング、高い頻度のChunk分割、より大きい
mongos負荷、高い頻度だが相対的に短時間の低いIO負荷
• 大きいChunkのパフォーマンス的な利点が多いが、
Chunk移動時にマシーンIOの限界を超える可能性あり。
• 長時間の高ディスクIOやアンバランスなシャーディング
を回避したい場合、小さいChunkが有効。
© CROOZ,Inc
10

11. ChunkSizeの値と分割
• 1.6以前でのChunkのデフォルトサイズは200M。1.8より
後のバージョンでは64M。
• 分割アルゴリズムは単純にChunkサイズに達した時に半
分に分割しようとする。
• ネット上でChunkサイズに関して、最初は64Mでデータ
が大きくなると200Mに戻るとの情報があるが、公式ド
キュメントで確認できていない。
© CROOZ,Inc
11

12. AggregationフレームワークとMapReduce
集計機能概要
© CROOZ,Inc
12

13. Aggregationフレームワーク
• Aggregationパイプラインとも呼ばれ、SQLでのgroup
byなどの集計系機能を提供する。
• シャーディング構成では一部の処理はmongosで行うの
で、mongosに負荷をかけてしまう。
• 処理中に物理メモリの10％以上の利用はエラーとなる。
• 結果セットはBSON状態で16MiBに制限されていて、超
えるとエラーになる。
© CROOZ,Inc
13

14. MapReduce概要と特徴
• Aggregationパイプラインで扱いきれないデータ、あるいはより複
雑な集計を走りたい場合はMapReduceを利用。
• MongoでのMapReduceの実装はMap、Reduce、Finalizeの3つのス
テージで構成され、それぞれカスタムメソッドを定義する。
• Reduceステージの結果を新たのReduceステージに流して再帰的に
組み合わせることができる。
• 集計対象は単一コレクションのみ。シャード構成可。
• 以前処理した結果に追加分のデータのみ処理し計算をマージするこ
とができる。(Incremental MapReduceという)
© CROOZ,Inc
14

15. MapReduce概要と特徴②
• シャード構成のコレクションに対して処理を行う場合、一部の処理
が各シャードで並列で行われる。
• 内部処理はJavaScriptエンジンで、DBに対し多くのリードとライト
ロックがかかるため遅い。
• 同等の処理をAggregationパイプラインで行うより遅い。
• シャード構成以外の分散処理能力はない。
• リアルタイム処理に向けて設計されてなく、バックグラウンド処理
推奨となっている。
© CROOZ,Inc
15

16. MongoDB Connector for Hadoop
• Hadoop用MongoDBコネクタはHadoopのプラグインで、Mongoを
Hadoopのデータソースあるいは出力先にできる。
• HadoopとMongoDBの連携は以下の用途が考えられる。
– MongoDB組み込みMapReduce機能の代替。
バッチ処理等でMongoのデータをHadoop処理ノードにロードし、処理完了後
Mongoのコレクションに格納する。
– データウェアハウス
データウェアハウスとしてのHadoopのデータソースの一つとしてMongoDBを
利
用する。
– ETLデータ
MongoDBからHadoopを経由して、データを変換整形して、他のDBに格納する。
© CROOZ,Inc
16

17. Hadoopと組み込みMapReduce機能の比較
• 組み込み：
–
–
–
–
–
–
–
各言語のドライバが利用でき、手軽に利用できる。
Incremental MapReduceが利用できる。
処理時mongosとmongodに対しCPU負荷をかけてしまう。
シャード構成以外の分散処理ができない。
複数コレクションを跨ぐ処理ができない。
他のデータベースのデータを混ぜて集計処理ができない。
遅い。
• Hadoop (with MongoDB)：
– 別途Hadoopクラスタとジョブプログラムが必要。
– 処理負荷をMongoから完全に切り離すことができる。（データロードの分は
別）
– 高度な分散処理ができる。
– 複数コレクション、ひいては別のデータベースシステムのデータも含めて集計
処理できる。
– 早い。
© CROOZ,Inc
17