20121126 Solr@ニコニコ生放送

  • 1,191 views
Uploaded on

第9回Solr勉強会 …

第9回Solr勉強会
http://atnd.org/events/33718
で発表した内容

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,191
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
10
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Solr@ニコニコ生放送株式会社ドワンゴ 吉村総一郎(@sifue)
  • 2. ニコニコ生放送とは
  • 3. 2007年12月にニコニコ動画に追加されたライブストリーミングサービス動画に流れるコメントをつけられる公式放送、チャンネル放送、ユーザー生放送があり、一日に約10万番組(大体30分枠)が放送中
  • 4. 10/17にバージョンQをリリース(ニコ生のトップはひどい叩かれようだった...)要求の高いユーザー、ニコ厨(ヘビーユーザ)と生主(生放送者)が独自の文化感を醸成自分も生主の一人
  • 5. 自己紹介
  • 6. 吉村 総一郎 (@SIFUE)twitter、github、はてなのidはsifue2012年4月ドワンゴ入社 (担当:検索、tweetまとめ、Qトップの一部)前職では製造業向けシステムのサーバーサイド等やってきた順: Jackrabbit→Lucene→Solr(600GBのMSOfficeファイルとか)→ニコ生のSolr
  • 7. ニコ生のSolr担当者が入れ替わり退職していた...その方をtwitterでfollowすることからスタート今日の話は、後で資料や環境を調べたりIRCログから発掘して判明した情報です☆(ゝω・)vキャピ
  • 8. ニコニコ生放送における要件
  • 9. 元々MySQL + Sennaだった問題として、検索精度、レスポンス、各種ソートがない、などがあった (残念ながら当時はGoogleの方が...)要件は放送開始後1分以内にひっかかること とにかく高速なインデックス更新が必要だいたい1年ぐらいかけて少しずつ移行 (%, 部分)
  • 10. 機能 キーワード検索 マイナス, AND, OR検索 放送中、放送予定、放送終 了での区分け タグ検索、タグ絞込み コミュニティ毎のグループ化 各種ソート 放送日時範囲指定
  • 11. 構成 Master (write-only) 2core 8G mem SolrReplication Slave (read-only) Slave (read-only)モジュール: Solr/Lucene3.4.0, jetty-7.5.0.v20110901マスター(1台 - 更新のみ) - スレーブ(2台)構成 リプリケーションはSolrの機能を利用 この構成は、スレーブ格上げ・追加がやりやすく可用性高い 元々は分散インデクスを実装していたが、ボトルネックがDBから のデータ収集にあったことや、不具合で断念
  • 12. インデックス対象 ✕ 700,000過去の全ての公式番組の番組情報と1週間でできる70万番組の番組情報 (更新は多いが全量は少ない)1番組あたり1kb∼10kb程度のテキストを持つ更新頻度の高い情報に「来場者数」と「コメント数」がある
  • 13. インデックス作成タイミング DB DB … batch(PHP) Solr AP Redis AP … 基本はバッチ処理で作成。 大量の番組更新・削除情報はWebサーバー(AP)か ら情報を一旦Redisに積んでそれを利用。
  • 14. アナライザトーカナイザはインデックス更新速度優先で、solr.CJKTokenizerFactoryをそのまま利用フィルタは、solr.HTMLStripCharFilterFactoryとお手製の正規化フィルタのみ無論Bi-gramなので、「FF」とか「DQ」に弱い。そこはタグ情報を付加してしのいでいる
  • 15. 1日のSELECTリクエスト 分刻みピーク時で40QPS程度 (iPhone, Android等含む)スレーブ2台の2コア割当でロードアベレージは、ピーク時で8程度でなんとかなんとか
  • 16. 1日のUPDATEリクエスト分刻みピーク時は80QPSの更新 (番組作成・更新・削除)1番組のテキストが多くて5000文字程度で小さいマスターのロードアベレージはピークでも0.2程度で余裕あり
  • 17. 簡単に今のパフォーマンスを紹介しましたが、実はここに至るまで壮絶な失敗があったようでした... 自作分散インデクシングが高負荷状態でCPU100%にな ったり、メモリリークしたり 特定のテキストでお手製Filterが無限ループ ボット・クローラー対策結局最後は、非常にシンプルな構成に→これがいいのかも
  • 18. 開発環境用意のための工夫
  • 19. Developer DB jar/war Hot deploy Request Developer DBMulti tenancy Sinatra(Ruby) Developer DB Solr Solr Solr Solr Create overlay.xml Developer DB Solr Solr Solr … … Jettyのマルチテナント機能を利用した単一Jettyサーバーへの30近 いsolr環境構築 検索はDBと結合してるので、個人の開発DBの数だけ環境用意 が大変、仮想イメージ配るのも大変、Jetty立てまくりも大変 リクエスト送ると自動でインスタンスを作るサーバーを作って マルチテナントを用意。jarの更新も1箇所でOK。
  • 20. 今後インデックス作成のCPUに余裕があるのでkuromojiやgosenを使った形態素解析に移行したい...が。台湾語や英語サイトも立ち上がっておりこういうのどうしてるのか聞きたい。(単漢字とか。)データ収集の方にボトルネックがあるのでむしろそちら側の改善をやっていく予定。
  • 21. 以上ご清聴ありがとうございました
  • 22. 質疑応答