本文目录一览：
- 1、java查询的分页思路！！
- 2、ES 深度分页scroll使用方式
- 3、怎么用spring获取es数据
- 4、ES深度分页与批量操作
- 5、ElasticSearch第5天 es实现分页查询的几种方式
java查询的分页思路！！
分页显示一般有两种实现方式：业务层分页、数据库层分页（以下会用到两个参数，提前说明下 page：请求第几页，size：每页显示多少条）
业务层分页：从数据库取出所有数据，然后通过传过来的page和size对所有数据截取，比如一共查了100条数据，保存在list里面，要求查询第2页，每页显示10条，则可以通过list属性，取100条数据 中的第11条到第20条，可通过遍历实现。
数据库层分页：数据库都会有分页函数（mysql 是limit函数，sqlServer是row_number()函数，可自行百度下）该方法是通过传过来的page和size在查询数据库时就开始分页，以mysql为例，查询第2页，每页显示10条，则sql语句是 ”select * from XX limit 10,10“(第一个10表示从下标为10开始查，第二个10是共读取10条)
性能肯定是第二种分页方式好，只要搞懂分页原理，想实现分页其实很简单，只要搞清楚分页是将多条数据中的某几条挑出来
ES 深度分页scroll使用方式
我们知道ES对于from+size的个数是有限制的，二者之和不能超过1w。当所请求的数据总量大于1w时，可用scroll来代替from+size。
首次查询使用方式如下：
接下来的查询方式如下：
如果你对scroll取出的数据顺序没有要求的话，则可以对“_doc”进行排序，es对这种排序做了优化。使用方式如下：
如果你想通过slice并行分片查询的话，可以这样设置：
两个请求可以同时运行。但是这样做会有个缺陷，内存占用较大，且第一次查询很慢。因为查询是O(N)的复杂度且每个slice占用N个bits，N是shard的总文档数。之后缓存的数据将加快查询。
为了避免上述情况，可以选择一个doc_values做slice，但是必须要确保这个field有以下特性：
在第一次查询时，记录上一次查询的位置，在接下来的查询中获取到上次查询的位置，接着查询。
比如说将查询order by time offset 0 limit 100，改写成order by time where time0 limit 100，记录最后一个$time_max,接下来的查询order by time offset 100 limit 100，改写成order by time where time$time_max limit 100。如此往复，可以看出scroll是一个常量查询延迟和开销，并无什么副作用。
关于scroll 和search after的详细信息，请看 .
对应到java api中，可用addSort("_doc", SortOrder.ASC)代替。
怎么用spring获取es数据
1. ES和solr都是作为全文搜索引擎出现的。都是基于Lucene的搜索服务器。
2. ES不是可靠的存储系统，不是数据库，它有丢数据的风险。
3. ES不是实时系统，数据写入成功只是trans log成功（类似于MySQL的bin log），写入成功后立刻查询查不到是正常的。因为数据此刻可能还在内存里而不是进入存储引擎里。同理，删除一条数据后也不是马上消失。写入何时可查询？ES内部有一个后台线程，定时将内存中的一批数据写入到存储引擎，此后数据可见。默认后台线程一秒运行一次。该线程运行的越频繁，写入性能越低。运行的频率越低，写入的性能越高（不会无限高）。
4. 目前已知的单ES集群可以存储PB级别的数据，不过这个就非常费劲了。TB级别数据没压力。
5. 如果使用ES官方提供的jar包访问，需要JDK1.7及以上。
6. 使用对应的版本访问ES server。如果ES server端的版本是1.7，那么请使用ES 1.7的client。如果ES server是2.1，请使用2.1的client。
7. ES索引存在Linux服务器的文件系统之上（背后是文件系统，不是类似于HDFS的分布式文件系统）
8. ES Java client是线程安全的，全局构建一个即可满足读写需求，不要每次都创建ES client。每次访问ES都构建新的es client即会抛出次异常。
9. 非常不建议使用ES的动态识别和创建的机制，因为很多情况下这并非你所需要。推荐的做法是在写数据之前仔细的创建mapping。
10. 强烈不建议在ES中使用深分页。可能会导致集群不可用。
11. ES是静态分片，一旦分片数在创建索引时确定那么后继不能修改。
12. ES里提供了type，很多人以为type是物理表，一个type的数据是独立存储的；但是在ES内部并不是这样，type在ES内部仅仅是一个字段。所以在很多数据能分为独立index的情况下，不要放到一个index里用type去分。只有嵌套类和父子类的情况下使用type才是合理的。
13. ES并不提供原生的中文分词的能力。有第三方的中文分词的插件，比如ik等。Ik是个toy分词器，有严肃的分词需求的话，请在使用ES之前使用独立的分词器分好词后向ES写入。
14. ES中的index，首先会进行分片，每一个分片数据一般都会有自己的副本数据，ES分配分片的策略会保证同一个分片数据和自己的副本不会分配到同一个节点上。当集群中的某一节点宕机后，ES的master在ping该节点时通过一定的策略会发现该节点不存活；会开启ES的恢复过程
15. ES没有update的能力。所有的update都是标记删除老文档，然后重新insert一条新文档。
ES深度分页与批量操作
一、分页查询
1.普通分页查询
2.深度分页
其实就是搜索的深浅度，比如第一页、第二页、第二十页等等，是浅分页。第一万页，第两万页等就是很深了
我们在获取第9999条到10009条数据的时候，其实每个分片都会拿到10009条数据，然后集合在一起，总共是30027条数据，针对这些数据再做排序处理，最后获得十条数据。
如此一来，搜索的太深，就会造成性能问题，会耗费内存和占用cpu。而且es为了性能，也不支持超过一万条数据以上的分页查询。解决深度分页问题，就是应该避免深度分页的操作（限制分页页数）。比如最多提供100页的展示等。
3.scroll滚动搜索
滚动搜索可以先查询出一些数据，然后再紧接着以此往下查询。在第一次查询的时候会有一个滚动id，相当于一个锚标记，随后再次滚动搜索需要上次的标记。每次搜索都是基于一个历史的数据快照，在查询期间，如果有数据变更，所有的内容不会变化
4.批量查询mget
未命中的结果也会返回json显示是否有值。
POST /_doc/_mget
{
"ids":[
"1008",
"1007",
"555"
]
}
ElasticSearch第5天 es实现分页查询的几种方式
es实现分页查询，在ES中有三种方式可以实现分页：from+size、scroll、search_after
这种分页方式虽然查询变快了，但滚动上下文代价很高，每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上,那么在实时情况下如果处理深度分页的问题呢？es 给出了 search_after 的方式，这是在 = 5.0 版本才提供的功能。
searchAfter的方式通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景。
search_after的理念是，=在不同分片上（假设有5个分片），先按照指定顺序排好，根据我们传的search_after值 ，然后仅取这个值之后的size个文档。这 5*size 个文档拿到Es内存中排序后，返回前size个文档即可。避免了浅分页导致的内存爆炸情况，经实际使用性能良好,ES空闲状态下查询耗时稳定在50ms以内，平均10~20ms。
ElasticSearch之Search_After的注意事项
1.搜索时，需要指定sort,并且保证值是唯一的（可以通过加入_id或者文档body中的业务唯一值来保证）；
2.再次查询时，使用上一次最后一个文档的sort值作为search_after的值来进行查询；
3.不能使用随机跳页，只能是下一页或者小范围的跳页（一次查询出小范围内各个页数，利用缓存等技术，来实现小范围分页，比较麻烦，比如从第一页调到第五页，则依次查询出2,3,4页的数据，利用每一次最后一个文档的sort值进行下一轮查询，客户端或服务端都可以进行，如果跳的比较多，则可能该方法并不适用）
它与滚动API非常相似，但与它不同，search_after参数是无状态的，它始终针对最新版本的搜索器进行解析。因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除
from+ size 分页，如果数据量不大或者from、size不大的情况下，效率还是蛮高的。但是在深度分页的情况下，这种使用方式效率是非常低的，并发一旦过大，还有可能直接拖垮整个ElasticSearch的集群。
scroll 分页通常不会用在客户端，因为每一个 scroll_id 都会占用大量的资源，一般是后台用于全量读取数据使用
search_after通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景，一般用于客户端的分页查询
大体而言就是在这三种分页方式中，from + size不适合数据量很大的场景，scroll不适合实时场景，而search after在es5.x版本之后应运而生，较好的解决了这个问题。
