ES原理总结

—ES写数据：
ES里写的流程，有四个底层的核心概念：refresh、flush、translog、merge

—ES读数据的过程

查询—GET到某一条数据
（1）可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。
（2）客户端发送请求到任意一个 node，成为 coordinate node 。
（3）coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin 随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
（4）接收请求的 node 返回 document 给 coordinate node 。
（5）coordinate node 返回 document 给客户端。

—搜索 全文检索
客户端发送请求到协调节点
协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ，都可以。

query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id ）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

–ES在数据量很大的情况下如何提高查询效率

（1）性能优化的杀手锏 – filesystem cache
减少数据量仅仅放要用于搜索的几个关键词即可，尽量写入的数据跟es机器的filesystem cache是差不多的就可以了。

（2）数据预热
把搜索频率比较高的数据定时放到filesystem cache中。

（3）冷热分离
做类似mysql的水平拆分，就是将大量的访问很少，单独写一个索引，然后将很频繁热数据单独写一个索引，频繁热数据全部放到缓存中，冷数据放到磁盘上。

（4）document模型设计
设计es中的数据模型

（5）分页的性能优化

a、不允许深度分页（默认深度分页性能很差）
b、类似于app中的不断一页一页的，不能挑选页跳转，也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据
可以用scroll api

简单介绍下生产环境es集群的架构情况

（1）es生产集群部署了5台数据，每台机器是6核64G的，集群总内存是320G
（2）es集群的日增量数据大概是2000万条数据，每天日增量数据大概是500MB,每月增量数据大概是6亿15G，系统已经几个月，大概数据总量是100G左右。
（3）目前线上大概是有5个索引。每个索引的数据量大概是20G，所以这个数据量之内，每个索引分配的是8个shard,比默认的5个shard多个3个shard。