pixiv サイバーエージェント共同勉強会 solr導入記

pixiv Solr 導入記 X

自己紹介
　松宮　孝大（ mattun ）
　プログラムエンジニア
◎ pixiv でかかわっているサービス　　・ pixiv モバイル　　・ pixiv chat 　　・ pixiv の検索全般
を担当しています
Java が好きなんですが pixiv には Java 好きは居ません・・・

目次
Tritonn 使用時の検索の問題点
Solr の検証
pixiv での Solr の最適化
まとめ

Solrを導入する目的 Tritonn による検索に限界があるため検索専用のアプリケーションを模索検索だけで３０台ある台数を減らせればいいなぁモバイルで人気順ソートを実装する

Tritonn時代のマシン構成
アプリケーション
Mysql-Tritton(senna) を使用
マシン構成 ( 自作機 B28) 　 x ３０台
AthlonX2 4850e 2.50GHz (2 コア ) Mem 8G SSD X25(80GB) or C300(64GB)

でのTritonnの問題点

Mysql の全文検索には更新時ロックがかかる
MyISAM のため Replication で更新クエリーがくるとそこでロックがかかってしまう
CPU のコア数でスケールできない
ロックがかかるため CPU が１コア分くらいしか使い切れていない
R-18 など数値のある文字が重い
たとえば６を検索したとき⑥や全角半角の６なども OR 検索し条件が増える揺らぎ補正のため Normalize は Off にできない
MySQL のバージョンをあげることができない
Tritonn が組み込まれたバージョンを使用しなければならないため Mysql5.1 などにアップグレードできなかった

何かの検索文字 R-18
東方 ( はいてない OR 穿いてない OR はいてません OR 穿いてません OR ノーパン )
( 髪 OR かみ )( ほどき OR ほどく OR ほどけ OR ほどい OR ほどいた OR ほどいて OR ほどこう OR ほどかせ OR ほどかれ OR 解き OR 解く OR 解け OR 解い OR 解いた解いて OR 解こう OR 解かせ OR 解かせ OR 解かれ OR おろす OR おろし OR おろした OR おろして OR おろそう OR おろさせ OR おろされ OR 下ろす OR 下ろし OR 下ろした OR 下ろして OR 下ろそう OR 下ろさせ OR 下ろされ )
いろいろ重い検索条件を載せたかったのですがエロワードばかりなので自主規制・・・

これはやばい！よし！Solrだ！現在でも捌けないのに人気順ソートをモバイルに実装する必要がでてくる・・・

Solrの特徴

参照・更新ロックがかからない
レプリケーションが単純なファイル転送
Master が持っているファイルをスレーブにコピーするだけ内部で rsync と同じようなことをしているだけ
スレーブの追加が簡単
設定ファイルを書くだけで起動すれば勝手に転送される Master と同じインデックスファイルをもらうだけ
分散検索ができる
Normalize や形態素解析や NGram など目的に合わせたカスタマイズが可能

Commit が重い
　 Solr はドキュメントを追加した後に Commit を行って初めてデータが反映される ( トランザクションに近い？ ) 　　その Commit が結構な負荷のため１件ずつリアルタイムで更新せず溜め込んだデータをバッチで一気に処理する　 pixiv では更新されたイラスト情報を Mysql のトリガーでログテーブルに保存しそのログを元に Scala で差分更新処理をしている
Commit のタイミングでキャッシュが消える
　頻繁に更新するとクエリーキャッシュの意味を余り成さない
PHP や Ruby にシリアライズされた結果を返してくれる
　他にも XML や JSON などあり

Solr3.2.0を使用
Solr の設定
tokenizer : NGramTokenizer 　指定された文字数で分割する
filter : LowerCaseFilter 大文字英字を小文字に変換
charfilter : MappingCharFilterFactory 後ほど説明
データ構造
uniqueKey: illust_id
その他検索に必要なタグ、タイトル、コメント、作品が R18 かどうかなど
illust_id 以外はインデックスのみでデータを持たない

Solr検証時の問題点

文字が長いと途中から検索できない・・・ NGramTokenizer という Solr 標準の Tokenizer を使用してたのですがコードを読んでみると最大値がなぜか 1024 文字固定になっていたため可変に修正 solr-3.2.0/lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/ngram/NGramTokenizer.java 修正前コード char[] chars = new char[1024]; input.read(chars); inStr = new String(chars).trim(); 修正後コード CharArrayWriter writer = new CharArrayWriter(1024); int c; while((c = input.read()) != -1) { writer.write(c); } inStr = new String(writer.toCharArray()).trim();

MultiValueを使うと検索結果がおかしい unigram で２文字以上の検索ワードを投げるとタグがくっついた形ヒットする例えばタグに [ オリジナル ] [ パン ] というタグがあったとして「ルパン」と検索すると・・・ [ オリジナル ] [ パン ] という様に分かれているタグが引っかかってしまう対処法が分からなかったため検索ワードの文字数によって unigram と bigram のインデックスを使い分けて対処したオリジナル猫の検索例　　 tag_bigram: オリジナル OR tag_unigram: 猫

半角カタカナ文字にヒットしない半角カタカナを全角カタカナでヒットさせるには自前で設定をしなければならない (NGramTokenizer を使用する場合 ) その場合 MappingCharFilterFactory というフィルターを使って Normalize することができる設定例 " ｶﾞ "=>" ガ " " ｷﾞ "=>" ギ " pixiv では「へ」はどちらでもヒットするように設定 " へ "=>" ヘ " " べ "=>" ベ " " ぺ "=>" ペ "

大量の件数がある場合ソートが重い全体で１２００万件の内 [ 東方 ] というタグには１００万件以上ありソートだけで１ .5 秒くらいかかっている１秒以上かかるものがある時点で検索を捌くことは不可能データ更新は１分間隔でしていたのでキャッシュの恩威が少ないちなみにソートをしなければ一瞬で検索できる

じゃあ高速化しましょう！

高速化１ Solr には DistributedSearch という分散インデックス検索ができるのでインデックスを分散する４分割 ( イラスト ID%4 の余りが番号 ) して各マシンに１つずつインデックスを持てば検索速度が４倍早くなるこの機能は検索時にインデックスを持っているサーバーをパラメータで渡すだけでいいのでクライアント側の修正は簡単である例 q= 東方 &shareds=localhost:8983/solr/index0,localhost:8983/solr/index1

※ 補足左に行くほど新しい全体のインデックス４分割されたイラストのインデックス１つのイラストをイメージ index1 index2 index3 index4

すべてのインデックスから１０件分 ( ４分割なので４０件分 ) の「東方」の結果を受け取るクライアント「東方」を検索するその中で１０件分の結果が返る分散検索のイメージ図４つのインデックスに投げる Solr1 index1 Solr3 index3 Solr2 index2 Solr4 index4 DistributedSearcher

高速化１の結果
速度的には４分割するだけでかなりの高速化になった
[ 東方 ] で 1.5 秒だったものが 0.4 秒くらいへ
それでも想定のマシン数では捌ききれない！

高速化２
先ほどの４分割されたインデックスを古い日付のインデックスと見なし、新しい日付のイラスト（１５万件）だけのインデックスを作り実質５分割にした
新しい日付イラストは１分間隔で差分更新する
古い日付のイラストは１時間隔で差分更新する
キャッシュの量を大量に設定
１０万件以降のページングはキャッシュしない　　 <queryResultMaxDocsCached>100000</queryResultMaxDocsCached> 　　一度の検索で２万件のキャッシュを保持しておく <queryResultWindowSize>20000</queryResultWindowSize>

全体のインデックス古い日付のイラストのインデックス最新の日付のイラスト１分更新 index1 index2 index3 index4 Index_new

高速化２の結果超高速化された！古い日付のイラストには Solr にあるクエリーキャッシュで返せる（キャッシュヒット率 79 ％）新しいイラストは件数が１５万件なのでまったく重くない
問題点として古い日付のイラストのインデックスと最新の日付のインデックスに同じデータが被ってしまうと件数に不整合が起こるのでデータが被らないように調整する

最新の日付のインデックスと古い日付のインデックスが被らないようにする全体のインデックス最新の日付のイラスト Index_new 古い日付のイラストのインデックス index1 index2 index3 index4

最終的にどれだけ高速化されたか？
実質常にクエリーキャッシュが効いているため件数の多い [ 東方 ] でも 1.5 秒 -> 0.04 ～ 0.1 秒などになった
Tritonn では３０台で捌けなかったものが６台で余裕となった
QPS 的に言うと Solr のステータスでは 200 / qps と出ている

まとめ
普通に使うだけでも Tritonn より早い
分散サーチ機能がついているためスケールが簡単にできる。
過去のデータや不変なデータを別のインデックスに持つようにし更新頻度を抑えればキャッシュのヒット率が大幅にあがる
常に大量の更新がある場合はバッチ処理が必須

ご清聴ありがとうございました

http://logmania.masakiplus.net	1087
http://ameblo.jp	968
http://webcache.googleusercontent.com	15
http://s.ameblo.jp	12
http://twitter.com	8
http://feeds.feedburner.com	5
http://slide.yoshiday.net	3
http://s.deeeki.com	2
http://trunkly.com	1
http://a0.twimg.com	1
http://feedblog.ameba.jp	1
https://twitter.com	1

pixiv サイバーエージェント共同勉強会 solr導入記

by Takahiro Matsumiya

Accessibility

Upload Details

Usage Rights

12 Embeds 2,104

Statistics

pixiv サイバーエージェント共同勉強会 solr導入記 Presentation Transcript