在方面查询中有巨大的时间差异

我有一个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进行重新索引并进行“大”测试 –

在方面查询中有巨大的时间差异

回答

相关问题