MongoDB で作るソーシャルデータ新解析基盤

～いまとむかし～doryokujin

NoSQLセミナー：ソーシャルメディア、ソーシャルアプリが育てたNoSQL技術

[名前] doryokujin ( 井上 敬浩 )

[年齢] 26歳

[専攻] 数学（統計・確率的アルゴリズム）

[会社] 芸者東京エンターテインメント

[職業] データマイニングエンジニア

[趣味] マラソン ( 42.195km: 2時間33分 )

[コミュニティ]

・MongoDB JP: もっとMongoDBを日本に！

・TokyoWebMining: 統計解析・データマイニングの各種方法論、WEB上のデータ活用に関する勉強会

・おしゃれStatistics: 名著「statistics」を読み進めながら統計を学ぶ勉強会

自己紹介

[2010年11月] MongoDB ユーザーグループ発足

・MongoDB JP - Google グループ

[2010年12月] 「第1回 MongoDB 勉強会」を開催

・「第1回 MongoDB JP ＆ CouchDB JP 合同勉強会 in Tokyo」活動報告

[2011年03月] 「MongoDB Conference in Japan」を開催

・「MongoDB Conference in Japan」レポート

[2011年04月] 「第2回 MongoDB 勉強会」を開催

・「第2回　MongoDB JP 勉強会 in Tokyo」レポート

[2011年05月] 「第3回 MongoDB 勉強会」を開催※ MongoDB 勉強会はフューチャーアーキテクトさんにて毎月開催しています！

MongoDB JP (#mongotokyo)

・ログ（アクセスログ・行動ログ等）解析基盤の話を2つ：

「MongoDB と Hadoop を活用したデータ解析基盤」

- 2010年11月 ～ 2011年4月までの仕様

「MongoDB と Redis・Scribe を活用したデータ解析基盤」

- 2011年5月からの新仕様（現在開発継続中）

- 新基盤の詳細なアーキテクチャは「第4回MongoDB勉強会（6月中旬）」で発表予定

今日の発表内容

過去に発表した資料

1. 旧解析基盤について

1.1 処理フローについて

1.2 解析結果の例

2. 新解析基盤について

2.1 処理フローについて

2.2 MongoDB 機能紹介

2.3 新解析基盤の紹介

アジェンダ

1. 旧解析基盤について「MongoDB と Hadoop を活用したデータ解析基盤」

http://www.slideshare.net/doryokujin/mongodb-uimongodb

1.1 処理フロー

[企画・経営者に対して]・彼らの意志決定の助けとなるようなデータを提供

- 基本的なPV、UU、DAO、ARPUなどは当たり前

- イベントの効果・特定の行動に対する詳細な情報をユーザー単位で見れるように

※ 基本的にあらゆるデータを提供。出ていないデータはログとして出力してもらうために、形式と出し方を提示してエンジニアに仕込んでもらう

解析者のおしごと１

1. 分散するサーバーから各種ログをローカルに収集2. 課金・登録情報MySQLから該当データを取得3. ユーザーゲームセーブデータをCassandraから取得

旧解析基盤の処理フロー

1.Data Gathering

3.Data Analysis

5.Data Mining

6.Data Sharing

2.Data Pre-processing

4.Reslt Data Strage

1. ログの整形2. フィルタリング

1. ユーザーIDをキーにした各指標値の集計2. アクセスログの集計3. 一定期間のイベントの効果測定のための集計

ランキング課金情報登録日

行動ログアクセスログ

ゲームセーブデータ

2. Data Pre-processing3. Data Analysis 4. ResultData

Storage

Python ScriptThrift & Python

データセンター → AmazonS3

1. Data Gathering

Cassandra MySQL

HDFS

1. Data Gathering

5. Data Sharing6. Data Mining

旧解析基盤の処理フロー

exec/day

Sleepy.Mongoose

解析対象データ

ソーシャルデータ

Graph Analysis

Web UI

Data Analysis

5. Data Sharing

6. Data Mining

旧解析基盤の処理フロー

ScientificPython

1.2 解析結果の例

User 課金データ// 11/10に最も課金してくれたユーザーTOP10> db.user_charge.find({date:"2010-11-10"}) .sort({totalCharge:-1}).limit(10).forEach(printjson){ "_id" : "2010-11-10+7777+Charge", "date" : "2010-11-10", "lastUpdate" : "2010-11-10", "totalCharge" : 10000, "userId" : ”7777", "actionType" : "Charge", "boughtItem" : { "ｱｸｾｻﾘｰの素EX" : 13,

"ｺﾈﾙｷﾞｰ+6000" : 3,

"ｱｸｾｻﾘｰの素PRO" : 20

}}{…

> db.daily_charge.find({date:"2010-11-10",T:"all"}) .limit(10).forEach(printjson) { "_id" : "2010-11-10+group+Charge+all+all", "date" : "2010-11-10", "total" : 100000, "UU" : 2000, "group" : { 　　"わくわくポイント" : 1000000,

　　"ｱｸｾｻﾘｰ" : 1000000, ... }, "boughtItemNum" : { "料理の素EX" : 8, "ｱｸｾｻﾘｰの素" : 730, ... }, "boughtItem" : { "料理の素EX" : 10000, "ｱｸｾｻﾘｰの素" : 100000, ...

Daily 課金データ

User 行動データ> db.user_trace.find({date:"2010-11-10”,actionType:

"a{Make}",userId:”7777"}).limit(10).forEach(printjson)

{ "_id" : "2010-11-10+7777+a{Make}",　　 "date" : "2010-11-10"

"lastUpdate" : "2010-11-11", "userId" : ”7777", "actionType" : "a{Make}", "actionDetail" : {　　　　 "make item ksutera" : 3,

"make item makaron" : 1, "make item huwahuwamimiate" : 1, "make item ringoame" : 3,　　　　　…

　　　}

}

Daily 行動データ> db.daily_trace.find( {date:{$gte:"2010-11-10”,$lte:”2010-11-20”},actionType:"a{Make}"}

).limit(10).forEach(printjson)

{

"_id" : "2010-11-10+group+a{Make}",

"date" : "2010-11-10", "lastUpdate" : "2010-11-12",

"actionType" : "a{Make}",

"actionDetail" : {

　　　 "make item kinnokarakuridokei" : 615,

"make item banjo-" : 377, "make item itigoke-ki" : 135904,

"make item wadaikoan" : 40,

　　　　　"make item ha-pu" : 11,

　　　　　...

},...}

ユーザー属性データ> db.user_registration.find({userId:”7777"}).forEach(printjson){ "_id" : "2010-06-29+7777+Registration", "userId" : “7777" "actionType" : "Registration", "category" : { R1” : “True”, #直近1週間ログインしていない場合 = True “T” : “ll” #プレイ期間が長期のユーザー

　　　　　…　　　}, “tag”:[“longTerm”,”highFreq”], #ブログのタグのようなもの　　　“firstCharge” : “2010-07-07”, #初課金日　　　“lastLogin” : “2010-09-30”, #最終ログイン日

　　　“playTerm” : 94, #プレイ期間　　　“totalCumlativeCharge” : 50000, #総合課金額　　　“totalMonthCharge” : 10000, #直近1ヶ月の課金額　　　…}

属性カテゴリデータ> var cross = new Cross() //ユーザー定義関数

//月額課金×プレイ期間（退会ユーザー）

> MCResign = cross.calc(“2010-10-08”,“MC”,1)

課金/期間 0円(z) ~1000円(s) ~10000円(m) 10000円~(l) 合計

~1日(z) 50000 10 5 0 50015

~1週間(s) 50000 100 50 3 50153

~1ヶ月(m) 100000 200 100 1 100301

~3ヶ月(l) 100000 300 50 6 100356

3ヶ月~(ll) 0 0 0 0 0

//月額課金×プレイ期間（現役ユーザー）

> MCNotResign = cross.calc("2010-10-08","MC",-1)課金/期間 0円(z) ~1000円(s) ~10000円(m) 10000円~(l) 合計

~1日(z) 50000 10 5 0 50015

…

[例] チュートリアルページの離脱状況を確認：

アクセスデータ

//ユーザー定義関数

> access = getAccessData(“tutorial”,“2010-12-01”)

UU PATH

10000 /playshop2-gree/tutorial/FirstTopPage

9500 /playshop2-gree/tutorial/Tutorial01Page

8000 /playshop2-gree/tutorial/Tutorial02Page

7700 /playshop2-gree/tutorial/Tutorial03Page

7000 /playshop2-gree/tutorial/Tutorial04Page

4000 /playshop2-gree/tutorial/make/avatar

3800 /playshop2-gree/tutorial/Tutorial05Page

…

[まとめ]・MongoDBは解析結果データ格納サーバーのみ

・集計自身は Hadoop が担当

・大容量のログを Hadoop で Reduction してMongoDBに格納

旧解析基盤

[特徴]→ MongoDB が解析対象データ（ログ）サーバーにも

→ 集計自身に MongoDB が参加

→ 大容量のログを MongoDB に格納、その切り出しを Input として Hadoop などで処理、そして Mongo へ

新解析基盤では…

2. 新解析基盤について「MongoDB と Redis・Scribe を活用したデータ解析基盤」

2.1 処理フロー

[エンジニアに対して]・問題が起こった場合、該当する時間のログを提供して早期問題解決に役立てる

・不正値や異常値を発見して不正ユーザーの対策や早期バグの発見に役立てる

[サポートに対して]・ユーザーの問い合わせ・クレームに対して根拠をもって返答し、納得してもらえるように、対象ユーザーの行動を全てトラッキングできるようにする

解析者のおしごと2

・ログの表示機能：

指定された期間のログを提供する機能

・ログの検索機能：

ユーザーIDや行動タイプ、期間の条件でログを切出す機能

・バッチ集計機能：

ユーザーID・日・時間ごとにあらゆる指標を計算する機能

・非バッチ集計機能：

急な要請にも即座に該当データの提示や集計ができる機能

解析基盤に求められるもの

[Data Storage]：前者2つはデータを”Storage”する機能

・ファイルシステム

・[RDBMS] ORACLE・MySQL

・[NoSQL] HBASE・MongoDB・etc...

[Data Processing]：後者2つはデータを”Processing”する機能

・[Hadoop Family] Hadoop・Pig・Hive・Mahout

・[Other] disco・Piccolo・Apache Hama

・[NoSQL] MongoDB・Redis・Riak・etc...

検討すべきツール

[重要なこと]

・いかに少ないコスト・リソースで実現するか

・いかに楽に・安定的に運用していくか

・いかにある程度のリアルタイム性を持たせるか

・1人で構築・管理していく上で最適なものを

[結論]：MongoDB + Redis + Scribe (後 Hadoop)

解析基盤に求められるもの

新解析基盤の処理フロー1.Data Gathering

4.Data Analysis6.Data Mining

7.Data Sharing

2.Data Pre-processing

5.ResltData Strage

3. Raw Data Strage

Raw Data Search

User Tracking

4. ResultData Storage

ランキング課金情報登録日

ゲームセーブデータ

Python ScriptThrift & Python

Cassandra MySQL

1. Data Gathering

5. Data Sharing6. Data Mining

新解析基盤の処理フロー

行動ログアクセスログ

1. Data Gathering2. Data Pre-processing

データセンター

insert/hour

3. Data AnalysisWith

2.2. Mongo DB 機能紹介～Replication・Sharding・MapReduce～

[開発元] 10gen http://www.10gen.com/

[実装] C++

[OS] Linux, Mac, Windows, Solaris

[由来] “Humongous”（ばかでかい）amounts of data

[ライセンス]

・Database: GNU AGPL v3.0 License

・Drivers: Apache License v2.0

イントロダクション

Production Deployments

[ドキュメント指向DB] JSON（内部ではBSONで保持）

[完全なインデックスサポート] あらゆる属性でインデックス作成

[Replication] 自動フェイルオーバー・高可用性

[Sharding] 自動シャーディング

[Map/Reduce] フレキシブルな記述が可能

[クエリ] あらゆる条件で条件指定可能

[高速 In-Place Update] 高速なAtomic Modifiers

[GridFS] 巨大なファイルも保存可能http://www.mongodb.org/

MongoDB の特徴

2.2(a) Replica Sets

2.2(a) Replica Sets

Member1Primary

Member2Secondary

Member4Secondary

Sync

SyncSync

Member3Secondary

[特徴]

・1 Primary + N Secondary

・自動フェイルオーバー機能

・自動リカバリー機能

・Set メンバーの追加・削除が容易

・Primary - Secondary 間は非同期通信

・Write は Primary のみ・Read は Secondary からも ( “Read Scaling” )

2.2(a) Replica Sets

[自動フェイルオーバー]

2.2(a) Replica Sets

Member1Primary

Member2Secondary

Member4Secondary

Sync

SyncSync

Member3Secondary

1. Current Primary

[自動フェイルオーバー]

2.2(a) Replica Sets

Member1Primary

Member2Secondary

Member4Secondary

Member3Secondary

2. Primary Down

[自動フェイルオーバー]

2.2(a) Replica Sets

Member1Primary

Member2Secondary

Member4Secondary

Member3Secondary

3. Election Time

Negotiate Negotiate

Negotiate

[自動フェイルオーバー]

2.2(a) Replica Sets

Member2Primary

Member4Secondary

Member3Secondary

4. New Primary

SyncSync

primary 選出基準1. priority 値が最大2. primary との最終同期が最新3. votes 値が高い

[自動リカバリー]

2.2(a) Replica Sets

Member2Primary

Member4Secondary

Member3Secondary

Sync Sync

Member1Secondary

CatchUp & Sync

2.2(b) Sharding

2.2(b) Sharding

mongod 1

DatabaseA DatabaseB

CollectionA Coll CollDoc Doc DocDoc Doc DocDoc Doc DocDoc Doc Doc

Doc Doc DocDoc Doc Doc

Doc Doc DocDoc Doc Doc

DocDocDocDoc

Doc

Doc Doc DocDoc Doc Doc

EnableSharding

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 2

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 3

mongod 1

DatabaseA DatabaseB

CollectionA Coll CollDoc Doc DocDoc Doc Doc

DocDocDocDoc

Doc

分割

[Sharding とは]

Shard1

Shard2 Shard3

[特徴]

・クライアントの接続を mongos サーバーが仲介することによってクラスタ全体の情報を意識せず扱える

・クライアントは Sharding していない状況と同じようにクエリを発行し、結果を得ることができる

・Shardの 追加・撤退が容易にできる

・自動 Sharding 機能 が指定した Shard Key でデータ振り分けルールを自動決定・随時更新

・自動 Balancing 機能 が Chunk の移動を行い、Shard 間でデータの均質性を保つ

2.2(b) Sharding

2.2(b) Sharding

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 2

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 3mongod 1

DatabaseA DatabaseB

CollectionA Coll CollDoc Doc DocDoc Doc Doc

DocDocDocDoc

Doc

mongosconfigshard 情報

ClientClient Client

データの自動振り分け

[自動 Sharding]

Shard1 Shard2 Shard3

DocDoc

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 2

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 3mongod 1

DatabaseA DatabaseB

CollectionA Coll CollDoc Doc DocDoc Doc Doc

DocDocDocDoc

Doc

mongosconfigshard 情報

ClientClient Client

Doc Doc DocDoc Doc DocDoc Doc DocDoc Doc Doc

shardの偏り！

[自動 Balancing 1]

2.2(b) ShardingShard1 Shard2 Shard3

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 2

DatabaseACollectionADoc Doc DocDoc Doc DocDoc Doc Doc

mongod 3mongod 1

DatabaseA DatabaseB

CollectionA Coll CollDoc Doc DocDoc Doc Doc

DocDocDocDoc

Doc

mongosconfigshard 情報

ClientClient Client

Doc Doc DocDoc Doc Doc Doc Doc Doc Doc Doc Doc

マイグレーション※マイグレーションは Chunk 単位

2.2(b) ShardingShard1 Shard2 Shard3

[自動 Balancing 2]

[注意点]

※ Sharding 環境では様々な問題が起こる

・Unique なキーが重複してしまう

・常に振り分けルールを更新するため、パフォーマンスが低下

・single update operation でエラー

・マイグレーション中は Count() コマンドに誤差

・マイグレーションには多大なメモリ消費とサーバー負荷が

・メモリが不足しているとマイグレーションは起こらない

2.2(b) Shardinghttp://www.slideshare.net/doryokujin/mongo-sharding

2.2(c) Mongo Map Reduce

2.2(c) Mongo Map Reduce“Primary”に指定した Shard

ResultCollection

3. Reduce

out option1. replace2. merge3. reduce4. memory

4. Result

[Mongo Map Reduce Model]

mongos ※shuffle 機能は無い1.ルーティング・指示

Shard1

2. Map Reduce

Shard2

2. Map Reduce

Shard3

2. Map Reduce

Shard4

2. Map Reduce

Shard5

2. Map Reduce

Shard6 2. Map Reduce

Shard13. Reduce

[特徴]

・Java Script で記述

・Map Reduce の出力先に4つの選択肢がある：

replace: 新しくコレクションを作り結果を格納。既に同名コレクションが存在するならコレクション全体を上書

merge: 既存のコレクションに同名のキーがあるフィールドの値を書き換える

reduce: 既存のコレクションに同名のキーがあるフィールドに対して新値と元の値に対して reduce 関数を適用

inline: コレクションを作成せず、メモリ上で計算して結果を返す(16MBまで)

2.2(c) Mongo Map Reduce

[注意点]

・map reduce処理は mongod あたり1スレッドしか使用できない

・16MB 以上の出力はコレクションへの書き込みが発生

・実行中も DB はロックしないが他のオペレーションが遅くなる

・仕組みとルールを理解していないと所望の結果が得られない

・JavaScript で記述しないといけない

2.2(c) Mongo Map Reduce

2.2(d) まとめと課題

・Sharding は以下の理由で信頼できない

- Migration 時におこる様々な問題

- Update や Unique Index 周りも問題

- データ分割ルールが複雑になりすぎて把握できない

・Map Reduce はそれほど以下の理由で強力ではない

- Shard あたり1コアしか使い切ることができない

- 16MB以上の計算結果はコレクションに書き出す

- Secondary の Collection を活用することができない

2.2(d) まとめと課題

これらの課題をいかに克服するか

2.3 新解析基盤の紹介

[技術要素]・MongoDB v1.8.1

・Redis v2.2.6

・scribe

・Hadoop

[構成サーバー]・MongoDB Data サーバー × 6：Raw Data Storage

・MongoDB Result サーバー × 2 : 解析済データサーバー

・BackUp サーバー × (3 - 6)：古くなったデータのJSON Dumper

・Monitoring サーバー × 1：Mongoの監視・サーバー情報管理

技術要素・構成サーバー

2.3(a) Mongo: Raw Data Storage

[25 shard 構成]

・25 shard × 3 Replica Sets + 3 config + 6 mongos

・Shard key = “hour”

・shard0 - shard23 に各時間 (0,1,...,23) を1つずつ割り当てるマニュアル Sharding、Chunk の分割も起こさない

・よって自動 Sharding は使わない

・自動 Balancer の停止：Migration は起こさない

Mongo: Raw Data Storage

Manual Sharding Model

Sharding の種々の問題を防ぐ

[08/May/2011:04:35:11 +0900]

[4Shard / Server]

・サーバー1台 (4core) に4shard=(4mongod)を同居

[Output Only Shard]

・25 番目の shard は解析結果コレクションの書き出し用

・ログデータは保持しない

・SSDによる高速出力

[Replication]

・他サーバーに Replica Set Member を配置

全コアを使いきる

高速書き出し

Mongo: Raw Data Storage

Shard00

Shard01

Shard02

Shard03

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard20

Shard21

Shard22

Shard23

Shard16

Shard17

Shard18

Shard19

Disk1

Disk2

mongos

．．．

Shard24 SSD

mongos ．．． mongos

Primary

Secondary

server1 server2server6

Mongo: Raw Data Storage

Shard00

Shard01

Shard02

Shard03

Shard00

Shard01

Shard02

Shard03

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard20

Shard21

Shard22

Shard23

Shard16

Shard17

Shard18

Shard19

Disk1

Disk2

．．．

Shard24 SSD

mongos

Raw Data Search

Primary

Secondary

db.collection.find( {date:20110517, userId:”1234”});

mongosが該当するshardからデータ取得

Client

Shard00

Shard01

Shard02

Shard03

Shard00

Shard01

Shard02

Shard03

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard04

Shard05

Shard06

Shard07

Disk1

Disk2

Shard20

Shard21

Shard22

Shard23

Shard16

Shard17

Shard18

Shard19

Disk1

Disk2

．．．

Shard24 SSD

mongos

Insert per Hour

Primary

Secondary

db.collection.insert( {hour:0, userId:”1234”, actionType:”login”,});

Client

db.collection.insert( {hour:21, userId:”9876”, actionType:”put item”,...});

mongosが該当するshardへデータ挿入

Shard00

Shard01

Shard02

Shard03

．．．

mongos

挿入頻度と scribe

データは1時間毎にscribeから取得し保存先のhostのmongosにbulk insert

0 - 3時までのログ 20 - 23時までのログ

行動ログアクセスログ

データセンター

insert/hour

mongos

2.3(b) Mongo: Data Analysis

Shard00

Shard01

Shard02

Shard03

Shard20

Shard21

Shard22

Shard23

SSD

Mongo Master MR (for small data)

Shard00

Shard01

Shard02

Shard03

24shard(=24core) フル活用してMapReduce SSD上のcollection

に高速書き込みmongos

2.MR 2.MR 2.MR2.MR 2.MR

3.Reduce

1.ルーティング・指示

．．．

ResultCollection

Shard24

4. Result

out:reduce

Result情報には各Shardの統計情報=時間別統計情報

[雑感]

・デフォルトの Mongo Map Reduce は Master しか使えない

・Map Reduce 実行中でもDBはロックしない

・ただしパフォーマンスは落ちる

・長時間の Map Reduce を Master に対して行いたくない

・書き込みの起きていない Master と全ての Slave で Map Reduce したい

Mongo Master MR (for small data)

※現在insertが行われている時間帯のShard は

避ける

[Slave In-Memory Map Reduce Model]

Shard04

Shard05

Shard06

Shard07

Shard00

Shard01

Shard02

Shard03

Shard16

Shard17

Shard18

Shard19

Shard24 SSD

In-Memory MRIn-Memory MRIn-Memory MR

Shard20

Shard21

Shard22

Shard23

In-Memory MR

Shard04

Shard05

Shard06

Shard07

In-Memory MR

Shard00

Shard01

Shard02

Shard03

In-Memory MR

Mongo Slave MR (for middle data)

．．．

Primary

Secondary

Mongo Redis Model (for middle data)

1. 全 Shard 全 Primary / Secondary(insert 中の Shard除く) の mongod に直接接続（並列処理）

Primary

Secondary

3. 各 mongod の実行結果(key,value)を同host内のRedisに集約 HINCRBY or INCR or SADD ...3.Reduce

2. mapreduce / distinct / find などを実行。find の場合は別途集計処理

local redis

Mongo Redis Model (for middle data)

．．．

global redis

local redis local redis local redis

ResultCollection

①

② ②

②

③③③

①

①

④④④

⑤

Mongo R Redis Model (for small data)Shard04

Shard05

Shard06

Shard07

Shard00

Shard01

Shard02

Shard03

RMongo

server

doRedis

doRedisRMongo

local redis global redis

行列演算

Mongo R Graph Model(for small data)Shard04

Shard05

Shard06

Shard07

Shard00

Shard01

Shard02

Shard03

RMongo

RMongoGraphなどの複雑なオブジェクト

Res.MongoDB

RMongo

RMongo

CappedCollection

ResultCollection

Graph・Network Analysis

Mongo MR on Disk (for big data)Shard04

Shard05

Shard06

Shard07

Shard00

Shard01

Shard02

Shard03

text

text

text

text

text

text

text

text

key1

key2

key3

key4

find

find

Mongo Hadoop Model (for big data)Shard04

Shard05

Shard06

Shard07

Shard00

Shard01

Shard02

Shard03

text

text

text

text

text

text

text

text

find

find

HDFSor

FileSytem

[まとめ]

・現バージョン (v1.8) においても Sharding と Map Reduce はプロダクションレベルでは無い

・Mongo DB は多機能だけれども高性能ではない

・まだたくさんの不都合が起こっている

・ただし解析でログを扱う場合にはそれらの機能に一部の制限をつけて加える事で強力な手段となる

・ある程度のリアルタイム性も確保することが可能

・Mongo DB は素晴らしい解析基盤を提供してくれる！！

最後に

ありがとうございました