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 勉強会 #mongonouchihttp://syokenz.github.io/marunouchi-mongodb/

http://www.mongodb.jp/

https://groups.google.com/forum/#!forum/mongodb-jp

https://www.facebook.com/MongodbJp

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 、……

http://www.mongodb.org/

http://www.mongodb.com/


RDBMS と NoSQL(1)

RDBMS (Relational Database Management System)関係モデルに基づいたデータベース管理システム

SQL (Standard Query Language) による宣言的な操作オプティマイザにより「どうデータを格納し」「どうデータを得る」かは最適化されて高速に実行される

アトミックなデータ操作

データの一貫性保持が重要


RDBMS と NoSQL(2)しかしクラウド時代においては、データの一貫性保持はコストが高い……こともある

一貫性保持は常に必要なのか？例： EC サイトの在庫状況はリアルタイムでなくてもよい

決済時に一貫性が担保されていればよい

一貫性の完全な保持を諦めれば水平にスケールできる

DB

AppTokyo

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/valuestore

MongoDB

RDBMS

https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144


MongoDB の強み


多彩なクエリー文字列としてのマッチ、範囲検索、正規表現など

論理演算で複数の条件の組み合わせも可

B-Tree インデックスによる検索・ソートも使える

ほぼオンメモリで動作するため非常に高速

{ "_id" : ObjectId("524406662caf1cab1f000001"), "title" : "MongoDB is fun!", "body" : "I love MongoDB very much.", "author" : "[email protected]", "created" : ISODate("2013-09-26T10:03:18.825Z"), "comment" : [ { "author" : "[email protected]", "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

[email protected]

2 Ichiro Tanaka

[email protected]

3 Taro Yamada

[email protected]

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" : "[email protected]", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ " }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 " } ]}

↑JSON(JavaScript Object Notation)

I


ドキュメント指向と動的スキーマ (1)

RDBMS: 表

各列の型は一致している必要あり

MongoDB: ドキュメント

それぞれの文書の構造は異なっていても構わない

検索その他では存在する部分だけが対象

ドキュメントの集まりを「コレクション」と呼ぶ

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ " }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 " }, ]}

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "created" : ISODate("2013-09-26T10:03:18.825Z"),}


ドキュメント指向と動的スキーマ (2)アプリケーションの設計の段階で、スキーマ定義を厳密に考えないでも大丈夫

すぐに開発に取り掛かれる

カジュアルにスキーマ定義を変更できる

スピード感のあるアプリ開発

パフォーマンスを得るにはスキーマに対する十分な理解が必要なので「スキーマレス」は厳密には NO

作りながらスキーマを定義していく

動的スキーマ


スキーマ定義の例：ブログ

大雑把な仕様記事が持つのはタイトル、内容、著者、記事が書かれた日時、コメント、 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 コメ

ント


ブログのスキーマ例 (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" : "[email protected]", }{ "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "[email protected]", }{ "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "[email protected]", }

Collection: authors

{ "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2d3..."), "content" : "ぼくもお気に入り！ ",}{ "_id" : ObjectId("52e1f310..."), "author_id" : ObjectId("52e1f2e6..."), "content" : "使い所難しいですけどね。 ",}

Collection: comments正規化のためにコレクションを分割● ちょっと煩雑● アプリケーション JOIN

が必要になる

正規化のためにコレクションを分割● ちょっと煩雑● アプリケーション JOIN

が必要になる


ブログのスキーマ例 (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" : "[email protected]", }{ "_id" : ObjectId("52e1f2d3..."), "author" : "Ichiro Tanaka", "email" : "[email protected]", }{ "_id" : ObjectId("52e1f2e6..."), "author" : "Taro Yamada", "email" : "[email protected]", }

Collection: authors

動的スキーマの利点を用いる● 扱うコレクションが一個減ってスッ

キリした● アプリケーション JOIN が必要にな

る点は変わらない

動的スキーマの利点を用いる● 扱うコレクションが一個減ってスッ

キリした● アプリケーション JOIN が必要にな

る点は変わらない


ブログのスキーマ例 (3)いっそのこと全部埋め込んでしまおう！

{ "_id" : ObjectId("52440666..."), "title" : "もんごたん楽しい！ ", "body" : "MongoDBいいですね！好きです！ ", "author" : "Naruhiko Ogasawara", "email" : "[email protected]", "created_at” : ISODate("2014-01-24T06:13:54.240Z") "permalink" : "mongo_tan_is_fun", "comment" : [ { "author" : "Ichiro Tanaka", "email" : "[email protected]", "content" : "ぼくもお気に入り！ ", }, { "author" : "Taro Yamada", "email" : "[email protected]", "content" : "使い所難しいですけどね。 ", }, ]}

Collection: postsJSON においては配列の要素内には任意の 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 … DocNupdate 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


レプリカセット基礎 (2)プライマリノードがダウンした場合残ったノード間で投票を行い次のプライマリを決める

この場合は「どこまでレプリケーションが終わっているか」で決まる

Secondary 1

Secondary 2Primary

Application

Driver

Heartbeat

ぼくは 5分前の処理まで

レプリカもらったよ

ぼくは 10分前までだなぁ


レプリカセット基礎 (3)選ばれたノードが次のプライマリになる

この時点でノードがダウンすると、 1台では投票ができないためレプリカセットがダウンする

1/3冗長

Primary

Secondary 2Primary

Application

Driver

Heartbeat

じゃあぼくがプライマリーやるね

ReplicationREAD

WRITE


レプリカセット基礎 (4)ダウンしていたノードが復活するとセカンダリノードに復帰

ただしダウンタイムが長いと自動復帰は不可

動いているセカンダリノードからリストアするのが無難

Primary

Secondary 2Secondary 2

Application

Driver

Heartbeat

ReplicationREAD

WRITE


レプリカセット基礎 (5)

Heartbeat:ノード間の死活監視

OPLOG:プライマリノードの操作をセカンダリにレプリケーションするために、操作を保存するコレクション

有限サイズのコレクション（ Capped collection ）セカンダリが長時間停止していると溢れてレプリカセットが機能不全を起こす


レプリカセット応用 (1)

Arbiter: 投票権のみ持ち、データを持たないノード

システム構成のコストを下げることが可能

ただし冗長性は下がる（トレードオフ）

Primary

Secondary Arbiter



Delayed Node: オペレーションミス対策

レプリケーションを意図的に遅らせたノード

オペミスしてデータを失ったときにすぐに Delayed Nodeから巻き戻せば復帰可能

Primary

Secondary Secondary DelayedSecondary

30分遅れ

slaveDelay=1800priority=0hidden=true


レプリカセット応用 (3)セカンダリノードに対するアクセス

Write Concernデータの書き込みがどこまで波及するまで待つかを設定する値

基本は即座に戻る

セカンダリノードの数も指定可

Read Prefenceセカンダリノードからの読み込みを許可してプライマリの負荷を下げる

古い値を掴んでも大丈夫なとき

P

S S

j : 1w : 2

P

S S

PRIMARYSECONDARY



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

< 64MBakio rakutaro-∞ +∞

Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B







naruhiko

Shard key: username


Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B

db.foo.insert({username: "osamu", ....})







naruhiko

Shard key: username


Shard 1A

Chunk

< 64MB

CChunkChunk

< 64MB

B

db.foo.insert({username: "osamu", ....})

naruhiko

Shard key: username


Shard 1A

B から分割

< 64MB

C

< 64MB

B

osamu< 64MB

D


オートシャーディングの仕組み (2)リバランシング

各シャードにおいて、最大のチャンク数を持つシャードと最小のチャンク数を持つシャードの差が規定値を超えた場合、バランスを取るためチャンクが移動する

新規にシャードを追加した場合も同様にリバランシングが起きる

A

Shard 1 Shard 2





A

Shard 1 Shard 2A

Shard 1 Shard 2

B





A

Shard 1 Shard 2A

Shard 1 Shard 2

B

A

Shard 1 Shard 2

B

C





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


シャードキーに求められる性質

適度なランダムネスある程度チャンク分割が進んだあとは、シャード内にまんべんなくチャンクが分配されるようになること

シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配置されること

適度なローカリティあるひとまとまりの処理が数個のチャンク内で完結する

シャーディングでは 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

データベースエンジニア養成読本編集部技術評論社

http://www.amazon.co.jp/dp/4873115906

http://www.amazon.co.jp/dp/4774158062

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

Technology

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