目次
いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやいや、話もしてくださいと言われてしまったので、 発表もしてきました。 発表資料はブログの最後に掲載してあります。
日時：2011/12/19(月) 19:00～21:00 場所：Voyage Group 8階
1.Fessについて N2SM菅谷さん 資料：http://www.slideshare.net/shinsuke/solr-fess
マルチコアで構成されてる。
S2Robotでクロールしてますよ。
※ごめんなさい、あまり聞けなかった。。。あとで資料を読んで質問します！
2.lucene-gosenについて @johtani
発表しました。
3.ApacheConに参加しました @Ijokarumawak 資料：http://www.slideshare.net/KojiKawamura/apache-con-2011report
日本->カナダ->ベルリン->カナダ->日本
50万円。。。
キーノート１：
セキュアな開発について。
キーノート２：
Hortonworksのコミュニティ運営大変だよねぇ、頑張るよという話。
キーノート３：
本題：Lucene 4.0の話：Simonさん
ヨーロッパの方？
PostingsFormatの話。
Document内部の情報を使うためにどうする？
StoredField：あんまり効率よくないね。
FieldCache（on RAM）：インデックス作る動作の逆を行う。これも効率よくないね。
IndexDocValue：インデックス作成時に作られるので読み込み性能が１００倍！（DocValue）
Document Writer Per Thread！
Automaton Query
あいまい検索の処理に利用。
Solr Flair
Solr同梱
Prism
LucidImaginationが出してるJRubyのラッパー
GitHubで公開されてるらしい。
Blacklight
RoR
図書館むけのパッケージじゃなかったっけ？
VUFind
PHP
これも図書館向け？
TwigKit
JSPのタグリブ
おぉ。これ直接読んでるのかな？
Ajax Solr
Ajax用
QA
Q：TwigKit、Ajax Solrは直接Solrを呼んでるんですかね？
A：たぶん、そうですね。JSPのはSolrJかもしれないですが。
4.サフィックスアレイの話 @nobu_k 資料：http://www.slideshare.net/nobu_k/suffix-arraysolr
Suffix Arrayの話
全文検索インデックスの話。
Suffix Array＝検索漏れがない。
Suffix＝接尾辞
RedBullがどの文書に入っているか！
SuffixArrayのメリット
検索漏れがない＝n-gramと同様
仕組み上n-gramよりも早くなるケースが多い。
長いクエリに対して速い
THIS IS IT：全部ストップワード
SuffixArrayのデメリット
インデックス構築系
アルゴリズムが難しい。
メモリ上での構築はちょっとだけ楽（けど、簡単ではない）
SAISなど。けど、これだとメモリがいっぱいないとキツイ
HDDでの構築
ランダムアクセスを排除したアルゴリズムが必要（dc3,dc7）
インデックス更新、差分更新できない。
頑張って１台100GB/day
Sedueでは？
SA＆インメモリn-gramのハイブリッド
更新分はn-gramに
検索時にはn-gram＋SAの内容をマージして出力
検索
二分探索はHDDとは相性が悪い。
メモリ上で検索できればOKだけど、サイズが大きいからきびしい。
圧縮接尾辞配列なら可能だけど、低速。。。
SSDだとはやいよ！
SSD対応のクラウドはまだないけど。。。
Sedueでは最初の２０段でキャッシュしてる。
VSストップワード
ストップワード込でインデックス作るみたい。
1.SAを二分探索
2.該当区間から出現位置をロード
3.出現位置をソート
O(n)だけど、CPUのキャッシュミスが激しく影響
4.ソートした出現位置からヒット文書を求める。
同じくキャッシュミスがやばい
・実際にはmallocした領域のページフォルトが一番やばい
SAが超活躍する場面
遺伝子の検索
n-gramとか死ぬ。形態素解析も無理。区切りがわからんｗ
5.P2P検索 ORBIS @ceeflyer 資料：http://www.slideshare.net/ceeflyer/p2p-search-engine-orbis
ORBISとは？ラテン語で「目」
ORBISとは？
リアルタイム検索エンジン
自律分散検索エンジン
もともとはAmebaなうの検索のため
ノード構成
比較的小規模（～１０００台）<=しょ、小規模ですか。すごいな。
Master-Slaveの差がなし
MessagePack利用
フルメッシュネットワークを構築
インデックス
フィールド：
Content（形態素解析対象）
Appendix（形態素解析しない）
Flag（属性）
ハッシュレプリケーションで登録。近いハッシュ値に登録（レプリカ数を指定できるのかな？）
単語に対して転置インデックスを一定数で固定
投稿日時が新しいものだけ検索するため。
検索：
マージして結果を返す。
壊れてたら取れたものだけ返す。
QA：
Q：ハッシュ値が大きくて１台しか選ばれないとかあるのでは？
A：ハッシュ値は循環しているという形で３台とか選ぶ。
Q：最大何台で稼働させてる？
A：現在はまだ５台程度
Q：障害時にレプリケーションの維持はするのか？
A：現時点はしてない。
Q；Cassandra、Lucendraとかあるけど、それをしなかった理由は？
A：単純にConfigurationができるから、１から作った。
今回はSolr以外の話も聞けたのがとても面白かったです。 やはり、Solr以外の検索エンジンについても知見があると、色々と比較の話しとかしやすいので。 それにしても、一からP2Pの検索エンジンを作っているのにはびっくりしました。 他にもSuffixArray（Sedue）の話も気になっていたのが少し氷解したし、海外旅行のノウハウがApacheConの話で聞けたしｗ やはり、発表をすると話しをしてもらえるのもあって、いい機会だなと再認識しました。 今回も紹介ネタだったので、ちゃんと事例とか測定したものも発表できるようにならねばと。。。
ということで、私の発表資料はこちらになります。疑問点とか質問事項とか、指摘事項など、コメントorTwitterで連絡いただけるとすごく嬉しいです。
comments powered by Disqus
See Also by Hugo
- 第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)
- 第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)
- 第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)
- モーショノロジー2012#1に参加しました。(Jugemより移植)
- 第6回Solr勉強会に参加しました。(Jugemより移植)