elasticsearch外用与内观(三)-当搜索时，elasticsearch都在做什么(上)

  在了解了es的存储之后，我们再来看看es的搜索过程。

  因为插入的文档是被分散存储到不同分片上的，所以搜索采用两阶段查询方式，
query阶段 和 fetch阶段。

我们在发起搜索请求的时候，query命令被发到任意一个节点上，这个节点就是这个请求的协调节点：

51.png

再由协调节点决定把请求分发给哪些分片:

52.png

这时不区分是主分片还是副本分片，因为不管是什么样的分片，都是lucene实例，都可以提供搜索功能，这也是副本越多系统吞吐量越高的原因，每个分片都执行同一个query，在本地生成一个长度为from+size的优先队列（priority queue ）：

53.png

优先队列自身就实现了排序功能，然后各个分片的队列返回给协调节点:

54.png

协调节点合拿到有分片返回的优先队列之后，进行汇总：

55.png

比如搜索条件里设置{ "from"是 90, "size"是 10 }，那么在获取到100条数据后，把前90个id丢掉，只留后10个id:

56.png

因为Query阶段是轻量级的并不需要获取真实的数据，只需要获取满足条件的【doc id列表】即可，这样即使有100万个文档，但是获取的只是doc id列表并不需要占用多少内存。

有了doc id之后，进入fetch阶段:

57.png

fetch阶段通过query阶段的返回的doc id列表，由协调节点发起多个get请求到多个分片上，同样不区分主副分片，在收到每个分片返回的结果后，由协调节点进行组装并返回给客户端，这样就完成了整个搜索操作。

搜索速度的快慢，是由倒排索引的效率决定的，所以为了更快的搜索，es需要把磁盘里的倒排索引加载到内存中进行操作:

58.png

然而存储这么多倒排索引很费内存，所以es对倒排索引又做了一次压缩，然后再放入内存，他使用的是FST(Finite State Transducers)压缩方法，最后生成一个term index(分词的索引)放到内存。

FST压缩方法是这样的，比如:

有这样几个字符串，中国联通 中国移动 中国电信，正常存储是12个字符:

59.png

但是如果这样存储:

60.png

就可以少存储两个“中国”，这样就实现了压缩。

然后每个节点存一个这个分词的倒排索引在磁盘的具体位置，这样搜索时首先在term index中进行查找，然后再加载具体数据:

61.png

这样整体查询速度提升了，内存的占用也减少了。