0
MongoDB紹介2012/5/18 matsumura
MongoDBってなんぞ - 多機能 but 発展途上•    ドキュメント指向データベース     o    最新2.0.5•    自動シャーディング     o    Read / Writeがスケールアウト•    自動フェイルオーバー...
構成例              Web	        Web	                mongos	     mongos	                3processで最小構成台数                       ...
基本的なデータの持ち方                                                    MySQLで例えると mongod	                                         ...
レプリカセット- MySQL同様Mongod (Primary)	               Mongod(Secondary)	        Mongod(Secondary)	データベース etcr	                  ...
自動フェイルオーバー•    Primaryが死ぬ•    Primaryが死んだことがreplica set内で共有•    残ったノードで投票を行う•    ノードごとの優先度設定、最終同期時刻をもとに投票     を行う•    過半数よ...
自動シャーディング - phase1Mongod (Shard A)	                    Mongod (Shard B)	データベース etcr	                         データベース etcr	コ...
自動シャーディング - phase2Mongod (Shard A)	          Mongod (Shard B)	データベース etcr	               データベース etcr	コレクション 行動履歴	         ...
自動シャーディング - phase3Mongod (Shard A)	                    Mongod (Shard B)	データベース etcr	                         データベース etcr	コ...
自動シャーディング - phase4Mongod (Shard A)	                    Mongod (Shard B)	 データベース etcr	                        データベース etcr	 ...
自動シャーディング - phase5Mongod (Shard A)	                    Mongod (Shard B)	 データベース etcr	                        データベース etcr	 ...
自動シャーディング - phase6• Sharding Demo
スキーマレス•  Create table, Create column family 不要  o  Insertした時点で作られる  o  アプリ要件に合わせて柔軟に入れられる  Item1 = {      _id: ObjectId(4b...
柔軟なクエリ• SQL文を持たない• Demo• ハッシュでO/Rマッパーのように指定する o  フロントjavascriptからクエリオブジェクトを    送って、サーバーサイドでは検証後、即実行でき    る
クエリ 周辺の話 (1)• Index(B-Tree)  o  配列やオブジェクトに対してもはれる      § ただし、配列は1つ / indexに制限  o  メモリに乗るようにintを使うと吉     // indexをつける     ...
クエリ 周辺の話(2)• クエリオプティマイザ o MySQLのようなコストベースではない o 初回のクエリで複数クエリプランを同時実行 o  最も早かったクエリを利用 o  データ量に応じて定期的に見直し o  explain()
クエリ 周辺の話(3)• Capped コレクション o  あらかじめサイズを決めたコレクション o  古いものから順次消えていく o  挿入順での検索で高速 o  Shardingできない o  削除不能 o  Create文を明示的に発行し...
クエリ findの話 (1)•  検索条件は、bsonオブジェクトの先頭に寄せる1. db.activityHistoryDemo.find({owner_id: 123})2. db.activityHistoryDemo.find({‘co...
クエリ findの話 (2)•  bsonオブジェクト階層を細分化したほうが早いdb.activityHistoryDemo.find({‘concerned.id’: ‘201’})                   {          ...
クエリ findの話 (3)•  条件の指定順序 o  And条件は結果の小さな条件から順次     §  補集合を無視するので。  ○ db.sample.find({owner_id: 123, ‘concerned.type’: ‘ca...
クエリ findの話 (4)•  DBRef  doc = {    name: ryooo,    card:[      {$ref: card, $id : ObjectId(4b0552b0f0da7d1eb6f12xxx)},    ...
クエリ findの話 (5)•  検索条件に関数も使える(javascript) // 極端な話、こんなクエリも書けちゃいます db.cards.find(function(){   row = db.user_summary.findOne(...
クエリ findの話 (6) Shard keyを利用したクエリ               Shard keyを利用しないクエリ                      targeted                         gl...
クエリ insert/updateの話 (1)•  fire and forget   o  発火即忘却       §  結果を確認せずreturnする       §  結果を知りたければgetlasterrorオプションを指定•  確...
クエリ insert/updateの話 (2)•  ID値   o  デフォルトでは、IDは自動で振られる   o  ObjectId = BSON(       [4byte timestamp] +       [3byte hash(ho...
クエリ insert/updateの話 (3)•  Padding  o  insert時に、パディング領域を確保している       §  配列に追加されるなど、ドキュメントサイズが拡大しても高           速にupdateするため...
クエリ removeの話•  断片化  o  削除時はドキュメントの再配置を行わないので断片化する  o  repairコマンド       §  同容量の空き領域が必要       §  サーバー単位(sharding環境なら各shard...
困った話 - 1•  flush前のデータロスト o  デフォルトでは60sに1回flushされるまではメモリで保持     §  最大で60秒間のデータロストの可能性 o  対策1 (∼ver1.8)     §  60秒の設定を短縮する...
困った話 - 2•  書き込み時(flush時)はDBロックする o  あまり問題にならないほど、書き込みは高速とのこと     §  ほんまかいな•  非効率なCPUリソース利用 o  書き込み処理とMapReduceではシングルコアしか使...
みんなが苦労しているのは•  Shard key の決め方  o  Chunkの移動があまり起こらないこと  o  長期の運用でも綺麗に分散すること  o  Shard keyを使って効率よく検索できること•  Shard keyは一度決めると...
Shard keyの考察 (うけうり)•  [bad] 離散データ  o  chunk分割できない      §  例:都道府県コード•  [bad] 単純インクリメントデータ  o  最後のchunkのみが分割移動される      §  ...
シンプルな解析PFの例      Web	   Web	                              使ったことないものを                            仕事で使ってみたいという想い	        解析用...
Upcoming SlideShare
Loading in...5
×

Mongodb 紹介

906

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
906
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Mongodb 紹介"

  1. 1. MongoDB紹介2012/5/18 matsumura
  2. 2. MongoDBってなんぞ - 多機能 but 発展途上•  ドキュメント指向データベース o  最新2.0.5•  自動シャーディング o  Read / Writeがスケールアウト•  自動フェイルオーバー o  Master deadでも自動でフェイルオーバー•  柔軟なクエリ o  SQLで可能なことはJOIN句以外 一通りできる•  スキーマレス o  データによって自由に持つものを決められる 他にも多機能
  3. 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
  4. 4. 基本的なデータの持ち方 MySQLで例えると mongod mysqld データベース etcr データベース コレクション 行動履歴 コレクション XXマスタ テーブル doc doc doc doc doc doc レコード doc doc doc doc データベース other コレクション 各種ログ doc doc doc
  5. 5. レプリカセット- MySQL同様Mongod (Primary) Mongod(Secondary) Mongod(Secondary) データベース etcr データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 コレクション 行動履歴 docA docB docC docA docB docC docA docB docC docD docE docF docD docE docF docD docE docF 再現 再現 データベース local データベース local データベース local コレクション oplog コレクション oplog コレクション oplog 同 操作 操作 操作 期 操作 操作 操作 操作 操作 操作
  6. 6. 自動フェイルオーバー•  Primaryが死ぬ•  Primaryが死んだことがreplica set内で共有•  残ったノードで投票を行う•  ノードごとの優先度設定、最終同期時刻をもとに投票 を行う•  過半数より多くの票を集めたノードがPrimaryとなる•  この間 約20s ∼ 60s
  7. 7. 自動シャーディング - phase1Mongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk ( –無限大 〜 無限大] docA docB docC デフォルト 200MB
  8. 8. 自動シャーディング - phase2Mongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk ( –無限大 〜 D] docA docB docC Chunk ( D 〜 無限大] docD docE docF
  9. 9. 自動シャーディング - phase3Mongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk ( –無限大 〜 D] docA docB docC docC’ docC’’ docC’’’ Chunk ( D 〜 無限大] docD docE docF
  10. 10. 自動シャーディング - phase4Mongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk ( –無限大 〜 C’] docA docB docC Chunk (C’ 〜 D] docC’ docC’’ docC’’’ Chunk ( D 〜 無限大] docD docE docF
  11. 11. 自動シャーディング - phase5Mongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk ( –無限大 〜 C’] Chunk ( D 〜 無限大] docA docB docC docD docE docF Chunk (C’ 〜 D] docC’ docC’’ docC’’’ 水平方向に スケールアウト
  12. 12. 自動シャーディング - phase6• Sharding Demo
  13. 13. スキーマレス•  Create table, Create column family 不要 o  Insertした時点で作られる o  アプリ要件に合わせて柔軟に入れられる Item1 = { _id: ObjectId(4b0552b0f0da7d1eb6f12xxx), name: 秘薬, price: 100, } Item2 = { _id: ObjectId(4b0552b0f0da7d1eb6f12yyy), name: 自分用秘薬, }
  14. 14. 柔軟なクエリ• SQL文を持たない• Demo• ハッシュでO/Rマッパーのように指定する o  フロントjavascriptからクエリオブジェクトを 送って、サーバーサイドでは検証後、即実行でき る
  15. 15. クエリ 周辺の話 (1)• Index(B-Tree) o  配列やオブジェクトに対してもはれる § ただし、配列は1つ / indexに制限 o  メモリに乗るようにintを使うと吉 // indexをつける db.test.ensureIndex({x:1, y:1, z:1}) ○ db.test.find({x:a}) ○ db.test.find({x:a, y:b}) ○ db.test.find({x:a, y:b}).sort({z:1}) // 順序が重要 × db.test.find({y:b, x:a})
  16. 16. クエリ 周辺の話(2)• クエリオプティマイザ o MySQLのようなコストベースではない o 初回のクエリで複数クエリプランを同時実行 o  最も早かったクエリを利用 o  データ量に応じて定期的に見直し o  explain()
  17. 17. クエリ 周辺の話(3)• Capped コレクション o  あらかじめサイズを決めたコレクション o  古いものから順次消えていく o  挿入順での検索で高速 o  Shardingできない o  削除不能 o  Create文を明示的に発行して作成 § db.createCollection("mycoll", {capped:true, size:100000})
  18. 18. クエリ findの話 (1)•  検索条件は、bsonオブジェクトの先頭に寄せる1. db.activityHistoryDemo.find({owner_id: 123})2. db.activityHistoryDemo.find({‘concerned.id’: ‘201’}) { owner_id: 123, request: { type: 合成, params: {}}, process: {category: composit}, memo: [lv.0 -> lv.15], concerned: [ {io: i, type: card, id: 100, object: 111, base: true}, {io: i, type: card, id: 201, object: 222}, {io: o, type: card, id: 100, object: 111}, ] })
  19. 19. クエリ findの話 (2)•  bsonオブジェクト階層を細分化したほうが早いdb.activityHistoryDemo.find({‘concerned.id’: ‘201’}) { owner_id: 123, request: { type: 合成, params: {}}, process: {category: composit}, memo: [lv.0 -> lv.15], concerned: [ {io: i, type: card, id: 100, object: 111, base: true}, {io: i, type: card, id: 201, object: 222}, {io: o, type: card, id: 100, object: 111}, ] })
  20. 20. クエリ findの話 (3)•  条件の指定順序 o  And条件は結果の小さな条件から順次 §  補集合を無視するので。 ○ db.sample.find({owner_id: 123, ‘concerned.type’: ‘card’}) × db.sample.find({‘concerned.type’: ‘card’, owner_id: 123}) o  Or条件は結果の大きな条件から順次 §  後続条件は補集合から検索するので。 ○ db.sample.find({$or: [{‘concerned.type’: ‘card’}, {owner_id: 123}]) × db.sample.find({$or: [{owner_id: 123}, {‘concerned.type’: ‘card’}])
  21. 21. クエリ findの話 (4)•  DBRef doc = { name: ryooo, card:[ {$ref: card, $id : ObjectId(4b0552b0f0da7d1eb6f12xxx)}, ] } doc.card[0].fetch() // ←カードオブジェクトがとれる @ruby db = Connection.new.db(”etcr ") user_card = db["user_card"].save({:name => ”ryooo”, :card_id => 123}) ref = DBRef.new(”card", user_card.card_id) db.dereference(ref) #=> カードオブジェクト
  22. 22. クエリ findの話 (5)•  検索条件に関数も使える(javascript) // 極端な話、こんなクエリも書けちゃいます db.cards.find(function(){ row = db.user_summary.findOne({owner_id: this.owner_id}) return this._id == row.leader_card_id; })•  mongoサーバーサイドに関数を登録できる // 関数を登録 db.system.js.save({_id:’name, value: function (){ //implementation }}); f = db.system.js.findOne({_id:’name}) // 検索で利用(fはサーバー側で実行される) Db.cards.find(f)
  23. 23. クエリ findの話 (6) Shard keyを利用したクエリ Shard keyを利用しないクエリ targeted globalMongod (Shard A) Mongod (Shard B) データベース etcr データベース etcr コレクション 行動履歴 コレクション 行動履歴 Chunk Chunk docA docB docC docD docE docF
  24. 24. クエリ insert/updateの話 (1)•  fire and forget o  発火即忘却 §  結果を確認せずreturnする §  結果を知りたければgetlasterrorオプションを指定•  確実にcommitさせる o  データファイルにフラッシュさせる §  fsync: true o  2台のメンバーに書き込みが完了するまで待機(timeout:5000) §  db.getlasterror(2, 5000) §  db.getlasterror(majority)
  25. 25. クエリ insert/updateの話 (2)•  ID値 o  デフォルトでは、IDは自動で振られる o  ObjectId = BSON( [4byte timestamp] + [3byte hash(hostname)] + [2byte pid] + [3byte inc]) // parseすれば時間やサーバーなどもわかる object_id = 4b0552b0f0da7d1eb6f12yyy’ createdDt = new Date(parseInt(object_id.substr(0, 8), 16) * 1000) #=> Thu Nov 19 2009 23:14:08 GMT+0900 (JST)
  26. 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. 27. クエリ removeの話•  断片化 o  削除時はドキュメントの再配置を行わないので断片化する o  repairコマンド §  同容量の空き領域が必要 §  サーバー単位(sharding環境なら各shardで) o  compactコマンド §  より少ない空き領域で可能 §  コレクション単位 §  paddingも削除するので、増加性を持ったコレクションはデ フラグ後にupdateパフォーマンス悪化
  28. 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. 29. 困った話 - 2•  書き込み時(flush時)はDBロックする o  あまり問題にならないほど、書き込みは高速とのこと §  ほんまかいな•  非効率なCPUリソース利用 o  書き込み処理とMapReduceではシングルコアしか使えない o  読み込みは複数コアを使う
  30. 30. みんなが苦労しているのは•  Shard key の決め方 o  Chunkの移動があまり起こらないこと o  長期の運用でも綺麗に分散すること o  Shard keyを使って効率よく検索できること•  Shard keyは一度決めると変えられない•  Migration中の残念なパフォーマンスと不整合
  31. 31. Shard keyの考察 (うけうり)•  [bad] 離散データ o  chunk分割できない §  例:都道府県コード•  [bad] 単純インクリメントデータ o  最後のchunkのみが分割移動される §  例:連番•  [bad] ランダム値 o  十分に分散するまでは偏りがあるため、大きなchunkができる §  例:ハッシュ•  [good] 緩やかに増加するキーと検索に利用するキーの組 み合わせ o  検索利用キーでひと月かけて偏りが発生してくるが、ひと月たてば偏 りがリセットされる §  例:yyyymm-owner_id
  32. 32. シンプルな解析PFの例 Web Web 使ったことないものを 仕事で使ってみたいという想い 解析用サーバー 日次増分をMap/Reduceで集計 認証機能が必要なため。 I/Oをjsonで一致させて 開発スピードアップ
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×