es的数据存储结构；近实时查询原因

概述

es存储中大体可以看成index(表) + document（行记录）组成

es支持分布式存储，一个index会产生多个分片，保存在不同的实例上。其中分为若干个主分片和副分片。当主分片挂了，会切换到副分片，主分片和副分片的数据是一致的（写的时候先找主分片，读的时候是2者都可以）。这个切换的过程由es集群节点中的leader决定。如果当前的leader挂了，会选举出一个新leader。

es读和写的过程(近实时查询原因)

写：客户端会选择一个node节点**（协调节点）**请求过去，然后节点会对这个document数据进行路由，转发给对应的主分片所在node上。实际处理的node处理完之后会同步到副分片所在节点。主分片和副分片都完成之后，响应客户端处理成功。

这里的写只是写到了FileSystem Cache；即es和磁盘中间的一层缓存。将数据刷到磁盘需要一个fsync操作，这个操作是比较耗时的，要是每条数据写入都同步触发，那性能太差了。

所以在es中新增的document会被收集到indexing buffer区后被重写成一个segment然后直接写入filesystem cache中，这个操作是非常轻量级的，相对耗时较少，之后经过一定的间隔或外部触发后才会被flush到磁盘上，这个操作非常耗时。但只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到，而不用执行一个full commit也就是fsync操作，这是一个非常轻量级的处理方式而且是可以高频次的被执行，而不会破坏es的性能

在elasticsearch里面，这个轻量级的写入和打开一个cache中的segment的操作叫做refresh，默认情况下，es集群中的每个shard会每隔1秒自动refresh一次，这就是我们为什么说es是近实时的搜索引擎而不是实时的，也就是说给索引插入一条数据后，我们需要等待1秒才能被搜到这条数据，这是es对写入和查询一个平衡的设置方式，这样设置既提升了es的索引写入效率同时也使得es能够近实时检索数据。

读（根据id读）：读取数据也是先选一个node节点**（协调节点）**发请求过去，节点会把id进行hash，转发到实际的node中，然后在主分片和副分片中随机轮询进行查询。

搜索原理

搜索：es的搜索主要依靠的就是倒排索引，开始也是客户端选择一个node节点**（协调节点）**请求过去，然后转发到所有的shard分片对应的主/副分片，每个分片将搜索对应的document id和score等信息返回给一开始的协调节点，然后协调节点排序完之后根据id拿到对应的document数据再返回给客户端。

深度分页问题

分页：es的分页在深度分页下性能会很差，比如查询10000页的1000条数据，es的协调节点会从所有分片中拉取10000条到协调节点，即总数据=分片数量X10000.然后在协调节点里处理得到最后的1000条数据。