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集群的可用和稳定；
参考：http://www.infoq.com/cn/news/2016/08/Elasticsearch-5-0-Elastic