第10回Solr勉強会 at VOYAGE GROUPに行ってきました

ここのところ、業務でSolrを触ってないせいか、っていうか、
↓のブログ書いたの最後カモ的な感じで、
先日リリースされたSolr4.0と話題のSolrCloudを試してみる | shinodogg.com
アンテナ下がり気味で、勉強会があることを直前まで知りませんでした。。
そんなこんなで10分ちょい遅刻くらいで参加させていただきました。
　
■ 1. 株式会社ロンウイット　関口　宏司さん
　　タイトル：Wikipediaからの類義語知識の自動獲得について
　

　
10分くらい遅れて参加。何やら難しい数式が。。
　
精度と再現率の算出→結構人手で。
ウィキペディアの見出し語はそんなに精度が高くない。
　
・結果
　”サンジャポ”とか、”マツケン”も二種類ちゃんと取れるし。”丸ビル”とか。
　⇒ 日本語は発音が長いとすぐ略されてしまうのが分かる。
　
・失敗も当然ある。
　”スマホ”は抽出できたけど”スマフォ”はできない。
　”マンU”や”のりピー”も抽出できず。
　Mr.Childrenはアルファベットなのでミスチル抽出できず。

・日本語は類義語が多い⇒日本語検索では類義語対応必須。

・Lucene4.0はNLPやるのに向いてる。
　
・類似度を算出するときのフィルターみたいのは？
　パラメーターをいじれるようにしたけど、そんなにバリエーション試してない。
　一回走らせると三時間かかるので、、関口さんもお忙しい…。
　
・今日の発表で使ったソースの公開は？
　出版物として↓の本に寄稿したので(英語ですが)そちらに大体ソースが載る。
　＃関口さんにお金が落ちないらしいけど。。

Apache Solr入門の関口宏司さんが寄稿されているそうです！ / Check out Lucene and Solr: The Definitive Guide http://t.co/EjnbGNBWia via @oreillymedia

— Eiji Shinohara @ アルゴリア 🗾 (@shinodogg) March 26, 2013

　
　
■ 2. グリー株式会社　尾形　暢俊さん
　　タイトル：GREEにおける全文検索の歴史
　

　
GREEの検索の話。あんまり今まで検索に重きを置いてこなかった。
尾形さんは今は検索担当ではないが、以前担当だった頃は一人で面倒みていた。
現在担当の方も一人で検索を担当されているそうです。
　
・今までの変遷
　2007年頃にSenna。不安定。再起動。
　2009年までTritonn。MySQLの新しいのにについてくのが辛い。
　2012年までLucene+Tomcatで。フラグメントとオプティマイズ。サービスアウトしてホゲホゲ。
　　　　　　　クライアントが何千台。。全部を書き換えて、、丸一日がかりのスゲー作業
　
・現在はSolr化
　ほぼメンテフリー
　SPoFフリー
　Luceneのバージョン古かったので検索性能がとてもよくなった。
　導入時にまだSolrCloudはなかったのでちょいちょい工夫。

・下位互換の維持は必須。
　元々Lucene+Tomcatでgetで。xml返すようにしていた。
　⇒Solrもここを変えないように。

・検索サーバーは四十何台。
　アプリからはキューに投げる
　インデクサがキューからデータ取ってマスタにインデクシング
　レプリケーションで。
　全てが複数台で冗長性を確保。
　250qpsとか。
　マルチコアとかうまいこと使えば抑えられそうだけど、言えばサーバー増強してもらえる。。
　7スキーマ。ほとんど使われてないのもある。1日2アクセスとか。。
　
・Rangeクエリが重い。
　GREEに新規登録した人向けのスパム対策。登録してから一定時間経たないとダメよ。
　レンジクエリするなら時間置いてからインデクシングすれば？
　⇒キューにそんなに長く入れとくのは。。
　
・インデクサーはマスターにラウンドロビンで分散。マルチスレッドで。
　
・青少年なんちゃらとかで人力監視が必要だったり。。
　cronでシェル叩いてsshとかsolrpingとか。
　
・スキーマ変更を無停止でやるのが大変。
　スレーブをマスタに昇格とか。この辺は今後自動化したい。
　
・辞書を使ってないので精度が高くない。バイグラムで。
　ただ、多言語考えると辞書と形態素解析とかってアラビア語とかだとどーなの？的な。
　
・ユーザーデータがマスタ三つにそれぞれ80ギガくらい。
　
↓発表資料

x.com

　
　
■ 3. ソフトバンクBB株式会社　野口　勝義さん
　　タイトル：企業内の大規模ファイルサーバ検索事例
　

　
SoftBankBBで検索システムの企画、開発。
今後はスプリント、ウィルコム、イーモバとかも？？

今回は社内のファイルサーバーの検索の話。
検索をクラウドサービスのオプションとかに出来ないか？とかってのが検索をはじめた感じ。
ManifoldCFっていうクローラーとSolrの組み合わせ。
　
・なぜSolr？
OSS。ネット上に情報も多いし、コミュニティもしっかりしてそう。

・なぜMCF？
　自前でクローラ作ってたたけど、ファイルクロールもWebクロールもやってくれるし。
　アクティブディレクトリフレンドリー。
　
・極秘ファイルとかあるからユーザーのアクセス権をちゃんとみてる。
　
・社内のファイルポータルサービスを作りたい
　⇒全部で何ファイルとかわからないｗ
　　ユーザー1万人。ファイルは全部で70テラ。7000万ファイル…。
　
・いきなりはキツイからドッグフーディング。3TB, 500万ファイル。

・ファイルサーバーは9台。MCFはPostgreSQL推奨だけどMySQLで。

　
・複数ジョブで一つのインスタンスに同時更新できない。
　Solrのコア、クロールジョブ、ファイルサーバーを一対一対一
　9台なので9個の構成
　
・MCFでタイムアウトしたり、Solrがインデクシングしてる間にApacheがタイムアウトしちゃったり…
　mp4とかインデクシングするとSolr4.0だと落ちたり。既知の問題でjarファイル足せば解決するらしい。
　
・MySQL周りの不具合をMCFのコミュニティに問い合わせたら
　どうしようもないって言われたが1.1からリトライするようになった。
　
・エラーが出たらもっかいインデクシングするような実装。
　
・MySQLのスロークエリーログが出まくる
　MCFのカールさんに実行計画渡して1.1で大分改善されたけど。。

・クロールが追いつかない。。
　ファイルの更新頻度がひくいファイルが大多数。
　リアルタイムで食いたいのは、ファイルポータル経由で置いてね。
　そしたら、そっちはリアルタイムで検索できるようにするよ的な。
　
・インデックスの肥大化。
　ファイルの本文をストアしないやうに。が、そうすると本文のスニペットが。
　
・シノニム
　テザリング、手座リング、tezaring、、、
　kakasiでローマ字読み。フロントで処理。
　⇒辞書登録ごとに全クロールは無理だからイイ解決策かも。

・ブーストクエリで特定語、特定の更新日時。継続的にチューニング。
　
・地雷踏みまくってて大変そうだけど、挫折は？4人で頑張ってる。
　
　
■ 4. 株式会社サイバーエージェント　弘瀬　健さん
　　タイトル：SolrCloudの導入事例
　

　
サイバーエージェントでイロイロなサービスの検索を担当されている。
SolrCloudはSimplog検索に適用。
　
・SolrCloudは、、
　クラウドによる分散検索＆インデクシング。
　ZooKeeperでクラウド情報管理。
　マスターとかスレーブとか意識しなくてOK。
　　
・用語
　コレクション、シャード、ノード、コア、、んー、写真の写りがびっみょー…ｗ

　
・Simplogはスマホ向けのブログサービス。
　Solr4.1。約300万投稿。インデックスファイルは1.5ギガ。
　5分置きにインデクシング。3qpsとか。
　が、レスポンスは50ミリsec。イマイチじゃね？と。
　
・サーバーはOpenStackの仮装環境。
　centos6.2。ext3と4のがあるw インフラの人にお願いしたら…ｗ
　
・50ミリsecについて。
　SolrCloudのノードとシャードの数変えたら？っていう検証。
　⇒JMeterでホゲホゲ。
　検証結果については資料で細かく載せてくれてたので。。。
　ってか↓まとめスライドも写真撮ったけど、また写り悪くてなんだかわからんすね…orz

　
・その他
　Solr4.0だとleader云々でtomcat落とす時に気を使う必要があった⇒4.1で解決
　
・leader不在のシャードができると更新できない。
　シャードが欠落すると検索できなくなる。縮退的なことできるけど、、
　⇒ガッツリしたレプリカ用意しといた方がイイ。
　
・性能はマスタースレーブの方が全然イイ。管理は楽なんだけれども。
　
・なぜSolrCloud？⇒いい感じのイケニエサービスきたw
　
・CAさんはわざわざ罠を踏みにいってない？MongoDBとかも。ソレって社風？w
　⇒問題あったら、おめー自分で責任取れよ的な雰囲気。
　
発表された方々も素晴らしかったのですが、個人的には、
主催の@johtaniさんのあたたか味のあるコメントがとてもナイスでした！
ElasticSearch勉強会するかもとのことでした。
　
尾形さんの発表にもありましたが、バージョンが古くても
↓の書籍は未だSolr使いにとってはバイブルですね。