java – solr空间不良表现

发布时间：2020-12-15 02:32:12 所属栏目：Java 来源：网络整理

导读：我正在使用SOLR-3.4,使用具有LatLonType(subType = tdouble)的模式进行空间过滤.我有一个约20M的索引.我的基本问题是,如果我使用cache = true执行bbox过滤器,性能相当不错(~40-50 QPS,大约100-150ms延迟),但是一个很大的缺点是疯狂的快速老一代堆增长最终导

我正在使用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：

A tdouble with precisionStep of 8 means that your doubles will be splitted in sequences of 8 bits. If all your latitudes and longitudes only differ by the last sequence of 8 bits,then tdouble would have the same performance has a normal double on a range query. This is why I suggested to test a precisionStep of 4.

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

解决方法

在响应空间查询时获取Solr的配置文件对于理解什么是慢速有很大帮助,例如参见 hprof.

不过,这里有一些关于如何(或许)改善延迟的想法.

首先,您可以尝试测试在减少precisionStep时会发生什么(例如尝试4).如果纬度和经度彼此太接近并且precisionStep太高,Lucene就无法利用具有多个索引值的优势.

您还可以尝试为JVM提供更少的内存,以便为操作系统缓存提供更多机会来缓存经常访问的索引文件.

然后,如果它仍然不够快,您可以尝试通过将a frange query用于getRangeQuery方法的字段类型将TrieDoubleField替换为子字段.这将减少磁盘访问次数,同时以更高的内存使用量为代价计算范围. (我从来没有测试过它,它也可能提供可怕的性能.)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!