MongoDB very basic (Japanese) / MongoDB基礎の基礎

OSC 2014 Kansai@Kyoto
MongoDB
基本の基本
2014.08.02
MongoDB 日本ユーザー会
MongoDB JP
小笠原徳彦
(OGASAWARA, Naruhiko)

OSC 2014 Kansai@Kyoto 2/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

MongoDB JP とは
MongoDB を使ってる！使いたい！興味ある！人たち
の集まり
公式サイト： http://www.mongodb.jp/
Google Groups:
https://groups.google.com/forum/#!forum/mongodb-jp
Facebook Page:
https://www.facebook.com/MongodbJp
丸の内 MongoDB 勉強会 #mongonouchi
http://syokenz.github.io/marunouchi-mongodb/

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

MongoDB とは
MongoDB Inc. が中心になって開発している NoSQL
データベース
MongoDB http://www.mongodb.org/
MongoDB Inc. http://www.mongodb.com/
ライセンスは AGPLv3
SQL のような DDL は存在しない
言語ごとに異なる「ドライバー」を経由してアクセス
C 、 C++ 、 Ruby 、 Perl 、 Python 、 Java 、 JavaScript 、
Scala 、 Haskell 、……

RDBMS と NoSQL(1)
RDBMS (Relational Database Management System)
関係モデルに基づいたデータベース管理システム
SQL (Standard Query Language) による宣言的な操作
オプティマイザにより「どうデータを格納し」「どうデータを得
る」かは最適化されて高速に実行される
アトミックなデータ操作
データの一貫性保持が重要

RDBMS と NoSQL(2)
しかしクラウド時代においては、データの一貫性保
持はコストが高い……こともある
一貫性保持は常に必要なのか？
例： EC サイトの在庫状況はリアルタイムでなくてもよい
決済時に一貫性が担保されていればよい
一貫性の完全な保持を諦めれば水平にスケールできる
DB
App
Tokyo
US App
EU App EU AppDB
US AppDB
Tokyo AppDB

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

NoSQL の一つとしての MongoDB(1)
ドキュメント指向データベース
バランスの良い NoSQL を目指す
https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144
スケーラビリティ＆パフォーマンス
機能の豊富さ
memcached
key/value
store
MongoDB
RDBMS

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!" }
]
}

MongoDB の割り切り
トランザクションを持たない
複数の操作をくるんで、途中で失敗したらロールバック
……といった機能はない
一つ一つのデータ操作はアトミック
JOIN がない
複数のドキュメントを DB 側で結合はできない
アプリケーションで結合する必要があるがアトミックな操
作ではない
…… でも、なくても構わない状況は多いよね？　と
いう割り切りがポイント

MongoDB/NoSQL と RDBMS
NoSQL とは一般に「使い方にクセがある」「どこか
割り切ったことがある」「その代わりにとても得意な
ところがある」もの
事前に「不得意なところが許容できるか」を判断で
きないなら、素直に RDBMS を使ったほうが良い
速度
クエリーの種類
トランザクション
メモリ使用量
ディスク使用量
スケーラビリティ
0
50
100
RDBMS
MongoDB
このグラフは
例であり
実際の評価では
ありません

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

MongoDB = ドキュメント指向
RDBMS: 関係（表） MongoDB: ドキュメント
ID NAME EMAIL
1 Naruhiko
Ogasawara
naruoga@exam
ple.com
2 Ichiro
Tanaka
tanaka.ichiro@e
xample.com
3 Taro
Yamada
taroy@example.
com
Users
ID CONTENT A_ID
1 ぼくもお気に入り！ 2
2 使い所難しいです
けどね。
3
... ... ...
Comments
ID ARTIC
LE_ID
COMM
ENT_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)
I

ドキュメント指向と動的スキーマ (1)
RDBMS: 表
各列の型は一致してい
る必要あり
MongoDB: ドキュメント
それぞれの文書の構造
は異なっていても構わ
ない
検索その他では存在す
る部分だけが対象
ドキュメントの集まりを
「コレクション」と呼ぶ
{
"_id" : ObjectId("52440666..."),
"comment" : [
{ "author" : "Ichiro Tanaka",
"email" : "tanaka.ichiro@example.com",
"content" : " ぼくもお気に入り！ " },
{ "author" : "Taro Yamada",
"content" : " 使い所難しいですけどね。 " },
]
}
{
"_id" : ObjectId("52440666..."),
"created" : ISODate("2013-09-26T10:03:18.825Z"),
}

ドキュメント指向と動的スキーマ (2)
アプリケーションの設計の段階で、スキーマ定義を
厳密に考えないでも大丈夫
すぐに開発に取り掛かれる
カジュアルにスキーマ定義を変更できる
スピード感のあるアプリ開発
パフォーマンスを得るにはスキーマに対する十分な
理解が必要なので「スキーマレス」は厳密には NO
作りながらスキーマを定義していく
動的スキーマ

スキーマ定義の例：ブログ
大雑把な仕様
記事が持つのはタイトル、内容、著者、記事が書かれた
日時、コメント、 permalink
コメントが持つのは内容、著者
blog.example.com
もんごたん楽しい！
by Naruhiko Ogasawara
MongoDB いいですね！好きです！
2014/01/23 13:13
comment (2)
ラーメン食べたい
by Taro Yamada
なんだかラーメンな気分。どこかで食べ
ていこうかな。
2014/01/22 20:13
comment (2)
...
新着
10 件
Click
blog.example.com/permalink
もんごたん楽しい！
by Naruhiko Ogasawara
MongoDB いいですね！好きです！
2014/01/23 13:13
ぼくもお気に入り！
by Ichiro Tanaka
使い所難しいですけどね。
by Taro Yamada
コメ
ント

ブログのスキーマ例 (1)
RDBMS 的にはこう
{
"_id" : ObjectId("52440666..."),
"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..."),
}
{
"_id" : ObjectId("52e1f2d3..."),
"author" : "Ichiro Tanaka",
"email" : "ichiro.tanaka@example.com",
}
{
"_id" : ObjectId("52e1f2e6..."),
"author" : "Taro Yamada",
}
Collection: authors
{
"_id" : ObjectId("52e1f310..."),
"author_id" : ObjectId("52e1f2d3..."),
"content" : " ぼくもお気に入り！ ",
}
{
"_id" : ObjectId("52e1f310..."),
"author_id" : ObjectId("52e1f2e6..."),
"content" : " 使い所難しいですけどね。 ",
}
Collection: comments
正規化のためにコレク
ションを分割
●
ちょっと煩雑
● アプリケーション JOIN
が必要になる
正規化のためにコレク
ションを分割
●
ちょっと煩雑
● アプリケーション JOIN
が必要になる

投稿とコメントは似た項目が多いのでまとめられる
{
"_id" : ObjectId("52440666..."),
"author_id" : ObjectId("52e1ee36..."),
"created_at” :
ISODate("2014-01-24T06:13:54.240Z")
"comment" : [
ObjectId("52e1f310..."),
ObjectId("52e1f310...")
]
}
{
"_id" : ObjectId("52e1f310..."),
"author_id" : ObjectId("52e1f2d3..."),
}
{
"_id" : ObjectId("52e1f310..."),
"author_id" : ObjectId("52e1f2e6..."),
}
Collection: posts
{
"_id" : ObjectId("52e1ee36..."),
}
{
"_id" : ObjectId("52e1f2d3..."),
}
{
"_id" : ObjectId("52e1f2e6..."),
}
Collection: authors
動的スキーマの利点を用いる
●
扱うコレクションが一個減ってスッ
キリした
●
アプリケーション JOIN が必要にな
る点は変わらない
動的スキーマの利点を用いる
●
扱うコレクションが一個減ってスッ
キリした
●
アプリケーション JOIN が必要にな
る点は変わらない

いっそのこと全部埋め込んでしまおう！
{
"_id" : ObjectId("52440666..."),
"created_at” :
ISODate("2014-01-24T06:13:54.240Z")
"comment" : [
{
},
{
},
]
}
Collection: posts
JSON においては配列の要素内には
任意の JSON オブジェクトをとれるの
で、この中にコメントの情報を直接埋
め込んでしまう（ embedded ）
● MongoDB の強力な文書操作機能
により、配列内部にデータを押し込
んでも柔軟に操作可能！
● あれ、 author 正規化しなくていい
の？
●
考えてみれば、ユーザー名とかパ
スワードのたぐいはブログアプリ側
でセッションで管理しているはずな
ので、 DB 側でユニーク性を保証す
る必要はない！と割り切れる
●
迷ったら埋め込み文書、が
MongoDB 的スキーマ設計
JSON においては配列の要素内には
任意の JSON オブジェクトをとれるの
で、この中にコメントの情報を直接埋
め込んでしまう（ embedded ）
● MongoDB の強力な文書操作機能
により、配列内部にデータを押し込
んでも柔軟に操作可能！
● あれ、 author 正規化しなくていい
の？
●
考えてみれば、ユーザー名とかパ
スワードのたぐいはブログアプリ側
でセッションで管理しているはずな
ので、 DB 側でユニーク性を保証す
る必要はない！と割り切れる
●
迷ったら埋め込み文書、が
MongoDB 的スキーマ設計

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

●MongoDB の性能の秘密
MongoDB はファイルシステムに展開されているコレ
クションを mmap している
ローカリティがある READ アクセスについてはオンメモリ
でアクセスするので高速
要は「ディスクにスワップアウトできるオンメモリ DB 」
ローカリティが低いアクセスは性能が出ない
Storage
V. mem
P. mem

データアクセスとインデックス
MongoDB のデータアクセスはとても素朴
頭から順に舐めているだけ（線形探索）＝検索 O(n)
ついでにいうとドキュメントの順序は保証されない
インデックス
あるキーに着目した B-Tree インデックス＝検索 O(log n)
検索・ソートに利用可
Doc1 Doc2 Doc3 … DocN
update Doc2 （サイズ拡大）
Doc1 Doc2Doc3 … DocN（隙間）

インデックス詳細
インデックスはコレクション自体と同じファイル
どんどん張っているとデータサイズが肥大化する
インデックスを後から張るとデータ量に比例した時
間がかかる（当然）
昇順・降順でインデックスは張れる
複数キーのインデックスも利用可能
db.posts.ensureIndex({created_at:-1, author:1})
部分的に使うことも可能

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

レプリカセット基礎 (1)
レプリカセット：簡単な仕組みで高可用性を実現
最低 3 台のノードをセットにして動かす
アプリケーションに応答するプライマリノードは自動的に
決定される（明示的なマスターノードは存在しない）
Secondary 1
Secondary 2Primary
Application
Driver
Read
Write
Heartbeat
Replication
Replication

プライマリノードがダウンした場合
残ったノード間で投票を行い次のプライマリを決める
この場合は「どこまでレプリケーションが終わっている
か」で決まる
Secondary 1
Secondary 2Primary
Application
Driver
Heartbeat
ぼくは 5 分前の
処理まで
レプリカもらったよ
ぼくは 10 分前
までだなぁ

選ばれたノードが次のプライマリになる
この時点でノードがダウンすると、 1 台では投票ができ
ないためレプリカセットがダウンする
1/3 冗長
Primary
Secondary 2Primary
Application
Driver
Heartbeat
じゃあぼくが
プライマリーやるね
Replication
READ
WRITE

ダウンしていたノードが復活するとセカンダリノード
に復帰
ただしダウンタイムが長いと自動復帰は不可
動いているセカンダリノードからリストアするのが無難
Primary
Secondary 2Secondary 2
Application
Driver
Heartbeat
Replication
READ
WRITE

Heartbeat:
ノード間の死活監視
OPLOG:
プライマリノードの操作をセカンダリにレプリケーション
するために、操作を保存するコレクション
有限サイズのコレクション（ Capped collection ）
セカンダリが長時間停止していると溢れてレプリカセットが機
能不全を起こす

レプリカセット応用 (1)
Arbiter: 投票権のみ持ち、データを持たないノード
システム構成のコストを下げることが可能
ただし冗長性は下がる（トレードオフ）
Primary
Secondary Arbiter

Delayed Node: オペレーションミス対策
レプリケーションを意図的に遅らせたノード
オペミスしてデータを失ったときにすぐに Delayed Node
から巻き戻せば復帰可能
Primary
Secondary Secondary
Delayed
Secondary
30 分遅れ
slaveDelay=1800
priority=0
hidden=true

セカンダリノードに対するアクセス
Write Concern
データの書き込みがどこまで波及
するまで待つかを設定する値
基本は即座に戻る
セカンダリノードの数も指定可
Read Prefence
セカンダリノードからの読み込みを
許可してプライマリの負荷を下げる
古い値を掴んでも大丈夫なとき
P
S S
j : 1
w : 2
P
S S
PRIMARY
SECONDARY

Disaster Recovery （災害復旧）対策
データセンタをまたいでレプリカセットを構築することで、
DC がまるごと死んだとしてもサービス提供可能
Primary
Secondary Secondary Secondary
Secondary
Arbiter
Datacenter 1 Datacenter 2

レプリカセットの魅力
仕組み自体はとてもシンプル
高可用性を容易に実現できる
高いシステム構成の自由度
DR 対策やバックアップ対策などにも対応可能
水平展開、 DC をまたいだ運用が容易なクラウド時
代にふさわしい仕組み

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

シャーディングとは
sharding: 一般的なデータベース用語
DB 負荷を分散させるためにスケールアウトさせること
RDBMS の場合、同時にアクセスする必要のあるデータ
は一つのサーバで処理するように注意深く配置する
非常に難しい
スケールアップ
DBMS
DBMS
DBMS
スケールアウト
DBMS DBMS DBMS DBMS
DBMS
DBMS DBMS
DBMS DBMS

MongoDB のオートシャーディング
MongoDB はスケールアウト（＝シャーディング）で
パフォーマンスを稼ぐ戦略
シャーディングを簡単に行う仕組みが組み込まれている
＝オートシャーディング

オートシャーディングの仕組み (1)
シャードキー
オートシャーディングの
動作を規定するキー（複
合可）
シャードキーの範囲に
よってコレクションを塊
（チャンク）に分割する
チャンク
サイズは 64MB （標準）
DB の操作によりサイズ
超過した場合は分割さ
れる
naruhiko
Shard key: username
< 64MB
akio rakutaro-∞ +∞
Shard 1
A
Chunk
< 64MB
C
ChunkChunk
< 64MB
B

シャードキー
合可）
チャンク
れる
naruhiko
Shard key: username
< 64MB
Shard 1
A
Chunk
< 64MB
C
ChunkChunk
< 64MB
B
db.foo.insert({username: "osamu", ....})

シャードキー
合可）
チャンク
れる
naruhiko
Shard key: username
< 64MB
Shard 1
A
Chunk
< 64MB
C
ChunkChunk
< 64MB
B
db.foo.insert({username: "osamu", ....})
naruhiko
Shard key: username
< 64MB
Shard 1
A
B から
分割
< 64MB
C
< 64MB
B
osamu
< 64MB
D

リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと
最小のチャンク数を持つシャードの差が規定値を超えた
場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシング
が起きる
A
Shard 1 Shard 2

が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B

が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B
A
Shard 1 Shard 2
B
C

が起きる
A
Shard 1 Shard 2
A
Shard 1 Shard 2
B
A
Shard 1 Shard 2
B
C
A
Shard 1 Shard 2
B
C
C

シャードキーに求められる性質
適度なランダムネス
ある程度チャンク分割が進んだあとは、シャード内にまん
べんなくチャンクが分配されるようになること
シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配
置されること
適度なローカリティ
あるひとまとまりの処理が数個のチャンク内で完結する
シャーディングでは mmap がチャンク単位になるため、
うまくいくと各シャードでオンメモリで処理が可能になる

オートシャーディングは万能か？
シャードキーをうまく選定できるか？が肝
シャードキーの選定ミスはパフォーマンスの劣化（と、場
合によっては OPLOG 溢れによるデータ喪失）を招く
シャードキーは一度決めたら変更は不可能なので、パイ
ロットプロジェクトなどで慎重にデータの性質を見極め
る必要がある
最初から超大規模なデータを扱うことだけが分かって
おり、データの性質が不明確な案件だとリスクがある

内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
まとめ

まとめ
MongoDB はクラウド時代に必要な種々の要素を備
えた、 RDBMS を補完する優れた DB である
ただし嵌まりパターンに使った場合
これは MongoDB に限らず NoSQL に共通
アプリケーションを開発しながらスキーマをデザイン
していく動的スキーマ
シンプルな仕組みで高可用性を実現し、なおかつさ
まざまなバリエーションを作れるレプリカセット
同じマシンを並べてパフォーマンスを稼ぐ水平ス
ケーリングを支援するオートシャーディング

参考図書
MongoDB イン・アクション
http://www.amazon.co.jp/dp/4873115906
Kyle Banker ( 著 ), Sky 株式会社玉川竜司 ( 翻訳 )
オライリー・ジャパン
データベースエンジニア養成読本 [DB を自由自在
に活用するための知識とノウハウ満載 !]
http://www.amazon.co.jp/dp/4774158062
データベースエンジニア養成読本編集部
技術評論社

MongoDB very basic (Japanese) / MongoDB基礎の基礎

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to MongoDB very basic (Japanese) / MongoDB基礎の基礎

Similar to MongoDB very basic (Japanese) / MongoDB基礎の基礎 (20)

More from Naruhiko Ogasawara

More from Naruhiko Ogasawara (20)

Recently uploaded

Recently uploaded (8)

MongoDB very basic (Japanese) / MongoDB基礎の基礎