Post on 01-Dec-2014
description
OSC 2014 Kansai@Kyoto
MongoDB基本の基本
2014.08.02
MongoDB 日本ユーザー会MongoDB JP
小笠原徳彦(OGASAWARA, Naruhiko)
OSC 2014 Kansai@Kyoto 2/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 3/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 4/52
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/
OSC 2014 Kansai@Kyoto 5/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 6/52
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 、……
OSC 2014 Kansai@Kyoto 7/52
RDBMS と NoSQL(1)
RDBMS (Relational Database Management System)関係モデルに基づいたデータベース管理システム
SQL (Standard Query Language) による宣言的な操作オプティマイザにより「どうデータを格納し」「どうデータを得る」かは最適化されて高速に実行される
アトミックなデータ操作
データの一貫性保持が重要
OSC 2014 Kansai@Kyoto 8/52
RDBMS と NoSQL(2)しかしクラウド時代においては、データの一貫性保持はコストが高い……こともある
一貫性保持は常に必要なのか?例: EC サイトの在庫状況はリアルタイムでなくてもよい
決済時に一貫性が担保されていればよい
一貫性の完全な保持を諦めれば水平にスケールできる
DB
AppTokyo
US App
EU App EU AppDB
US AppDB
Tokyo AppDB
OSC 2014 Kansai@Kyoto 9/52
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
OSC 2014 Kansai@Kyoto 10/52
NoSQL の一つとしての MongoDB(1)ドキュメント指向データベース
バランスの良い NoSQL を目指す
https://wiki.mongodb.com/pages/viewpage.action?pageId=20743144
スケ
ーラ
ビリ
ティ
&パ
フォ
ーマ
ンス
機能の豊富さ
memcached
key/valuestore
MongoDB
RDBMS
OSC 2014 Kansai@Kyoto 11/52
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!" } ]}
OSC 2014 Kansai@Kyoto 12/52
MongoDB の割り切り
トランザクションを持たない複数の操作をくるんで、途中で失敗したらロールバック……といった機能はない
一つ一つのデータ操作はアトミック
JOIN がない
複数のドキュメントを DB 側で結合はできない
アプリケーションで結合する必要があるがアトミックな操作ではない
…… でも、なくても構わない状況は多いよね? という割り切りがポイント
OSC 2014 Kansai@Kyoto 13/52
MongoDB/NoSQL と RDBMS
NoSQL とは一般に「使い方にクセがある」「どこか割り切ったことがある」「その代わりにとても得意なところがある」もの
事前に「不得意なところが許容できるか」を判断できないなら、素直に RDBMS を使ったほうが良い
速度
クエリーの種類
トランザクション
メモリ使用量
ディスク使用量
スケーラビリティ
0
50
100
RDBMS
MongoDB
このグラフは例であり
実際の評価ではありません
OSC 2014 Kansai@Kyoto 14/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 15/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 16/52
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)
I
OSC 2014 Kansai@Kyoto 17/52
ドキュメント指向と動的スキーマ (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"),}
OSC 2014 Kansai@Kyoto 18/52
ドキュメント指向と動的スキーマ (2)アプリケーションの設計の段階で、スキーマ定義を厳密に考えないでも大丈夫
すぐに開発に取り掛かれる
カジュアルにスキーマ定義を変更できる
スピード感のあるアプリ開発
パフォーマンスを得るにはスキーマに対する十分な理解が必要なので「スキーマレス」は厳密には NO
作りながらスキーマを定義していく
動的スキーマ
OSC 2014 Kansai@Kyoto 19/52
スキーマ定義の例:ブログ
大雑把な仕様記事が持つのはタイトル、内容、著者、記事が書かれた日時、コメント、 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 コメ
ント
OSC 2014 Kansai@Kyoto 20/52
ブログのスキーマ例 (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
が必要になる
OSC 2014 Kansai@Kyoto 21/52
ブログのスキーマ例 (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 が必要にな
る点は変わらない
OSC 2014 Kansai@Kyoto 22/52
ブログのスキーマ例 (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 的スキーマ設計
OSC 2014 Kansai@Kyoto 23/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 24/52
●MongoDB の性能の秘密
MongoDB はファイルシステムに展開されているコレクションを mmap している
ローカリティがある READ アクセスについてはオンメモリでアクセスするので高速
要は「ディスクにスワップアウトできるオンメモリ DB 」
ローカリティが低いアクセスは性能が出ない
Storage
V. mem
P. mem
OSC 2014 Kansai@Kyoto 25/52
データアクセスとインデックス
MongoDB のデータアクセスはとても素朴
頭から順に舐めているだけ(線形探索)=検索 O(n)ついでにいうとドキュメントの順序は保証されない
インデックス
あるキーに着目した B-Tree インデックス=検索 O(log n)検索・ソートに利用可
Doc1 Doc2 Doc3 … DocNupdate Doc2 (サイズ拡大)
Doc1 Doc2Doc3 … DocN(隙間)
OSC 2014 Kansai@Kyoto 26/52
インデックス詳細
インデックスはコレクション自体と同じファイルどんどん張っているとデータサイズが肥大化する
インデックスを後から張るとデータ量に比例した時間がかかる(当然)
昇順・降順でインデックスは張れる
複数キーのインデックスも利用可能db.posts.ensureIndex({created_at:-1, author:1})部分的に使うことも可能
OSC 2014 Kansai@Kyoto 27/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 28/52
レプリカセット基礎 (1)レプリカセット:簡単な仕組みで高可用性を実現
最低 3台のノードをセットにして動かす
アプリケーションに応答するプライマリノードは自動的に決定される(明示的なマスターノードは存在しない)
Secondary 1
Secondary 2Primary
Application
Driver
Read
Write
Heartbeat
Replication
Replication
OSC 2014 Kansai@Kyoto 29/52
レプリカセット基礎 (2)プライマリノードがダウンした場合残ったノード間で投票を行い次のプライマリを決める
この場合は「どこまでレプリケーションが終わっているか」で決まる
Secondary 1
Secondary 2Primary
Application
Driver
Heartbeat
ぼくは 5分前の処理まで
レプリカもらったよ
ぼくは 10分前までだなぁ
OSC 2014 Kansai@Kyoto 30/52
レプリカセット基礎 (3)選ばれたノードが次のプライマリになる
この時点でノードがダウンすると、 1台では投票ができないためレプリカセットがダウンする
1/3冗長
Primary
Secondary 2Primary
Application
Driver
Heartbeat
じゃあぼくがプライマリーやるね
ReplicationREAD
WRITE
OSC 2014 Kansai@Kyoto 31/52
レプリカセット基礎 (4)ダウンしていたノードが復活するとセカンダリノードに復帰
ただしダウンタイムが長いと自動復帰は不可
動いているセカンダリノードからリストアするのが無難
Primary
Secondary 2Secondary 2
Application
Driver
Heartbeat
ReplicationREAD
WRITE
OSC 2014 Kansai@Kyoto 32/52
レプリカセット基礎 (5)
Heartbeat:ノード間の死活監視
OPLOG:プライマリノードの操作をセカンダリにレプリケーションするために、操作を保存するコレクション
有限サイズのコレクション( Capped collection )セカンダリが長時間停止していると溢れてレプリカセットが機能不全を起こす
OSC 2014 Kansai@Kyoto 33/52
レプリカセット応用 (1)
Arbiter: 投票権のみ持ち、データを持たないノード
システム構成のコストを下げることが可能
ただし冗長性は下がる(トレードオフ)
Primary
Secondary Arbiter
OSC 2014 Kansai@Kyoto 34/52
レプリカセット応用 (2)
Delayed Node: オペレーションミス対策
レプリケーションを意図的に遅らせたノード
オペミスしてデータを失ったときにすぐに Delayed Nodeから巻き戻せば復帰可能
Primary
Secondary Secondary DelayedSecondary
30分遅れ
slaveDelay=1800priority=0hidden=true
OSC 2014 Kansai@Kyoto 35/52
レプリカセット応用 (3)セカンダリノードに対するアクセス
Write Concernデータの書き込みがどこまで波及するまで待つかを設定する値
基本は即座に戻る
セカンダリノードの数も指定可
Read Prefenceセカンダリノードからの読み込みを許可してプライマリの負荷を下げる
古い値を掴んでも大丈夫なとき
P
S S
j : 1w : 2
P
S S
PRIMARYSECONDARY
OSC 2014 Kansai@Kyoto 36/52
レプリカセット応用 (4)
Disaster Recovery (災害復旧)対策
データセンタをまたいでレプリカセットを構築することで、DC がまるごと死んだとしてもサービス提供可能
Primary
Secondary Secondary Secondary
Secondary
Arbiter
Datacenter 1 Datacenter 2
OSC 2014 Kansai@Kyoto 37/52
レプリカセットの魅力
仕組み自体はとてもシンプル
高可用性を容易に実現できる
高いシステム構成の自由度
DR対策やバックアップ対策などにも対応可能
水平展開、 DC をまたいだ運用が容易なクラウド時代にふさわしい仕組み
OSC 2014 Kansai@Kyoto 38/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 39/52
シャーディングとは
sharding: 一般的なデータベース用語
DB負荷を分散させるためにスケールアウトさせること
RDBMS の場合、同時にアクセスする必要のあるデータは一つのサーバで処理するように注意深く配置する
非常に難しい
スケ
ール
アッ
プ
DBMS
DBMS
DBMS
スケールアウト
DBMS DBMS DBMS DBMS
DBMS
DBMS DBMS
DBMS DBMS
OSC 2014 Kansai@Kyoto 40/52
MongoDB のオートシャーディング
MongoDB はスケールアウト(=シャーディング)でパフォーマンスを稼ぐ戦略
シャーディングを簡単に行う仕組みが組み込まれている
=オートシャーディング
OSC 2014 Kansai@Kyoto 41/52
オートシャーディングの仕組み (1)シャードキー
オートシャーディングの動作を規定するキー(複合可)
シャードキーの範囲によってコレクションを塊(チャンク)に分割する
チャンクサイズは 64MB (標準)
DB の操作によりサイズ超過した場合は分割される
naruhiko
Shard key: username
< 64MBakio rakutaro-∞ +∞
Shard 1A
Chunk
< 64MB
CChunkChunk
< 64MB
B
OSC 2014 Kansai@Kyoto 42/52
オートシャーディングの仕組み (1)シャードキー
オートシャーディングの動作を規定するキー(複合可)
シャードキーの範囲によってコレクションを塊(チャンク)に分割する
チャンクサイズは 64MB (標準)
DB の操作によりサイズ超過した場合は分割される
naruhiko
Shard key: username
< 64MBakio rakutaro-∞ +∞
Shard 1A
Chunk
< 64MB
CChunkChunk
< 64MB
B
db.foo.insert({username: "osamu", ....})
OSC 2014 Kansai@Kyoto 43/52
オートシャーディングの仕組み (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
OSC 2014 Kansai@Kyoto 44/52
オートシャーディングの仕組み (2)リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと最小のチャンク数を持つシャードの差が規定値を超えた場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシングが起きる
A
Shard 1 Shard 2
OSC 2014 Kansai@Kyoto 45/52
オートシャーディングの仕組み (2)リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと最小のチャンク数を持つシャードの差が規定値を超えた場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシングが起きる
A
Shard 1 Shard 2A
Shard 1 Shard 2
B
OSC 2014 Kansai@Kyoto 46/52
オートシャーディングの仕組み (2)リバランシング
各シャードにおいて、最大のチャンク数を持つシャードと最小のチャンク数を持つシャードの差が規定値を超えた場合、バランスを取るためチャンクが移動する
新規にシャードを追加した場合も同様にリバランシングが起きる
A
Shard 1 Shard 2A
Shard 1 Shard 2
B
A
Shard 1 Shard 2
B
C
OSC 2014 Kansai@Kyoto 47/52
オートシャーディングの仕組み (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
OSC 2014 Kansai@Kyoto 48/52
シャードキーに求められる性質
適度なランダムネスある程度チャンク分割が進んだあとは、シャード内にまんべんなくチャンクが分配されるようになること
シャードキーの -∞ 〜 +∞ まで概ね均等にデータが配置されること
適度なローカリティあるひとまとまりの処理が数個のチャンク内で完結する
シャーディングでは mmap がチャンク単位になるため、うまくいくと各シャードでオンメモリで処理が可能になる
OSC 2014 Kansai@Kyoto 49/52
オートシャーディングは万能か?
シャードキーをうまく選定できるか?が肝シャードキーの選定ミスはパフォーマンスの劣化(と、場合によっては OPLOG溢れによるデータ喪失)を招く
シャードキーは一度決めたら変更は不可能なので、パイロットプロジェクトなどで慎重にデータの性質を見極める必要がある
最初から超大規模なデータを扱うことだけが分かっており、データの性質が不明確な案件だとリスクがある
OSC 2014 Kansai@Kyoto 50/52
内容
MongoDB JP とは
NoSQL と MongoDB
MongoDB の性質
ドキュメント指向
性能とインデックス
レプリカセット
オートシャーディング
まとめ
OSC 2014 Kansai@Kyoto 51/52
まとめ
MongoDB はクラウド時代に必要な種々の要素を備えた、 RDBMS を補完する優れた DB である
ただし嵌まりパターンに使った場合
これは MongoDB に限らず NoSQL に共通
アプリケーションを開発しながらスキーマをデザインしていく動的スキーマ
シンプルな仕組みで高可用性を実現し、なおかつさまざまなバリエーションを作れるレプリカセット
同じマシンを並べてパフォーマンスを稼ぐ水平スケーリングを支援するオートシャーディング
OSC 2014 Kansai@Kyoto 52/52
参考図書
MongoDB イン・アクションhttp://www.amazon.co.jp/dp/4873115906
Kyle Banker (著 ), Sky株式会社 玉川 竜司 (翻訳 )オライリー・ジャパン
データベースエンジニア養成読本 [DB を自由自在に活用するための知識とノウハウ満載 !] http://www.amazon.co.jp/dp/4774158062
データベースエンジニア養成読本編集部技術評論社