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