GET操作只能对单个文档进行处理，由_index、_type和_id三元组来确定唯一文档。但搜索需要一种更复杂的模型，因为不知道查询会命中哪些文档。
找到匹配文档仅仅完成了搜索流程的一半，因为多分片中的结果必须组合成单个排序列表。集群的任意节点都可以接收搜索请求，接收客户端请求的节点称为协调节点。在协调节点，搜索任务被执行成一个两阶段过程，即query then fetch。真正执行搜索任务的节点称为数据节点。
需要两个阶段才能完成搜索的原因是，在查询的时候不知道文档位于哪个分片，因此索引的所有分片（某个副本）都要参与搜索，然后协调节点将结果合并，再根据文档ID获取文档内容。例如，有5个分片，查询返回前10个匹配度最高的文档，那么每个分片都查询出当前分片的TOP 10，协调节点将5×10 = 50的结果再次排序，返回最终TOP 10的结果给客户端。
一个简单的搜索请求示例如下：
在上面的例子中，我们从所有字段搜索“first”关键词，返回信息中几个基本字段的含义如下：
- took代表搜索执行时间（单位：毫秒）；
- total代表本次搜索命中的文档数量；
- max_score为最大得分，代表文档匹配度；
- hits为搜索命中的结果列表，默认为10条。
1、索引和搜索
ES中的数据可以分为两类：精确值和全文。
- 精确值，比如日期和用户id、IP地址等。
- 全文，指文本内容，比如一条日志，或者邮件的内容。
这两种类型的数据在查询时是不同的：对精确值的比较是二进制的，查询要么匹配，要么不匹配；全文内容的查询无法给出“有”还是“没有”的结果，它只能找到结果是“看起来像”你要查询的东西，因此把查询结果按相似度排序，评分越高，相似度越大。
对数据建立索引和执行搜索的原理如下图所示：
1.1 建立索引
如果是全文数据，则对文本内容进行分析，这项工作在 ES 中由分析器实现。分析器实现如下功能：
- 字符过滤器。主要是对字符串进行预处理，例如，去掉HTML，将&转换成and等。
- 分词器（Tokenizer）。将字符串分割为单个词条，例如，根据空格和标点符号分割，输出的词条称为词元（Token）。
- Token过滤器。根据停止词（Stop word）删除词元，例如，and、the等无用词，或者根据同义词表增加词条，例如，jump和leap。
- 语言处理。对上一步得到的Token做一些和语言相关的处理，例如，转为小写，以及将单词转换为词根的形式。语言处理组件输出的结果称为词（Term）。分析完毕后，将分析器输出的词（Term）传递给索引组件，生成倒排和正排索引，再存储到文件系统中。
1.2 执行搜索
搜索调用Lucene完成，如果是全文检索，则：
- 对检索字段使用建立索引时相同的分析器进行分析，产生Token列表；
- 根据查询语句的语法规则转换成一棵语法树；
- 查找符合语法树的文档；
- 对匹配到的文档列表进行相关性评分，评分策略一般使用TF/IDF；
- 根据评分结果进行排序。
2、Search Type
ES目前有两种搜索类型：
- DFS_QUERY_THEN_FETCH；
- QUERY_THEN_FETCH（默认）。
两种不同的搜索类型的区别在于查询阶段，DFS查询阶段的流程要多一些，它使用全局信息来获取更准确的评分。
本章的流程分析默认搜索类型。下面我们仍旧按照请求涉及的节点来分析流程，搜索流程涉及两个节点：协调节点和数据节点。
3、分布式搜索过程
一个搜索请求必须询问请求的索引中所有分片的某个副本来进行匹配。假设一个索引有5个主分片，每个主分片有1个副分片，共10个分片，一次搜索请求会由5个分片来共同完成，它们可能是主分片，也可能是副分片。也就是说，一次搜索请求只会命中所有分片副本中的一个。
当搜索任务执行在分布式系统上时，整体流程如下图所示：
3.1 协调节点流程
两阶段相应的实现位置：查询（Query）阶段：search.InitialSearchPhase；取回（Fetch）阶段：search.FetchSearchPhase。
它们都继承自SearchPhase，如下图所示：
Query阶段
在初始查询阶段，查询会广播到索引中每一个分片副本（主分片或副分片）。每个分片在本地执行搜索并构建一个匹配文档的优先队列。
优先队列是一个存有topN匹配文档的有序列表。优先队列大小为分页参数from + size。
分布式搜索的Query阶段（图片来自官网）如下图所示：
QUERY_THEN_FETCH搜索类型的查询阶段步骤如下：
- 客户端发送search请求到NODE 3。
- Node 3将查询请求转发到索引的每个主分片或副分片中。
- 每个分片在本地执行查询，并使用本地的Term/Document Frequency信息进行打分，添加结果到大小为from + size的本地有序优先队列中。
- 每个分片返回各自优先队列中所有文档的ID和排序值给协调节点，协调节点合并这些值到自己的优先队列中，产生一个全局排序后的列表。
协调节点广播查询请求到所有相关分片时，可以是主分片或副分片，协调节点将在之后的请求中轮询所有的分片副本来分摊负载。
查询阶段并不会对搜索请求的内容进行解析，无论搜索什么内容，只看本次搜索需要命中哪些shard，然后针对每个特定shard选择一个副本，转发搜索请求。
Fetch阶段
Query阶段知道了要取哪些数据，但是并没有取具体的数据，这就是Fetch阶段要做的。
分布式搜索的Fetch阶段（图片来自官网）如下图所示：
Fetch阶段由以下步骤构成：
- 协调节点向相关NODE发送GET请求。
- 分片所在节点向协调节点返回数据。
3.协调节点等待所有文档被取得，然后返回给客户端。
分片所在节点在返回文档数据时，处理有可能出现的_source字段和高亮参数。
协调节点首先决定哪些文档“确实”需要被取回，例如，如果查询指定了{ ＂from＂: 90, ＂size＂:10 }，则只有从第91个开始的10个结果需要被取回。
为了避免在协调节点中创建的number_of_shards * （from + size）优先队列过大，应尽量控制分页深度。
3.2 执行搜索的数据节点流程（略）
4、小结
- 聚合是在ES中实现的，而非Lucene。
- Query和Fetch请求之间是无状态的，除非是scroll方式。
- 分页搜索不会单独“cache”,cache和分页没有关系。
- 每次分页的请求都是一次重新搜索的过程，而不是从第一次搜索的结果中获取。看上去不太符合常规的做法，事实上互联网的搜索引擎都是重新执行了搜索过程：人们基本只看前几页，很少深度分页；重新执行一次搜索很快；如果缓存第一次搜索结果等待翻页命中，则这种缓存的代价较大，意义却不大，因此不如重新执行一次搜索。
- 搜索需要遍历分片所有的Lucene分段，因此合并Lucene分段对搜索性能有好处。
