我有一个包含大约6千万到1亿个文档的索引。我们几乎总是基于外键ID查询这些文档(除了其他过滤查询和字段查询等),以将查询范围限定在特定的父对象中。
例如:
我的问题是:我应该将其更改为TrieIntField吗?这样会加速性能吗?如果是的话,给定我知道我将始终查询单个特定值,并且该parent_id的基数处于10,000-100,000(最大)数量级,那么理想的precisionStep和positionIncrementGap值是什么?
附加细节编辑(来自下面答案的评论):
我们系统的使用方式是,我们最终会连续使用相同的fq进行许多查询。当缓存被填充时,系统运行得非常快。当由于提交而导致缓存被清空时,这个查询(甚至只有这个fq的测试用例)可能需要长达20秒。因此,我正在尝试找出如何加速填充缓存的初始查询。
第二次编辑:
很抱歉,经过进一步测试,发现上述性能差的情况只发生在返回facets字段时(例如,
例如:
/solr/q=*:*&fq=parent_id_s:42
是的,这里的“_s”表示这是当前的solr.StrField字段类型。我的问题是:我应该将其更改为TrieIntField吗?这样会加速性能吗?如果是的话,给定我知道我将始终查询单个特定值,并且该parent_id的基数处于10,000-100,000(最大)数量级,那么理想的precisionStep和positionIncrementGap值是什么?
附加细节编辑(来自下面答案的评论):
我们系统的使用方式是,我们最终会连续使用相同的fq进行许多查询。当缓存被填充时,系统运行得非常快。当由于提交而导致缓存被清空时,这个查询(甚至只有这个fq的测试用例)可能需要长达20秒。因此,我正在尝试找出如何加速填充缓存的初始查询。
第二次编辑:
很抱歉,经过进一步测试,发现上述性能差的情况只发生在返回facets字段时(例如,
&facet=true&facet.field=resolved_facet_facet
)。有大约十几个这些字段时,查询有时需要20-30秒,但只有在新的搜索器中才会出现这种情况。当缓存被填充时,它是瞬间完成的。因此,也许我的问题在于facets字段,而不是parent_id字段。
facet.method = enum
。似乎这是一个小的改进,但似乎打开并调整自动预热可能是我所能做的最好的事情... - Jeff Gran