2. MongoDBってなんぞ
- 多機能 but 発展途上
• ドキュメント指向データベース
o 最新2.0.5
• 自動シャーディング
o Read / Writeがスケールアウト
• 自動フェイルオーバー
o Master deadでも自動でフェイルオーバー
• 柔軟なクエリ
o SQLで可能なことはJOIN句以外 一通りできる
• スキーマレス
o データによって自由に持つものを決められる
他にも多機能
3. 構成例
Web
Web
mongos
mongos
3processで
最小構成台数 最適化
3process
data data meta
mongod
mongod
Mongod
(config)
mongod
mongod
Mongod
(config)
mongod
mongod
Mongod
Replica Replica (config)
set
set
17. クエリ 周辺の話(3)
• Capped コレクション
o あらかじめサイズを決めたコレクション
o 古いものから順次消えていく
o 挿入順での検索で高速
o Shardingできない
o 削除不能
o Create文を明示的に発行して作成
§ db.createCollection("mycoll", {capped:true,
size:100000})
26. クエリ insert/updateの話 (3)
• Padding
o insert時に、パディング領域を確保している
§ 配列に追加されるなど、ドキュメントサイズが拡大しても高
速にupdateするため(In-place update)
o Padding領域を越える更新
§ ドキュメントの再配置が発生(遅い)
§ 増加性を持ったコレクションはPaddingサイズ調整が必要
• Atomicな操作
o 1つのドキュメントの更新に対して別のクエリをブロック
o トランザクションのACIDのA(atomic : all or nothing)ではない。
o sharding環境でサポートされない
27. クエリ removeの話
• 断片化
o 削除時はドキュメントの再配置を行わないので断片化する
o repairコマンド
§ 同容量の空き領域が必要
§ サーバー単位(sharding環境なら各shardで)
o compactコマンド
§ より少ない空き領域で可能
§ コレクション単位
§ paddingも削除するので、増加性を持ったコレクションはデ
フラグ後にupdateパフォーマンス悪化
28. 困った話 - 1
• flush前のデータロスト
o デフォルトでは60sに1回flushされるまではメモリで保持
§ 最大で60秒間のデータロストの可能性
o 対策1 (∼ver1.8)
§ 60秒の設定を短縮する
§ getlasterror()でflushさせる
• 重くなる
o 対策2 ジャーナルモード (ver1.8∼)
§ ジャーナルログ(disc)に100msに1回書き込む
§ flushと違い、データの更新先などを意識しないため早い
§ 起動時にJournalディレクトリがあれば復元し、正常終了時
はディレクトリを削除する。
29. 困った話 - 2
• 書き込み時(flush時)はDBロックする
o あまり問題にならないほど、書き込みは高速とのこと
§ ほんまかいな
• 非効率なCPUリソース利用
o 書き込み処理とMapReduceではシングルコアしか使えない
o 読み込みは複数コアを使う
30. みんなが苦労しているのは
• Shard key の決め方
o Chunkの移動があまり起こらないこと
o 長期の運用でも綺麗に分散すること
o Shard keyを使って効率よく検索できること
• Shard keyは一度決めると変えられない
• Migration中の残念なパフォーマンスと不整合
31. Shard keyの考察 (うけうり)
• [bad] 離散データ
o chunk分割できない
§ 例:都道府県コード
• [bad] 単純インクリメントデータ
o 最後のchunkのみが分割移動される
§ 例:連番
• [bad] ランダム値
o 十分に分散するまでは偏りがあるため、大きなchunkができる
§ 例:ハッシュ
• [good] 緩やかに増加するキーと検索に利用するキーの組
み合わせ
o 検索利用キーでひと月かけて偏りが発生してくるが、ひと月たてば偏
りがリセットされる
§ 例:yyyymm-owner_id
32. シンプルな解析PFの例
Web
Web
使ったことないものを
仕事で使ってみたいという想い
解析用サーバー
日次増分をMap/
Reduceで集計
認証機能が必要なため。
I/Oをjsonで一致させて
開発スピードアップ