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