yapc::asia 2010 twitter解析サービス
TRANSCRIPT
基本システム構成 • リソース – オリコンランキング情報/RSS/Google Blog Search結果/各種API
• クローラー – LWP::UserAgent/WebService::Simple/XML::Feed
• DB – MySQL
• Webアプリ – DBIx::Class/Catalyst
Twitter解析のポイント • tweetの更新が非常に速い • データ量が多くなりがち
• とにかくtweetを速くどこかへ格納する • 解析する際に非同期で処理をする • 情報のプライオリティを決める
tweetの取得 • Search API と Streaming API の併用
Package Twib::CLI::Reader::Feed; use JSON::XS; use LWP::UserAgent;
Package Twib::CLI::Reader::Stream; use AnyEvent::Twitter::Stream;
#API Reader my $client = Gearman::Client‐>new; $client‐>job_servers(qw|localhost:7003|); $client‐>dispatch_background( "fetch", $json, {} );
#Worker my $worker = Gearman::Worker‐>new; $worker‐>job_servers(qw|localhost:7003|); $worker‐>register_function( "fetch" => \&fetch ); $worker‐>work while 1;
sub fetch { my $job = shift; my $args = $job‐>arg; $fetcher‐>fetch( decode_json($args) ); }
Webページ情報の取得 • 短縮URL – リダレイクト先をみて「展開」させる – tweetされたURL ‒ 展開されたURLのペアをキャッシュ
• 要約HTMLの取得 – HTML::LDRFullFeed by tokuhirom
• RSS Reader で 全文表示するためのXpathを含むwedata
– HTML::ExtractContent • 特徴画像の抽出 – Content-TypeとContent-Lengthを見て判断
扱うデータ Post – comment – url – user_name
Link – url – title – summary – image_url
LinkAttribute – created_on – tweet_count
情報のプライオリティを決める • 少ないリソースでいかに更新が速く大きくなりがちなデータを処理するか
• Twibの場合は「直近のランキング情報」に価値がある
• 優先度の高いデータにリソースをさく • DELETEしてもいいデータを決めておく
LinkAttribute > Link > Post
mongoDBを採用した理由 捨てた理由
• Shardingの容易さ • リソースコントロールが難しい • そもそも物理的に制限がある • 方針を決めて独自のパーティショニングでMySQLを使った方がよい
特化した機能はAPI化させる • 画像API • http://image.twib.jp/counter/http://twib.jp/
• http://image.twib.jp/user/yusukebe – Redirect to : http://a1.twimg.com/profile_images/15300142/profile_childfood_normal.jp
• http://image.twib.jp/favicon?url=http://yusukebe.com/
Twitter解析アプリの可能性 • 一般的なクロール&表示型サービス – SELECT > INSERT/UPDATE
• Twitter解析アプリ – INSERT/UPDATE > SELECT ?
• 更新頻度の高いシステムを個人で作れてしまう