Analytics with MongoDB

7,785 views

Published on

3 Comments
20 Likes
Statistics
Notes
No Downloads
Views
Total views
7,785
On SlideShare
0
From Embeds
0
Number of Embeds
2,631
Actions
Shares
0
Downloads
82
Comments
3
Likes
20
Embeds 0
No embeds

No notes for slide

Analytics with MongoDB

  1. 1. Analytics with MongoDB @bibrost
  2. 2. @bibrostFreelance EngineerMongoDB JP / GraphDB JPMade Analytics system for SocialAppsJoined SV startup from September 2011- Python(Tornado) / Scala( Lift ) Page : 1
  3. 3. Today‘s Theme1.What’s Analytics?2.Why MongoDB?3.Case study Page : 2
  4. 4. What’s Analytics? Page : 3
  5. 5. データを分析し「行動」を変え結果を向上させる継続的活動 Data Analytics Action Page : 4
  6. 6. One Big Issue Page : 5
  7. 7. Discover gold dust in desert vs Discover gold in mine Page : 6
  8. 8. Garbage in garbage out ゴミのようなデータを使っていくら 解析しても出てくる結果はゴミばかり Page : 7
  9. 9. コスト 砂漠 現実的ライン 鉱山 データ量 Page : 8
  10. 10. Do you want todiscover gold in mine? Page : 9
  11. 11. Garbage to garbage box ゴミはゴミ箱に捨てて忘れる、という戦略 具体的には ・無計画に保存されたログ ・ルールが無く解釈が困難なログ ・必要な情報が不足しているログ Page : 10
  12. 12. Strategic Loggingきちんとプランニングした上で分析のためのデータを生成する プランニング 実装 収集・分析なんのために? どうログを送れば より高速にするには?どんな結果を得たい? 意図した結果を どのプロダクトを使うか?どう行動につなげる? 得ることができるか? わかりやすい表現は? Page : 11
  13. 13. Why MongoDB? Page : 12
  14. 14. is DocumentDB Relational DB Oracle, PostgreSQL, etcKey-value Store Redis, etc Columnar DB Hbase , Cassandra, etc Document DB MongoDB, CouchDB , etc Graph DB Neo4j, FlockDB, etc Page : 13
  15. 15. Strategicなログ収集に利用しやすいMongoDBが持つ3つの特性- Structured- Schemaless- Scalable Page : 14
  16. 16. Structured構造化データを持ち、更にクエリを利用できるactivity = { user:”1”, date:2011024, actions:{ battle:[{target:”5”,result:”win”}, {target:”59,result:”lose”}], paid:[{item:”5”,amount:1,unit:50,price:50}] }}db.activity.find{date:{‘$gte’:20111001,’$lte’:20111015}インデックスを貼ることができ構造データの高速サーチが可能 Page : 15
  17. 17. Schemaless構造化されていながら、スキーマを持たず柔軟に利用可能activity = { user:”1”, date:2011024, actions:{ battle:[{target:”5”,result:”win”}, {target:”59,result:”lose”}], paid:[{item:”5”,amount:1,unit:50,price:50}] }}ドキュメントによってフィールドがあったりなかったりしてもOK。後からいくらでも構成変更ができる上、リストを持つことも可能 Page : 16
  18. 18. Scalable巨大なデータをさばける拡張性と速度・ログの保存に適した高速なCappedCollectionの提供 ※データサイズを固定し、Indexを持たないことで非常に高速に保存可能 読み込みにはtailable cursorを用いる・fire-and-forgetによる結果を待たないinsert ※unsafeではあるが、高速にクライアントへレスポンスを返す事が可能・Bulk insertによる一括インサートなどを利用することで、大規模なアプリのストリーミングデータを取り込むのに十分な性能を出すことができます。 Page : 17
  19. 19. 3つの特性を活かすことで効率化がしやすい Page : 18
  20. 20. Case study Page : 19
  21. 21. Nijiboxさんのソーシャルアプリ向けにMongoDBを利用した解析用のバックエンドシステムを開発 Page : 20
  22. 22. Mission- 改善のアクションに繋げられるツールを作る- フロントエンドにやさしいUI- 効率よく、早く実行できるシステム- スケーラビリティの高い仕組み Page : 21
  23. 23. 各アプリケーションにクライアントライブラリを配布し、そこから構造化データを送る。データは分析用のクラスタに送られ、最終的に専用の管理ツールから閲覧できるようになっている。 アプリA Clientクラス レシーバー アプリB Clientクラス Database 管理画面 アプリC Clientクラス Page : 22
  24. 24. Httpとjsonが扱えれば使えるコードを提供して導入コストを抑えるフレームワークに組込ロジック側では一文で送信可能に require_once(Client.php); $userid = 1000; $server = "http://xxxx/"; $appid = "test"; Client::init($userid,$server,$appid); // ここまではフレームワークに組込 // アプリ上ではこの一行でログ送信OK _ntls()->setAction("mission",array("type"=>"taiman","gekiha" => 100)); Page : 23
  25. 25. 内部的には、入ってきたローデータを一度中間形式に変更しそこから各種解析をかける仕組み。基本的なデータ(KPI等)は定期的に解析データをキャッシュ。必要であれば中間データからオンデマンドに解析を実施できるインターフェイスを提供している。 Page : 24
  26. 26. Point, Challenge- 開発初期から参加し、どのようなデータを 送るかについて議論した上で進めた- 認証機構をチームで使っているBacklogを通す事で簡素化- 能動的に取得するログに絞込むことで負荷軽減- ログ送信のためのクラスを作り、フレームワークに組込- 開発チームのメンバが利用できるインターフェイスを用意 Page : 25
  27. 27. Message Page : 26
  28. 28. Analystになろう- アナリスト≠技術者。ビジネスやアプリへの理解が必要- 勿論、解析のためのテクノロジを利用する技術は必要- それと同等に仮説、マーケ、検証、継続マネジメントも重要- これから需要は増えそうだが、プレイヤーが少ない→ 市場価値を高める一手としてオススメ Page : 27
  29. 29. Questions Page : 28
  30. 30. @bibrostThanks

×