■[event][Solr]Solr勉強会行ってきた。

21日にECナビさんで開催されたSolr（そーら）勉強会に参加してきました。

http://atnd.org/events/937

Luceneを1、2年前ぐらいに触っていて、そのときSolrも調査したことがあったので、その頃からどのように変わったのか楽しみにしていきました。

以下発表内容のまとめです。

Solrとは？（ロンウィット関口さん）

• 全文検索ライブラリのLucene
  • JavaのAPIを使うので、開発期間の短くなっている昨今では導入の敷居が高い
• SolrはLuceneを使った検索サーバ実装
  • HTTPベースのAPIが提供されている→言語を選ばない
  • 検索アプリが非常に楽に作成可能→時代に合っている
• Solrとのデータやりとり
  • XMLで登録データを作成（CSVでも可）→HTTPでPOSTすると登録が完了
  • 検索結果もXMLでGETする
  • 検索アプリでは、XMLで返ってきた結果を加工してHTMLに変換して表示する
• 多彩なナビゲーション機能
  • ハイライト機能、ファセット機能など
  • ファセットを使うと検索結果からジャンルなどで絞込み可能なナビゲーションを実現可能
• キャッシュ機能
  • documentCache … ドキュメントをキャッシュしてIOなしで結果を返す
  • filterCache … ファセット利用のためのキャッシュ
  • queryResultCache … クエリ結果をキャッシュしてIOなしで結果を返す
  • Luceneでは難しいキャッシュのウォームアップを実現→インデックス更新時に遅くならない
• インデックスレプリケーション
  • マスター・スレーブ構成のレプリケーションが可能
• 分散検索
  • インデックスを分散して配置して横断的に検索可能
• ApacheライセンスのOSS ＋ LuceneもSolrも機能拡張を前提としたインターフェース（API）＋ 活発なコミュニティ

「関口宏司のLuceneブログ」の方です。

質疑応答でSolrの次バージョンである1.4リリース日について質問がありました。Lucene 2.9のリリースが先なので、9月ぐらいに出るといいなあ、とのことでした。

その他、CJKAnalyzerやHilighterのバグについての質問がありました。

事例紹介

商品検索でのSolrの利用（ECナビ春山さん）

• ECナビでの利用
  • 商品検索、Buzzurlなど
  • 去年の7月ぐらいから使い始めた
• ECナビ商品検索での利用状況
  • 登録件数2300万件
  • クエリ数最大100万/日
  • 元のデータサイズ10G
  • インデックスサイズ18G
• 利用しているSolrの機能
  • DistributedSearch(分散検索)
  • rsyncでのレプリケーション
  • ファセット
  • 独自Tokenizer
  • 元データはMySQLに格納
  • インデックス作成用SolrにMySQLからCSVでインデクシング
  • 検索用マシンにrsyncでレプリケート（一日一回）
  • 2台ずつの検索用マシンでユーザ用とロボット用に
  • 3分の1に分割して一台の中で分散検索
• スペック
  • インデックス用 … メモリ4G、RAIDなし
  • 検索用メモリ … メモリ18G、RAID0+1
• バージョン
  • Solr 1.3
  • Java 6
  • Tomcat 6
• （ECNaviTokenizer）
  • つのだ☆ひろのように星があってもなくても同じトークンを
  • ハイフンの表記ゆれに対応(cyber-shot→cyber shot cybersyot)
  • 半角カナを全角カナに正規化

質疑応答でインデックスを3つに分割して分散検索していることについて質問がありました。試験的にやってみたが微妙で、まだベストプラクティスを模索中とのことです。

プロキシを使ってインデックス更新中は軽いほうに処理が向くようにしているらしいです。

Solr+SSDについてもLTする予定でしたが、マシントラブルで聞けなかったので次回に期待です。

Solr導入事例＠リクルート(リクルート植野さん)

• 社内事業を横断してSolrでの開発支援を仕事に
• 某事例でのSolr利用状況
  • 25〜280 QPS（5台運用）
  • ドキュメント数250万件
  • 10分間隔で差分更新
  • ファセットも一部で利用
• 信頼性の担保
  • 冗長化で5台以上
  • ロードバランシング
  • 更新は全台同時投入
  • 小規模な場合は相乗りも
• 誰でも使えるように
  • 自社Solrクライアント、スキーマ定義にワークシート、DynamicField活用
  • Solrサーバ上での作業を極力0に
  • S2JDBCのJDBCManagerに習ってSolrManagerを→流れるようなインターフェースを実現
  • Solrの学習コスト低減、実装方法の統一、冗長化実装の隠蔽
• Solrの拡張
  • mecabとN-gram
  • 拡張はpluginとして展開→solr.warに手を加えずpluginとしてjarに
• 今後の展開
  • SolrのUIライブラリの展開→利用者にわかりやすいSolrの伝え方
  • ほぼリアルタイムな検索
  • ×それSolrでできるよ。→○Solrじゃないと大変だよ？

質疑応答での、Solrクライアントを用意したことで全くSolrを意識せずにDBと同じように使うようになって、結果としてSolr利用のナレッジが蓄積されないという話が印象的でした。

Solrの拡張性をうまく生かして利用されているように思いました。

冗長化した事例は初めて聞いたので興味深かったです。

MapionにおけるSolr状況（マピオン*1）

• 利用方法
  • フリーワード検索
  • ファセット検索（ジャンル）
  • 地図から緯度経度からの検索
• Solr導入経緯
  • マピオン電話帳で当初MySQL5.0 + Sennaを利用
  • データ数900万件でチューニングしても負荷が高い
  • Solr1.3リリース→1ヶ月調査→導入
• 利用状況
  • 1日約100万クエリ
  • 範囲検索30％、キーワード検索70％
• データ件数
  • 電話帳900万件(Shard 30)
  • ランドマーク40万件(Shard 4)
• データ更新
  • 電話帳は差分更新で1日2回
  • そのほかは更新頻度に応じて全件更新
• サーバ構成
  • インデックス作成用サーバ1台
  • 検索サーバ8台
  • Shards用3台(検索結果をマージするサーバ？)
  • 元データはRDBMSに
  • Shardsと検索用Solrサーバの間でロードバランシング
• 緯度経度検索
  • 拡張コンポーネントとして実装
  • 距離計算をして出すのに負荷が高いので8台使用
• 検索の拡張
  • 2Box検索（q=キーワード&near=場所）
  • 1Box検索（キーワード 場所）
  • どちらも場所をジオコーディングして内部的に拡張コンポーネントに検索方法を切り替え
• 1ホストあたりの最大コネクション数を修正してJavaの起動オプションで制御可能に

検索での地名の判定について質問がありました。裏側でマピオン独自の住所エンジンで位置的なクエリかどうか判別して緯度経度を付与しているそうです。

先ほどのリクルートでもジオコーディングのコンポーネントを作っていたので、Solrがそういう検索に利用されているというのは意外でした。

LT

Yahoo！Japanにおけるジオコーダの実装の紹介（ヤフー西岡さん）

• Solrのではなくジオコーダについて
• 前処理
  • 同義語クエリーの書き換え
    • 通称名問題（渋谷公会堂→CCレモンホール、ヤフードーム→福岡ドーム）
    • 業種正規化（いためし→イタリアン、ネカフェ→インターネットカフェ）
  • 表記ゆれ
    • 住所・地名の揺らぎ、異体字など
  • バーストワード対応
    • ある場所に関係する流行のキーワードで検索して対応する場所を出す対応
    • 例：ガンダムなど
  • ローマ字問題(sibuya→渋谷)
    • Yahooの提供しているかな漢字変換APIを使うと便利
• 形態素解析 OR N-gramの利用→0マッチを避ける
• ソート
  • CTRを優先
  • タイトルより業種に一致を優先
  • 完全一致＞形態素＞N-gram
• Yahooでは独自形態素解析を利用

某全裸のアイドルが逮捕された公園をバーストワード対応を行ったらCTRが90%言ったという話が非常に興味深かったです。

EC2とOpenSocialちょっぴりAndoroid（GMOインターネット新里さん）

• 発表資料
• クラウド、リアルな情報を取得可能なデバイス、ソーシャルな情報のAPI提供
• →モバイルを使ったソーシャルネットワークとリアルの融合
• EC2 + OpenSocial(mixi) + Android(GPS情報)
• Android間のやり取りでP2P通信（PIAX）
• Androidからの情報取得やデバッグ、APIの仕様変更など色々問題も

PIAXとno titleを初めて知ったのですが、使うとなかなか面白そうなものが作れそうです。時間があるときに是非試してみたいと思いました。

Solr＠twitter検索（@penguinana）

• 発表資料
• Twitter検索(yats)
  • 3億以上の呟きを収集
  • 日本語ユーザ5500万が検索対象
  • つぶやいて平均60秒ぐらいで検索可能に
  • 50万/月PV
  • 270万リクエスト/月
• Twitter検索の特徴
  • 更新頻度高い
  • 文章短いが件数多い
  • 日付でソート
• インデックス更新の高速化
  • 一日分のデータしか持たない追加専用のSolrを作成し、100秒間隔更新（数秒で更新終了）
  • 1ヶ月分を12時間間隔で更新（数十秒で更新終了）
  • 全体を1ヶ月に一回しか更新（数時間で更新終了）
• キャッシュ
  • キャッシュをオンにして更新
  • ヒット率：五時間後64%→1週間後77%
• 遅いクエリをはじく
  • ページングの後のほう、複雑な条件式、ヒット数が多いものなど
  • 時間がかかるとApacheのプロセスが溜まって落ちる
  • 5秒で返ってこなかったらタイムアウト
• SSDの利用
  • 7倍ぐらい速度向上
  • 静音
  • CPUがボトルネックに

具体的な施策の話が主だったので、個人的には一番参考になりました。

Solrに限らず、結構なデータ数がある検索システムを作る場合でも参考になるのではないかと思います。

全体的な感想

自分の想像していたよりもSolrが一般的になってきている印象を受けました。気に入っているプロダクトなので、今後利用実績や資料がもっと増えることを期待しています。

元データをRDBMSで持っているというパターンが多かったです。個人的にもSolrだけにデータを持たせるのは若干不安を感じますが、2重に持つのは冗長な気もしました。

CJKAnalyzerを使うとN-gramになるのでインデックスサイズがかなり大きくなるというデメリットがあるのですが、結構気にせずに使っている方が多いように思いました。検索漏れのほうが困るので使っている場合もあるかもしれませんが、Javaの形態素解析ライブラリのSenの更新が止まっているのも原因のひとつかも、と思って検索していたらcmecab-javaというライブラリを発見。Solrを使う機会があったら試してみたいです。

他の方の勉強会の記事

• Solr勉強会に行ってきました[solr][ecnavi][mapion][recruit] - d.hatena.zeg.la
• no title

Permalink | コメント(1) | トラックバック(2) | 01:57