倒排索引
ElasticSearch的搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合。例如文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置。那么，倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词。
分词：在value中提取出各个关键词的过程
| 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 | 1, 2, 3, 4, 5 | |
| 6 | 加盟 | 2, 3, 5 |
| 7 | 创始人 | 3 |
| 8 | 拉斯 | 3, 5 |
| 9 | 离开 | 3 |
| 10 | 与 | 4 |
| .. | .. | .. |
有了倒排索引，搜索引擎可以很快速地响应用户的查询。比如用户输入"地图"，通过倒排索引，可以快速的找到含有"地图"的文档是id为1, 2, 3, 4, 5，的文档。从而达到快速的全文检索的目的。
ES中的倒排索引
ES 在 term 的基础上利用 term 的前缀或者后缀构建了 term index, 用于对 term 本身进行索引，ES 实际的索引结构如下图所示
这样当我们去搜索某个关键词时，ES 首先根据它的前缀或者后缀迅速缩小关键词的在 term dictionary 中的范围，大大减少了磁盘IO的次数。
单词词典（Term Dictionary)：记录所有文档的单词，记录单词到倒排列表的关联关系
倒排列表(Posting List)-记录了单词对应的文档结合，由倒排索引项组成。
倒排索引项(Posting)：
- 文档ID；
- 词频TF–该单词在文档中出现的次数，用于相关性评分；
- 位置(Position)-单词在文档中分词的位置。用于短语搜索（match phrase query)；
- 偏移(Offset)-记录单词的开始结束位置，实现高亮显示；
全文检索的实现流程
ES可以理解为是一个分布式的存储和检索系统，在存储的时候默认是根据每条记录的_id字段做路由分发的，这意味着es服务端是准确知道每个document分布在那个shard上的。相对而言search是一个比较复杂的执行模式，因为我们不知道那些document会被匹配到，任何一个shard上都有可能，所以一个search请求必须查询一个索引或多个索引里面的所有shard才能完整的查询到我们想要的结果。
找到所有匹配的结果是查询的第一步，来自多个shard上的数据集在分页返回到客户端的之前会被合并到一个排序后的list列表，由于需要经过一步取top N的操作，所以search需要进过两个阶段才能完成，分别是query和fetch。
query（查询阶段）
- 客户端发送search请求到NODE 3。
- Node 3将查询请求转发到索引的每个主分片或副分片中。
- 每个分片在本地执行查询，并使用本地的Term/Document Frequency信息进行打分，添加结果到大小为from + size的本地有序优先队列中。
- 每个分片返回各自优先队列中所有文档的ID和排序值给协调节点，协调节点合并这些值到自己的优先队列中，产生一个全局排序后的列表。
注意：协调节点它的职责是广播search请求到所有相关的shard上，然后合并他们的响应结果到一个全局的排序列表中然后进行第二个fetch阶段，注意这个结果集仅仅包含docId和所有排序的字段值，search请求可以被主shard或者副本shard处理，这也是为什么我们说增加副本的个数就能增加搜索吞吐量的原因，协调节点将会通过round-robin的方式自动负载均衡。
fetch（读取阶段）
- 协调节点标识了那些document需要被拉取出来，并发送一个批量的mutil get请求到相关的shard上。
- 每个shard加载相关document，如果需要他们将会被返回到协调节点上。
- 一旦所有的document被拉取回来，协调节点将会返回结果集到客户端上。
