1.
Introduction to
MongoDB
@just_do_neet
1

2.
Today’s Agenda
今日のお題目
•MongoDBの一般的な解説
•向いてそうな適用範囲
•ソーシャルゲームとMongoDB（資料紹介のみ）
•まとめ
2

3.
MongoDBの一般的な解説
3

4.
MongoDB
Mongoは「でっかい」という意味らしいです
http://www.mongodb.org/
http://www.mongodb.jp/
•10gen社が主体として開発しているオープンソース
所謂「NoSQL」の一つ
4

5.
Features
よく言われるMongoDBの特徴
•ドキュメント指向なデータベース
•スケーラブルなデータベース
5

6.
Document Oriented
ドキュメント指向の概念
•ある一定のフォーマットにてエンコードされた
データをひとつの「ドキュメント」として扱う。
•フォーマット：XML、YAML、BSON、etc.
•ドキュメントは一般的に構造化データの形式を取
ることが多い。
• “The central concept of a document-oriented database is the notion of a
Document. While each document-oriented database implementation
differs on the details of this definition, in general, they all assume
documents encapsulate and encode data (or information) in some
standard format(s) (or encoding(s)).”
http://en.wikipedia.org/wiki/Document-oriented_database
6

7.
Document Oriented
ドキュメント指向の概念
•MongoDBはドキュメントを「BSON」形式で扱
う。http://bsonspec.org/
•一つの入れ物(collection)の中には、BSONフォー
マットであれば異なる構造のデータでも入れる事
ができる。
→スキーマレス
→柔軟な構造のデータベース
7

8.
Document on MongoDB
MongoDBの中でのデータ
> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})
> db.musicians.save({name:"Spitz", menbers : 4 , companey: "Road & Sky"})
> db.musicians.save({name : "Pat Metheny" , country : "US" , awards :
{ name : "grammy", count:19}})
>
> db.musicians.find()
{ "_id" : ObjectId("4f4ce8621b5c3f27d189c5bc"), "name" : "Masashi Sada",
"age" : 60, "genre" : "fork" }
{ "_id" : ObjectId("4f4ce8ed1b5c3f27d189c5bd"), "name" : "Spitz",
"menbers" : 4, "companey" : "Road & Sky" }
{ "_id" : ObjectId("4f4ce95c1b5c3f27d189c5be"), "name" : "Pat Metheny",
"country" : "US", "awards" : { "name" : "grammy", "count" : 19 } }
8

9.
Document on MongoDB
MongoDBの中でのデータ
> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})
> db.musicians.save({name:"Spitz", menbers : 4 , companey: "Road & Sky"})
> db.musicians.save({name : "Pat Metheny" , country : "US" , awards :
{ name : "grammy", count:19}})
>
> db.musicians.find()
{ 各ドキュメントの構造は同じでなくても良い Sada",
"_id" : ObjectId("4f4ce8621b5c3f27d189c5bc"), "name" : "Masashi
"age" : 60, "genre" : "fork" }
{ "_id" : ObjectId("4f4ce8ed1b5c3f27d189c5bd"), "name" : "Spitz",
"menbers" : 4, "companey" : "Road & Sky" }
{ "_id" : ObjectId("4f4ce95c1b5c3f27d189c5be"), "name" : "Pat Metheny",
"country" : "US", "awards" : { "name" : "grammy", "count" : 19 } }
9

10.
Document on MongoDB
MongoDBの中でのデータ
> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})
> db.musicians.save({name:"Spitz", menbers : 4 , companey: "Road & Sky"})
> db.musicians.save({name : "Pat Metheny" , country : "US" ,
awards : { name : "grammy", count:19}})
>
> db.musicians.find()
{ ドキュメントの中に階層的なデータを入れるこ
"_id" : ObjectId("4f4ce8621b5c3f27d189c5bc"), "name" : "Masashi Sada",
"age" : 60, "genre" : "fork" }
{ とができる。
"_id" : ObjectId("4f4ce8ed1b5c3f27d189c5bd"), "name" : "Spitz",
"menbers" : 4, "companey" : "Road & Sky" }
{ "_id" : ObjectId("4f4ce95c1b5c3f27d189c5be"), "name" : "Pat Metheny",
"country" : "US", "awards" : { "name" : "grammy", "count" : 19 } }
10

11.
Document on MongoDB
MongoDBの中でのデータ
> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})
> db.musicians.save({name:"Spitz", menbers : 4 , companey: "Road & Sky"})
> db.musicians.save({name : "Pat Metheny" , country : "US" , awards :
{ name : "grammy", count:19}})
>
> db.musicians.find()
{ "_id" : ObjectId("4f4ce8621b5c3f27d189c5bc"), "name" : "Masashi Sada",
"age" : 60, "genre" : "fork" }
{ "_id" : ObjectId("4f4ce8ed1b5c3f27d189c5bd"), "name" : "Spitz",
"menbers" : 4, "companey" : "Road & Sky" }
{ "_id" : ObjectId("4f4ce95c1b5c3f27d189c5be"), "name" : "Pat Metheny",
"country" : "US", "awards" : { "name" : "grammy", "count" : 19 } }
各ドキュメントには必ず一意のIDが割り振られ
る。デフォルトはMongo独自のID（ObjectID）
明示的に指定も可。
11

12.
Document on MongoDB
MongoDBの中でのデータ
> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})
> db.musicians.save({name:"Spitz", menbers : 4 , companey: "Road & Sky"})
> db.musicians.save({name : "Pat Metheny" , country : "US" , awards :
{ name : "grammy", count:19}})
>
> db.musicians.ensureIndex({name : 1})
> db.musicians.getIndices()
[
{"v" : 1,"key" : {"_id" : 1},"ns" : "music.musicians","name" : "_id_"},
{"v" : 1,"key" : {"name" : 1},"ns" : "music.musicians","name" : "name_1"}
]
>
任意のフィールドにインデックスを貼ることが
できる。（B-Tree）
12

13.
Document on MongoDB
MongoDBの中でのデータ
•入れ物の中に、異なる構造のデータを格納するこ
とができる（スキーマレス）
•階層構造を持つデータを格納することができる。
•かつ、RDBに近い操作性を持っている。
13

14.
Scalability
MongoDBにおけるスケーラビリティ
•Replica Set(High Availability)
•Sharding(Horizontal Scaling)
http://www.mongodb.org/display/DOCS/Introduction
14

15.
Scalability
MongoDBにおけるスケーラビリティ
•Replica Set(High Availability)
•Sharding(Horizontal Scaling)
Replica Setは同一のデータを複数インスタンス
で管理することでHA構成を実現するもの。
1 Replica Setあたり最低３台が必要。
http://www.mongodb.org/display/DOCS/Introduction
15

16.
Scalability
MongoDBにおけるスケーラビリティ
•Replica Set(High Availability)
•Sharding(Horizontal Scaling)
Shardingはデータを複数クラスターで分散配置
させるための仕組み。
(≒マルチマスタ化）
http://www.mongodb.org/display/DOCS/Introduction
16

17.
Scalability
MongoDBにおけるスケーラビリティ
•標準機能としてReplica Set / Sharding機能が備
わっている。
•カタログスペック上は手軽にHA構成、水平
sharding構成を組むことができる。
•実際はshard間のデータ偏り調整など運用にコツ
がいる
17

18.
Other Features
その他の特徴的な機能
•GridFS
•大きいサイズのファイルを扱うための仕組み
•地理空間インデックス
•緯度経度検索
•Capped Collection
•固定サイズの入れ物。サイズを超えたら古いも
のから自動的に削除される。
18

19.
Cons.
MongoDBの欠点（主観含む）
•トランザクション未サポート
•トランザクションは甘え (ﾄﾞﾔｧ
•Global Lock（2.2からCollection Lockに？）
•システムリソースが肥大化（メモリ、ディスク）
•データ圧縮未対応（通信、データストア共）
•セキュリティ周りが弱い etc.
19

20.
Cons.
MongoDBの欠点（主観含む）
•厳密なトランザクション処理が必要なシステムに
は向かない。（課金、会員管理など...）
•書き込み過多なシステムには基本向かない。
•Big Dataを扱う環境には向かない。
•スケールするが故に、下手にそれなりの規模の
システムに導入するとサーバー無限増殖の刑
に...
20

21.
Ref. PFI Tech. White Paper
参考：PFI Technical White Paper
(P.17)
http://preferred.jp/wp-content/uploads/2012/03/PFIwhitepaper.pdf
21

22.
Compress vs Not Compress
圧縮：非圧縮のデータサイズの差
•下記例は同一フォーマットの文字列データを格納
した際の比較（MongoDB / HBase）
•MongoDBはHBase（snappy圧縮時）の三倍強。
700000000 MongoDB
600000000 MongoDB(fragment)
500000000 HBase
HBase(fragment)
400000000 HBase(snappy)
300000000
200000000
100000000
0
size(1,000,000 record)
22

23.
Summary
ここまでのまとめ
•ドキュメント指向DB。異なる構造や複雑な構造
のデータを扱える。検索機能も強力。
•HA機能、Sharding機能を標準的に持っている。
•トランザクションは甘え。
•富豪的な作りのミドルウェアなので使用するリ
ソースの多さに起因する課題があるので注意。
23

24.
向いてそうな適用範囲
24

25.
Suitable Cases
向いてそうな使い方（主観）
•（注）下記以外にも適切な使い方はたくさんある
と思うので皆さんも考えてください。
1.RDBやKVSでは表現しきれない複雑な構成の
データを扱う。
2.一時的なログ集計、ログ管理。データ集計基
盤。
3.プロトタイピング用の環境。
25

26.
#1 Complex Data
複雑な構成のデータ
•既存のRDBやKVSでは扱いづらいデータ。
•RDBは複数の構造(schema)のデータをひとつ
の入れ物(table)に入れて扱いづらい
•KVSは自由度が高いが、Valueの検索が難し
い。
•複数の構造のデータをひとつの入れ物に入れて、
検索性も高めるためにはどうすれば？
26

27.
#1 Complex Data
複雑な構成のデータ
•例：ソーシャルサービスのActivity Feed
http://photoalbum.naver.jp/
27

28.
#1 Complex Data
複雑な構成のデータ
•例：ソーシャルサービスのActivity Feed
•Activityごとにデータ構
造が違う。
（コメント、like 、写真 etc...）
28

29.
#1 Complex Data
複雑な構成のデータ
•例：ソーシャルサービスのActivity Feed
•ひとつのActivityの中に
複数のアイテムが存在す
るケースがある。
29

30.
#1 Complex Data
複雑な構成のデータ
•例：ソーシャルサービスのActivity Feed
•Activityに含まれるアイ
テム（写真など）を個別
に検索する必要がある。
（データの消し込みなど）
30

31.
#1 Complex Data
複雑な構成のデータ
•RDBでモデリングした場合
•Oops...
31

32.
#1 Complex Data
複雑な構成のデータ
•KVSでモデリング？した場合
•Valueの検索に課題
32

33.
MongoDB Can Do It!
MongoDBならできるよ！
•そこでMongoDBですよ。
•スキーマレスなので...
•複数のフォーマットのActivityをひとつの入れ
物に詰め込める。
•かつ検索性能も落とさずに済む。
33

34.
Delete Photo(Column)
例：写真の削除
#lookup photo
db.activity.find({feedList.feedData.photoList, photoId})
#delete photo
db.activity.remove({feedList.feedId, feedId})
#re-insert timeline data
db.activity.insert(newFeedData)
34

35.
Delete Album(Row)
例：アルバムの削除
#lookup album
db.activity.find({feedList.feedData.albumList.albumId,
alubmId})
#delete album
db.activity.remove({feedList.feedId, feedId})
35

36.
Dot Notation
dot notation記法による階層の深いデータの検索
•MongoDBはdot notationという記法で階層の深い
データの検索が可能。
（db.hoge.find({a.b.c.d.e : 1}) のような形が可）
•インデックスを貼ることも可能。
#lookup album
db.activity.find({feedList.feedData.albumList.albumI
d, alubmId})
#delete album
db.activity.remove({feedList.feedId, feedId})
36

37.
#1 Summary
#1 ここまでのまとめ
•複雑な構造のデータを検索性を落とさずに使うに
はMongoDBは向いている。
•ただし先に紹介したような設計にするとデータ
が肥大化しがちなので注意。
•参照・更新のスループットを落とさないために
はデータ・インデックスをオンメモリで乗るサ
イズに収めるのが前提。
37

38.
#2 Storing Logs
ログファイルの保存先としてのMongoDB
•ログファイルは多くの場合非構造・スキーマレス
で保存されている。
•ただ保存するだけでなく、ログの検索や集計を
手軽に行いたい
•RDBなどスキーマを厳密に定義した入れ物はあ
まり向かない。
→MongoDB!
38

39.
Advanced Queries
MongoDBの高度なクエリー
•MongoDBはNoSQLと言われる群の中では検索・
集計クエリーの機能が っているのが特徴。
•count()
•group()
•MapReduce
•正規表現
•Aggregation Framework
39

40.
Queries : count()
count() 文
•条件に合致する件数を返す。SQLのcount文とだ
いたい同じ。
> db.accesslogs.find({method : 'GET', code: '200'}).count()
6644
40

41.
Queries : group()
group() 文
•集計処理を実現するための機能。Sharding環境で
は動かない（後述のMapReduce推奨）
•後述のAggregation Frameworkに今後は統合され
る。
> db.accesslogs.group(
... {key: {method: true},
... cond: {},
... initial: {count: 0},
... reduce: function(doc, out) { out.count++; }
... });
[
{"method" : "GET","count" : 6644},
{"method" : "POST","count" : 3}
]
41

42.
MapReduce
MapReuce機能
•Map/Reduceモデルで集計処理を行う。複数の
Shardで集計した結果をReduceする。
•処理中ずっとLockがかかるのでProductionで実行
するには不向き。
> db.accesslogs.mapReduce(map ,reduce , {out: { inline : 1}});
{
"results" : [
{"_id" : "GET","value" : {"count" : 6644}},
{"_id" : "POST","value" : {"count" : 3}}
],
"timeMillis" : 444,
"counts" : {"input" : 6647,"emit" : 6647,"output" : 2},
"ok" : 1,
}
42

43.
Regular Expressions
正規表現機能
•検索条件に正規表現の文を指定できる (PCRE)。
ログの検索には便利。
> db.accesslogs.find({agent : /Mozilla/5.0/i})
{ "_id" : ObjectId("4f2a9ad6a03a3a34ef000001"), "host" : "0.0.0.0""method" : "GET",
"path" : "/odai/2132564671424954401", "code" : "200", "size" : "15947", "referer" :
"http://matome.naver.jp/", "agent" : "Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7", "time" :
ISODate("2012-02-01T02:02:19Z") }
{ "_id" : ObjectId("4f2a9ad6a03a3a34ef000002"), "host" : "0.0.0.0","method" : "GET",
"path" : "/odai/2132564671424954401", "code" : "200", "size" : "16084", "referer" :
"http://matome.naver.jp/", "agent" : "Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7") }
43

44.
Aggregation Framework
Aggregation Framework
•様々な集約ルールをUnixのPipeのような感じでつ
ないでいくことができる機能（2.1.0以降）
http://www.mongodb.org/display/DOCS/Aggregation+Framework
http://datablend.be/?p=1400
44

45.
Problem of Log Collecting
ログ収集における課題
•MongoDBにログを保存する際は以下のような点
が課題に。
•非構造データ→構造データの変換
（生ログ→BSON）
•ログの収集
（web/app server→log server）
•ログ保存時の負荷分散
（一度にまとめて保存しようとするとMongoDBのGlobal Lockの 食
に...）
45

46.
Fluentd
Fluentd : The event collector service
https://github.com/fluent/fluentd
http://fluentd.org/doc/
http://community.fluentd.org/browse/help-center/
46

47.
Fluentd
Fluentd : The event collector service
•syslogのように、準リアルタイムにネットワーク越
しのログ転送が行えるミドルウェア。
•JSON準拠の構造化データでやりとりをする。
•設定・導入が非常に簡単。
•プラグイン形式で入出力処理の拡張が行える
•MongoDBに書き込むためのプラグインもある
https://github.com/fluent/fluent-plugin-mongo
47

48.
Fluentd
Fluentd : The event collector service
•以下の構成のようにすると、web/appのログを準リ
アルタイムで別システム（Hadoop/MongoDB/etc）
に書き込む事ができる。
Apps Hadoop
fluentd Clusters
fluentd
Apps
fluentd
mongod
Apps
fluentd
fluentd
48

49.
Fluentd
Fluentd : The event collector service
•準リアルタイムでログの保存ができると、データの
準リアルタイムでの集計や可視化ができる。
49

50.
Fluentd
参考資料
http://dl.dropbox.com/u/224433/kamakura_pm_2/index.html
50

51.
#2 Summary
#2 ここまでのまとめ
•ログデータの保存集計にMongoDBは向いている
•検索性を落とさずスキーマレスなデータの格納
ができる。
•検索・集計クエリーがそれなりに っている
•Fluentdと組み合わせると煩わしいログの収集
処理も簡単に。欲しいデータが常に手元に。
•一時保存の場合はCapped Collectionが便利
51

52.
#3 Prototyping
#3 プロトタイピング向けのDBとしてMongoDBを使用
•プロトタイプアプリで「とりあえず動くもの」を
作成するにはRDBを使用するのが面倒くさい。
•テーブル作成のたびにcreate table文。
•開発中にDBのスキーマが頻繁に変わる。
•MongoDBなら事前定義不要。クエリー実行した
内容のとおりにデータが作成される。
•プログラマ側でコントロールできる。
52

53.
#3 Prototyping
参考資料
http://www.slideshare.net/fungoing/mongodb-7948933
53

54.
ソーシャルゲームと
MongoDB（資料紹介）
54

55.
Ref. Ameba pico
Ameba Pico（piggの海外版）での事例資料
•『Ameba PicoとMongoDB』
http://www.slideshare.net/snamura/mongo-db-
couchdb20101214
•『AmebaPico 裏側の技術やAWS活用について』
http://www.slideshare.net/KoheiMorino/
amebapico-aws
55

56.
Ref. Animal Land
Animal Land（海外向けブラウザゲーム）の事例
•『ソーシャルゲームにおけるMongoDB適用事
例』
http://www.slideshare.net/matsukaz/mongodb-
animal-land-11134607
56

57.
まとめ
57

58.
Conclusion
まとめにかえて
•広く浅くMongoDBに関する話をしてきました。
•個人的な主観は以下です。
•比較的平和なケース：
複雑なデータ構造をメモリに載りきる範囲で運
用。ログ集計などバックエンドで使用。
•チャレンジングなケース（お金的な意味で）：
Big Dataを扱う。大規模システムのストレージ
として用いる。
58

59.
Conclusion
まとめにかえて
•開発が活発でたくさんの新機能も予定されている
ので、今後の進展が期待できるプロダクトです。
•今後の動きにぜひ注目していてください。
•個人的にはRedisも好きです。
•2.6から導入されるLua Scriptingは楽しそうで
すね
59

60.
ご清聴
ありがとうございました
60