MongoDB〜その性質と利用場面〜

12,634 views

Published on

2014年2月7日、OSS推進フォーラム クラウド技術部会にて発表したMongoDBの入門プレゼンです。

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

No Downloads
Views
Total views
12,634
On SlideShare
0
From Embeds
0
Number of Embeds
4,424
Actions
Shares
0
Downloads
87
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

MongoDB〜その性質と利用場面〜

  1. 1. 日本 OSS 推進フォーラム クラウド技術部会 MongoDB 〜その性質と利用場面〜 2014 年 2 月 7 日(金) 株式会社ミライト情報システム オープンソリューション技術本部 小笠原 徳彦 ogasawara.naruhiko@miraitsystems.jp
  2. 2. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 2/61
  3. 3. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 3/61
  4. 4. 自己紹介 小笠原 徳彦 (株)ミライト情報システム オープンソリューション技術本部 応用システム技術部 所属 MongoDB 日本ユーザー会 MongoDB JP メンバー MongoDB University Certified Engineer 日本OSS推進フォーラム クラウド技術部会 4/61
  5. 5. ミライト情報システムについて 2012 年 7 月 1 日発足 ミライト・ ホールディングス 「ミライト」は Mirai + IT の 造語 IT と技術で作る未来の 通信、未来の暮らし。 企業スローガン 「 OPEN THE NEXT! 」 私たちは、オープンシス テムでお客様の「次」を 拓きます 2012 年 10 月 1 日〜 ミライト・テクノロジーズ 2012 年 7 月 1 日〜 株式会社ミライト情報システム 日本OSS推進フォーラム クラウド技術部会 5/61
  6. 6. オープンソリューション技術本部 オープンスタンダード、オープンソースを活用して 低コストで高品位なソリューションを提供する http://www.miraitsystems.jp/opensource/nosql.html 日本OSS推進フォーラム クラウド技術部会 6/61
  7. 7. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 7/61
  8. 8. RDBMS と NoSQL(1) RDBMS (Relational Database Management System) 関係モデルに基づいたデータベース管理システム SQL (Standard Query Language) による宣言的な操作 オプティマイザにより「どうデータを格納し」「どうデータを得 る」かは最適化されて高速に実行される アトミックなデータ操作 データの一貫性保持が重要 日本OSS推進フォーラム クラウド技術部会 8/61
  9. 9. RDBMS と NoSQL(2) しかしクラウド時代においては、データの一貫性保 持はコストが高い……こともある Tokyo Tokyo App US App DB US App EU DB App DB App DB EU App 一貫性保持は常に必要なのか? 例: EC サイトの在庫状況はリアルタイムでなくてもよい 決済時に一貫性が担保されていればよい 一貫性の完全な保持を諦めれば水平にスケールできる 日本OSS推進フォーラム クラウド技術部会 9/61
  10. 10. RDBMS と NoSQL(3) クラウドに必要な要件を持つストレージエンジンを RDBMS と使いわける シンプルな機能 高速 スケーラブル Not Only SQL = NoSQL (SQL に NO! ではない ) Key Value Store (KVS) Apache Cassandra, Tokyo Cabinet, Rakuten ROMA, Redis, Riak グラフ指向 DB Neo4j, HyperGraphDB 列指向 DB Apache HBase ドキュメント指向 DB CouchDB, MongoDB 日本OSS推進フォーラム クラウド技術部会 10/61
  11. 11. NoSQL の一つとしての MongoDB(1) ドキュメント指向データベース スケーラビリティ&パフォーマンス バランスの良い NoSQL を目指す memcached key/value store MongoDB RDBMS 機能の豊富さ https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144 日本OSS推進フォーラム クラウド技術部会 11/61
  12. 12. MongoDB の強み ドキュメント指向 { } "_id" : ObjectId("524406662caf1cab1f000001"), "title" : "MongoDB is fun!", "body" : "I love MongoDB very much.", "author" : "naruoga@example.com", "created" : ISODate("2013-09-26T10:03:18.825Z"), "comment" : [ { "author" : "foo@example.com", "content" : "I also love it!" } ] 多彩なクエリー 文字列としてのマッチ、範囲検索、正規表現など 論理演算で複数の条件の組み合わせも可 B-Tree インデックスによる検索・ソートも使える ほぼオンメモリで動作するため非常に高速 日本OSS推進フォーラム クラウド技術部会 12/61
  13. 13. MongoDB の割り切り トランザクションを持たない 複数の操作をくるんで、途中で失敗したらロールバック ……といった機能はない 一つ一つのデータ操作はアトミック JOIN がない 複数のドキュメントを DB 側で結合はできない アプリケーションで結合する必要があるがアトミックな操 作ではない …… でも、なくても構わない状況は多いよね? と いう割り切りがポイント 日本OSS推進フォーラム クラウド技術部会 13/61
  14. 14. MongoDB/NoSQL と RDBMS NoSQL とは一般に「使い方にクセがある」「どこか 割り切ったことがある」「その代わりにとても得意な ところがある」もの 速度 100 クエリーの種類 スケーラビリティ 50 RDBMS MongoDB 0 トランザクション ディスク使用量 メモリ使用量 このグラフは 例であり 実際の評価では ありません 事前に「不得意なところが許容できるか」を判断で きないなら、素直に RDBMS を使ったほうが良い 日本OSS推進フォーラム クラウド技術部会 14/61
  15. 15. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 15/61
  16. 16. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 16/61
  17. 17. MongoDB = ドキュメント指向 RDBMS: 関係(表) Entries ID TITLE 1 ... BODY もんごた ん楽しい! MongoDB いいです ね!好きです! ... ... MongoDB: ドキュメント { A_ID 1 ... CommentsLink ID ARTIC LE_ID ID Users COMM ENT_ID NAME EMAIL 1 1 1 Naruhiko Ogasawara naruoga@exam ple.com 2 1 2 2 Ichiro Tanaka tanaka.ichiro@e xample.com 3 Taro Yamada taroy@example. com 1 ... ... ... } Comments ID CONTENT A_ID 1 ぼくもお気に入り! 使い所難しいです けどね。 ↑JSON (JavaScript Object Notation) 2 2 "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "tanaka.ichiro@example.com", "content" : " ぼくもお気に入り! " }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 " } ] 3 ... 日本OSS推進フォーラム クラウド技術部会 ... ... 17/61
  18. 18. DEMO: 文書挿入 mongo shell に接続して、 db test の collection foo に適当な値を突っ込みます $ mongo MongoDB shell version: 2.4.6 connecting to: test > use test switched to db test > db.foo.find() > db.foo.insert({name: "Naruhiko Ogasawara", email : "naruoga@example.com", city: "Sakura"}) > db.foo.find() { "_id" : ObjectId("52e20ebeb5b6beeb03b2074e"), "name" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "city" : "Sakura" } 日本OSS推進フォーラム クラウド技術部会 18/61
  19. 19. ドキュメント指向と動的スキーマ (1) RDBMS: 表 { 各列の型は一致してい る必要あり MongoDB: ドキュメント それぞれの文書の構造 は異なっていても構わ ない 検索その他では存在す る部分だけが対象 ドキュメントの集まりを 「コレクション」と呼ぶ 日本OSS推進フォーラム クラウド技術部会 } { } "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "tanaka.ichiro@example.com", "content" : " ぼくもお気に入り! " }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 " }, ] "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "created" : ISODate("2013-09-26T10:03:18.825Z"), 19/61
  20. 20. ドキュメント指向と動的スキーマ (2) アプリケーションの設計の段階で、スキーマ定義を 厳密に考えないでも大丈夫 すぐに開発に取り掛かれる カジュアルにスキーマ定義を変更できる スピード感のあるアプリ開発 パフォーマンスを得るにはスキーマに対する十分な 理解が必要なので「スキーマレス」は厳密には NO 作りながらスキーマを定義していく 動的スキーマ 日本OSS推進フォーラム クラウド技術部会 20/61
  21. 21. スキーマ定義の例:ブログ blog.example.com もんごたん楽しい! by Naruhiko Ogasawara MongoDB いいですね!好きです! 2014/01/23 13:13 comment (2) ラーメン食べたい by Taro Yamada なんだかラーメンな気分。どこかで食べ ていこうかな。 2014/01/22 20:13 comment (2) blog.example.com/permalink Click もんごたん楽しい! by Naruhiko Ogasawara MongoDB いいですね!好きです! 2014/01/23 13:13 新着 10 件 ぼくもお気に入り! by Ichiro Tanaka 使い所難しいですけどね。 by Taro Yamada コメ ント ... 大雑把な仕様 記事が持つのはタイトル、内容、著者、記事が書かれた 日時、コメント、 permalink コメントが持つのは内容、著者 日本OSS推進フォーラム クラウド技術部会 21/61
  22. 22. ブログのスキーマ例 (1) RDBMS 的にはこう Collection: authors { Collection: posts { } "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author_id" : ObjectId("52e1ee36..."), "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ ObjectId("52e1f310..."), ObjectId("52e1f310...") ] } { } { } "_id" : ObjectId("52e1ee36..."), "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "taroy@example.com", Collection: comments { } { } "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : " ぼくもお気に入り! ", "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : " 使い所難しいですけどね。 ", 日本OSS推進フォーラム クラウド技術部会 正規化のためにコレク 正規化のためにコレク ションを分割 ションを分割 ● ちょっと煩雑 ● ちょっと煩雑 ● アプリケーション JOIN ● アプリケーション JOIN が必要になる が必要になる 22/61
  23. 23. ブログのスキーマ例 (2) 投稿とコメントは似た項目が多いのでまとめられる Collection: posts { } { } { } "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author_id" : ObjectId("52e1ee36..."), "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ ObjectId("52e1f310..."), ObjectId("52e1f310...") ] "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : " ぼくもお気に入り! ", "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : " 使い所難しいですけどね。 ", 日本OSS推進フォーラム クラウド技術部会 Collection: authors { } { } { } "_id" : ObjectId("52e1ee36..."), "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "taroy@example.com", 動的スキーマの利点を用いる 動的スキーマの利点を用いる ● 扱うコレクションが一個減ってスッ ● 扱うコレクションが一個減ってスッ キリした キリした ● アプリケーション JOIN が必要にな ● アプリケーション JOIN が必要にな る点は変わらない る点は変わらない 23/61
  24. 24. ブログのスキーマ例 (3) いっそのこと全部埋め込んでしまおう! Collection: posts { } "_id" : ObjectId("52440666..."), "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", "content" : " ぼくもお気に入り! ", }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 ", }, ] 日本OSS推進フォーラム クラウド技術部会 JSON においては配列の要素内には JSON においては配列の要素内には 任意の JSON オブジェクトをとれるの 任意の JSON オブジェクトをとれるの で、この中にコメントの情報を直接埋 で、この中にコメントの情報を直接埋 め込んでしまう( embedded )) め込んでしまう( embedded MongoDB の強力な文書操作機能 MongoDB の強力な文書操作機能 により、配列内部にデータを押し込 により、配列内部にデータを押し込 んでも柔軟に操作可能! んでも柔軟に操作可能! ● あれ、 author 正規化しなくていい ● あれ、 author 正規化しなくていい の? の? ● 考えてみれば、ユーザー名とかパ ● 考えてみれば、ユーザー名とかパ スワードのたぐいはブログアプリ側 スワードのたぐいはブログアプリ側 でセッションで管理しているはずな でセッションで管理しているはずな ので、 DB 側でユニーク性を保証す ので、 DB 側でユニーク性を保証す る必要はない!と割り切れる る必要はない!と割り切れる ● 迷ったら埋め込み文書、が ● 迷ったら埋め込み文書、が MongoDB 的スキーマ設計 MongoDB 的スキーマ設計 ● ● 24/61
  25. 25. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 25/61
  26. 26. MongoDB の性能の秘密 ● MongoDB はファイルシステムに展開されているコレ クションを mmap している P. mem V. mem Storage ローカリティがある READ アクセスについてはオンメモリ でアクセスするので高速 要は「ディスクにスワップアウトできるオンメモリ DB 」 逆に言うと全データアクセスをするような処理は page in/out が多発するので性能が出ない 日本OSS推進フォーラム クラウド技術部会 26/61
  27. 27. データアクセスとインデックス MongoDB のデータアクセスはとても素朴 頭から順に舐めているだけ(線形探索)=検索 O(n) ついでにいうとドキュメントの順序は保証されない Doc1 Doc2 Doc3 … DocN update Doc2 (サイズ拡大) Doc1 (隙間) Doc3 … DocN Doc2 インデックス あるキーに着目した B-Tree インデックス=検索 O(log n) 検索・ソートに利用可 日本OSS推進フォーラム クラウド技術部会 27/61
  28. 28. インデックス詳細 インデックスはコレクション自体と同じファイル どんどん張っているとデータサイズが肥大化する インデックスを後から張るとデータ量に比例した時 間がかかる(当然) 昇順・降順でインデックスは張れる 複数キーのインデックスも利用可能 db.posts.ensureIndex({created_at:-1, author:1}) 部分的に使うことも可能 キーの存在はドキュメントによるが、それでもイン デックスは張れる 日本OSS推進フォーラム クラウド技術部会 28/61
  29. 29. インデックス _id の節約 先ほどのブログのスキーマを少し改良 Collection: posts { } "_id" : "mongo_tan_is_fun", "title" : " もんごたん楽しい! ", "body" : "MongoDB いいですね!好きです! ", "author" : "Naruhiko Ogasawara", "email" : "naruoga@example.com", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "ichiro.tanaka@example.com", "content" : " ぼくもお気に入り! ", }, { "author" : "Taro Yamada", "email" : "taroy@example.com", "content" : " 使い所難しいですけどね。 ", }, ] 日本OSS推進フォーラム クラウド技術部会 _id は必ずインデックスが張られるの _id は必ずインデックスが張られるの で、メモリ・ストレージを余計に消費 で、メモリ・ストレージを余計に消費 する する ● 文書作成時に指定しない場合は ● 文書作成時に指定しない場合は 自動的に生成される( 12 バイトの 自動的に生成される( 12 バイトの バイト列) バイト列) ● インデックスを張ったほうが良く、一 ● インデックスを張ったほうが良く、一 意性が保証される値が別にあるな 意性が保証される値が別にあるな ら、それを _id にするとよい ら、それを _id にするとよい ● ブログにおいては permalink は当 ● ブログにおいては permalink は当 然リンクとしてユニークなものだと 然リンクとしてユニークなものだと いうアプリ要件があるから、これを いうアプリ要件があるから、これを _id にすると便利 _id にすると便利 29/61
  30. 30. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 30/61
  31. 31. レプリカセット基礎 (1) レプリカセット:簡単な仕組みで高可用性を実現 最低 3 台のノードをセットにして動かす アプリケーションに応答するプライマリノードは自動的に 決定される(明示的なマスターノードは存在しない) Replication Secondary 1 Heartbeat Driver Application Read Write Secondary 2 Primary Replication 日本OSS推進フォーラム クラウド技術部会 31/61
  32. 32. レプリカセット基礎 (2) プライマリノードがダウンした場合 残ったノード間で投票を行い次のプライマリを決める この場合は「どこまでレプリケーションが終わっている か」で決まる Secondary 1 ぼくは 5 分前の 処理まで レプリカもらったよ Heartbeat Driver Application Primary Secondary 2 ぼくは 10 分前 までだなぁ 日本OSS推進フォーラム クラウド技術部会 32/61
  33. 33. レプリカセット基礎 (3) 選ばれたノードが次のプライマリになる この時点でノードがダウンすると、 1 台では投票ができ ないためレプリカセットがダウンする 1/3 冗長 Primary EAD R E RIT W Driver Application 日本OSS推進フォーラム クラウド技術部会 Heartbeat Primary じゃあぼくが プライマリーやるね Re pl ica tio n Secondary 2 33/61
  34. 34. レプリカセット基礎 (4) ダウンしていたノードが復活するとセカンダリノード に復帰 ただしダウンタイムが長いと自動復帰は不可 動いているセカンダリノードからリストアするのが無難 Primary EAD R E RIT W Driver Application 日本OSS推進フォーラム クラウド技術部会 Secondary 2 Heartbeat Re pl ica tio n Secondary 2 34/61
  35. 35. レプリカセット基礎 (5) Heartbeat: ノード間の死活監視 OPLOG: プライマリノードの操作をセカンダリにレプリケーション するために、操作を保存するコレクション 有限サイズのコレクション( Capped collection ) セカンダリが長時間停止していると溢れてレプリカセットが機 能不全を起こす 日本OSS推進フォーラム クラウド技術部会 35/61
  36. 36. レプリカセット応用 (1) Arbiter: 投票権のみ持ち、データを持たないノード システム構成のコストを下げることが可能 ただし冗長性は下がる(トレードオフ) Primary Secondary 日本OSS推進フォーラム クラウド技術部会 Arbiter 36/61
  37. 37. レプリカセット応用 (2) Delayed Node: オペレーションミス対策 レプリケーションを意図的に遅らせたノード オペミスしてデータを失ったときにすぐに Delayed Node から巻き戻せば復帰可能 Primary Secondary 日本OSS推進フォーラム クラウド技術部会 Secondary 30 分遅れ Delayed Secondary slaveDelay=1800 priority=0 hidden=true 37/61
  38. 38. レプリカセット応用 (3) セカンダリノードに対するアクセス Write Concern データの書き込みがどこまで波及 するまで待つかを設定する値 P j:1 w:2 S S 基本は即座に戻る セカンダリノードの数も指定可 Read Prefence RY 日本OSS推進フォーラム クラウド技術部会 A ND CO SE セカンダリノードからの読み込みを 許可してプライマリの負荷を下げる レプリケーション前の値を掴んでも 大丈夫なときに用いる PRIMARY S P S 38/61
  39. 39. レプリカセット応用 (4) Disaster Recovery (災害復旧)対策 データセンタをまたいでレプリカセットを構築することで、 DC がまるごと死んだとしてもサービス提供可能 Datacenter 1 Datacenter 2 Primary Secondary Secondary Secondary Secondary 日本OSS推進フォーラム クラウド技術部会 Arbiter 39/61
  40. 40. レプリカセットの魅力 仕組み自体はとてもシンプル 高可用性を容易に実現できる 高いシステム構成の自由度 DR 対策やバックアップ対策などにも対応可能 水平展開、 DC をまたいだ運用が容易なクラウド時 代にふさわしい仕組み 日本OSS推進フォーラム クラウド技術部会 40/61
  41. 41. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 41/61
  42. 42. シャーディングとは sharding: 一般的なデータベース用語 スケールアップ DB 負荷を分散させるためにスケールアウトさせること DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS スケールアウト RDBMS の場合、同時にアクセスする必要のあるデータ は一つのサーバで処理するように注意深く配置する 非常に難しい 日本OSS推進フォーラム クラウド技術部会 42/61
  43. 43. MongoDB のオートシャーディング MongoDB はスケールアウト(=シャーディング)で パフォーマンスを稼ぐ戦略 シャーディングを簡単に行う仕組みが組み込まれている =オートシャーディング 日本OSS推進フォーラム クラウド技術部会 43/61
  44. 44. オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する Shard key: username -∞ akio rakutaro naruhiko < 64MB < 64MB +∞ < 64MB Shard 1 A Chunk B C チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる 日本OSS推進フォーラム クラウド技術部会 44/61
  45. 45. オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する Shard key: username -∞ akio rakutaro naruhiko < 64MB < 64MB +∞ < 64MB Shard 1 A Chunk B C db.foo.insert({username: "osamu", ....}) チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる 日本OSS推進フォーラム クラウド技術部会 45/61
  46. 46. オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー(複 合可) シャードキーの範囲に よってコレクションを塊 (チャンク)に分割する チャンク サイズは 64MB (標準) DB の操作によりサイズ 超過した場合は分割さ れる 日本OSS推進フォーラム クラウド技術部会 Shard key: username -∞ akio rakutaro naruhiko < 64MB < 64MB +∞ < 64MB Shard 1 A Chunk B C db.foo.insert({username: "osamu", ....}) Shard key: username -∞ akio naruhiko osamu < 64MB < 64MB rakutaro < 64MB +∞ < 64MB Shard 1 A C B D B から 分割 46/61
  47. 47. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 A 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 47/61
  48. 48. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 Shard 1 Shard 2 A A B 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 48/61
  49. 49. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 Shard 1 Shard 2 A Shard 1 Shard 2 A A B B C 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 49/61
  50. 50. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 Shard 1 Shard 2 A Shard 1 Shard 2 Shard 1 Shard 2 A A A B B B C C C 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 50/61
  51. 51. シャードキーに求められる性質 適度なランダムネス ある程度チャンク分割が進んだあとは、シャード内にまん べんなくチャンクが分配されるようになること シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配 置されること 適度なローカリティ あるひとまとまりの処理が数個のチャンク内で完結する シャーディングでは mmap がチャンク単位になるため、 うまくいくと各シャードでオンメモリで処理が可能になる 日本OSS推進フォーラム クラウド技術部会 51/61
  52. 52. オートシャーディングは万能か? シャードキーをうまく選定できるか?が肝 シャードキーの選定ミスはパフォーマンスの劣化(と、場 合によっては OPLOG 溢れによるデータ喪失)を招く シャードキーは一度決めたら変更は不可能なので、パイ ロットプロジェクトなどで慎重にデータの性質を見極め る必要がある 最初から超大規模なデータを扱うことだけが分かって おり、データの性質が不明確な案件だとリスクがある 日本OSS推進フォーラム クラウド技術部会 52/61
  53. 53. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 53/61
  54. 54. デモの内容 AWS に構築したレプリカセットに Ruby スクリプトか らデータを投入 AWS 上でプライマリノード A をダウンさせる 自動フェイルオーバで別のノード B がプライマリに 昇格し、書き込みが継続することを確認 A を再度起動する A がセカンダリノードとして復旧することを確認 日本OSS推進フォーラム クラウド技術部会 54/61
  55. 55. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 55/61
  56. 56. MongoDB が生きるケース アプリケーションを作りながらスキーマ設計やサイ ジング設計を行うことができるケース ダウンタイムレスの可用性が求められ、そのための 投資が許容されるケース パブリッククラウドなどで、水平スケールが容易に可 能なケース アプリケーションサイドに 自由度を与えたいケース 日本OSS推進フォーラム クラウド技術部会 56/61
  57. 57. MongoDB が難しいケース 一番最初にシステム構築、予算割り当てを明確に 求められるケース データの総量だけ分かっており、データの構造その 他について情報が一切ないケース 処理能力に応じた水平スケールが難しいケース 事前見積もり・構築・運用について 制限が強いケース 日本OSS推進フォーラム クラウド技術部会 57/61
  58. 58. MongoDB が難しいケース 一番最初にシステム構築、予算割り当てを明確に 求められるケース データの総量だけ分かっており、データの構造その 他について情報が一切ないケース 処理能力に応じた水平スケールが難しいケース 事前見積もり・構築・運用について 制限が強いケース 言い換えれば、 SIer 的案件では MongoDB は難しい ところもある 日本OSS推進フォーラム クラウド技術部会 58/61
  59. 59. まとめ MongoDB はクラウド時代に必要な種々の要素を備 えた、 RDBMS を補完する優れた DB である ただし嵌まりパターンに使った場合 これは MongoDB に限らず NoSQL に共通 アプリケーションを開発しながらスキーマをデザイン していく動的スキーマ シンプルな仕組みで高可用性を実現し、なおかつさ まざまなバリエーションを作れるレプリカセット 同じマシンを並べてパフォーマンスを稼ぐ水平ス ケーリングを支援するオートシャーディング 日本OSS推進フォーラム クラウド技術部会 59/61
  60. 60. 参考図書 MongoDB イン・アクション http://www.amazon.co.jp/dp/4873115906 Kyle Banker ( 著 ), Sky 株式会社 玉川 竜司 ( 翻訳 ) オライリー・ジャパン データベースエンジニア養成読本 [DB を自由自在 に活用するための知識とノウハウ満載 !] http://www.amazon.co.jp/dp/4774158062 データベースエンジニア養成読本編集部 技術評論社 日本OSS推進フォーラム クラウド技術部会 60/61
  61. 61. 著作権とライセンス・免責事項 本スライドの著作者は(株)ミライト情報システムと いたします。 本スライドはクリエイティブ コモンズ 表示 継承 4.0 国際ライセンスのもとに提供されています。 http://creativecommons.org/licenses/by-sa/4.0/deed.ja 本スライドの内容は小笠原徳彦の個人的見解によ るものであり、(株)ミライト情報システムその他所 属組織などの見解を代表するものではありません。 日本OSS推進フォーラム クラウド技術部会 61/61

×