在方面查詢中有巨大的時間差異

我有一個SOLR DB with ca. 70M文件。某些查詢返回約300個文檔。隨着在方面查詢中有巨大的時間差異

facet.field = A僅需4毫秒，
facet.field = B需要800毫秒來回報您！

在我的模式中是否有錯誤？它可以做得更快嗎？

<fieldtype name="B_type" class="solr.TextField" positionIncrementGap="100"  
      sortMissingLast="true" omitNorms="true"> 
    <analyzer type="index"> 
     <tokenizer class="solr.KeywordTokenizerFactory" /> 
     <filter class="solr.StandardFilterFactory" ignoreCase="true" /> 
    </analyzer> 
    <analyzer type="query"> 
     <tokenizer class="solr.KeywordTokenizerFactory" /> 
     <filter class="solr.StandardFilterFactory" ignoreCase="true" /> 
    </analyzer> 
</fieldtype> 

<field name="A" type="string" indexed="true" stored="true" multiValued="false" /> 
<field name="B" type="B_type" indexed="true" stored="false" multiValued="true" />

來源

2013-12-17 Stefan Weiss

領域A是string類型，這是很好的，用作小面的。你的字段B被分析，你特殊的字符和你小寫它，這不是很好用作一個方面。後面的事情在應用StandardFilterFactory時完成。

在Solr's Wiki有大約方面

因爲小面領域往往指定服務於兩個目的，人類可讀的文本和向下鑽取查詢值，他們經常從用於領域的索引不同的有趣的部分搜索和排序：

他們往往沒有標記化到單獨的詞

他們往往不被映射成小寫

人們可讀的標點符號通常不會被刪除（雙引號除外）

通常不需要存儲它們，因爲存儲值看起來非常像索引值，而分面機制用於值檢索。

正如你可以看到你在中間，你小寫錯過了兩個點，你刪除特殊字符。

按照Indexing Fields with SOLR and LowerCaseFilterFactory的建議，您應該在您的模式中引入一個新字段，該字段應該是string，並通過copyField與您的字段B保持同步。這個新領域應該用於刻面，它應該更快。我們通常將這些字段命名爲後綴，如B_raw。

由於您確實有70米的文件，因此提前測試一個子集以節省您的時間將是一個不錯的主意。

來源

2013-12-17 15:35:32 cheffe

我喜歡cheffe的回答。 – Arun

我的B場已經是「B來源」的副本，只用於刻面。我會嘗試聲明它的字符串並使用LowerCaseFilterFactory。 –

對於1M文檔看起來不錯。必須在接下來的日子裏對整個DB進行重新索引並進行「大」測試 –

在方面查詢中有巨大的時間差異

回答

相關問題