2012年11月27日

第9回Solr勉強会に行ってきた #SolrJP

第9回Solr勉強会 に行ってきました。 日本語解析の話、Web サービスにおける運用の話がメインでした。 実サービスでしっかりと利用されているんだなぁ、と実感できる勉強会でした。

まとめ、レポートなど。相変わらず早いですね。

Who we are, what we do, and a little bit about Kuromoji

Atilika Inc. の Christian Moenさん

Atilika のコアは search engine, big data analysis, NLP の３本立て。 製品を開発してコンサルティングもやるっぽい。customer-driven innovation と称するモデル。

kuromoji は、solr の example の schema.xml では "text_ja" で定義されている。 Solr 3.6 からは標準搭載なのですぐに使い始められる。 JapaneseTokenizer から始まり、日本語用のフィルターチェインを構成している。

<analyzer> を抜粋

<tokenizer class="solr.JapaneseTokenizerFactory" mode="search"/>
<filter class="solr.JapaneseBaseFormFilterFactory"/>
<filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt" enablePositionIncrements="true"/>
<filter class="solr.CJKWidthFilterFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt" enablePositionIncrements="true" />
<filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/>
<filter class="solr.LowerCaseFilterFactory"/>

「空港」は「airport」でも検索したい。日英に対応するとき、compound nouns が必要になる。 関西国際空港は「関西」「国際」「空港」に分割できる。空港と Airport の対応付けが必要になる。

kuromoji にはカスタム辞書も定義できる。フラットなファイルで重み付けもない。

ongoing work:

  • improve compound segmentation
  • explore improving unknown word segmentation
  • add additional dictionary support (NAIST-JDIC, UniDic)
  • other improvements

「踊り字」への対応も検討している。馬鹿々々しい ⇒ 馬鹿馬鹿しい や、ところどころ、ミスズ、など。

Japanese numbers (漢数字) の最初のパッチは LUCENE-3922 (Add Japanese Kanji number normalization to Kuromoji) に添付した。まだまだ改善が必要。 円マークが後ろに付いても前に付いてもノーマライズしたい。

Japanese spellchecker/suggester も実装している。

最後に、これは読んでおいた方が良い、という記事を紹介。

[感想など] kuromoji のことを初めて聞いたときは、なんで外国人が日本語の形態素解析を？と思いましたが、 今は Lucene プロジェクトの一部として寄贈されており、素晴らしい貢献で頭が上がりません。 ちょっとした形態素解析としては十分な機能だと思いますが、漢数字のノーマライズも視野に入れており、まだまだ改善が見込める kuromoji。 LUCENE-3922 は目を通しておこうと思いました。

Solr@ニコニコ生放送

株式会社ドワンゴの吉村総一郎さん (@sifue)

ニコ生の Solr 担当者が入れ替わり退職していた。 元々は MySQL+senna で運用していたが、Solr にリプレイスした。 要件としては放送開始後１分以内にヒットすること。以前は Google の方が早かった。 １年くらいかけて少しずつ移行。未だに完全移行にはいたっていない。 移行するときは「ユーザーの検索クエリを そのまま 引き継げる」ように気をつけている。

運用としては、master/slave 構成で jetty-7.5 で立ち上げている。 リプリケーションは Solr の機能を利用。元々は分散インデクスも検討していたらしいが、本運用に乗せるまでは至らず。 過去の全ての公式番組の番組情報と、１週間でできる７０万番組の番組情報を扱っている。 今は１億を超える番組があるらしい。 来場者数、コメント数でソートする機能が必要になる。こららのデータは更新頻度が高い。

トークナイザーは CJKTokenizerFactory をそのまま利用している。 N-gram はスラングなどには有効なので形態素解析は入れてない、のではないか。前任者がいないので不明。 FF とか DQ にバージョン込みで検索された場合に弱い。FF1 で検索して FF13 とかがヒットすると嬉しくない。 /select はピーク時で 40QPS 程度。 /update は 80QPS くらい。 １番組のテキスト量自体はそんなに多くない。せいぜい5000文字程度。 ユーザーが作っているツールの影響で一時的に負荷が上昇することがあるらしい。

開発環境構築の話。 Jetty のマルチテナント機能を利用した単一 Jetty サーバを構築する。

サービスの今後としては、英語、台湾語のサイトの立ち上げも計画している、とのこと。 Solr には言語判定 (language detection) の機能が 3.5 から導入されている。

[感想など] 担当者が入れ替わってしまい過去の経緯が分からない、という件はフムフムと同感でした。 ほどほどに人の入れ替えがあると、どうしても平均勤続年数よりもソフトウェアの寿命の方が長くなります。 きちんとしたドキュメントでなくとも、なんらかの過去ログとして掘り起こせる状態にしておくことは意味があるんだなぁとか。。。 Jetty のマルチテナント機能を知りませんでしたので、こちらのドキュメントを参考にして試しておこうと思いました。

ドリルダウン色々

株式会社 マーズフラッグ の柳吾朗さん (@hitode7456)

ドリルダウンの比較と、そのデータをどうやってレンダリングするか？という考察。

  • 実直型
  • 少し工夫
  • Pivit Facet

Solr では Facet + Filter Query の組み合わせが一般的。

検索コスト、データ加工、柔軟性の３点で評価。 多段のドリルダウンを実現するときに便利。 事情があって 4.0 を導入できない環境ではタブ区切りなどで対処するのも一つの手。

Pivot Facets に関してはこの辺り。Solr 4.0 から利用可能。

[感想など] Solr 4.0 の環境では Pivot Facet を使えますので、これから Solr を導入する場合は課題とはなりませんが、 既存の (Solr 1.x, Solr 3.x) 環境に適用するときの工夫として丁寧で分かりやすい説明でした。 なお、ファセット検索は Yonik さん (Solr の作者) の記事も分かりやすいのでオススメです。

SolrとElasticsearchの比較

兼山元太さん (@penguinana_)

cookpad では Solr 4.0 を使っている。

livedoor グルメのデータを使ったサンプルの実装 ⇒ https://github.com/penguinco/ld_gourmet_search

  • livedoor グルメの DataSet を公開 - livedoor Techブログ
    • データはCSV で提供
    • 定期アップデートはされません。
    • 2011年4月22日の時点のデータのみとなります

ElasticSearch は Kuromoji をプラグインで利用できるらしい。 これを使うと「神泉」が分割されない。 (素の状態だと「神」と「泉」に分割されてしまう)

ElasticSearch はプラグインでいろいろとインストールできるようで、管理画面もプラグインで導入する。 導入に当たってはこのガイドが分かりやすいらしい。 ⇒ http://www.elasticsearch.org/guide/

その他に Elasticsearch の嬉しいところいくつか：

  • レプリケーションが簡単 (もともと「分散」を実現するためのアーキテクチャだから)
  • 設定をアプリケーション側で管理できる。
  • 必要なツールは curl だけ。XML ファイルを扱う必要がない。
  • リプリカ数の管理や同期／非同期の選択もできる。

Solr に比べてマシンが複数あっても設定の管理が簡単そうなので、新規導入で Solr と Elasticsearch を比較するなら Elasticsearch もアリ。 ただし、既存の Solr がある程度の運用に乗っている場合は、あえて乗り換えるほどには動機が弱いかな、という状況。

ログはどうなるんだろうか？という質問があり、マシンごとに取り出せたりするのかが実運用する上での課題になるのかも。

[感想など] Solr/Elasticsearch のどちらも関係ありませんが、livedoor グルメのダウンロード用データが公開されていたことが一番の驚きでした。 「再現性のあるまとまったサンプルデータ」としては非常に重宝しそうです。 実際にデモアプリを実装しているのは見習わなくてはと思いました。 Elasticsearch 自体の説明としては、Sematext の比較記事もオススメです。 全部で５部構成で、現在は第４部まで書かれています。

終わりに

日本語解析の話、Web サービスにおける運用の話がメインでした。 実サービスでしっかりと利用されているんだなぁ、と実感できる勉強会でした。 また、自分自身としては最近は Solr を触ってないなぁと反省. . .

いつもいつも、運営してくださる方々には感謝です。

ラベル: , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)