Solr在日期范围查询方面的性能较差

我目前正努力在SOLR4.10（CDH5.14）中使用日期范围查询的NRT索引在约1800万个文档核心上获得良好的性能。 我尝试了多种策略，但似乎都失败了

每个文档都有多个版本（10到100），在不同的非重叠时间段（开始时间/结束时间）有效

查询模式如下：查询referenceNumber（或其他条件），但仅返回在referenceDate（日精度）有效的文档。75%的查询在过去30天内选择了引用日期。 如果我们不使用referenceDate进行查询，我们的性能会非常好，但是使用额外的referenceDate过滤器会使性能降低100倍，即使将其强制作为后过滤器也是如此

下面是一些来自python脚本的性能测试，该脚本执行http查询并计算100个不同引用编号的QTime

+----+-------------------------------------+----------------------+--------------------------+
| ID | Query                               | Results              | Comment                  |
+----+-------------------------------------+----------------------+--------------------------+
| 1  | q=referenceNumber:{referenceNumber} | 100 calls in <10ms   | Performance OK           |
+----+-------------------------------------+----------------------+--------------------------+
| 2  | q=referenceNumber:{referenceNumber} | 99 calls in <10ms    | 1 call to warm up        |
|    | &fq=startDate:[* to NOW/DAY]        | 1 call   in >=1000ms | the cache then all       |
|    | AND    endDate:[NOW/DAY to *]       |                      | queries hit the filter   |
|    |                                     |                      | cache. Problem: as       |
|    |                                     |                      | soon as new documents    |
|    |                                     |                      | come in, they invalidate |
|    |                                     |                      | the cache.               |
+----+-------------------------------------+----------------------+--------------------------+
| 3  | q=referenceNumber:{referenceNumber} | 99 calls in >=500ms  | The average of           |
|    | &fq={!cache=false cost=200}         | 1  call  in >=1000ms | calls is 734.5ms.        |
|    | startDate:[* to NOW/DAY]            |                      |                          |
|    | AND    endDate:[NOW/DAY to *]       |                      |                          |
+----+-------------------------------------+----------------------+--------------------------+

嗨，我有另一个解决方案给你，它将提供一个良好的性能后，执行相同的查询到solr

当您尝试使用int number而不是dates启动相同的查询时，它的运行速度会比预期的更快

希望对你有帮助

---

我也有同样的问题。有人知道答案吗？你在这个领域的准确步骤是什么？。。升级到Solr的更新版本是一种选择吗？后面介绍的DateRange字段使用空间功能提供适当的范围支持。startDate/endDate的精度步长为6，versionNumber的精度步长为0。不，不可能更新solr，因为它是CDH 5.14的一部分。Solr 7将在今年到期的CDH的下一个版本中提供。我猜

versionNumber

的范围足够小，因此更改精度步长不会有多大作用。更大的精度步骤可能有助于日期稍微减少生成的代币数量，但6或8通常是很好的值<代码>10类似于距离搜索的最接近秒的分辨率。如果您只按天搜索，则更大的精度步骤可能有用，但如果不使用数据集和查询配置文件进行测试，则很难说。谢谢您的建议。我已经更新了描述以反映您的解决方案，但与日期：[*到现在/天]解决方案相比，它似乎没有提供任何性能。TrieDate的内部索引为long，因此这与使用常规日期字段相同。

+----+-------------------------------------+----------------------+--------------------------+
| ID | Query                               | Results              | Comment                  |
+----+-------------------------------------+----------------------+--------------------------+
| 4  | fq={!cache=false}                   | 35 calls in <10ms    |                          |
|    | referenceNumber:{referenceNumber}   | 65 calls in >10ms    |                          |
+----+-------------------------------------+----------------------+--------------------------+
| 5  | fq={!cache=false}                   | 9 calls in >100ms    |                          |
|    | referenceNumber:{referenceNumber}   | 6 calls in >500ms    |                          |
|    | AND versionNumber:[2 TO *]          | 85 calls in >1000ms  |                          |
+----+-------------------------------------+----------------------+--------------------------+

+----+-------------------------------------+----------------------+--------------------------+
| 6  | fq={!cache=false cost=0}            | 89 calls in >100ms   |                          |
|    | referenceNumber:{referenceNumber}   | 11 calls in >500ms   |                          |
|    | &fq={!cache=false cost=200}         |                      |                          |
|    | startDate:[* TO NOW] AND            |                      |                          |
|    | endDate:[NOW TO *]                  |                      |                          |
+----+-------------------------------------+----------------------+--------------------------+
| 7  | fq={!cache=false cost=0}            | 36 calls in >100ms   |                          |
|    | referenceNumber:{referenceNumber}   | 64 calls in >500ms   |                          |
|    | &fq={!cache=false cost=20}          |                      |                          |
|    | startDate:[* TO NOW] AND            |                      |                          |
|    | endDate:[NOW TO *]                  |                      |                          |
+----+-------------------------------------+----------------------+--------------------------+

My Suggestion is store date in int format, please find below example.

 Your Start Date : 2017-03-01
 Your END Date : 2029-03-01

**Suggested format in int format. 
 Start Date : 20170301
 END Date : 20290301**

 So your query will be.
q=referenceNumber:{referenceNumber}
&fq=startNewDate:[* to YYMMDD]
AND    endNewDate:[YYMMDD to *]