MongoDB〜その性質と利用場面〜
25 likes65,475 views
2014年2月7日、OSS推進フォーラム クラウド技術部会にて発表したMongoDBの入門プレゼンです。
![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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-12-320.jpg)
![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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-17-320.jpg)
![ドキュメント指向と動的スキーマ (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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-19-320.jpg)
![ブログのスキーマ例 (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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-22-320.jpg)
![ブログのスキーマ例 (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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-23-320.jpg)
![ブログのスキーマ例 (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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-24-320.jpg)
![インデックス _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](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-29-320.jpg)
![参考図書
MongoDB イン・アクション
http://www.amazon.co.jp/dp/4873115906
Kyle Banker ( 著 ), Sky 株式会社 玉川 竜司 ( 翻訳 )
オライリー・ジャパン
データベースエンジニア養成読本 [DB を自由自在
に活用するための知識とノウハウ満載 !]
http://www.amazon.co.jp/dp/4774158062
データベースエンジニア養成読本編集部
技術評論社
日本OSS推進フォーラム クラウド技術部会
60/61](https://image.slidesharecdn.com/ossforum-mongodb-140209072145-phpapp02/85/MongoDB-60-320.jpg)
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