• Save
ソーシャルアプリのプロトタイプ制作にMongoDBを活用
Upcoming SlideShare
Loading in...5
×
 

ソーシャルアプリのプロトタイプ制作にMongoDBを活用

on

  • 35,234 views

 

Statistics

Views

Total Views
35,234
Views on SlideShare
11,482
Embed Views
23,752

Actions

Likes
28
Downloads
0
Comments
0

28 Embeds 23,752

http://cloudrop.jp 17478
http://d.hatena.ne.jp 2466
http://www.nogutetu.com 2436
http://webcache.googleusercontent.com 383
http://gihyo.jp 365
http://slide.yoshiday.net 289
http://cynipe.hateblo.jp 79
http://toqoz.hateblo.jp 55
http://fungoing.jp 49
url_unknown 40
http://infra.rrdtool.net 39
http://www.slideshare.net 17
http://hatenatunnel.appspot.com 9
http://translate.googleusercontent.com 7
http://shadianpardaz.com 6
http://localhost 5
http://paper.li 5
http://s.deeeki.com 5
https://www.google.co.jp 4
http://us-w1.rockmelt.com 4
http://twitter.com 3
http://cache.baidu.com 2
http://cache.yahoofs.jp 1
http://freeandroidgames.appspot.com 1
http://timprx.appspot.com 1
http://www.twylah.com 1
http://gaeforyou.appspot.com 1
http://ventil.se 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ソーシャルアプリのプロトタイプ制作にMongoDBを活用 ソーシャルアプリのプロトタイプ制作にMongoDBを活用 Presentation Transcript

    • ソーシャルアプリのプロトタイプ制作にMongoDBを活用~PHP+Sleepy.Mongooseでお手軽永続化~Fungoing LLC / Satoshi MiyauchiTwitter : @bibrost
    • Profile 宮内 聖 / Satoshi Miyauchi @bibrost 自宅警備員(週休2日) 兼 Fungoing LLC 代表 兼 株式会社監査と分析 システム開発担当 兼 株式会社ニジボックス 傭兵 … etc Webデザイン、映像編集、Webサービスの開発など・・・いろいろ 引きこもりフリーランス生活。と思ったら最近はたまに出勤。 Scala、MongoDB、Solrをメインにやってます ※お仕事、協業のご相談は随時受付中 Page : 1
    • Recent Works ( with MongoDB! )3月30日Open katsumaweb.net Scala+MongoDB+Rogueを使って開発 前回のMongoDB勉強会で発表しました Webに資料もあります4月中旬~ ソーシャルアプリ開発のお手伝い リクルート子会社のニジボックスという会社で アプリ開発のお手伝いをしています。 MongoDBを提案してプロジェクトで利用 → 今日はここの話をします! Page : 2
    • Outline 1. プロジェクト概要 → 関わっている内容と、MongoDBの利用について 2. MongoDBでお手軽永続化 → コードを見ながら、利用方法を紹介 3. 実装の裏側 → どうやって実装してるか 4. Q&A → 実装した理由や狙いなどをQ&A方式で 5. MongoDB活用のセオリー → 今までの経験も含めた、MongoDB活用に関する所感 Page : 3
    • 1. プロジェクト概要 Page : 4
    • 2010年末にできたばかりで、ここへ来てスタッフも集まり気合入れてアプリを開発しようというプロジェクトへ参加。担当領域は社内フレームワークの改善、ログ分析プラットフォームの構築、開発プロセスの改善などがメイン。 Page : 5
    • まずやったこと 機能ごとに開発するのではなく、小さいサイズからでも完成品を作り それを毎週増築→レビュー→フィードバックしていく形の 開発プロセスの提案。 Week1 Week2 Week3 Week4企画 コンテンツ コンテンツ コンテンツ コンテンツコンテンツ 開発 開発 開発 開発開発フィード レビュー レビュー レビューバック Page : 6
    • プロセスの意図 Week1 week2 week3 week4 ユーザが体験できるシナリオを少しずつ拡張していくことで、 「ユーザが楽しませるために重要な要素」をレビュー、改善しやすくする。 どんなに機能を増やしても、ユーザが入り込んできてくれなければ まったく意味がない。この方法であれば、ユーザの導入に近い部分から 完成していくので無駄な作業も減り本質的な改善に力を注げる。 [Week1] チュートリアル、最初のミッション、メインループ [Week2]アイテムの実装 [Week3]コミュニケーションの実装、、、 という風に、徐々にできることを増やしていく。 Page : 7
    • と、いう狙いなのですが・・・リリースタイミングが多いので結構大変。 更にレビューを受けての仕様変更は 毎週あるというのが前提です。 Page : 8
    • この速度で開発しようとするといちいちRDBのスキーマ定義なんて していられない・・・。メンバー間でのスキーマ同期にかかるコストも馬鹿にならないし どうしたものか Page : 9
    • ん、そういえば・・・ Page : 10
    • があるじゃないか Page : 11
    • そもそも、ログ分析部分はMongoDBでやるつもりだったのでSleepy.mongooseの環境は検証用にすでにある ログ分析プラットフォーム アプリ Sleepy.Mongoose ログ送信クラス MongoDB ※MongoDBの接続ライブラリを セットアップするコストを減らすために Log Collection アプリ側はcurl+jsonだけで利用可にする (Capped Collection) ログフロント Map/Reduce コンソール Analytics Source (JSで操作) Collection ログ閲覧画面 jQuery + Graph UI Sleepy.Mongoose Page : 12
    • Sleepy.Mongoose =Python+Pymongoで書かれた MongoDBのRESTinterface実装http://www.snailinaturtleneck.com/blog/2010/02/22/sleepy-mongoose-a-mongodb-rest-interface/ Page : 13
    • イメージ 初期はMongoDBを粘土(CrayModel)のように いじりまわして開発。内容が固まったらRDBで 金型を作ってそこへ流しこむ・・・そんな感じ。 Week1 Week3 Week5 Week7 Week9 Week11 Week2 Week4 Week6 Week8 Week10 Week12 Week1~8あたりまではMongoDBで 最終的には どんどんシステムを練り続ける RDBに固める Page : 14
    • でプロトタイプを作っていこう! Page : 15
    • そして導入後・・・喜びのお言葉 MongoDBに病みつきです!! 準備(CREATE)なしでいきなり 挿入(INSERT)なんて!? もうmySQLには戻れません!! チームメンバーFさん Page : 16
    • 2. MongoDBでお手軽永続化 Page : 17
    • こんなコードが書けるようにフレームワークを拡張しました Page : 18
    • とりあえず永続化! // データを作って、、、 $data = array( ‚name‛ => ‚Sword‛, ‚category‛ => ‚Weapon‛ ‚price‛=> 1200 ); // insert _persistence()->insert( ‚item‛, $data ); Page : 19
    • データとってくる // とりあえず10件とってくる $docs = _persistence()->from( ‚item‛ )->fetch(10); // 11~20件目をとってくる $docs = _persistence() ->from( ‚item‛ ) ->skip(10) ->fetch(10); // 件数をとってくる $count = _persistence() ->from( ‚item‛ ) ->count(); Page : 20
    • 検索してみる // 名前が一致したものをとってくる $docs = _persistence() ->from( ‚item‛ ) ->cBy(‚name‛,‛Sword‛) ->fetch(10); // 範囲を含めてとってくる $docs = _persistence() ->from( ‚item‛ ) ->cOr( array(‚category‛ => ‚weapon‛, ‚category‛ => ‚armor‛) ) ->cBetween(‚price‛,1000,2000) ->skip(0) ->fetch(10); Page : 21
    • 並び替える // priceの昇順でとってくる $docs = _persistence() ->from( ‚item‛ ) ->cOr( array(‚category‛ => ‚weapon‛, ‚category‛ => ‚armor‛) ) ->cBetween(‚price‛,1000,2000) ->sortAsc(‚price‛) // ->sortDesc(‚price‛) ->skip(0) ->fetch(10); Page : 22
    • 更新してみる // とりあえず取得 $docs = _persistence()->from( ‚item‛ )->fetch(10); $docs[0][‘price’] = 1500; // 新しいオブジェクトで更新 $docs = _persistence() ->updateById( ‚item‛, $docs[0][‘_id’][‘$oid’], $docs[0] ); Page : 23
    • 削除する // とりあえず取得 $docs = _persistence()->from( ‚item‛ )->fetch(10); // 1件目にあったデータを削除 $docs = _persistence()->removeById( ‚item‛, $docs[0][‘_id’][‘$oid’] ); Page : 24
    • といった風に、アプリ側のコードだけで 手軽に永続化できるよ! MongoDBのクエリは書くのが結構面倒なのでよく使いそうなのを簡単に使えるようにしておいた Page : 25
    • プロトタイプとはいえ、紙芝居では プレイ感をレビューしきれない。そこでこの機能でとりあえず実装。 Page : 26
    • 設定 自社フレームワークに組み込んであるので、二行ほど変更するだけ // ENV.php define(‚MONGOOSE_HOST‛,‛http://xxx.xxx.xxx.xxx:27080‛); define(‚MONGOOSE_DB‛,‛fw‛); ※Sleepy.MongooseのサーバはAWSに設置 Page : 27
    • 3. 実装の裏側 Page : 28
    • クライアント環境 PHP 5.2 ~ (json_encode/decode) + php_curl 以上 Page : 29
    • サーバ環境 MongoDB 1.8 + Pyhton 2.7 + Pymongo 1.10.1 + Sleepy.Mongoose Page : 30
    • 永続化の仕組み Persistence->from(“col”) QueryBuilderを返す QueryBuilder->cBy() QueryBuilder->cBetween() QueryBuilder->skip() Criteria QueryBuilder->sortAsc() Application QueryBuilderクラスは Criteriaクラスに QueryBuilder->fetch() 条件を保存 Persistence->insert() Persistence->find() Persistence->updateByID() Persistence->removeByID() Sleepy.MongoosePersistenceクラス群を使ってアプリから永続化。 Persistence->request()最終的にはrequestメソッドが MongoDBSleepy.Mongooseにアクセス Page : 31
    • 内部処理private function request( $table, $command, $query, $post = NULL ){ $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $this->api."{$table}/_{$command}{$query}"); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); if( isset($post) ){ curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post ); } $result = curl_exec($ch); $result = json_decode($result,true); return $result;} どうってこともない、cURLを使ってSleepy.Mongooseにリクエスト するだけの簡単なおしごと Page : 32
    • Fromメソッドの処理 // _persistence()はプロセス内で一回だけPersistence // インスタンスを生成して返すヘルパ(いわゆるgetInstence) $p = _persistence(); // fromメソッドはnew QueryBuilder(‚collection‛)を返す $builder = $p->from(‚collection‛); // cBy,skipなどのメソッドは設定が加わった$thisを返す $builder = $builder->cBy(‚‛,‛‛); $builder = $builder-> ->skip(10); // fetch,countは自身に設定されたcriteriaを使い // cURL経由でSleepy.Mongooseにアクセス $builder->fetch(10); 以上はすべて繋げて書けるので前述のコードになる Page : 33
    • 一点だけ注意 元のSleepy.Mongooseはcountに対応していないっぽいです 探し方が悪いだけかもしれない Page : 34
    • 仕方ないのでforkして 自分でcountインターフェイスを追加githubに上げているのでよろしければどうぞhttps://github.com/bibrost/sleepy.mongoose※本体が更新されてたのでマージしないと、、、 Page : 35
    • 4. Q&A Page : 36
    • Q. PHPのMongoDBドライバは使わないの? ・使う可能性がある開発チームの数が多く、 環境の設定をできるだけ減らしたかった ・アプリ側のインフラをいじりたくない ・ポリシー上DBサーバに直接アクセスできない などの理由からSleepy.Mongoose経由にしています。 Page : 37
    • Q. もう本番でもMongoDBでいいのでは? ・Complex Transactionが使えない →有料アイテム購入などで必要 ・MongoDBをメンテできるエンジニアがいない ので本番はMySQL。 Page : 38
    • Q. プロジェクトへの効果は? ・開発者間でDBスキーマを同期させる必要がなく、 Subversion上のソースだけで完結するので 作業のオーバーヘッドが減ったと感じる ※コレクション名、DB名の変更=初期化 ・まだ未知数だが、そもそも複雑なクエリは 書けないのでRDBに移したときも パフォーマンスを出しやすいのではと期待 Page : 39
    • 5. MongoDB活用のセオリー Page : 40
    • ここ数ヶ月MongoDBを使ってきた経験をもとに、 僕なりの活用セオリーをまとめてみました。 これから試してみようかな?という方の 参考になればと思います。 Page : 41
    • 僕が思うMongoDBのサイコーなところ スキーマレス! × なのにクエリが強力! = ストレスフリーなアプリ開発! しかも盛りだくさんなおまけつき! (Sharding, Replica Set, Geo Index and more…) Page : 42
    • 僕が思うMongoDBのサイテーなところ 信頼性なさすぎ Page : 43
    • ようするに 信頼性を犠牲にしても、 開発効率や柔軟性が重視される ケースに活用するとGood プロトタイプ制作だと信頼性なんて二の次どころか不要。 バックエンド系も許容範囲が広げやすい。 フロントなユーザ投稿コンテンツなどクリティカル度低いものに Page : 44
    • 一応擁護しておく 信頼性が全くないわけじゃないです。 が、そこを強化するとパフォーマンス 落ちたり他のソリューションとの 差別化ができなくなってきたりで 深い闇のMongoDBワールドが待っています Page : 45
    • Use case... 用途 適正 理由 高速なCappedCollection、柔軟なスキーマログ解析系 ○ 事例も多く使いやすい 悪くはないが、RedisやMySQL(memcache)などキャッシュ △ 他の選択肢を検討してもよいかとプロトタイプ制作 ○ スキーマレスかつクエリも使えるのでとても便利 信頼性が低いのであまりやらないほうがいいかな。認証系 △ ただし、OpenSocialのように外部に本体があるなら 使ってもいいかも?ゲーム・エンタメ △ 厳密な処理が必要じゃないシステムであればOK 多少のデータロストを許容できるなら強力。コミュニティ・CGM ○ このあたりはデータのプロパティ追加も起きやすく スキーマフリーの力を発揮できる決済系 ××× 考えないほうがいいとおもいます。業務システム ×× 向いてないと思います Page : 46
    • まずはプロトタイプ制作にMongoDBを使うのはオススメ。影響範囲も少なくストレスフリーに 開発ができますよ! Page : 47
    • でストレスのないアプリ開発を 楽しみましょう! Page : 48
    • ありがとうございました。Satoshi Miyauchi @bibrost Page : 49