elasticsearch5.x之Slice scroll

1.背景

在使用ES的过程中，存在进行深度分页的需求，但是ES深度分页会占用大内存，吞吐量提升很难，因此进行调研ES特性，找到解决深度分页或者满足此类需求的解决方法。

2.具体

2.1 Sliced Scroll

开始支持的最小版本：5.0.0

2.2 Search After

由于对数据实时性没有严格的要求，因此暂时没有使用这个功能；下面的测试是Sliced Scroll

2.3 压测及结论

2.3.1 环境搭建

在三台虚拟机上面安装一个Es5.x集群；

2.3.2 压测报告

测试报告

任务：10个线程各自读取19966360个doc
searchWithScroll
15:23:44
15:51:48
总耗时：28分钟

任务：10个线程各自读取19966360个doc
fromsize
16:04:06
16:10:58
运行到16:10:58时，获取的量为3200000，此刻服务端内存溢出
总耗时：不可用

任务：10个线程各自读取19966360个doc
searchSliceWithScroll
16:51:06
17:07:16
总耗时：16分钟

任务：10个线程各自读取19966360个doc(特殊说明：切片数为10，shard数为5，切片数大于shard数)
searchSliceWithScroll
09:58:31
10:10:48
总耗时：12分钟

10:24:46
10:36:04
总耗时：12分钟

任务：10个线程各自读取19966360个doc(特殊说明：切片数为5，shard数为5，切片数等于shard数)
searchSliceWithScroll
10:37:44
10:49:23
总耗时：12分钟

10:52:12
11:05:09
总耗时：13分钟

———————采用默认的uid来进行切片————————–
任务：10个线程各自读取19966360个doc(特殊说明：切片数为5，shard数为5，切片数等于shard数)
searchSliceWithScroll
13:41:06
13:52:42
总耗时：11分钟

13:55:02
14:07:00
总耗时：11分钟

结论：使用searchSliceWithScroll替代fromsize；另外，Sliced默认采用的uid切片和单独创建一个整形字段来切分对内存和cpu的影响区别不大（从公司的falcon监控上从测试中观察到）；

注意：虽然Scroll相对fromsize较好，但是要也要注意服务保护，保护es集群的可用和稳定；

参考：https://github.com/elastic/elasticsearch/blob/148f9af5857f287666aead37f249f204a870ab39/docs/reference/search/request/search-after.asciidoc

参考：http://www.infoq.com/cn/news/2016/08/Elasticsearch-5-0-Elastic