Solr 相当于数字字段的 SQL BETWEEN
希望有一些指针可以加快 3.4.0 版本中一些（非常）慢的 solr 查询的速度。
我有大约 600 万个文档的索引。每个文档都非常小，并且包含两个 solr.TrieDoubleField ； “开始”和“结束”。
<fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/>
----
<field name="start" type="double" indexed="true" stored="false" />
<field name="end" type="double" indexed="true" stored="false" />
查询时，我需要执行相当于以下的 SQL：
WHERE @input BETWEEN Start AND End
为此，我将查询编写为：
start:[* TO @input] AND end:[@input TO *]
查询成功，返回正确的文档，但 QTime 约为 4,500；大多数其他查询都远低于 100。
可以修改哪些内容来提高性能？
Hoping for some pointers to speed up some (very) slow solr queries in version 3.4.0.
I have an index of about 6-million documents. Each document is quite small, and contains two solr.TrieDoubleFields; "start" and "end".
<fieldType name="double" class="solr.TrieDoubleField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/>
----
<field name="start" type="double" indexed="true" stored="false" />
<field name="end" type="double" indexed="true" stored="false" />
When querying I need to perform the SQL equivalent of:
WHERE @input BETWEEN Start AND End
To do this I'm writing my query as:
start:[* TO @input] AND end:[@input TO *]
The query succeeds, returning the correct document, but with a QTime of ~4,500; most other queries are well below 100.
What can be modified to improve performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信您应该尝试 函数范围 (frange)< /a> Solr 中的查询解析器。请参阅介绍性博客文章 - 范围有关如何使用 Function Range 查询解析器的更多详细信息，请参阅 Solr 1.4 中的函数。
（注意这也应该适用于高于 1.4 的所有 Solr 版本）
所以我认为类似以下的内容应该有效...
我不确定是否可以使用通配符作为上限和下限，大概不是……
I believe that you should try the Function Range (frange) query parser in Solr. Please see the introductory blog post - Ranges Over Functions in Solr 1.4 for more details on how to use the Function Range query parser.
(Note this should apply to all versions of Solr greater that 1.4 as well)
So I think something like the following should work...
I am not sure if you can use wildcards for the upper and lower bounds, probably not...