Solr/Lucene性能问题中的按日期排序
我们已经建立了一个包含3600万个文档（每个文档约1K-2K）的Solr索引，并尝试查询最多100个与单个简单关键字匹配的文档。正如我们所希望的那样，这工作得相当快。 但是，如果我们现在将“&sort=createDate+desc”添加到查询中（从而请求与查询匹配的前100个“新”文档），它将运行很长很长时间，最终导致OutOfMemoryException。 据我从手册中了解，这是因为Lucene需要在执行查询之前将该字段（createDate）的所有不同值加载到内存（FieldCache afaik）中。由于createDate字段包含日期和时间，不同值的数量相当大。 同样重要的是，我们经常更新索引 也许有人可以提供一些见解和指导，告诉我们如何调整Lucene/Solr或改变我们的方法，使查询时间变得可以接受？Solr/Lucene性能问题中的按日期排序,lucene,solr,Lucene,Solr,我们已经建立了一个包含3600万个文档（每个文档约1K-2K）的Solr索引，并尝试查询最多100个与单个简单关键字匹配的文档。正如我们所希望的那样，这工作得相当快。 但是，如果我们现在将“&sort=createDate+desc”添加到查询中（从而请求与查询匹配的前100个“新”文档），它将运行很长很长时间，最终导致OutOfMemoryException。 据我从手册中了解，这是因为Lucene需要在执行查询之前将该字段（createDate）的所有不同值加载到内存（FieldCache
您的意见将不胜感激！谢谢。问题是Lucene将数字存储为字符串。有一些实用程序将日期拆分为YYYY、MM、DD，并将它们放在不同的字段中。这会产生更好的结果
更新版本的Lucene（2.9及以后版本）支持数字字段，并且性能显著提高（几个数量级，IIRC）。请查看有关数字查询的文章。您可以按索引顺序对结果排序。 按文件编号递减的排序规范为：
new SortField(null, SortField.DOC, true)
分区将分割所检查的集。如果在最新分区中有N个结果，则无需检查旧分区。尝试将日期类型数据转换为字符串类型（如毫秒）。感谢您的输入，Sashikant！事实上，升级到Solr1.4（实现Lucene2.9）带来了巨大的不同。对我们来说，它的主要优势在于它维护每个段的FieldCache，并且在提交未更改的段后不需要重新加载它。