目次
記念すべき！？第10回のSolr勉強会です。
発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイートのおかげか、キャンセル処理もちゃんと行なってもらえて助かりました。 開場直後にドタバタしてしまい、すみませんでした。。。
とりあえず、第一報の記事をアップしておきます。
懇親会での話とか感想はまたあとで。
関口さんの資料は実は、前もって見たことがある資料でした。 最初の発表にしては、少しむずかしいと思った方もいるかなぁと。 ただ、類義語の辞書は結構作るのが大変だし、探しても出てこないものなので、面白い話だったんではないかなぁと。 「ミスチル」はできないけど、「マツケン」ができるのは読みがあるからとかなんですかねぇ？って質問するの忘れてた。
尾形さんの話は結構、みんな通ってきた道かもなぁと思いました。他の方も同じ経験してるんじゃないかなぁと。 ただ、一人でやるのはすごいですよね。検索って結構人数が割かれてない場合が多いのかなぁ。 あんまり使われていないというのが少し悲しい話でしたが。。。 サーバを要求すれば結構なスペックが用意してもらえるのはうらやましい限りですねぇ。 スキーマ変更については、レプリケーション機能を使うと追加などならうまくいくんじゃないでしょうか。（そんなツイートもありましたよ。togetter読み返すと出てきます。） フィールド名を変更しないで型を変更するなどしたらおかしくなると思いますが。
野口さんの話はなかなかチャレンジングでいいなぁと思いました。よく挫けずに頑張られているなぁとｗ 試行錯誤した仮定も発表してもらえると同じ轍を踏んだ人が助かると思います。 大きな企業で本格的に横断的な社内検索が出来る仕組みが出来上がっているって話はなかなかきかないかなと。 どうしても、社内検索とかお金が出なくて手を付けられないといいう悲しい話が多いので、こういう話は共有したい情シスの方がいっぱいいるんじゃないかなぁと。 ManifoldCFが結構地雷を多く含んでいるのは大変そうですね。。。 SolrにもTikaが入っていたりしますが、個人的にはTikaがやるべき処理は前処理と思っているので、Solrとは別の場所でやりたいとか考えていたりします。 ManifoldCFがその辺りまでやってくれるかまではちゃんと調べてないんですが。 Solrは検索だけに注力させることで、役割を分割できるので、性能の対処とかを行うのが楽になるんじゃないかなぁとか。 ManifoldCFで困ってる人は他にもいるようなので、ジャンジャン使って、どんどんチケット上げて貢献してもらうといいかと。 また、定期的に発表してもらうと面白そうだなぁと。
弘瀬さんの話は結構興味ある方がいたんじゃないかなと。 SolrCloudは壮大だなぁと思いつつ、手を出しづらいと思ってる方が多いと思います。 実際のサービスに投入して試行錯誤された話を細かな数値も上げて発表してもらえるのは検証をやる方の助けになります。 残念ながら、私もSolrCloudは興味有りつつちゃんと追っかけてないので、途中でnodeとshardとcoreの関係がわからなくなってしまいましたので。。。 もう一度勉強して、スライドを見たいと思います。。。 分散検索（1つのインデックスが複数のcoreやshardに分割された状態）が絡んでくると、複数台の検索の性能のうち、一番遅い性能が最終的な検索性能に響いてくるので、検索リクエストの偏りとかも影響が出たりするかもしれないなぁと。 そういった意味でも試行回数を3以上で計測した結果で再度発表してもらうと面白そう！（なんか、下心見え見えですがｗ）
前回、今回も感じたのですが、もう少し質問をしてもらえると発表された方も励みになるかなぁと思いました。 質問しにくい雰囲気になってるのでしょうか？参加者が結構いるから質問しにくく感じたりするのでしょうか？ そのあたりをもう少しうまくやれるようになにかコメントもらえると嬉しいかなぁと。 運営で気になった点などもコメントやツイートをいただけると今後の改善にも役立てますので気兼ねなく連絡いただけると助かります。 開場がドタバタしすぎとか、ハッシュタグがわからなかったとか。
今回は思ったよりも懇親会に残る方が少なめでした。 コミッターの方（LuceneやManifoldCFとかlucene-gosenとか）が複数いたり、Solrを結構触ってる方がいたりと面白い話が聞けそうだったのですが。。。 Kuromojiのユーザ辞書の改良点をチケットにあげるって約束したのでやらないとなぁ。 早く帰るつもりだったのに気づいたら23時でしたwやっぱり色々と話ができるのが楽しくて。。。 駅前の機動隊とかびっくりしながら帰りました。 今回、お話ができなかった方もいらっしゃるかと思いますが、気兼ねなく、ツイートしてもらったり、声をかけていただければと。
あと、常に発表していただける方は歓迎しておりますので、連絡いただけると非常に助かります！ こんな話が聞きたいなどでもいいかと思いますので、連絡いただければと。
#SolrJPもtogetterにまとめてもらいました。ありがとうございます。 以下は、いつものメモになります。
日時：2013/03/26 19:00 to 21:00
場所：VOYAGE GROUP 会議室
1. 株式会社 ロンウイット 関口 宏司さん
タイトル：Wikipediaからの類義語知識の自動獲得について
・「辞書型コーパス」という単語は造語かもしれません。
・なんでこんなことを？
→類義語辞書を自動生成したいから。
・自賠責保険、自動車賠償責任保険を例にSynonymFilterの説明。
・Wikipediaを入力として、類義語辞書を作成するときにLuceneのインデックスを活用してる。
・類義語候補の見つけ方
いくつかヒューリスティクスな処理とかも入れてます。
日本語Wikipedia固有なもの。
・実際に導出された単語も載ってる。
FTPなども導出で来てる。
丸ビルとかも。
・導出できなかったものもあります。
「十六進法」が「十進法」になってる
「ミスチル」も無理。
・ミスもあるけど、類義語が存在しない場合になんとなく、使う辞書としては採用できるのでは？
類義語検索対象のブーストを小さくするなどをすれば役に立つ
Q：類似度にしきい値を用意したりしてますか？
A：min.scoreという値を用意し、足切りをしている。
Q：ベクトルを作るという話があったが、品詞でフィルタリングとかしてる？
A：名詞に限って処理してます。名詞に限らなくてもいいかも。。。（若干聴き逃しました）
重みの高いn件をベクトルの対象にしてます。
2. グリー株式会社 尾形 暢俊さん
タイトル：GREEにおける全文検索の歴史
・GREEさん、検索はないがしろにされてる。。。
一人でつくって、一人でメンテナンスしてる。
・GREEの検索は右上の検索ボックスが
・2007年はSennaつかってました。
Tritonnに移行。2009年くらいまで。
やっぱり安定しない＋MySQLのバージョンアップしたいけど、追従できない
・2012年初頭までLuceneでやってた。（結構古い）
フラグメントが発生してOptimizeすると、検索サーバが使えなくなる。。。
検索しにくるサーバが1000台いるので、Optimizeかけるときに、1000台のサーバの設定を書き換えるとかしてた。。。
・現在まではSolrをつかってる。
Luceneのバージョンも古かったので100倍くらい速くなった。
・Solr本が必須ですよ！！！
・Lucene+Tomcatから移行。
移行に気をつける点として、I/FをそのままSolrに置き換えると。
Solr返却のXMLをカスタマイズしたり、クエリをSolr向けに書き換えたり。
あと、メンテナンスが楽になるように。
40数台のインデックスサーバがあると。
一人でメンテナンスしてるから、楽になる方法が重要
・レプリケーションで、Optimizeの影響が出ないように。
キューをつかって、マスタに登録して、スレーブにレプリカを配布
・スキーマが7つ
あんまり使われてなくてかなしい。。。
・負荷のグラフもありました。
・RangeQueryを結構使う。
・作りこんだ部分
インデックスのMasterへ分散させる処理とか
クエリの変換とか人力監視処理とかNGワードとか
サーバ監視のための仕組み
・今でも大変なこと
スキーマ変更が大変
スレーブをマスタに昇格とかが手動
・今後改善したいこと
精度を上げたい
辞書を使ってみたいけど、各国語対応
あと、自動化とか
3. ソフトバンクBB株式会社 野口 勝義さん
タイトル：企業内の大規模ファイルサーバ検索事例
・情シスの企画版？という立場のかた。
・売上に貢献したいのでクラウドサービスとして検索をオプションとして立ち上げてみた！
・Solr＋ManifoldCFで作ってみたよと
・なんでSolr？
OSSだし、機能が充実
・なんでManifoldCF？
Active Directory連携が使いたかったと。
社内検索ってやっぱりアクセス権がうるさいので。
・ManifoldCFの説明はロンウイットさんの画像を使わせてもらいましたｗ
・ファイルサーバが、70TB。。。
・困ったこと。
・その１
・クローラージョブの構成の最適化どうする？
・マルチコアで、クローラーとファイルサーバを1対1の構成にしてみた。
・その２
・ファイル数が増えるとまた問題が。。。
・ファイルサイズが大きい→Heapが足りないエラーとか、MCFのタイムアウトとか。。。
ファイルサイズのリミットを設けてみた。
mp4とかでエラーがでるとか。既知のエラーでしたとか。
ulimitがたりないとか。
MCFの稀に出るバグとか。。。
ファイルサーバの不良ブロックとか。。。
・その３
・クロールに時間がかかる
・MySQLでスロークエリとか
MySQLよく知らないとか言われながらコミッターに対応してもらうなど。
SSDつかうとか考え中
・フルクロールで1週間
差分でも1日強かかる。
ManifoldCFだけで対応できないから、ファイルの特徴を元に
→ManifoldCFを経由しないリアルタイムインデックス更新のAPIを経由してMasterじゃなくて、更新かけると。（特定のクライアントからの方法）
・その４
・本文データをstored=falseに
けど、ハイライトできないから、どうにかしたい
・ユーザの要望
・もしかして検索
類義語？じゃないよねぇ。テザリング、tezaringuとか
フロント側で頑張った。（Solr諦めました）
・検索スコアも弄りたいとか
外部データでブーストとかもしたい。External Fieldとか使うといいのでは？とか。
4. 株式会社サイバーエージェント 弘瀬 健さん
タイトル：SolrCloudの導入事例
・Webエンジニアだったのに、検索エンジニアに！
・SolrCloudもサービスインしてると。
・SolrCloud概要
4.0以降の機能とか。
・SolrCloudの構成要素
概念的なもの。Collection、Shard
物理的なもの。Node、Core
・ Simplogってサービスに導入済み。
ZooKeeperが3台、6Shard、3nodeという形式
・性能
平均レスポンスタイム50msec
思ったより出てないので、調べてみた。node数とかshard数を変えてみて調べてみた（まだ、模索中。）
・色々テストケース試したけど、試行回数が1回だけです。
詳細なデータが出てるのありがたい（全部はまだ理解できてないですｗ）
・検証まとめ
ノード当たりのcore数が少ないほうが検索、更新性能がいい
1コレクション当たりのshard数が少ないほうが検索性能がいい
・まとめ
・SolrCloudの利点
クライアントが色々意識しなくていいのがうれしい。
・SolrCloudの注意点
shardの分割機能がまだないので、大変。
コレクション情報が壊れると検索更新できないとか。4.0だとバグが有った
・性能的には素のSolrのほうがいいよと。
comments powered by Disqus
See Also by Hugo
- 第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)
- 第7回Elasticsearch勉強会を開催しました。#elasticsearchjp
- 第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp
- Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)
- 検索技術勉強会2024 Springで司会しました