Introduction to   MongoDB   @just_do_neet                   1
Today’s Agenda今日のお題目 •MongoDBの一般的な解説 •向いてそうな適用範囲 •ソーシャルゲームとMongoDB(資料紹介のみ) •まとめ                             2
MongoDBの一般的な解説                 3
MongoDBMongoは「でっかい」という意味らしいですhttp://www.mongodb.org/                          http://www.mongodb.jp/•10gen社が主体として開発しているオープ...
Featuresよく言われるMongoDBの特徴 •ドキュメント指向なデータベース •スケーラブルなデータベース                    5
Document Orientedドキュメント指向の概念 •ある一定のフォーマットにてエンコードされた  データをひとつの「ドキュメント」として扱う。    •フォーマット:XML、YAML、BSON、etc. •ドキュメントは一般的に構造化デ...
Document Orientedドキュメント指向の概念 •MongoDBはドキュメントを「BSON」形式で扱 う。http://bsonspec.org/ •一つの入れ物(collection)の中には、BSONフォー マットであれば異なる構...
Document on MongoDBMongoDBの中でのデータ> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})> db.musicians.save({name...
Document on MongoDBMongoDBの中でのデータ> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})> db.musicians.save({name...
Document on MongoDBMongoDBの中でのデータ> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})> db.musicians.save({name...
Document on MongoDBMongoDBの中でのデータ> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})> db.musicians.save({name...
Document on MongoDBMongoDBの中でのデータ> db.musicians.save({name:"Masashi Sada", age:60, genre:"fork"})> db.musicians.save({name...
Document on MongoDBMongoDBの中でのデータ •入れ物の中に、異なる構造のデータを格納するこ  とができる(スキーマレス) •階層構造を持つデータを格納することができる。 •かつ、RDBに近い操作性を持っている。     ...
ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling)            http://www.mongodb.o...
ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling)   Replica Setは同一のデータを複数インスタンス  ...
ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling)   Shardingはデータを複数クラスターで分散配置  させ...
ScalabilityMongoDBにおけるスケーラビリティ •標準機能としてReplica Set / Sharding機能が備  わっている。 •カタログスペック上は手軽にHA構成、水平  sharding構成を組むことができる。 •実際は...
Other Featuresその他の特徴的な機能 •GridFS   •大きいサイズのファイルを扱うための仕組み •地理空間インデックス   •緯度経度検索 •Capped Collection   •固定サイズの入れ物。サイズを超えたら古いも...
Cons.MongoDBの欠点(主観含む) •トランザクション未サポート   •トランザクションは甘え (ドヤァ •Global Lock(2.2からCollection Lockに?) •システムリソースが肥大化(メモリ、ディスク) •デー...
Cons.MongoDBの欠点(主観含む) •厳密なトランザクション処理が必要なシステムに  は向かない。(課金、会員管理など...) •書き込み過多なシステムには基本向かない。 •Big Dataを扱う環境には向かない。   •スケールするが...
Ref. PFI Tech. White Paper参考:PFI Technical White Paper                                                            (P.17)  ...
Compress vs Not Compress圧縮:非圧縮のデータサイズの差 •下記例は同一フォーマットの文字列データを格納 した際の比較(MongoDB / HBase) •MongoDBはHBase(snappy圧縮時)の三倍強。 700...
Summaryここまでのまとめ •ドキュメント指向DB。異なる構造や複雑な構造 のデータを扱える。検索機能も強力。 •HA機能、Sharding機能を標準的に持っている。 •トランザクションは甘え。 •富豪的な作りのミドルウェアなので使用するリ...
向いてそうな適用範囲             24
Suitable Cases向いてそうな使い方(主観) •(注)下記以外にも適切な使い方はたくさんある と思うので皆さんも考えてください。 1.RDBやKVSでは表現しきれない複雑な構成の データを扱う。 2.一時的なログ集計、ログ管理。データ...
#1 Complex Data複雑な構成のデータ •既存のRDBやKVSでは扱いづらいデータ。  •RDBは複数の構造(schema)のデータをひとつ   の入れ物(table)に入れて扱いづらい  •KVSは自由度が高いが、Valueの検索が...
#1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed    http://photoalbum.naver.jp/                                  27
#1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed                    •Activityごとにデータ構                    造が違う。          ...
#1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed                    •ひとつのActivityの中に                    複数のアイテムが存在す    ...
#1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed                    •Activityに含まれるアイ                    テム(写真など)を個別    ...
#1 Complex Data複雑な構成のデータ •RDBでモデリングした場合 •Oops...                  31
#1 Complex Data複雑な構成のデータ •KVSでモデリング?した場合 •Valueの検索に課題                   32
MongoDB Can Do It!MongoDBならできるよ! •そこでMongoDBですよ。 •スキーマレスなので...   •複数のフォーマットのActivityをひとつの入れ    物に詰め込める。   •かつ検索性能も落とさずに済む。...
Delete Photo(Column) 例:写真の削除#lookup photodb.activity.find({feedList.feedData.photoList, photoId})#delete photodb.activity.r...
Delete Album(Row) 例:アルバムの削除#lookup albumdb.activity.find({feedList.feedData.albumList.albumId,alubmId})#delete albumdb.acti...
Dot Notation dot notation記法による階層の深いデータの検索  •MongoDBはdot notationという記法で階層の深い   データの検索が可能。   (db.hoge.find({a.b.c.d.e : 1}) の...
#1 Summary#1 ここまでのまとめ •複雑な構造のデータを検索性を落とさずに使うに  はMongoDBは向いている。   •ただし先に紹介したような設計にするとデータ    が肥大化しがちなので注意。   •参照・更新のスループットを落...
#2 Storing Logsログファイルの保存先としてのMongoDB •ログファイルは多くの場合非構造・スキーマレス  で保存されている。   •ただ保存するだけでなく、ログの検索や集計を    手軽に行いたい   •RDBなどスキーマを厳...
Advanced QueriesMongoDBの高度なクエリー •MongoDBはNoSQLと言われる群の中では検索・  集計クエリーの機能が           っているのが特徴。   •count()   •group()   •MapRe...
Queries : count()  count() 文    •条件に合致する件数を返す。SQLのcount文とだ      いたい同じ。> db.accesslogs.find({method : GET, code: 200}).count...
Queries : group()  group() 文     •集計処理を実現するための機能。Sharding環境で      は動かない(後述のMapReduce推奨)     •後述のAggregation Frameworkに今後は統...
MapReduce  MapReuce機能    •Map/Reduceモデルで集計処理を行う。複数の      Shardで集計した結果をReduceする。    •処理中ずっとLockがかかるのでProductionで実行      するに...
Regular Expressions  正規表現機能     •検索条件に正規表現の文を指定できる (PCRE)。      ログの検索には便利。> db.accesslogs.find({agent : /Mozilla/5.0/i}){ "...
Aggregation FrameworkAggregation Framework  •様々な集約ルールをUnixのPipeのような感じでつ   ないでいくことができる機能(2.1.0以降)   http://www.mongodb.org/...
Problem of Log Collectingログ収集における課題 •MongoDBにログを保存する際は以下のような点 が課題に。  •非構造データ→構造データの変換   (生ログ→BSON)  •ログの収集   (web/app serv...
Fluentd Fluentd : The event collector servicehttps://github.com/fluent/fluentdhttp://fluentd.org/doc/http://community.fluentd....
FluentdFluentd : The event collector service•syslogのように、準リアルタイムにネットワーク越 しのログ転送が行えるミドルウェア。  •JSON準拠の構造化データでやりとりをする。  •設定・導入...
FluentdFluentd : The event collector service•以下の構成のようにすると、web/appのログを準リ アルタイムで別システム(Hadoop/MongoDB/etc) に書き込む事ができる。       ...
FluentdFluentd : The event collector service•準リアルタイムでログの保存ができると、データの 準リアルタイムでの集計や可視化ができる。                                 ...
Fluentd参考資料  http://dl.dropbox.com/u/224433/kamakura_pm_2/index.html                                                      ...
#2 Summary#2 ここまでのまとめ •ログデータの保存集計にMongoDBは向いている   •検索性を落とさずスキーマレスなデータの格納    ができる。   •検索・集計クエリーがそれなりに        っている   •Fluent...
#3 Prototyping#3 プロトタイピング向けのDBとしてMongoDBを使用 •プロトタイプアプリで「とりあえず動くもの」を  作成するにはRDBを使用するのが面倒くさい。   •テーブル作成のたびにcreate table文。   ...
#3 Prototyping参考資料       http://www.slideshare.net/fungoing/mongodb-7948933                                               ...
ソーシャルゲームとMongoDB(資料紹介)                54
Ref. Ameba picoAmeba Pico(piggの海外版)での事例資料 •『Ameba PicoとMongoDB』  http://www.slideshare.net/snamura/mongo-db-  couchdb20101...
Ref. Animal LandAnimal Land(海外向けブラウザゲーム)の事例 •『ソーシャルゲームにおけるMongoDB適用事  例』  http://www.slideshare.net/matsukaz/mongodb-  ani...
まとめ      57
Conclusionまとめにかえて •広く浅くMongoDBに関する話をしてきました。 •個人的な主観は以下です。  •比較的平和なケース:   複雑なデータ構造をメモリに載りきる範囲で運   用。ログ集計などバックエンドで使用。  •チャレン...
Conclusionまとめにかえて •開発が活発でたくさんの新機能も予定されている ので、今後の進展が期待できるプロダクトです。 •今後の動きにぜひ注目していてください。 •個人的にはRedisも好きです。  •2.6から導入されるLua Sc...
ご清聴ありがとうございました              60
Upcoming SlideShare
Loading in …5
×

Introduction to MongoDB

16,807 views

Published on

Published in: Technology

Introduction to MongoDB

  1. 1. Introduction to MongoDB @just_do_neet 1
  2. 2. Today’s Agenda今日のお題目 •MongoDBの一般的な解説 •向いてそうな適用範囲 •ソーシャルゲームとMongoDB(資料紹介のみ) •まとめ 2
  3. 3. MongoDBの一般的な解説 3
  4. 4. MongoDBMongoは「でっかい」という意味らしいですhttp://www.mongodb.org/ http://www.mongodb.jp/•10gen社が主体として開発しているオープンソース 所謂「NoSQL」の一つ 4
  5. 5. Featuresよく言われるMongoDBの特徴 •ドキュメント指向なデータベース •スケーラブルなデータベース 5
  6. 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. 7. Document Orientedドキュメント指向の概念 •MongoDBはドキュメントを「BSON」形式で扱 う。http://bsonspec.org/ •一つの入れ物(collection)の中には、BSONフォー マットであれば異なる構造のデータでも入れる事 ができる。 →スキーマレス →柔軟な構造のデータベース 7
  8. 8. Document on MongoDBMongoDBの中でのデータ> 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. 9. Document on MongoDBMongoDBの中でのデータ> 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. 10. Document on MongoDBMongoDBの中でのデータ> 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. 11. Document on MongoDBMongoDBの中でのデータ> 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. 12. Document on MongoDBMongoDBの中でのデータ> 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. 13. Document on MongoDBMongoDBの中でのデータ •入れ物の中に、異なる構造のデータを格納するこ とができる(スキーマレス) •階層構造を持つデータを格納することができる。 •かつ、RDBに近い操作性を持っている。 13
  14. 14. ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling) http://www.mongodb.org/display/DOCS/Introduction 14
  15. 15. ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling) Replica Setは同一のデータを複数インスタンス で管理することでHA構成を実現するもの。 1 Replica Setあたり最低3台が必要。 http://www.mongodb.org/display/DOCS/Introduction 15
  16. 16. ScalabilityMongoDBにおけるスケーラビリティ•Replica Set(High Availability)•Sharding(Horizontal Scaling) Shardingはデータを複数クラスターで分散配置 させるための仕組み。 (≒マルチマスタ化) http://www.mongodb.org/display/DOCS/Introduction 16
  17. 17. ScalabilityMongoDBにおけるスケーラビリティ •標準機能としてReplica Set / Sharding機能が備 わっている。 •カタログスペック上は手軽にHA構成、水平 sharding構成を組むことができる。 •実際はshard間のデータ偏り調整など運用にコツ がいる 17
  18. 18. Other Featuresその他の特徴的な機能 •GridFS •大きいサイズのファイルを扱うための仕組み •地理空間インデックス •緯度経度検索 •Capped Collection •固定サイズの入れ物。サイズを超えたら古いも のから自動的に削除される。 18
  19. 19. Cons.MongoDBの欠点(主観含む) •トランザクション未サポート •トランザクションは甘え (ドヤァ •Global Lock(2.2からCollection Lockに?) •システムリソースが肥大化(メモリ、ディスク) •データ圧縮未対応(通信、データストア共) •セキュリティ周りが弱い etc. 19
  20. 20. Cons.MongoDBの欠点(主観含む) •厳密なトランザクション処理が必要なシステムに は向かない。(課金、会員管理など...) •書き込み過多なシステムには基本向かない。 •Big Dataを扱う環境には向かない。 •スケールするが故に、下手にそれなりの規模の システムに導入するとサーバー無限増殖の刑 に... 20
  21. 21. Ref. PFI Tech. White Paper参考:PFI Technical White Paper (P.17) http://preferred.jp/wp-content/uploads/2012/03/PFIwhitepaper.pdf 21
  22. 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. 23. Summaryここまでのまとめ •ドキュメント指向DB。異なる構造や複雑な構造 のデータを扱える。検索機能も強力。 •HA機能、Sharding機能を標準的に持っている。 •トランザクションは甘え。 •富豪的な作りのミドルウェアなので使用するリ ソースの多さに起因する課題があるので注意。 23
  24. 24. 向いてそうな適用範囲 24
  25. 25. Suitable Cases向いてそうな使い方(主観) •(注)下記以外にも適切な使い方はたくさんある と思うので皆さんも考えてください。 1.RDBやKVSでは表現しきれない複雑な構成の データを扱う。 2.一時的なログ集計、ログ管理。データ集計基 盤。 3.プロトタイピング用の環境。 25
  26. 26. #1 Complex Data複雑な構成のデータ •既存のRDBやKVSでは扱いづらいデータ。 •RDBは複数の構造(schema)のデータをひとつ の入れ物(table)に入れて扱いづらい •KVSは自由度が高いが、Valueの検索が難し い。 •複数の構造のデータをひとつの入れ物に入れて、 検索性も高めるためにはどうすれば? 26
  27. 27. #1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed http://photoalbum.naver.jp/ 27
  28. 28. #1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed •Activityごとにデータ構 造が違う。 (コメント、like 、写真 etc...) 28
  29. 29. #1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed •ひとつのActivityの中に 複数のアイテムが存在す るケースがある。 29
  30. 30. #1 Complex Data複雑な構成のデータ •例:ソーシャルサービスのActivity Feed •Activityに含まれるアイ テム(写真など)を個別 に検索する必要がある。 (データの消し込みなど) 30
  31. 31. #1 Complex Data複雑な構成のデータ •RDBでモデリングした場合 •Oops... 31
  32. 32. #1 Complex Data複雑な構成のデータ •KVSでモデリング?した場合 •Valueの検索に課題 32
  33. 33. MongoDB Can Do It!MongoDBならできるよ! •そこでMongoDBですよ。 •スキーマレスなので... •複数のフォーマットのActivityをひとつの入れ 物に詰め込める。 •かつ検索性能も落とさずに済む。 33
  34. 34. Delete Photo(Column) 例:写真の削除#lookup photodb.activity.find({feedList.feedData.photoList, photoId})#delete photodb.activity.remove({feedList.feedId, feedId})#re-insert timeline datadb.activity.insert(newFeedData) 34
  35. 35. Delete Album(Row) 例:アルバムの削除#lookup albumdb.activity.find({feedList.feedData.albumList.albumId,alubmId})#delete albumdb.activity.remove({feedList.feedId, feedId}) 35
  36. 36. Dot Notation dot notation記法による階層の深いデータの検索 •MongoDBはdot notationという記法で階層の深い データの検索が可能。 (db.hoge.find({a.b.c.d.e : 1}) のような形が可) •インデックスを貼ることも可能。#lookup albumdb.activity.find({feedList.feedData.albumList.albumId, alubmId})#delete albumdb.activity.remove({feedList.feedId, feedId}) 36
  37. 37. #1 Summary#1 ここまでのまとめ •複雑な構造のデータを検索性を落とさずに使うに はMongoDBは向いている。 •ただし先に紹介したような設計にするとデータ が肥大化しがちなので注意。 •参照・更新のスループットを落とさないために はデータ・インデックスをオンメモリで乗るサ イズに収めるのが前提。 37
  38. 38. #2 Storing Logsログファイルの保存先としてのMongoDB •ログファイルは多くの場合非構造・スキーマレス で保存されている。 •ただ保存するだけでなく、ログの検索や集計を 手軽に行いたい •RDBなどスキーマを厳密に定義した入れ物はあ まり向かない。 →MongoDB! 38
  39. 39. Advanced QueriesMongoDBの高度なクエリー •MongoDBはNoSQLと言われる群の中では検索・ 集計クエリーの機能が っているのが特徴。 •count() •group() •MapReduce •正規表現 •Aggregation Framework 39
  40. 40. Queries : count() count() 文 •条件に合致する件数を返す。SQLのcount文とだ いたい同じ。> db.accesslogs.find({method : GET, code: 200}).count()6644 40
  41. 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. 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. 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. 44. Aggregation FrameworkAggregation Framework •様々な集約ルールをUnixのPipeのような感じでつ ないでいくことができる機能(2.1.0以降) http://www.mongodb.org/display/DOCS/Aggregation+Framework http://datablend.be/?p=1400 44
  45. 45. Problem of Log Collectingログ収集における課題 •MongoDBにログを保存する際は以下のような点 が課題に。 •非構造データ→構造データの変換 (生ログ→BSON) •ログの収集 (web/app server→log server) •ログ保存時の負荷分散 (一度にまとめて保存しようとするとMongoDBのGlobal Lockの 食 に...) 45
  46. 46. Fluentd Fluentd : The event collector servicehttps://github.com/fluent/fluentdhttp://fluentd.org/doc/http://community.fluentd.org/browse/help-center/ 46
  47. 47. FluentdFluentd : The event collector service•syslogのように、準リアルタイムにネットワーク越 しのログ転送が行えるミドルウェア。 •JSON準拠の構造化データでやりとりをする。 •設定・導入が非常に簡単。 •プラグイン形式で入出力処理の拡張が行える •MongoDBに書き込むためのプラグインもある https://github.com/fluent/fluent-plugin-mongo 47
  48. 48. FluentdFluentd : The event collector service•以下の構成のようにすると、web/appのログを準リ アルタイムで別システム(Hadoop/MongoDB/etc) に書き込む事ができる。 Apps Hadoop fluentd Clusters fluentd Apps fluentd mongod Apps fluentd fluentd 48
  49. 49. FluentdFluentd : The event collector service•準リアルタイムでログの保存ができると、データの 準リアルタイムでの集計や可視化ができる。 49
  50. 50. Fluentd参考資料 http://dl.dropbox.com/u/224433/kamakura_pm_2/index.html 50
  51. 51. #2 Summary#2 ここまでのまとめ •ログデータの保存集計にMongoDBは向いている •検索性を落とさずスキーマレスなデータの格納 ができる。 •検索・集計クエリーがそれなりに っている •Fluentdと組み合わせると煩わしいログの収集 処理も簡単に。欲しいデータが常に手元に。 •一時保存の場合はCapped Collectionが便利 51
  52. 52. #3 Prototyping#3 プロトタイピング向けのDBとしてMongoDBを使用 •プロトタイプアプリで「とりあえず動くもの」を 作成するにはRDBを使用するのが面倒くさい。 •テーブル作成のたびにcreate table文。 •開発中にDBのスキーマが頻繁に変わる。 •MongoDBなら事前定義不要。クエリー実行した 内容のとおりにデータが作成される。 •プログラマ側でコントロールできる。 52
  53. 53. #3 Prototyping参考資料 http://www.slideshare.net/fungoing/mongodb-7948933 53
  54. 54. ソーシャルゲームとMongoDB(資料紹介) 54
  55. 55. Ref. Ameba picoAmeba Pico(piggの海外版)での事例資料 •『Ameba PicoとMongoDB』 http://www.slideshare.net/snamura/mongo-db- couchdb20101214 •『AmebaPico 裏側の技術やAWS活用について』 http://www.slideshare.net/KoheiMorino/ amebapico-aws 55
  56. 56. Ref. Animal LandAnimal Land(海外向けブラウザゲーム)の事例 •『ソーシャルゲームにおけるMongoDB適用事 例』 http://www.slideshare.net/matsukaz/mongodb- animal-land-11134607 56
  57. 57. まとめ 57
  58. 58. Conclusionまとめにかえて •広く浅くMongoDBに関する話をしてきました。 •個人的な主観は以下です。 •比較的平和なケース: 複雑なデータ構造をメモリに載りきる範囲で運 用。ログ集計などバックエンドで使用。 •チャレンジングなケース(お金的な意味で): Big Dataを扱う。大規模システムのストレージ として用いる。 58
  59. 59. Conclusionまとめにかえて •開発が活発でたくさんの新機能も予定されている ので、今後の進展が期待できるプロダクトです。 •今後の動きにぜひ注目していてください。 •個人的にはRedisも好きです。 •2.6から導入されるLua Scriptingは楽しそうで すね 59
  60. 60. ご清聴ありがとうございました 60

×