Deep paging problem of solr, start设置越大查询越慢

进行solr查询时,如果查询结果很多而且业务需求需要全部返回时,传统的搜索引擎都会遇到一个棘手的问题:deep paging problem,即当翻页查询越多时,查询响应时间越长。传统的搜索服务如Baidu,Google 一般只提供1000以内的查询结果共用户查阅,如果需要更多的查询结果,用户可以输入更多的查询语句进行筛选。

下面利用Apache Solr进行deep page查询的性能测试:
【测试数据】:规模: 499W,内容一样(饲荆泞琴哇尘自缕勇恩本灾却咀功害鳃踪羽甲沏馏铆级奉耻陷下龄周),时间不同。
【机器性能】:64G内存 Linux-Suse
【测试一,翻页查询499W所有结果】
查询条件为rows为10000,timeAllowed为86400000 (即为一天), content为 饲荆泞琴哇尘自缕,进行rows=1W的翻页查询,查询的相应时间如下:

原始结果数据
单次查询结果数 单次查询耗时/ms 查询后结果总数
10000 1585 10000
10000 1585 20000
10000 1682 30000
10000 1818 40000
10000 1934 50000

10000 100138 4950000
10000 98741 4960000
10000 99211 4970000
10000 101182 4980000
10000 101054 4990000

返回499W查询结果总耗时 6.8小时,耗时相当惊人,而且根据单次查询时间的线性增长可知总体响应时间会呈指数增长趋势。

解决deep page问题带来的困扰,一个最有效的方法就是避开deep page问题进行查询。避开的方法有很多,例如时间,地域,或其他任何限制信息进行切片,基于此思路进行测试二:
【测试二,根据startTime进行时间分片,保证时间范围内的数据小于10W,片内再进行1W的翻页查询】
基本思路采用递归,由于进行结果数查询并不耗时,如果结果数大于阈值便进行时间二分,如此递归下去即可,查询的相应时间如下:
单次查询结果数 单次查询耗时/ms 查询后结果总数
10000 1482 10000
10000 1432 20000
10000 2008 30000
5802 1136 35802
10000 1828 45802

10000 1266 4953504
10000 2112 4963504
10000 1482 4973504
10000 2034 4983504
6496 2031 4990000

返回499W查询结果总耗时 0.29小时,关键优点是查询时间保持了线性增长。
对上面的两组试验数据进行绘图对比,首先对比测试取单条的相应时间:

可以看出,进行deep page查询的响应时间基本是呈线性增长,而进行time slice的查询时间基本保持不变。
然后对比取回所有结果的相应时间:

可以看出,进行deep page查询所有结果数,响应时间呈指数级增长,而进行time slice的查询响应时间基本是线性增长的。

原文出自:http://jacoxu.com/?p=608

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>