ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

第15回Solr勉強会 レポート

2014/12/08にグラントウキョウ サウスタワー(会場:株式会社リクルートテクノロジーズ 提供)にて開催された、「第15回Solr勉強会」レポートです。
第15回Solr勉強会 #SolrJP - Lucene/Solr勉強会 #SolrJP | Doorkeeper

スライド資料に無い説明を中心にまとめています。ぜひスライド資料を併せてご覧ください。

【参考】としている個所は私が挿入しています(補足や参考資料など)。発表者の意図したものではありませんので、その旨ご了承ください。

Lucene/Solr Revolution 2014 Report

株式会社ロンウイット 打田 さん

セッションレポート

CareerBuilder は転職支援サイト。

Semantic Search

Semantic Search はバックグラウンドで User Query を Semantically Extended Query に拡張している。例えば、スライドの例ではフレーズを認識し、地名に位置情報を付与している。

フレーズやタギングが増えると重くなる。
⇒『検索クエリからフレーズ抽出&タギング』処理の高速化が肝になる。

Semantic Search Architecture

機械学習によってモデルを作る。

スライドは Keywords の "machine learning" という入力を Modified Query に書き換えるまでの流れを表している。

Q&A

Q.
FSTとは単なる辞書だと考えてよいのか?
A.
FSTは概念もしくは理論。その応用の一つとして辞書への適用がある。
大量のエントリを高速にさばけるのがメリット。

補足

類義語検索と類義語ハイライト

株式会社ロンウイット 阿部 さん

日本語全文検索の検索設定例

検索漏れを防ぐために、形態素解析N-gramフィールドを組み合わせる。

N-gramフィールドだけだと検索ゴミが増えやすい。
形態素解析の重みを増やす。

【参考】
スライドで例示されている、defType=edismax は Extended DisMaxを使うという宣言です。詳細は以下のエントリをご参照ください。
Solrで検索する時にboost値を設定する(Extended DisMax)

AutoGeneratePhraseQueries (AGFQ) はデフォルトがfalse設定。
この属性は検索時にトークナイズされたトークンの順序を意識する。q=会社(1-gramでパース)したときに、AGFQ=falseなら「会社」「社会」がヒットするが、AGFQ=trueなら「会社」のみがヒットする。
日本語ではtrue設定のほうが向いている。

日本語全文検索のハイライト設定例

デフォルトハイライタはハイライトを間違えるが、この問題は修正されていない(LUCENE-1489)。

【参考】
該当のバグチケットです。
[LUCENE-1489] highlighter problem with n-gram tokens - ASF JIRA
コメントを読むと、FVH使えば解決できるから修正を望まない、となったようです。

FastVectorHighlighter (FVH) は正しくハイライトする。ただし、インデックスサイズが大きくなる(1.5倍とか)。

PostingSolrHighlighter はフレーズ単位のハイライティングを未サポート。
⇒コミュニティでも話には挙がっているが…。

SynonymFilterFactoryの設定

FSTSynonymFilter ではFSTを利用している。
Elasticsearch でもFSTを利用している。

【参考】
Elasticsearchが処理速度のためにFSTを採用したと説明しています。
You Complete Me | Elastic

FSTはロードも早いしコンパクト。
ただ、従来と挙動が変わる等、問題が山積みで実際には使えない。
⇒SlowSynonymFilterを使う。

branch_5x

SlowSynonymFilterが削除される!
⇒NGramSynonymTokenizerが解決策となるかも。

Solr at Yahoo! JAPAN

ヤフー株式会社 大須賀 さん

自己紹介

ManifoldCFコミッタ。ManifoldCF は Solr のクローラ。

【参考】
Apache ManifoldCF プロジェクトページ
Apache ManifoldCF™にようこそ!

Yahoo!では検索機能を担当している。

以前の検索サービスの仕組み

独自の全文検索ライブラリを提供していた。Luceneを素で使うのに近いイメージ。

スライドに挙げた問題以外にも、各サービスにエンジニアが分散するという悩みもあった。

ABYSS

Yahoo! Inc.が提供している、BOSS Search API に目を付けた。

現在の検索サービスの仕組み

ABYSSのプラットフォーム上で検索サービスを提供。各サービスはRESTに近いアクセス方法で利用する。

ABYSS再構築

設計当初とは状況が変わった。
・データ増大
・サービスが増えた(マルチテナンシー)

メンバーがいなくなったり、属人化したり。

内部のライブラリでEOLが始まり、バージョンアップしにくくなってきた。

昔であれば検索エンジンを構築する難易度が高かった。でも今ではOSSで公開される時代。自社開発はコストに見合わない。

こうした背景から、検索エンジンの研究は続けるが、ABYSS のコアには Solr を使うという判断をした。

Solr

稼働実績

LuceneEclipse のヘルプに使われている。

Apacheソフトウェア財団管理下

コミュニティが活発。
ASF管理の下、継続したメンテナンスが期待できる。

プラグインでの拡張が容易

Solrはプラグインが組み込みやすい。
Yahoo!独自開発の機能を移植できる。

OSSライセンス

OSSライセンスは明記されていないものが多い。
2年前の調査によれば、50%はライセンス表記がない、30%はソースコード内に書かれている、20%はライセンスファイルがある、という結果が出ている。

【参考】

A casual survey of the projects on GitHub by a specialized analyst revealed that as many as half include no easily identifiable copyright licensing information. About 30 percent include some sort of licensing information in the source files, and around 20 percent have a clear license or notice file that makes it obvious under what terms the code is made available.

GitHub needs to take open source seriously | InfoWorld

Solr はライセンスが明確なため、プロダクトへ取り込みやすい。

アーキテクチャ

Solr の GUI は利用せず、独自にクラスタの管理画面を用意した。

OpenStack で IaaS を提供している。

Log Indexes と Banana の組み合わせでログを可視化している。
Banana は Kibana を Solr 向けにポートフォワーディングしている。

サービスは Feed/Search API を介してアクセスする。

クエリや0件マッチの情報は Admin UI で確認できる。

WebMA

トークンを意味のある区切りにする。

類義語の展開や漢字違いもサポートする。

現在も解析器のメンテナンスを継続して行っている。

SPDYプロトコルサポート

通常、Solr の通信はHTTPプロトコル
SPDYプロトコルに対応したところ、17%の速度改善がみられた。

テストに利用したJetty9はパッチを当てたバージョンを利用している。

今後の計画

Machine-Learned Ranking (MLR) は機械学習結果を検索ランクに反映させる。

コントリビューション

SPDYプロトコルサポートをパッチとして送った!(SOLR-6699)

徹底比較!! Heliosearch vs Solr

デジタル・インフォメーション・テクノロジー株式会社 海老澤 さん

Heliosearchとは

2014年1月に公開された。

フィルタキャッシュをネイティブメモリに移している。

フィルタクエリをバイトコード化して高速化を図った。

検証方法

Heliosearch 0.08 は Solr 4.10.2 をベースとしている。
よって、今回の比較対象とした。

Web側から一定の QPS をかけた。

検証結果

CPU, QTime, GC負荷のいずれも Solr と変わらなかった。

ファセット処理の高速化

スライド中の QTime は実際の値ではなく、割合で表している。
Solr と Helio の差は誤差の範囲。

GC負荷の軽減

Solr と比べて Helio はヒープ使用サイズが小さい。
だが、GC実行時間は誤差の範囲。スライドのBサイトでは-9%という結果になったが、0.03秒の短縮と考えると、効果は少ない。

Helioserchを使ってみて

"facet.offset" のパラメータチェックがないため、負数指定でJVMがクラッシュする。
異常系ではあるが、要注意。

スライドで示したようなログの仕様変更は高速化のためかもしれない。

Amazon CloudSearch Deep Dive

アマゾンデータサービスジャパン株式会社 篠原 さん

Amazon CloudSearch Overview

AWSの Multi Availability-Zone の恩恵を受けられる。

TF-IDF で算出したスコアでソート可能。

カスタマ評価で重み付けすることも可能。

Amazon CloudSearch Update

大量のインデクシング処理の前にパーティション数を増やすことが可能。

Identity and Access Management (IAM) との連携強化により、間違って本番データを消してしまった…のような事故を防ぐことができる。

Inside Amazon CloudSearch

検索アクセス増加にはレプリケーションで対応する。

スケールアップでまかなえなくなったら、EMRでインデックスを分割してスケールアウトする。
ただし、Eventual Consistency なモデルなので、スケールアウトしたけどインデックスがない…というケースには要注意。

Q&A

Q.
インデクシングのバッチを実行してから200 OKとなり、クエリを受け付けられるようになるまでにどのぐらいかかるのか?S3を介すことで遅くならないのか?
A.
S3へのアップが実際に問題になることは無い。それより、ノードが追加されてもデータがないことのほうが問題となる(Eventual Consistency)。

資料

登壇者 篠原さんの『Lucene/Solr Revolution 2014 at Washington DC』レポートです。
Lucene/Solr Revolution 2014 at Washington DC

登壇者 打田さんの勉強会レポートです。
moco(beta)'s backup: 第15回Solr勉強会メモ

id:nashcft さんの勉強会レポートです。私がメモしきれなかった内容も含まれていますので、ぜひご参照ください。
第15回Solr勉強会 メモ #SolrJP - nashcft's blog

おまけ

今回の会場である、グラントウキョウサウスタワー 1Fにあったクリスマスツリーです。Suicaのペンギンもいます!