特に前知識など無しに参加してみた。技術調査的なノリだった。
Lucene / Solr Revolution 2014 Report : 株式会社ロンウィット 打田さん
- Lucene FST (Finite State Transducer)とSolrTextTaggerの紹介。
- conferenceに関してはスライドを読んでくださいとの事。
- 多言語対応やsemantic searchのアーキテクチャについてのセッションがあった。
- 多言語対応に関してはプレゼンの際には省略されたが、言語の扱い方を3つの戦略に分け、それぞれのPros/Consを挙げている。
- 言語毎にfieldを分ける場合、実装がシンプルになるが対応言語数が増えるにつれてパフォーマンスが落ちるので何かしら手を打つ必要が出てくる。
- 言語毎にcollection / coreを分ける場合、言語数に関わらずスピードが出て、検索対象となるfieldは1つなのでパーサの選択何でも良いが、環境含め複雑さが増す。
- 全ての言語を1つのfieldに入れる手法はSolrには機能として派存在しないらしい。何か自分で書くっぽい。
- Semantic search = query augmentation (再現率の向上) + ranking tuning
- 入力された検索ワードに対して類似の単語や付加情報を追加し、重み付けを加えたものを実際の検索に用いる。
- 拡張は以下の4ステップで行われる:
- SolrTextTaggerはLucene/Solrを応用したフレーズタガー。2つの単語認識とフレーズ認識の2段階でFSTを用いている。
- このFSTの実装がLuceneFST
- Finite State TransducerとはFinite State Automataが受理時に何かしらの値を出力する機能を持ったもの (?)
- でもSTTでは出力を使ってないらしい
"Essentially, an FST is a SortedMap<ByteSequence,SomeOutput>, if the arcs are in sorted order."
- Finite State TransducerとはFinite State Automataが受理時に何かしらの値を出力する機能を持ったもの (?)
- これを使ったらLuceneのFuzzyQueryが100倍速くなった(!)
- 応用として自然言語処理における高速・省メモリ辞書に使えるかも。
- デモ、図説、etc...
誰得なのか知らないですが、Lucene FST の実装の元になった論文です。 #SolrJP http://t.co/WvH7QaB1R8
— Tomoko Uchida (@moco_beta) December 8, 2014
類義語検索と類義語ハイライト : 株式会社ロンウィット 阿部さん
- 一般的な日本語全文検索における注意点と対応
- autoGeneratePhraseQueriesが云々
- Highlighterでは検索漏れを考慮してN-gramを利用
- 3種類のhighlighter:
- 現状ではFVHを利用するのが良い
- Synonym対応 (2-gram)
- FieldTypeでSynonymFilterFactoryを設定する(SOLR-4813)
- tokenizerFactory*属性はindexing側で設定する。
- 編集する度にreindexingが必要になり面倒。
- しかしquery側で設定すると色々不都合な事が多い。
- とはいえquery側で設定できると運用が楽なので提案は時々起こる。しかし採り入れられた事は無い。
- <=3.3と>=3.4でsynonym filterが異なる。
- <= 3.3はslowSynonymFilter
- >= 3.4はFSTSynonymFilter (ここでもFSTが使われている)
- 挙動が異なるので過去のqueryがおかしな結果を返すようになる。
- multiTokenが複雑 -> phrase queryがおかしくなる。
- highlightingも変。
- だが速い
Solr at Yahoo! JAPAN : ヤフー株式会社 大須賀さん
- 検索プラットフォーム"ABYSS"の再構築の際、Solrを用いる事を決定。
- SPDYプロトコルをサポートして高速化を実現
- 本家にパッチを送ったりもしている
徹底比較!! Heliosearch vs Solr : デジタル・インフォメーション・テクノロジー株式会社 海老澤さん
- HeliosearchはSolrの次世代となるNoSQL検索サーバ
- 内部でNoSQL DBを利用している訳ではなく、検索方式がNoSQLの範疇に含まれる、という事らしい。
- Solrの上位互換として (幾らか相違点はあるが) Solr想定の実装のままHeliosearchが使える。
- facetingが2倍速い, GC負荷軽減, 特定の条件下でfilter queryの最適化が行われ高速化, という謳い文句
- 実際上記箇所に関してはnative処理に変更していたりする
- その所為で設定不備等ある場合JVMごとダウンするリスクが...
- 実際に動作検証を行った所、結果に有意差は見られなかった。
- 構築法の問題か、まだ開発途上故か
- ログの表示に差異がある為影響ある場合はSolrのものを利用するべし。
Amazon CloudSearch Deep Dive : アマゾンデータサービスジャパン株式会社 篠原さん
- CloudSearchの紹介
- 導入楽チン
- 多言語によるtokenize, Suggestion, Geo-Spatialな検索など多機能。
- 内部でS3, DynamoDBを利用している
- データの増加とトラフィックの増加双方に対応できるようなスケールをする。
- スケールしてノード追加した時に新しいノードに何も入ってないという状況が発生しうる。
追記 (2014/12/12)
発表者の方々のスライドを追加。