全文検索エンジンのインデックス生成が遅いのはもはや常識ですね。
しかし具体的にどこが遅いんだろうと考えていたんですが、
今まではただ漠然と以下を怪しんでいました。
しかしどうでしょう。
SQLがヘボいから遅いというのは論外。
ORMを使っていてEntityへのマッピングが遅いのも論外。
s2jdbcはjoinが多い場合はentityへのマッピング処理が急激に遅くなる - treeのメモ帳
この辺がクリアできているとして、じゃあstored/indexedのフィールド数?形態素のデータ量?
以前indexedフィールドを0個にして試しましたが、全く速度は向上しませんでした。
ではstoredのデータ量?これは多少効果がありました。
storedはindexedと違って人間が読める形、つまりマルチバイトになるのでindexedより重いのでしょう。
しかし劇的な改善は見込めず。
となると形態素解析のフィールドが怪しいわけです。
形態素フィールドにindexedするデータ量はインデックス生成の時間に大きな影響を与えます。
しかし、具体的にどの処理が遅いのか解らないのです。
形態素で分割された単語単位のデータの格納が重い?それは考えにくい。
それなら単にmultivalueフィールドに沢山データ詰め込んでも同様に遅くなるはず。
という訳で消去法で形態素解析の処理自体が遅いという点に行き着きましたが、
更に探りを入れる必要があります。
schema.xmlでは形態素解析のフィールドは以下のような感じで定義します。
<fieldType name="text_ja" class="solr.TextField" positionIncrementGap="100" autoGeneratePhraseQueries="false"> <analyzer> <tokenizer class="solr.JapaneseTokenizerFactory" mode="search" userDictionary="lang/userdict_ja.txt"/> <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true"/> <filter class="solr.JapaneseBaseFormFilterFactory"/> <filter class="solr.JapanesePartOfSpeechStopFilterFactory" tags="lang/stoptags_ja.txt" enablePositionIncrements="true"/> <filter class="solr.CJKWidthFilterFactory"/> <filter class="solr.StopFilterFactory" ignoreCase="true" words="lang/stopwords_ja.txt" enablePositionIncrements="true" /> <filter class="solr.JapaneseKatakanaStemFilterFactory" minimumLength="4"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.TrimFilterFactory" /> <filter class="solr.RemoveDuplicatesTokenFilterFactory"/> </analyzer> </fieldType>
さて、トークナイズ(単語分割)が遅いのか、その後の各種フィルタが遅いのか、辞書を引くのが遅いのか。
仮にトークナイズが遅いなら、単語をキーに分割後の単語をEHCacheでキャッシュしてしまえば劇的な高速化ができそう?
とも考えています。
http://treeapps.hatenablog.com/entry/20110908/p1:title:bookmak
残念ながらここまでしか検証できていないので、今日はここまでです。
- 作者: Rafa Ku
- 出版社/メーカー: Packt Publishing
- 発売日: 2013/01/25
- メディア: ペーパーバック
- この商品を含むブログを見る