Subscribed unsubscribe Subscribe Subscribe

nashcft's blog

時々何か書く。

第15回Solr勉強会 メモ #SolrJP

特に前知識など無しに参加してみた。技術調査的なノリだった。

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ステップで行われる:
    1. ドメイン特化したフレーズモデルの作成 (machine learningなどを利用)
    2. SolrTextTaggerに1.で作成したフレーズを食わせる
    3. SolrTextTaggerで検索クエリからフレーズ抽出、tagging
    4. クエリを書き換える
    5. 1.のMLに関する所がセッションではあまり話されなかったと言っていたが、Lucene / Solrにがメインのconferenceだからそんなものでは?
  • 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."

  • これを使ったらLuceneのFuzzyQueryが100倍速くなった(!)
  • 応用として自然言語処理における高速・省メモリ辞書に使えるかも。
  • デモ、図説、etc...

類義語検索と類義語ハイライト : 株式会社ロンウィット 阿部さん

  • 一般的な日本語全文検索における注意点と対応
    • 検索漏れ: 形態素解析による
      • 単語の切れ目の認識による
    • 検索ゴミの発生: N-gramによる
      • 「こんにちは」-> 「こん」「んに」「にち」「ちは」で「こんばんは」や「にちようび」にヒットしてしまう
    • 形態素解析のあとにN-gramを用いて検索漏れを拾う。ゴミは重み付けを変える・システム出力を減らすなどして対応する。
  • autoGeneratePhraseQueriesが云々
  • Highlighterでは検索漏れを考慮してN-gramを利用
  • 3種類のhighlighter:
    1. Default Highlighter
      • N-gram fieldのhighlightが上手くいかない(バグ? LUCENE-1489)
    2. FastVectorHighlighter
      • Default Highlighterより速い
      • その分 (?) indexが大きくなる
    3. PostingsSolrHighlighter
      • FVHよりさらに速い
      • フレーズ単位のhighlightが未サポートなので日本語検索・ハイライト的には使えない (LUCENE-4825)。
  • 現状では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 : ヤフー株式会社 大須賀さん

徹底比較!! 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)

発表者の方々のスライドを追加。