MongoDB〜その性質と利用場面〜
•
25 gefällt mir•65,339 views
2014年2月7日、OSS推進フォーラム クラウド技術部会にて発表したMongoDBの入門プレゼンです。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie MongoDB〜その性質と利用場面〜
Ähnlich wie MongoDB〜その性質と利用場面〜 (20)
Mehr von Naruhiko Ogasawara
Mehr von Naruhiko Ogasawara (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
MongoDB〜その性質と利用場面〜
- 1. 日本 OSS 推進フォーラム クラウド技術部会 MongoDB 〜その性質と利用場面〜 2014 年 2 月 7 日（金） 株式会社ミライト情報システム オープンソリューション技術本部 小笠原 徳彦 ogasawara.naruhiko@miraitsystems.jp
- 2. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 2/61
- 3. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 3/61
- 4. 自己紹介 小笠原 徳彦 （株）ミライト情報システム オープンソリューション技術本部 応用システム技術部 所属 MongoDB 日本ユーザー会 MongoDB JP メンバー MongoDB University Certified Engineer 日本OSS推進フォーラム クラウド技術部会 4/61
- 5. ミライト情報システムについて 2012 年 7 月 1 日発足 ミライト・ ホールディングス 「ミライト」は Mirai + IT の 造語 IT と技術で作る未来の 通信、未来の暮らし。 企業スローガン 「 OPEN THE NEXT! 」 私たちは、オープンシス テムでお客様の「次」を 拓きます 2012 年 10 月 1 日〜 ミライト・テクノロジーズ 2012 年 7 月 1 日〜 株式会社ミライト情報システム 日本OSS推進フォーラム クラウド技術部会 5/61
- 7. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 7/61
- 8. RDBMS と NoSQL(1) RDBMS (Relational Database Management System) 関係モデルに基づいたデータベース管理システム SQL (Standard Query Language) による宣言的な操作 オプティマイザにより「どうデータを格納し」「どうデータを得 る」かは最適化されて高速に実行される アトミックなデータ操作 データの一貫性保持が重要 日本OSS推進フォーラム クラウド技術部会 8/61
- 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. 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. NoSQL の一つとしての MongoDB(1) ドキュメント指向データベース スケーラビリティ＆パフォーマンス バランスの良い NoSQL を目指す memcached key/value store MongoDB RDBMS 機能の豊富さ https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144 日本OSS推進フォーラム クラウド技術部会 11/61
- 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. MongoDB の割り切り トランザクションを持たない 複数の操作をくるんで、途中で失敗したらロールバック ……といった機能はない 一つ一つのデータ操作はアトミック JOIN がない 複数のドキュメントを DB 側で結合はできない アプリケーションで結合する必要があるがアトミックな操 作ではない …… でも、なくても構わない状況は多いよね？ と いう割り切りがポイント 日本OSS推進フォーラム クラウド技術部会 13/61
- 14. MongoDB/NoSQL と RDBMS NoSQL とは一般に「使い方にクセがある」「どこか 割り切ったことがある」「その代わりにとても得意な ところがある」もの 速度 100 クエリーの種類 スケーラビリティ 50 RDBMS MongoDB 0 トランザクション ディスク使用量 メモリ使用量 このグラフは 例であり 実際の評価では ありません 事前に「不得意なところが許容できるか」を判断で きないなら、素直に RDBMS を使ったほうが良い 日本OSS推進フォーラム クラウド技術部会 14/61
- 15. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 15/61
- 16. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 16/61
- 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. 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. ドキュメント指向と動的スキーマ (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
- 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. ブログのスキーマ例 (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. ブログのスキーマ例 (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. ブログのスキーマ例 (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. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 25/61
- 26. MongoDB の性能の秘密 ● MongoDB はファイルシステムに展開されているコレ クションを mmap している P. mem V. mem Storage ローカリティがある READ アクセスについてはオンメモリ でアクセスするので高速 要は「ディスクにスワップアウトできるオンメモリ DB 」 逆に言うと全データアクセスをするような処理は page in/out が多発するので性能が出ない 日本OSS推進フォーラム クラウド技術部会 26/61
- 27. データアクセスとインデックス MongoDB のデータアクセスはとても素朴 頭から順に舐めているだけ（線形探索）＝検索 O(n) ついでにいうとドキュメントの順序は保証されない Doc1 Doc2 Doc3 … DocN update Doc2 （サイズ拡大） Doc1 （隙間） Doc3 … DocN Doc2 インデックス あるキーに着目した B-Tree インデックス＝検索 O(log n) 検索・ソートに利用可 日本OSS推進フォーラム クラウド技術部会 27/61
- 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. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 30/61
- 31. レプリカセット基礎 (1) レプリカセット：簡単な仕組みで高可用性を実現 最低 3 台のノードをセットにして動かす アプリケーションに応答するプライマリノードは自動的に 決定される（明示的なマスターノードは存在しない） Replication Secondary 1 Heartbeat Driver Application Read Write Secondary 2 Primary Replication 日本OSS推進フォーラム クラウド技術部会 31/61
- 32. レプリカセット基礎 (2) プライマリノードがダウンした場合 残ったノード間で投票を行い次のプライマリを決める この場合は「どこまでレプリケーションが終わっている か」で決まる Secondary 1 ぼくは 5 分前の 処理まで レプリカもらったよ Heartbeat Driver Application Primary Secondary 2 ぼくは 10 分前 までだなぁ 日本OSS推進フォーラム クラウド技術部会 32/61
- 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. レプリカセット基礎 (4) ダウンしていたノードが復活するとセカンダリノード に復帰 ただしダウンタイムが長いと自動復帰は不可 動いているセカンダリノードからリストアするのが無難 Primary EAD R E RIT W Driver Application 日本OSS推進フォーラム クラウド技術部会 Secondary 2 Heartbeat Re pl ica tio n Secondary 2 34/61
- 35. レプリカセット基礎 (5) Heartbeat: ノード間の死活監視 OPLOG: プライマリノードの操作をセカンダリにレプリケーション するために、操作を保存するコレクション 有限サイズのコレクション（ Capped collection ） セカンダリが長時間停止していると溢れてレプリカセットが機 能不全を起こす 日本OSS推進フォーラム クラウド技術部会 35/61
- 36. レプリカセット応用 (1) Arbiter: 投票権のみ持ち、データを持たないノード システム構成のコストを下げることが可能 ただし冗長性は下がる（トレードオフ） Primary Secondary 日本OSS推進フォーラム クラウド技術部会 Arbiter 36/61
- 37. レプリカセット応用 (2) Delayed Node: オペレーションミス対策 レプリケーションを意図的に遅らせたノード オペミスしてデータを失ったときにすぐに Delayed Node から巻き戻せば復帰可能 Primary Secondary 日本OSS推進フォーラム クラウド技術部会 Secondary 30 分遅れ Delayed Secondary slaveDelay=1800 priority=0 hidden=true 37/61
- 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. レプリカセット応用 (4) Disaster Recovery （災害復旧）対策 データセンタをまたいでレプリカセットを構築することで、 DC がまるごと死んだとしてもサービス提供可能 Datacenter 1 Datacenter 2 Primary Secondary Secondary Secondary Secondary 日本OSS推進フォーラム クラウド技術部会 Arbiter 39/61
- 40. レプリカセットの魅力 仕組み自体はとてもシンプル 高可用性を容易に実現できる 高いシステム構成の自由度 DR 対策やバックアップ対策などにも対応可能 水平展開、 DC をまたいだ運用が容易なクラウド時 代にふさわしい仕組み 日本OSS推進フォーラム クラウド技術部会 40/61
- 41. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 41/61
- 42. シャーディングとは sharding: 一般的なデータベース用語 スケールアップ DB 負荷を分散させるためにスケールアウトさせること DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS DBMS スケールアウト RDBMS の場合、同時にアクセスする必要のあるデータ は一つのサーバで処理するように注意深く配置する 非常に難しい 日本OSS推進フォーラム クラウド技術部会 42/61
- 43. MongoDB のオートシャーディング MongoDB はスケールアウト（＝シャーディング）で パフォーマンスを稼ぐ戦略 シャーディングを簡単に行う仕組みが組み込まれている ＝オートシャーディング 日本OSS推進フォーラム クラウド技術部会 43/61
- 44. オートシャーディングの仕組み (1) シャードキー オートシャーディングの 動作を規定するキー（複 合可） シャードキーの範囲に よってコレクションを塊 （チャンク）に分割する Shard key: username -∞ akio rakutaro naruhiko < 64MB < 64MB +∞ < 64MB Shard 1 A Chunk B C チャンク サイズは 64MB （標準） DB の操作によりサイズ 超過した場合は分割さ れる 日本OSS推進フォーラム クラウド技術部会 44/61
- 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. オートシャーディングの仕組み (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. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 A 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 47/61
- 48. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 Shard 1 Shard 2 A A B 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 48/61
- 49. オートシャーディングの仕組み (2) リバランシング 各シャードにおいて、最大のチャンク数を持つシャードと 最小のチャンク数を持つシャードの差が規定値を超えた 場合、バランスを取るためチャンクが移動する Shard 1 Shard 2 Shard 1 Shard 2 A Shard 1 Shard 2 A A B B C 新規にシャードを追加した場合も同様にリバランシング が起きる 日本OSS推進フォーラム クラウド技術部会 49/61
- 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. シャードキーに求められる性質 適度なランダムネス ある程度チャンク分割が進んだあとは、シャード内にまん べんなくチャンクが分配されるようになること シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配 置されること 適度なローカリティ あるひとまとまりの処理が数個のチャンク内で完結する シャーディングでは mmap がチャンク単位になるため、 うまくいくと各シャードでオンメモリで処理が可能になる 日本OSS推進フォーラム クラウド技術部会 51/61
- 53. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 53/61
- 54. デモの内容 AWS に構築したレプリカセットに Ruby スクリプトか らデータを投入 AWS 上でプライマリノード A をダウンさせる 自動フェイルオーバで別のノード B がプライマリに 昇格し、書き込みが継続することを確認 A を再度起動する A がセカンダリノードとして復旧することを確認 日本OSS推進フォーラム クラウド技術部会 54/61
- 55. 内容 自己紹介 NoSQL と MongoDB MongoDB の性質 ドキュメント指向 性能とインデックス レプリカセット オートシャーディング レプリカセットによる可用性デモ MongoDB の生きるケース、難しいケース 日本OSS推進フォーラム クラウド技術部会 55/61
- 58. MongoDB が難しいケース 一番最初にシステム構築、予算割り当てを明確に 求められるケース データの総量だけ分かっており、データの構造その 他について情報が一切ないケース 処理能力に応じた水平スケールが難しいケース 事前見積もり・構築・運用について 制限が強いケース 言い換えれば、 SIer 的案件では MongoDB は難しい ところもある 日本OSS推進フォーラム クラウド技術部会 58/61
- 59. まとめ MongoDB はクラウド時代に必要な種々の要素を備 えた、 RDBMS を補完する優れた DB である ただし嵌まりパターンに使った場合 これは MongoDB に限らず NoSQL に共通 アプリケーションを開発しながらスキーマをデザイン していく動的スキーマ シンプルな仕組みで高可用性を実現し、なおかつさ まざまなバリエーションを作れるレプリカセット 同じマシンを並べてパフォーマンスを稼ぐ水平ス ケーリングを支援するオートシャーディング 日本OSS推進フォーラム クラウド技術部会 59/61
- 60. 参考図書 MongoDB イン・アクション http://www.amazon.co.jp/dp/4873115906 Kyle Banker ( 著 ), Sky 株式会社 玉川 竜司 ( 翻訳 ) オライリー・ジャパン データベースエンジニア養成読本 [DB を自由自在 に活用するための知識とノウハウ満載 !] http://www.amazon.co.jp/dp/4774158062 データベースエンジニア養成読本編集部 技術評論社 日本OSS推進フォーラム クラウド技術部会 60/61
- 61. 著作権とライセンス・免責事項 本スライドの著作者は（株）ミライト情報システムと いたします。 本スライドはクリエイティブ コモンズ 表示 継承 4.0 国際ライセンスのもとに提供されています。 http://creativecommons.org/licenses/by-sa/4.0/deed.ja 本スライドの内容は小笠原徳彦の個人的見解によ るものであり、（株）ミライト情報システムその他所 属組織などの見解を代表するものではありません。 日本OSS推進フォーラム クラウド技術部会 61/61