我正在使用SOLR-3.4，使用具有LatLonType（subType = tdouble）的模式进行空间过滤。我有一个约20M的索引。我的基本问题是，如果我使用cache = true执行bbox过滤器，性能相当不错（~40-50 QPS，大约100-150ms延迟），但是一个很大的缺点是疯狂的快速老一代堆增长最终导致主要收藏每30-40分钟（在一个非常大的堆上，25GB）。在那一点上，表现是不可接受的。另一方面，我可以关闭bbox过滤器的缓存，但随后我的延迟和QPS下降（延迟从100ms => 500ms）。 NumericRangeQuery javadoc讨论了你可以获得的出色性能（低于100毫秒），但现在我想知道是否启用了filterCache，并且没有人费心去查看导致的堆增长。我觉得这是一种捕获22，因为这两种配置都不是真的可以接受。
我对任何想法持开放态度。我的最后一个想法（未经验证）是使用geo hash（并祈祷它在cache = false时表现更好，或者如果cache = true则具有更易管理的堆增长）。
编辑：
精确步骤：默认（我认为是8倍）
系统内存：32GB（EC2 M2 2XL）
JVM：24GB
索引大小：11 GB
EDIT2：
使用precisionStep为8的tdouble意味着您的双精度数将以8位的顺序进行分割。如果您的所有纬度和经度仅因最后一个8位序列而不同，则tdouble将具有相同的性能，并且在范围查询中具有正常的双精度。这就是为什么我建议测试一个4的precisionStep。
问题：对于双重值，这实际上意味着什么？
答案 0 :(得分：1)
在回复空间查询时获得Solr的个人资料对于了解什么是慢的很有帮助，例如，请参阅hprof。
不过，这里有一些关于如何（或许）改善延迟的想法。
首先，您可以尝试测试减少precisionStep时会发生什么（例如尝试4）。如果纬度和经度彼此太近而且precisionStep太高，Lucene就无法利用几个索引值。
您还可以尝试为JVM提供更少的内存，以便为操作系统缓存提供更多机会来缓存经常访问的索引文件。
然后，如果它仍然不够快，您可以尝试将字段类型的TrieDoubleField替换为将使用a frange query作为getRangeQuery方法的字段类型。这将减少磁盘访问次数，同时以更高的内存使用量为代价计算范围。 （我从未测试过它，也可能提供可怕的性能。）