ES为什么那么快？除了倒排索引还有哪些原因？

前言

Elastic Search是什么这里就不多少了，今天主要来探究一下ES为什么搜索那么快。

架构上

先来复习一下ES的架构：Cluster - Node - ES Index - Shard(Lucene Index) - Segment
首先最大的概念是Cluster集群，ES是天然的分布式架构，由多台机器组成。每一台机器称为一个Node节点，节点内保存着多个Index的部分Shard。每个Shard实际上是一个Lucene Index，里面被分成了数个Segment，而Segment即为我们存储数据的最小单位。

我们将一个Index分成了多个Shard，分布在不同的机器上，这样的好处一个是横向扩展比较容易了，增加Shard就好了（并不是简单的增加Shard，需要创建更多Shard的Index，并将数据复制过去，这是因为Shard的数量关系到文档应保存到哪里，详见分片的路由机制，另一种扩容的方法是将Shard存放到不同的Node，这样实际上增加了Shard的容量），另一个好处就是我们搜索性能的增加。因为不同的Shard分布在不同的Node，因此可以多进程并发的去搜索各个Shard，提高了吞吐量和性能。

另外，我们的Node可分为主节点（维护索引元数据、负责切换Shard主从身份），数据节点和客户端节点（请求的分发与结果的汇总），此外还有协调节点的概念，负责转发索引请求到对应的Shard。每个节点都知道集群中任意文档的位置，因此每个节点都可作为协调节点，即每个节点都可响应客户端的请求，这也在客观上提高了系统的并发能力。协调节点会使用负载均衡的算法将查询请求分发到主从Shard上，来进行读请求的负载均衡。

资源争夺上：

ES采用乐观并发控制，避免了加锁导致的正在尝试的操作的blocked，通过_version字段来保证并发情况下的正确性。

同时，ES本身基于的Lucene库在底层将数据分为segment，几乎避免了锁的出现，大大的提升了读写效率。

搜索方式上：

我们知道ES使用倒排索引，那么其具体是如何实现的呢？又如何充分利用有限的内存来加速索引呢？

对于倒排索引，实际上就是维护了一个关键字到文档的对应关系：

DocId	Doc
1	谷歌地图之父跳槽 Facebook
2	谷歌地图之父加盟 Facebook
3	谷歌地图创始人拉斯离开谷歌加盟 Facebook
4	谷歌地图之父跳槽 Facebook 与 Wave 项目取消有关
5	谷歌地图之父拉斯加盟社交网站 Facebook

维护成：

WordId	Word	DocIds
1	谷歌	1, 2, 3, 4, 5
2	地图	1, 2, 3, 4, 5
3	之父	1, 2, 4, 5
4	跳槽	1, 4
5	Facebook	1, 2, 3, 4, 5
6	加盟	2, 3, 5
7	创始人	3
8	拉斯	3, 5
9	离开	3
10	与	4
…	…	…

可见为每个 field 都建立了一个倒排索引。Posting list就是一个int的数组，存储了所有符合某个term的文档id。实际上，除此之外还包含：文档的数量、词条在每个文档中出现的次数、出现的位置、每个文档的长度、所有文档的平均长度等，在计算相关度时使用。
更进一步的，我们将word按照字典顺序排序，这样就能够以二分查找的方式找到目标值，时间复杂度为logN（访问磁盘次数），但是这实际上和MySQL的B+树的查询时间复杂度是一样的。

但是磁盘的随机读操作仍然是非常昂贵的（一次 random access 大概需要 10ms 的时间）。所以尽量少的读磁盘，有必要把一些数据缓存到内存里。但是整个 term dictionary 本身又太大了，无法完整地放到内存里。于是就有了 term index。term index 有点像一本字典的大的章节表。比如：

A 开头的 term ……………. Xxx 页
C 开头的 term ……………. Yyy 页
E 开头的 term ……………. Zzz 页

如果所有的 term 都是英文字符的话，可能这个 term index 就真的是 26 个英文字符表构成的了。但是实际的情况是，term 未必都是英文字符，term 可以是任意的 byte 数组。而且 26 个英文字符也未必是每一个字符都有均等的 term，比如 x 字符开头的 term 可能一个都没有，而 s 开头的 term 又特别多。实际的 term index 是一棵 trie 树。

这就是ES速度超过MySQL的原因：Mysql 只有 term dictionary 这一层，是以 b-tree 排序的方式存储在磁盘上的。检索一个 term 需要若干次的 random access 的磁盘操作。而 Lucene 在 term dictionary 的基础上添加了 term index 来加速检索，term index 以树的形式缓存在内存中。从 term index 查到对应的 term dictionary 的 block 位置之后，再去磁盘上找 term，大大减少了磁盘的 random access 次数。