es加快查询速度的小套路

一. es查询速度与内存的关系

当我们向es里面写数据的时候，实际上都会写到磁盘文件里面去，查询的时候，os会将磁盘文件里的数据自动缓存到file system cache中去。所以es的性能非常依赖机器的内存，当机器内存比较小的时候查询速度就会受到限制，如果我们给filesystem cache更多的内存，尽量让内存可以容纳所有的idx segment file索引数据文件，那么搜索的时候就基本是在走内存的，少了从磁盘随机io到内存中，查询速度立马变成ms级别。

二. 没有银弹的优化手段

所以从上面es查询速度与内存的关系我们知道，其实es性能优化是没有什么银弹的，就是不能期待着随手调一个参数就可以万能对应所有性能慢 的场景，但是可以通过一些合理的小技巧来加快es的查询速度。

1. 不必缓存所有的字段信息

比如用户信息可能有很多字段，我们只会根据name，age去进行查询，那么我们没必要把其余的字段也保存到es，我们可以只写入name，age，存入es，这样使用filesystem cache内存就大大减少。然后其它字段用doc id关联存在hbase里面，hbase的特点适用于海量数据的在线存储，就是对hbase可以写入海量数据，但是不要做复杂的搜索，做一些简单的根据id搜索就很快，所以查询es的我们根据name，age查询es的doc id，再去hbase根据doc id里面查询所有信息。
之前如果整条消息走的es的磁盘查询到缓存再返回可能需要几秒，但是只根据name或者age查询doc id走的是filesystem cache缓存 + 根据doc id查询hbase里面所有的信息，时间大概就在几十毫秒。

2. 数据预热

比如在电商系统里面，可以将平时查看多的商品，提前用后台程序主动去访问es里面这些数据，这样数据就进入了filesystem cache里面，用户再去访问的时候性能会好很多。
@[TOC] #### 3.冷热分离
es可以做类似于mysql中的水平拆分，就是说将访问很频繁的热数据单独写入一个索引，将反问很少频率很低的大量数据单独写入一个索引。这样预热后让他们留在filesystem cache，不会被冷数据刷掉。

3. 文档模型的合理设计

因为es这种nosql是直接聚合数据的，比如订单信息文档，可能就有用户的大部分信息，也有商品的信息，还有交易的信息，这样设计是因为es里面对复杂的关联查询不友好。
所以文档模型设计是非常重要的，很多操作不要等到在搜索的时候才去想执行那些复杂关联查询的骚操作，而是在写的时候直接关联好写进去。

4.坑爹的深度分页

因为es的分布式属性，比如我要查第80页的10条数据，假如我们有10分片，不可能说从各个分片就查1条数据，而是需要从每个分片都查询800条数据过来，然后根据查询需求进行排序筛选等操作，翻的页越多，每个分片返回的数据就越多，所以如果翻前几页的时候可能很快就出来了，翻的页多了，就越来越慢了。
但是可以使用scroll api进行一个下拉分页，就是类似于微博，向下刷出来一页一页的数据。