solr 空间性能不佳答案

【问题标题】：solr spatial bad performancesolr 空间性能不佳
【发布时间】：2012-03-08 03:22:30
【问题描述】：

我正在使用 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 条规则，因为这两种配置都不是真正可以接受的。

我愿意接受任何想法。我的最后一个想法（未尝试过）是使用地理哈希（并祈祷它在 cache=false 时表现更好，或者如果 cache=true 则具有更易于管理的堆增长）。

编辑：

精确步长：默认（我认为是双精度为 8）

系统内存：32GB (EC2 M2 2XL)

JVM：24GB

索引大小：11 GB

EDIT2：

precisionStep 为 8 的 tdouble 意味着您的双精度数将被拆分为 8 位序列。如果您所有的纬度和经度仅相差最后一个 8 位序列，那么 tdouble 将具有相同的性能，在范围查询中具有正常的双精度。这就是为什么我建议测试 4 的precisionStep。

问题：这对于双精度值实际上意味着什么？

【问题讨论】：

您的 tdouble 字段使用什么precisionStep？系统方面，是否有一些内存留给操作系统缓存？能否分享一下系统的内存总量、分配给 JVM 的内存量以及索引的大小（以字节为单位）？
@jpountz：查看更新的问题，只是不确定如何获取索引大小。
在 unix 下，只需运行 du -hs indexDir。在 Windows 下，我认为您可以通过右键单击索引目录上的属性来实现。

标签： java performance solr lucene

【解决方案1】：

在响应您的空间查询时拥有 Solr 配置文件将有助于了解什么是慢速，例如，请参阅 hprof。

不过，这里有一些关于如何（也许）改善延迟的想法。

首先，您可以尝试测试减小 precisionStep 时会发生什么（例如尝试 4）。如果纬度和经度彼此太近并且precisionStep太高，Lucene就无法利用多个索引值。

您还可以尝试为 JVM 分配更少的内存，以便让操作系统缓存有更多机会缓存经常访问的索引文件。

然后，如果它仍然不够快，您可以尝试将替换 TrieDoubleField 作为子字段扩展为将使用a frange query 用于 getRangeQuery 方法的字段类型。这将减少磁盘访问次数，同时以更高的内存使用为代价计算范围。（我从未测试过它，它也可能提供糟糕的性能。）

【讨论】：

嗨，你能解释一下“如果纬度和经度彼此太近并且精度步长太高，Lucene 无法利用多个索引值”是什么意思。在我的特殊情况下，我正在创建一个范围从 1 英里到 20 英里的边界框（我猜 1 英里和 5 英里是最常见的，但我还没有专门检查过）。
由于我的索引在磁盘上占用了 11GB，我是否应该假设操作系统缓存整个内容所需的时间大致相同？磁盘上的索引大小是否考虑了存储字段，还是严格索引？我知道我看到的一个建议是将存储的字段减少为文档键，然后在 SOLR 之外管理文档（即仅在 solr 中进行索引）。
另外，你能评论一下geohash吗？它似乎是一种替代实现（即只需更改 schema.xml），然后将 bbox 过滤器查询指向 geohash 字段。
precisionStep 为 8 的 tdouble 意味着您的双精度将被拆分为 8 位序列。如果您所有的纬度和经度仅相差最后一个 8 位序列，那么 tdouble 将具有相同的性能，并且在范围查询中具有正常的双精度。这就是为什么我建议测试 4 的precisionStep。
如果你的索引是 11G，那么 OS 缓存可能会缓存所有内容，这里没问题。但同样，我们在猜测。拥有个人资料数据将有助于找到瓶颈。