Elastic Search

2024-10-29 17:44:49   1  举报





AI智能生成

Elastic Search是一个高度可扩展的开源搜索和分析引擎，用于处理海量数据。它支持全文搜索，结构化查询，和复杂的数据分析。Elastic Search以JSON格式存储数据，并允许进行实时索引和搜索。它具有出色的性能和易于使用的RESTful API，使其成为构建现代数据驱动应用的理想选择。

ElasticSearch

ES高可用

Elastic Stac

作者其他创作

大纲/内容

ES基础

是什么

Elaticsearch简称为ES，是一个开源的可扩展的分布式的全文检索引擎，它可以近乎实时的存储、检索数据。本身扩展性很好，可扩展到上百台服务器，处理PB级别的数据。ES使用Java开发并使用Lucene作为其核心来实现索引和搜索的功能，但是它通过简单的RestfulAPI和javaAPI来隐藏Lucene的复杂性。

为什么要有ES？（基于数据库查询的问题）

查询效率低，模糊查询数据库不会使用索引 （有些查询会导致索引失效）

查询的准确率不高 （功能弱）

功能

分布式搜索引擎

分布式：Elasticsearch自动将海量数据分散到多台服务器上去存储和检索 搜索：百度、谷歌，站内搜索

全文检索

提供模糊搜索等自动度很高的查询方式，并进行相关性排名，高亮等功能

数据的分析引擎（分组聚合）

电商网站，最近一周笔记本电脑这种商品销量排名top10的商家有哪些？新闻网站，最近1个月访 问量排名top3的新闻板块是哪些

对海量数据进行实时的处理

海量数据的处理：因为是分布式架构，Elasticsearch可以采用大量的服务器去存储和检索数据，自 然而然就可以实现海量数据的处理 近实时：Elasticsearch可以实现秒级别的数据搜索和分析

特点

speed  高速

相比较其它 的一些大数据引擎，Elasticsearch可以实现秒级的搜索，速度非常有优势。

scale 易扩展性

relevance 相关性

Elasticsearch是它搜索的结果可以按照分数进行排序，它能提供我们最相关的搜索结果

节点对等

支持超大量数据

可以扩展到 PB 级的结构化和非结构化数据 海量数据的近实时处理

企业使用场景

使用场景

搜索类场景

比如说电商网站、招聘网站、新闻资讯类网站、各种app内的搜索。

日志分析类场景

经典的ELK组合（Elasticsearch/Logstash/Kibana），可以完成日志收集，日志存储，日志分析查 询界面基本功能，目前该方案的实现很普及，大部分企业日志分析系统使用了该方案。

数据预警平台及数据分析场景

例如电商价格预警，在支持的电商平台设置价格预警，当优惠的价格低于某个值时，触发通知消 息，通知用户购买。  数据分析常见的比如分析电商平台销售量top 10的品牌，分析博客系统、头条网站top 10关注度、 评论数、访问量的内容等等。

商业BI（Business Intelligence）系统

比如大型零售超市，需要分析上一季度用户消费金额，年龄段，每天各时间段到店人数分布等信息，输出相应的报表数据，并预测下一季度的热卖商品，根据年龄段定向推荐适宜产品。 Elasticsearch执行数据分析和挖掘，Kibana做数据可视化。

常见案例

- 维基百科、百度百科：有全文检索、高亮、搜索推荐功能

- stack overflow 、CSDN：有全文检索，可以根据报错关键信息，去搜索解决方法。

- github：从上千亿行代码中搜索你想要的关键代码和项目。

- 日志分析系统：各企业内部搭建的ELK平台。

通用数据处理流程

主流全文搜索方案对比

Lucene

Lucene是Apache基金会维护的一套完全使用Java编写的信息搜索工具包（Jar包），它包含了索引结构、读写索引工具、相关性工具、排序等功能，因此在使用Lucene时仍需要我们自己进一步开 发搜索引擎系统，例如数据获取、解析、分词等方面的东西。 注意：Lucene只是一个框架，我们需要在Java程序中集成它再使用。而且需要很多的学习才能明 白它是如何运行的，熟练运用Lucene非常复杂。

Solr

Solr是一个有HTTP接口的基于Lucene的查询服务器，是一个搜索引擎系统，封装了很多Lucene细 节，Solr可以直接利用HTTP GET/POST请求去查询，维护修改索引。

Elasticsearch也是一个建立在全文搜索引擎 Apache Lucene基础上的搜索引擎。采用的策略是分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索

三者之间的区别和联系

Solr和Elasticsearch都是基于Lucene实现的。但Solr和Elasticsearch之间也是有区别的  <ul><li>1）Solr利用Zookpper进行分布式管理，而Elasticsearch自身带有分布式协调管理功能 。</li><li>2）Solr比Elasticsearch实现更加全面，Solr官方提供的功能更多，而Elasticsearch本身更注重于核心功能， 高级功能多由第三方插件提供。</li><li>3）Solr在传统的搜索应用中表现好于Elasticsearch，而Elasticsearch在实时搜索应用方面比Solr表现好。</li></ul>

Elasticsearch 与 Lucene 核心库竞争的优势在于

完美封装了 Lucene 核心库，设计了友好的 Restful-API，开发者无需过多关注底层机制，直接开箱即用。

分片与副本机制，直接解决了集群下性能与高可用问题

ES 与其他软件兼容

操作系统

JVM

Elastic Stack生态和场景方案

Elastic Stack生态

Beats + Logstash + ElasticSearch + Kibana

由于Elastic X-Pack是面向收费的，所以我们不妨也把X-Pack放进去，看看哪些是由X-Pack带来的，在阅读官网文档时将方便你甄别重点：

Beats

Beats是一个面向轻量型采集器的平台，这些采集器可以从边缘机器向Logstash、ElasticSearch发送数据，它是由Go语言进行开发的，运行效率方面比较快。从下图中可以看出，不同Beats的套件是针对不同的数据源。

Logstash

Logstash是动态数据收集管道，拥有可扩展的插件生态系统，支持从不同来源采集数据，转换数据，并将数据发送到不同的存储库中。其能够与ElasticSearch产生强大的协同作用，后被Elastic公司在2013年收购

它具有如下特性： 1）实时解析和转换数据； 2）可扩展，具有200多个插件； 3）可靠性、安全性。Logstash会通过持久化队列来保证至少将运行中的事件送达一次，同时将数据进行传输加密； 4）监控；

ElasticSearch

ElasticSearch对数据进行搜索、分析和存储，其是基于JSON的分布式搜索和分析引擎，专门为实现水平可扩展性、高可靠性和管理便捷性而设计的。 它的实现原理主要分为以下几个步骤： 1）首先用户将数据提交到ElasticSearch数据库中； 2）再通过分词控制器将对应的语句分词； 3）将分词结果及其权重一并存入，以备用户在搜索数据时，根据权重将结果排名和打分，将返回结果呈现给用户；

Kibana

Kibana实现数据可视化，其作用就是在ElasticSearch中进行民航。Kibana能够以图表的形式呈现数据，并且具有可扩展的用户界面，可以全方位的配置和管理ElasticSearch。 Kibana最早的时候是基于Logstash创建的工具，后被Elastic公司在2013年收购。 1）Kibana可以提供各种可视化的图表； 2）可以通过机器学习的技术，对异常情况进行检测，用于提前发现可疑问题

从日志收集系统看ES Stack的发展

我们看下ELK技术栈的演化，通常体现在日志收集系统中。

一个典型的日志系统包括： （1）收集：能够采集多种来源的日志数据 （2）传输：能够稳定的把日志数据解析过滤并传输到存储系统 （3）存储：存储日志数据 （4）分析：支持 UI 分析 （5）警告：能够提供错误报告，监控机制

beats+elasticsearch+kibana

Beats采集数据后，存储在ES中，有Kibana可视化的展示。

beats+logstath+elasticsearch+kibana

该框架是在上面的框架的基础上引入了logstash，引入logstash带来的好处如下： （1）Logstash具有基于磁盘的自适应缓冲系统，该系统将吸收传入的吞吐量，从而减轻背压。 （2）从其他数据源（例如数据库，S3或消息传递队列）中提取。 （3）将数据发送到多个目的地，例如S3，HDFS或写入文件。 （4）使用条件数据流逻辑组成更复杂的处理管道。

beats结合logstash带来的优势

（1）水平可扩展性，高可用性和可变负载处理：beats和logstash可以实现节点之间的负载均衡，多个logstash可以实现logstash的高可用

（2）消息持久性与至少一次交付保证：使用beats或Winlogbeat进行日志收集时，可以保证至少一次交付。从Filebeat或Winlogbeat到Logstash以及从Logstash到Elasticsearch的两种通信协议都是同步的，并且支持确认。Logstash持久队列提供跨节点故障的保护。对于Logstash中的磁盘级弹性，确保磁盘冗余非常重要。

（3）具有身份验证和有线加密的端到端安全传输：从Beats到Logstash以及从 Logstash到Elasticsearch的传输都可以使用加密方式传递 。与Elasticsearch进行通讯时，有很多安全选项，包括基本身份验证，TLS，PKI，LDAP，AD和其他自定义领域

增加更多的数据源： 比如：TCP，UDP和HTTP协议是将数据输入Logstash的常用方法

beats+MQ+logstash+elasticsearch+kibana

在如上的基础上我们可以在beats和logstash中间添加一些组件redis、kafka、RabbitMQ等，添加中间件将会有如下好处： （1）降低对日志所在机器的影响，这些机器上一般都部署着反向代理或应用服务，本身负载就很重了，所以尽可能的在这些机器上少做事； （2）如果有很多台机器需要做日志收集，那么让每台机器都向Elasticsearch持续写入数据，必然会对Elasticsearch造成压力，因此需要对数据进行缓冲，同时，这样的缓冲也可以一定程度的保护数据不丢失； （3）将日志数据的格式化与处理放到Indexer中统一做，可以在一处修改代码、部署，避免需要到多台机器上去修改配置

Elastic Stack最佳实践

日志收集系统

基础的日志系统

增加数据源，和使用MQ

Metric收集和APM性能监控

多数据中心方案

通过冗余实现数据高可用

两个数据采集中心（比如采集两个工厂的数据），采集数据后的汇聚

数据分散，跨集群的搜索

ES入门使用

核心概念

索引（Index）

ElasticSearch存储数据的地方，可以理解成关系型数据库中的数据库概念。

映射（Mapping）

mapping定义了每个字段的类型、字段所使用的分词器等。相当于关系型数据库中的表结构。

文档（Ducoment）

Elasticsearch中的最小数据单元，常以json格式显示。一个document相当于关系型数据库中的一行数据（一条记录）。

域（Feild）

列

倒排索引

一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，对应一个包含它的文档id列表。

类型（Type）

一种type就像一类`表`。如用户表、  在Elasticsearch7.X默认type为_doc

ES 5.x中一个index可以有多种type。 ES 6.x中一个index只能有一种type。 ES 7.x以后，将逐步移除type这个概念，现在的操作已经不再使用，默认_doc

文档元数据

_index：文档所属的索引名

_type：文档所属的类型名

_id：文档唯—ld

_source: 文档的原始Json数据

_version:  文档的版本号，修改删除操作_version都会自增1

_seq_no:  和_version一样，一旦数据发生更改，数据也一直是累计的。Shard级别严格递增，保证后写入的Doc的_seq_no大于先写入的Doc的_seq_no。

primary_term:  _primary_term 主要是用来恢复数据时处理当多个文档的 _seq_no 一样时的冲突，避免Primary Shard上的写入被覆盖。每当Primary Shard发生重新分配时，比如重启，Primary选举等，_primary_term会递增1。

倒排索引

基于数据库查询的问题

<ul><li>- 查询效率低，模糊查询数据库不会使用索引 （有些查询会导致索引失效）</li><li>- 查询的准确率不高 （功能弱）</li></ul>

将文档进行分词，形成词条和文档id的对应关系即为倒排索引

ES存储和查询的原理

ES解决数据库查询功能弱： 通过对数据进行分词来解决

ES解决数据库查询效率低：对分词的结构进行排序，然后进行了一个树形结构

IK分词器

IKAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始，IKAnalyzer已经推出了3个大版本。最初，它是以开源项目Lucene为应用主体的，结合词典分词和文法分析算法的中文分词组件。新版本的IKAnalyzer3.0则发展为面向Java的公用分词组件，独立于 Lucene项目，同时提供了对Lucene的默认优化实现。 IK分词器3.0的特性如下： 1）采用了特有的“正向迭代最细粒度切分算法“，具有60万字/秒的高速处理能力。 2）采用了多子处理器分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。 3）支持个人词条的优化的词典存储，更小的内存占用。 4）支持用户词典扩展定义。 5）针对Lucene全文检索优化的查询分析器IKQueryParser；采用歧义分析算法优化查询关键字的搜索排列组合，能极大的提高Lucene检索的命中率。

ElasticSearch 默认使用的分词器是 standard Analyzer ，会把中文一个字分成一个词

分词类型

ik_max_word

细粒度，分的词条多

ik_smart

粗粒度, 分的词条少

<ul><li>被搜索的内容想被更多的匹配到就可以使用`细粒度`</li><li>搜索关键字，更像精准匹配到搜索的内容，关键字可以使用`粗粒度`</li></ul>

扩展词典

停用词典

同义词典

语言博大精深，有很多相同意思的词，我们称之为同义词，比如“番茄”和“西红柿”，“馒头”和“馍”等。在 搜索的时候，我们输入的可能是“番茄”，但是应该把含有“西红柿”的数据一起查询出来，这种情况叫做 同义词查询。 注意：扩展词和停用词是在索引的时候使用，而同义词是检索时候使用。

索引操作

Restful

Java API

ES数据结构

简单数据类型

字符串

- text：  会分词，不支持聚合      - keyword： 不会分词，将全部内容作为一个词条，支持聚合 # 聚合：相当于mysql 中的聚合函数 => sum（求和）

数值

布尔（Boolean）

二进制（Binary）

范围类型

integer_range, float_range, long_range, double_range, date_range

日期（Date）

复杂数据类型

数组 []

对象 {}

ES映射操作

索引创建之后，等于有了关系型数据库中的database。Elasticsearch7.x取消了索引type类型的设置， 不允许指定类型，默认为_doc，但字段仍然是有的，我们需要设置字段的约束信息，叫做字段映射 （mapping） 字段的约束包括但不限于： <ul><li>字段的数据类型</li><li>是否要存储</li><li>是否要索引</li><li>分词器</li></ul>

创建映射字段

字段名：任意填写，下面指定许多属性，例如： <ul><li>type：类型，可以是text、long、short、date、integer、object等 </li><li>index：是否索引，默认为true</li><li>store：是否存储，默认为false </li><li>analyzer：指定分词器</li></ul>

映射属性详解

type：Elasticsearch中支持的数据类型非常丰富

String类型

- text：可分词，不可参与聚合

- keyword：不可分词，数据会作为完整字段进行匹配，可以参与聚合

Numerical：数值类型

- 基本数据类型：long、interger、short、byte、double、float、half_float

- 浮点数的高精度类型：scaled_float

- 需要指定一个精度因子，比如10或100。elasticsearch会把真实值乘以这个因子后存储，取出时再原。

Date：日期类型

elasticsearch可以对日期格式化为字符串存储，但是建议我们存储为毫秒值，存储为long，节省空间。

Array：数组类型

- 进行匹配时，任意一个元素满足，都认为满足

- 排序时，如果升序则用数组中的最小值来排序，如果降序则用数组中的最大值来排序

Object：对象

如果存储到索引库的是对象类型，例如上面的girl，会把girl变成两个字段：girl.name和girl.age

index ：index影响字段的索引情况

<ul><li>true：字段会被索引，则可以用来进行搜索。默认值就是true </li><li>false：字段不会被索引，不能用来搜索</li></ul>

index的默认值就是true，也就是说你不进行任何配置，所有字段都会被索引。但是有些字段是我们不希望被索引的，比如企业的logo图片地址，就需要手动设置index为false。

store ：是否将数据进行独立存储

原始的文本会存储在 _source里面，默认情况下其他提取出来的字段都不是独立存储的，是从 _source里面提取出来的。当然你也可以独立的存储某个字段，只要设置 store:true 即可，获取独立存储的字段要比从_source中解析快得多，但是也会占用更多的空间，所以要根据实际业务需求来设置， 默认为false

analyzer

指定分词器 一般我们处理中文会选择ik分词器 ik_max_word、ik_smart

查看映射关系

修改映射增加字段做其它更改只能删除索引重新建立映射

一次性创建索引和映射

刚才的案例中我们是把创建索引库和映射分开来做，其实也可以在创建索引库的同时，直接制定索引库中的索引，基本语法

ES文档的增删改查（见笔记）

JAVA API 操作索引/文档（见笔记）

高级应用

映射高级

Mapping 设置流程图

地理坐标点数据类型（geo_point）

<ul><li>字符串形式以半角逗号分割，如 "lat,lon"</li><li>对象形式显式命名为 lat 和 lon</li><li>数组形式表示为 [lon,lat] </li></ul>

通过地理坐标点过滤

geo_bounding_box

这是目前为止最有效的地理坐标过滤器了，因为它计算起来非常简单。 你指定一个矩形的顶部 , 底部 , 左边界和右边界，然后过滤器只需判断坐标的经度是否在左右边界之间，纬度是否在上下边界之间

location这些坐标也可以用 bottom_left 和 top_right 来表示

geo_distance

过滤仅包含与地理位置相距特定距离内的匹配的文档。假设以下映射和索引文档 然后可以使用 geo_distance 过滤器执行以下查询

动态映射

Elasticsearch在遇到文档中以前未遇到的字段，可以使用dynamic mapping（动态映射机制） 来确定字段的数据类型并自动把新的字段添加到类型映射。  Elastic的动态映射机制可以进行开关控制，通过设置mappings的dynamic属性，dynamic有如下设置项

true：遇到陌生字段就执行dynamic mapping处理机制

false：遇到陌生字段就忽略

strict：遇到陌生字段就报错

自定义动态映射（dynamic_date_formats）

自动映射可能会出现的问题

使用 dynamic_templates 可以完全控制新生成字段的映射，甚至可以通过字段名称或数据类型来应用不同的映射

每个模板都有一个名称，你可以用来描述这个模板的用途，一个 mapping 来指定映射应该怎样使用，以及至少一个参数 (如 match) 来定义这个模板适用于哪个字段。 模板按照顺序来检测；第一个匹配的模板会被启用。例如，我们给 string 类型字段定义两个模板： <ul><li>es ：以 _es 结尾的字段名需要使用 spanish 分词器。</li><li>en ：所有其他字段使用 english 分词器。</li></ul>

Query DSL（Domain Specific Language)

Elasticsearch提供了基于JSON的完整查询DSL（Domain Specific Language 特定域的语言）来定义查询。将查询DSL视为查询的 AST（抽象语法树），它由两种子句组成： <ul><li>叶子查询子句： 叶子查询子句在特定域中寻找特定的值，如 match，term或 range查询。</li><li>复合查询子句：复合查询子句包装其他叶子查询或复合查询，并用于以逻辑方式组合多个查询（例如 bool或 dis_max查询），或更改其行为（例如 constant_score查询）。</li></ul>

查询所有（match_all query）

<ul><li>query ：代表查询对象 </li><li>match_all ：代表查询所有</li></ul>

查询结果

全文搜索（full-text  query）

匹配搜索（match query）

全文查询的标准查询，它可以对一个字段进行模糊、短语查询。 match queries 接收 text/numerics/dates, 对它们进行分词分析, 再组织成一个boolean查询。可通过operator 指定bool组合操作（or、and 默认是 or ）。

or关系

match 类型查询，会把查询条件进行分词，然后进行查询，多个词条之间是or的关系

and关系

某些情况下，我们需要更精确查找，我们希望这个关系变成 and ，可以这样做

短语搜索（match phrase query）

match_phrase 查询用来对一个字段进行短语查询，可以指定 analyzer、slop移动因子 完全匹配可能比较严，我们会希望有个可调节因子，少匹配一个也满足，那就需要使用到slop。

query_string 查询

Query String Query提供了无需指定某字段而对文档全文进行匹配查询的一个高级查询，同时可以指定在哪些字段上进行匹配。

多字段匹配搜索(multi match query)

如果你需要在多个字段上进行文本搜索，可用multi_match 。multi_match在 match的基础上支持对多个字段进行文本查询。

词条级搜索(term-level queries)

可以使用term-level queries根据结构化数据中的精确值查找文档。结构化数据的值包括日期范围、IP 地址、价格或产品ID。  与全文查询不同，term-level queries不分析搜索词。相反，词条与存储在字段级别中的术语完全匹配。

词条搜索（term query）

term 查询用于查询指定字段包含某个词项的文档

词条集合搜索(terms query)

terms 查询用于查询指定字段包含某些词项的文档

范围搜索(range query)

<ul><li>- gte：大于等于 </li><li>- gt：大于 </li><li>- lte：小于等于 </li><li>- lt：小于 </li><li>- boost：查询权重</li></ul>

boost：用于影响返回结果的相关性评分，在原评分基础上*boost值。如果是2的话，就是2倍打分值，如果是0.5就是原打分的一半。

不为空搜索(exists query)

查询指定字段值不为空的文档。相当 SQL 中的 column is not null

词项前缀搜索(prefix query)

通配符搜索(wildcard query)

正则搜索(regexp query)

regexp允许使用正则表达式进行term查询.注意regexp如果使用不正确，会给服务器带来很严重的性能压力。比如.*开头的查询，将会匹配所有的倒排索引中的关键字，这几乎相当于全表扫描，会很慢。因此如果可以的话，最好在使用正则前，加上匹配的前缀

模糊搜索(fuzzy query)

在实际的搜索中，我们有时候会打错字，从而导致搜索不到。在Elasticsearch中，我们可以使用fuzziness属性来进行模糊查询，从而达到搜索有错别字的情形。 match查询具有“fuziness”属性。它可以被设置为“0”， “1”， “2”或“auto”。“auto”是推荐的选项，它会根据查询词的长度定义距离。

ids搜索(id集合查询)

复核搜索（compound query）

constant_score query

用来包装另一个查询，将查询匹配的文档的评分设为一个常值

布尔搜索(bool query) bool

查询用bool操作来组合多个查询字句为一个查询。可用的关键字： <ul><li>must：必须满足</li><li>filter：必须满足，但执行的是filter上下文，不参与、不影响评分</li><li>should：或</li><li>must_not：必须不满足，在filter上下文中执行，不参与、不影响评分</li></ul>

minimum_should_match代表了最小匹配精度，如果设置 minimum_should_match=1，那么should 语句中至少需要有一个条件满足，如果没有should语句说明没有一个满足。

在Elasticsearch中，有Query和 Filter两种不同的Context <ul><li>Query Context: 相关性算分</li><li>Filter Context: 不需要算分 ,可以利用Cache，获得更好的性能</li></ul>

相关性并不只是全文本检索的专利，也适用于yes | no 的子句，匹配的子句越多，相关性评分越高。 如果多条查询子句被合并为一条复合查询语句，比如 bool查询，则每个查询子句计算得出的评分会被合并到总的相关性评分中。

bool查询语法 <ul><li> 子查询可以任意顺序出现</li><li> 可以嵌套多个查询</li><li> 如果你的bool查询中，没有must条件,should中必须至少满足一条查询</li></ul>

排序

相关性评分排序

默认情况下，返回的结果是按照相关性进行排序的——最相关的文档排在最前

为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中，相关性得分由一个浮点数进行表示，并在搜索结果中通过 _score 参数返回，默认排序是 _score 降序，按照相关性评分升序排序如下

字段值排序

多级排序

假定我们想要结合使用 price和 _score（得分）进行查询，并且匹配的结果首先按照价格排序，然后按照相关性得分排序：

分页

<ul><li>- size：每页显示多少条 </li><li>- from：当前页起始索引， start = (pageNum - 1) * size</li></ul>

高亮

在使用match查询的同时，加上一个highlight属性： <ul><li> pre_tags：前置标签 </li><li> post_tags：后置标签 </li><li> fields：需要高亮的字段</li></ul>             name：这里声明title字段需要高亮，后面可以为这个字段设置特有配置，也可以空

结果

文档批量操作（bulk 和 mget）

mget 批量查询

单条查询 GET /test_index/_doc/1，如果查询多个id的文档一条一条查询，网络开销太大

同一索引下批量查询

bulk 批量增删改

Bulk 操作解释将文档的增删改查一些列操作，通过一次请求全都做完。减少网络传输次数

实际用法：bulk请求一次不要太大，否则一下积压到内存中，性能会下降。所以，一次请求几千个操 作、大小在几M正好。 bulk会将要处理的数据载入内存中，所以数据量是有限的，最佳的数据量不是一个确定的数据，它取决于你的硬件，你的文档大小以及复杂性，你的索引以及搜索的负载。 一般建议是 1000-5000个文档，大小建议是5-15MB，默认不能超过100M，可以在es的配置文件（ES的 config下的 elasticsearch.yml）中配置。 http.max_content_length: 10mb

Filter DSL

Elasticsearch中的所有的查询都会触发相关度得分的计算。对于那些我们不需要相关度得分的场景下， Elasticsearch以过滤器的形式提供了另一种查询功能，过滤器在概念上类似于查询，但是它们有非常快的执行速度，执行速度快主要有以下两个原因： <ul><li>- 过滤器不会计算相关度的得分，所以它们在计算上更快一些。 </li><li>- 过滤器可以被缓存到内存中，这使得在重复的搜索查询上，其要比相应的查询快出许多。</li></ul>

定位非法搜索及原因（_validate）

在开发的时候，我们可能会写到上百行的查询语句，如果出错的话，找起来很麻烦，Elasticsearch提供了帮助开发人员定位不合法的查询的api _validate

聚合分析

聚合分析是数据库中重要的功能特性，完成对一个查询的数据集中数据的聚合计算，如：找出某字段（或计算表达式的结果）的最大值、最小值，计算和、平均值等。Elasticsearch作为搜索引擎兼数据库，同样提供了强大的聚合分析能力。 对一个数据集求最大、最小、和、平均值等指标的聚合，在ES中称为指标聚合 metric，而关系型数据库中除了有聚合函数外，还可以对查询出的数据进行分组group by，再在组上进行指标聚合。在 ES 中group by 称为分桶，桶聚合 bucketing Elasticsearch聚合分析语法：（说明：aggregations 也可简写为 aggs）

指标聚合（metrics）

单值分析：标准stat类型

max min sum avg

文档计数 count

value_count 统计某字段有值的文档数

单值分析：其他类型

cardinality 值去重计数基数 (distinct)

weighted_avg 带权重的avg

median_absolute_deviation 中位值

非单值分析： stats类型

stats 统计 count max min avg sum 5个值

extended-stats： 高级统计，比stats多4个统计结果：平方和、方差、标准差、平均值加/减两个标准差的区间

matrix_stats  针对矩阵模型

string_stats 针对字符串

用于计算从聚合文档中提取的字符串值的统计信息。这些值可以从特定的关键字字段中检索

非单值分析：百分数类型

Percentiles 占比百分位对应的值统计

指定分位值

Percentiles rank 统计值小于等于指定值的文档占比

非单值分析：地理位置型

geo_bounds Geo bounds

geo_centroid Geo-centroid

geo_line Geo-Line

非单值分析：Top型

top_hits 分桶后的top hits

top_metrics

桶聚合（Bucketing）

Bucket Aggregations，桶聚合。 它执行的是对文档分组的操作（与sql中的group by类似），把满足相关特性的文档分到一个桶里，即桶分，输出结果往往是一个个包含多个文档的桶（一个桶就是一个group）。 <ul><li>bucket：一个数据分组 </li><li>metric：对一个数据分组执行的统计</li></ul>

<ul><li>- Terms，需要字段支持filedata</li><li>- keyword：默认支持fielddata</li><li>- text ：需要在Mapping 中开启fielddata，会按照分词后的结果进行分桶</li><li>- 数字类型</li><li>- Range / Data Range</li><li>- Histogram（直方图） / Date Histogram</li><li>- 支持嵌套：也就在桶里再做分桶</li></ul>

Terms

数字类型

Range <ul><li> 按照数字的范围，进行分桶</li><li> 在Range Aggregation中，可以自定义Key</li></ul>

嵌套聚合

对IP类型聚合：IP Range

对日期类型聚合-date-range

结果

此聚合与Range聚合之间的主要区别在于 from和to值可以在Date Math中表示，并且还可以指定日期格式，通过该日期格式将返回from and to响应字段。请注意，此聚合包括from值，但不包括to每个范围的值

对柱状图功能：Histrogram

直方图 histogram 本质上是就是为柱状图功能设计的。 创建直方图需要指定一个区间，如果我们要为售价创建一个直方图，可以将间隔设为 20,000。这样做将会在每个 $20,000 档创建一个新桶，然后文档会被分到对应的桶中。 对于仪表盘来说，我们希望知道每个售价区间内汽车的销量。我们还会想知道每个售价区间内汽车所带来的收入，可以通过对每个区间内已售汽车的售价求和得到。 可以用 histogram 和一个嵌套的 sum 度量得到我们想要的答案：

1. histogram 桶要求两个参数：一个数值字段以及一个定义桶大小间隔。 2. sum 度量嵌套在每个售价区间内，用来显示每个区间内的总收入。

如我们所见，查询是围绕 price 聚合构建的，它包含一个 histogram 桶。它要求字段的类型必须是数值型的同时需要设定分组的间隔范围。间隔设置为 20,000 意味着我们将会得到如 [0-19999, 20000-39999, ...] 这样的区间。 接着，我们在直方图内定义嵌套的度量，这个 sum 度量，它会对落入某一具体售价区间的文档中 price 字段的值进行求和。这可以为我们提供每个售价区间的收入，从而可以发现到底是普通家用车赚钱还是奢侈车赚钱。

响应结果

对应报表：

Histogram示例：按照工资的间隔分桶

top_hits

top_hits应用场景: 当获取分桶后，桶内最匹配的顶部文档列表

管道聚合 Pipeline Aggregation

管道机制的常见场景

如何理解管道聚合呢？最重要的是要站在设计者角度看这个功能的要实现的目的：让上一步的聚合结果成为下一个聚合的输入，这就是管道。

责任链模式

通过责任链模式, 你可以为某个请求创建一个对象链. 每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象

ElasticSearch 设计管道机制

简单而言：让上一步的聚合结果成为下一个聚合的输入，这就是管道。 接下来，无非就是对不同类型的聚合有接口的支撑，比如：

第一个维度：管道聚合有很多不同类型，每种类型都与其他聚合计算不同的信息，但是可以将这些类型分为两类： <ul><li>父级 父级聚合的输出提供了一组管道聚合，它可以计算新的存储桶或新的聚合以添加到现有存储桶中。</li><li>兄弟 同级聚合的输出提供的管道聚合，并且能够计算与该同级聚合处于同一级别的新聚合。</li></ul>

第二个维度：根据功能设计的意图 比如前置聚合可能是Bucket聚合，后置的可能是基于Metric聚合，那么它就可以成为一类管

例子

Average bucket 聚合

输出结果

聚合的作用范围

ES聚合分析的默认作用范围是query的查询结果集，同时ES还支持以下方式改变聚合的作用范围： <ul><li> Filter</li><li> Post Filter</li><li> Global</li></ul>

Query

Filter

Post Filter

global

排序

指定order，按照count和key进行排序： <ul><li> 默认情况，按照count降序排序</li><li> 指定size，就能返回相应的桶</li></ul>

ES聚合分析不精准原因分析

ElasticSearch在对海量数据进行聚合分析的时候会损失搜索的精准度来满足实时性的需求

Terms聚合分析的执行流程

不精准的原因：数据分散到多个分片，聚合是每个分片的取 Top X，导致结果不精准。ES 可以不每个分片Top X，而是全量聚合，但势必这会有很大的性能问题。

思考：如何提高聚合精确度？

方案1：设置主分片为1

注意7.x版本已经默认为1。

适用场景：数据量小的小集群规模业务场景

方案2：调大 shard_size 值

设置 shard_size 为比较大的值，官方推荐：size*1.5+10。shard_size 值越大，结果越趋近于精准聚合结果值。此外，还可以通过show_term_doc_count_error参数显示最差情况下的错误值，用于辅助确定 shard_size 大小。 <ul><li>size：是聚合结果的返回值，客户期望返回聚合排名前三，size值就是 3。</li><li>shard_size： 每个分片上聚合的数据条数。shard_size 原则上要大于等于 size</li></ul>

适用场景：数据量大、分片数多的集群业务场景。

方案3：将size设置为全量值，来解决精度问题

将size设置为   也就是分片支持的最大值，来解决精度问题。 原因：1.x版本，size等于 0 代表全部，高版本取消 0 值，所以设置了最大值（大于业务的全量值）。 全量带来的弊端就是：如果分片数据量极大，这样做会耗费巨大的CPU 资源来排序，而且可能会阻塞网络

适用场景：对聚合精准度要求极高的业务场景，由于性能问题，不推荐使用。

方案4：使用Clickhouse/ Spark 进行精准聚合

适用场景：数据量非常大、聚合精度要求高、响应速度快的业务场景。

Elasticsearch 聚合性能优化

启用 eager global ordinals 提升高基数聚合性能

适用场景：高基数聚合。高基数聚合场景中的高基数含义：一个字段包含很大比例的唯一值

global ordinals 中文翻译成全局序号，是一种数据结构，应用场景如下： <ul><li> 基于 keyword，ip 等字段的分桶聚合，包含：terms聚合、composite 聚合等。</li><li> 基于text 字段的分桶聚合（前提条件是：fielddata 开启）。</li><li> 基于父子文档 Join 类型的 has_child 查询和 父聚合。</li></ul>global ordinals 使用一个数值代表字段中的字符串值，然后为每一个数值分配一个 bucket（分桶）。

global ordinals 的本质是：启用 eager_global_ordinals 时，会在刷新（refresh）分片时构建全局序号。这将构建全局序号的成本从搜索阶段转移到了数据索引化（写入）阶段。

创建索引的同时开启：eager_global_ordinals。

注意：开启 eager_global_ordinals 会影响写入性能，因为每次刷新时都会创建新的全局序号。为了最大程度地减少由于频繁刷新建立全局序号而导致的额外开销，请调大刷新间隔 refresh_interval。

插入数据时对索引进行预排序

<ul><li>Index sorting （索引排序）可用于在插入时对索引进行预排序，而不是在查询时再对索引进行排序，这将提高范围查询（range query）和排序操作的性能。</li><li>在 Elasticsearch 中创建新索引时，可以配置如何对每个分片内的段进行排序。</li><li>这是 Elasticsearch 6.X 之后版本才有的特性。</li></ul>

注意：预排序将增加 Elasticsearch 写入的成本。在某些用户特定场景下，开启索引预排序会导致大约 40%-50% 的写性能下降。也就是说，如果用户场景更关注写性能的业务，开启索引预排序不是一个很好的选择。

使用节点查询缓存

节点查询缓存（Node query cache）可用于有效缓存过滤器（filter）操作的结果。如果多次执行同一 filter 操作，这将很有效，但是即便更改过滤器中的某一个值，也将意味着需要计算新的过滤器结果。

例如，由于 “now” 值一直在变化，因此无法缓存在过滤器上下文中使用 “now” 的查询。 那怎么使用缓存呢？通过在 now 字段上应用 datemath 格式将其四舍五入到最接近的分钟/小时等，可以使此类请求更具可缓存性，以便可以对筛选结果进行缓存。

使用分片请求缓存

聚合语句中，设置：size：0，就会使用分片请求缓存缓存结果。size = 0 的含义是：只返回聚合结果，不返回查询结果。

拆分聚合，使聚合并行化

Elasticsearch 查询条件中同时有多个条件聚合，默认情况下聚合不是并行运行的。当为每个聚合提供自己的查询并执行 msearch 时，性能会有显著提升。因此，在 CPU 资源不是瓶颈的前提下，如果想缩短响应时间，可以将多个聚合拆分为多个查询，借助：msearch 实现并行聚合

ES零停机索引重建

Elasticsearch是一个实时的分布式搜索引擎，为用户提供搜索服务，当我们决定存储某种数据时，在创建索引的时候需要数据结构完整确定下来，与此同时索引的设定和很多固定配置将不能改变。当需要改变数据结构时就需要重建索引，为此，Elasticsearch团队提供了辅助工具帮助开发人员进行索引重建。

方案一：外部数据导入方案

系统架构设计中，有关系型数据库用来存储数据，Elasticsearch在系统架构里起到查询加速的作用，如果遇到索引重建的操作，待系统模块发布新版本后，可以从数据库将数据查询出来，重新灌到 Elasticsearch即可。

数据库 + MQ + 应用模块 + Elasticsearch

操作步骤

<ol><li>通过MQ的web控制台或cli命令行，发送指定的MQ消息</li><li>MQ消息被微服务模块的消费者消费，触发ES数据重新导入功能 </li><li>微服务模块从数据库里查询数据的总数及批次信息，并将每个数据批次的分页信息重新发送给MQ 消息，分页信息包含查询条件和偏移量，此MQ消息还是会被微服务的MQ消息者接收处理。</li><li>微服务根据接收的查询条件和分页信息，从数据库获取到数据后，根据索引结构的定义，将数据组装成ES支持的JSON格式，并执行bulk命令，将数据发送给Elasticsearch集群。 这样就可以完成索引的重建工作。</li></ol>

方案特点

MQ中间件的选型不做具体要求，常见的rabitmq、activemq、rocketmq等均可。

在微服务模块方面，提供MQ消息处理接口、数据处理模块需要事先开发的，一般是创建新的索引时， 配套把重建的功能也一起做好。整体功能共用一个topic，针对每个索引，有单独的结构定义和MQ消息 处理tag，代码尽可能复用。处理的批次大小需要根据实际的情况设置。

微服务模块实例会部署多个，数据是分批处理的，批次信息会一次性全部先发送给MQ，各个实例处理的数据相互不重叠，利用MQ消息的异步处理机制，可以充分利用并发的优势，加快数据重建的速度。

缺点

对数据库造成读取压力，短时间内大量的读操作，会占用数据库的硬件资源，严重时可能引起数据库性能下降

网络带宽占用多，数据毕竟是从一个库传到另一个库，虽说是内网，但大量的数据传输带宽占用

数据重建时间稍长，跟迁移的数据量大小有关

方案二：基于scroll+bulk+索引别名方案

利用Elasticsearch自带的一些工具完成索引的重建工作，当然在方案实际落地时，可能也会依赖客户端的一些功能，比如用Java客户端持续的做scroll查询、bulk命令的封装等。数据完全自给自足，不依赖 其他数据源

执行步骤

特点

在数据传输上基本自给自足，不依赖于其他数据源，Java客户端不需要停机等待数据迁移，网络传输占用带宽较小。只是scroll查询和bulk提交这部分，数据量大时需要依赖一些客户端工具。 在Java客户端或其他客户端访问Elasticsearch集群时，使用别名是一个好习惯

方案三：Reindex API方案

Elasticsearch v6.3.1已经支持Reindex API，它对scroll、bulk做了一层封装，能够 对文档重建索引而不需要任何插件或外部工具。

命令

响应结果为：

version_type 属性

使用reindex api也是创建快照后再执行迁移的，这样目标索引的数据可能会与原索引有差异， version_type属性可以决定乐观锁并发处理的规则 reindex api可以设置version_type属性，如下：

version_type属性含义如下： <ul><li>internal：直接拷贝文档到目标索引，对相同的type、文档ID直接进行覆盖，默认值 </li><li>external：迁移文档到目标索引时，保留version信息，对目标索引中不存在的文档进行创建，已存在的文档按version进行更新，遵循乐观锁机制。</li></ul>

op_type 属性和conflicts 属性

如果op_type设置为create，那么迁移时只在目标索引中创建ID不存在的文档，已存在的文档，会提示错误，如下请求

有错误提示的响应，节选部分：

如果加上"conflicts": "proceed"配置项，那么冲突信息将不展示，只展示冲突的文档数量

query支持

reindex api支持数据过滤、数据排序、size设置、_source选择等，也支持脚本执行

零停机索引重建操作的三个方案，从自研功能、scroll+bulk到reindex，我们作为Elasticsearch的使用者，三个方案的参与度是逐渐弱化的，但稳定性却是逐渐上升的，我们需要清楚地去了解各个方案的优劣，适宜的场景，然后根据实际的情况去权衡，哪个方案更适合我们的业务模型.

ES Suggester智能搜索建议

什么是智能搜索？

现代的搜索引擎，一般会具备"Suggest As You Type"功能，即在用户输入搜索的过程中，进行自动补全或者纠错。通过协助用户输入更精准的关键词，提高后续全文搜索阶段文档匹配的程度。例如在京东上输入部分关键词，甚至输入拼写错误的关键词时，它依然能够提示出用户想要输入的内容

如果自己亲手去试一下，可以看到京东在用户刚开始输入的时候是自动补全的，而当输入到一定长度，如果因为单词拼写错误无法补全，就开始尝试提示相似的词。那么类似的功能在Elasticsearch里如何实现呢？ 答案就在Suggesters API。

Suggesters API

Suggesters基本的运作原理是将输入的文本分解为token，然后在索引的字典里查找相似的term并返回。 根据使用场景的不同， Elasticsearch里设计了4种类别的Suggester

Term Suggester

suggest就是一种特殊类型的搜索，DSL内部的"text"指的是api调用方提供的文本，也就是通常用户界面上用户输入的内容。这里的lucne是错误的拼写，模拟用户输入错误。 "term"表示这是一个term suggester。 "field"指定suggester针对的字段，另外有一个可选的"suggest_mode"

suggest_mode

missing：默认值，仅为不在索引中的词项生成建议词

popular：仅返回与搜索词文档词频或文档词频更高的建议词

always：根据 建议文本中的词项 推荐 任何匹配的建议词

Phrase Suggester

Phrase suggester在Term suggester的基础上，会考量多个term之间的关系，比如是否同时出现在索引的原文里，相邻程度，以及词频等等

例子

返回结果

options直接返回一个phrase列表，由于加了highlight选项，被替换的term会被高亮。因为lucene和 elasticsearch曾经在同一条原文里出现过，同时替换2个term的可信度更高，所以打分较高，排在第一位返回。Phrase suggester有相当多的参数用于控制匹配的模糊程度，需要根据实际应用情况去挑选和调试

Completion Suggester

它主要针对的应用场景就是"Auto Completion"。 此场景下用户每输入一个字符的时候，就需要即时发送一次查询请求到后端查找匹配项，在用户输入速度较高的情况下对后端响应速度要求比较苛刻。因此实现上它和前面两个Suggester采用了不同的数据结构，索引并非通过倒排来完成，而是将analyze过的数据编码成FST和索引一起存放。对于一个open状态的索引， FST会被ES整个装载到内存里的，进行前缀查找速度极快。但是FST只能用于前缀查找，这也是 Completion Suggester的局限所在。

例子

结果

值得注意的一点是Completion Suggester在索引原始数据的时候也要经过analyze阶段，取决于选用的 analyzer不同，某些词可能会被转换，某些词可能被去除，这些会影响FST编码结果，也会影响查找匹配的效果

比如：将analyzer更改为"english" 插入数据

bulk api索引同样的数据后，执行下面的查询，

居然没有匹配结果了，多么费解！原来我们用的english analyzer会剥离掉stop word，而is就是其中一个，被剥离掉了！用analyze api测试一下:

FST（Finite State Transducers）只编码了这3个token，并且默认的还会记录他们在文档中的位置和分隔符。用户输入"elastic i"进行查找的时候，输入被分解成"elastic"和"i"，FST没有编码这个“i” , 匹配败。好吧，如果你现在还足够清醒的话，试一下搜索"elastic is"，会发现又有结果，why? 因为这次输入的 text经过english analyzer的时候is也被剥离了，只需在FST里查询"elastic"这个前缀，自然就可以匹配到了。其他能影响completion suggester结果的，还有如"preserve_separators"，"preserve_position_increments"等等mapping参数来控制匹配的模糊程度。以及搜索时可以选用Fuzzy Queries，使得上面例子里的"elastic i"在使用english analyzer的情况下依然可以匹配到结果

<ul><li>preserve_separators: false  , 这个设置为false,将忽略空格之类的分隔符</li><li>preserve_position_increments: true  ,如果建议词第一个词是停用词,并且我们使用了过滤停用词的分析器,需要将此设置为false。</li></ul>

在实际应用开发过程中，需要根据数据特性和业务需要，灵活搭配analyzer和mapping参数，反复调试才可能获得理想的补全效果。回到篇首京东或者百度搜索框的补全/纠错功能，如果用ES怎么实现呢？

我能想到的一个的实现方式：在用户刚开始输入的过程中，使用Completion Suggester进行关键词前缀匹配，刚开始匹配项会比较多，随着用户输入字符增多，匹配项越来越少。如果用户输入比较精准，可能Completion Suggester的结果已经够好，用户已经可以看到理想的备选项了。 如果Completion Suggester已经到了零匹配，那么可以猜测是否用户有输入错误，这时候可以尝试一下 Phrase Suggester。如果Phrase Suggester没有找到任何option，开始尝试term Suggester。 精准程度上(Precision)看： Completion > Phrase > term，而召回率上(Recall)则反之。从性能上看， Completion Suggester是最快的，如果能满足业务需求，只用Completion Suggester做前缀匹配是最理想的。 Phrase和Term由于是做倒排索引的搜索，相比较而言性能应该要低不少，应尽量控制 suggester用到的索引的数据量，最理想的状况是经过一定时间预热后，索引可以全量map到内存。

Context Suggester

Completion Suggester 的扩展

可以在搜索中加入更多的上下文信息，然后根据不同的上下文信息，对相同的输入，比如"star"，提供不同的建议值，比如：咖啡相关：starbucks 电影相关：star wars

ES Java API（见笔记）

索引模板

索引模板是一种告诉Elasticsearch在创建索引时如何配置索引的方法 在创建索引之前可以先配置模板，这样在创建索引（手动创建索引或通过对文档建立索引）时，模板设置将用作创建索引的基础

模板类型

组件模板是可重用的构建块，用于配置映射，设置和别名；它们不会直接应用于一组索引。

索引模板可以包含组件模板的集合，也可以直接指定设置，映射和别名。

索引模板中的优先级

<ul><li>可组合模板优先于旧模板。如果没有可组合模板匹配给定索引，则旧版模板可能仍匹配并被应用。</li><li>如果使用显式设置创建索引并且该索引也与索引模板匹配，则创建索引请求中的设置将优先于索引模板及其组件模板中指定的设置。</li><li>如果新数据流或索引与多个索引模板匹配，则使用优先级最高的索引模板。</li></ul>

内置索引模板

Elasticsearch具有内置索引模板，每个索引模板的优先级为100，适用于以下索引模式： 1. logs-*-* 2. metrics-*-* 3. synthetics-*-* 所以在涉及内建索引模板时，要避免索引模式冲突。https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html

案例

首先创建两个索引组件模板：

执行结果如下

创建使用组件模板的索引模板

执行结果如下

模拟多组件模板

由于模板不仅可以由多个组件模板组成，还可以由索引模板自身组成；那么最终的索引设置将是什么呢？ElasticSearch设计者考虑到这个，提供了API进行模拟组合后的模板的配置。

高可用分布式集群

核心概念

集群（Cluster）

一个Elasticsearch集群由多个节点（Node）组成，每个集群都有一个共同的集群名称作为标识

<ul><li>- 不同的集群通过不同的名字来区分，默认名字“elasticsearch“</li><li>- 通过配置文件修改，或者在命令行中 -E cluster.name=es-cluster进行设定</li></ul>

节点（Node）

一个Elasticsearch实例即一个Node（本质上就是一个JVM进程），一台机器可以有多个实例，正常使用下每个实例都应该 会部署在不同的机器上。Elasticsearch的配置文件中可以通过node.master、node.data来设置节点类型 <ul><li>- 每一个节点都有名字，通过配置文件配置，或者启动时候 -E node.name=node1指定</li><li>- 每一个节点在启动之后，会分配一个UID，保存在data目录下</li></ul>

node.master

是否有成为主节点资格  true/false

node.data

表示节点是否存储数据   true/false

节点的类型

主节点+数据节点（master+data）（默认）

节点既有成为主节点的资格，又存储数据

数据节点（data）

节点没有成为主节点的资格，不参与选举，只会存储数据

客户端节点（client | coordinating Node）

不会成为主节点，也不会存储数据，主要是针对海量请求的时候可以进行负载均衡

其他数据节点

- Hot & Warm Node：不同硬件配置 的Data Node，用来实现Hot &amp; Warm架构，降低集群部署的成本

- Ingest Node：数据前置处理转换节点，支持pipeline管道设置，可以使用ingest对数据进行过滤、转换等操作

- Machine Learning Node：负责跑机器学习的Job，用来做异常检测

- Tribe Node：Tribe Node连接到不同的Elasticsearch集群，并且支持将这些集群当成一个单独的集群处理

分片

主分片

<ul><li> 用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上</li><li> 一个分片是一个运行的Lucene的实例</li><li> 主分片数在索引创建时指定，后续不允许修改，除非Reindex</li></ul>

复制分片

<ul><li>- 用以解决数据高可用的问题。 副本分片是主分片的拷贝</li><li>- 副本分片数，可以动态调整</li><li>- 增加副本数，还可以在一定程度上提高服务的可用性(读取的吞吐)</li></ul>

副本

这里指主分片的副本分片（主分片的拷贝）

<ul><li>提高恢复能力：当主分片挂掉时，某个复制分片可以变成主分片；</li><li>提高性能：get 和 search 请求既可以由主分片又可以由复制分片处理；</li></ul>

设置分片和副本

思考：增加一个节点或改大主分片数对系统有什么影响？

分片的设定：对于生产环境中分片的设定，需要提前做好容量规划

分片数设置过小

- 导致后续无法增加节点实现水平扩展

- 单个分片的数据量太大，导致数据重新分配耗时

分片数设置过大

7.0 开始，默认主分片设置成1，解决了over-sharding（分片过度）的问题 <ul><li>- 影响搜索结果的相关性打分，影响统计结果的准确性</li><li>- 单个节点上过多的分片，会导致资源浪费，同时也会影响性能</li></ul>

// 查看集群的健康状况 GET _cluster/health

集群status

<ul><li>Green：主分片与副本都正常分配</li><li>Yellow： 主分片全部正常分配，有副本分片未能正常分配</li><li>Red： 有主分片未能分配。例如，当服务器的磁盘容量超过85%时，去创建了一个新的索引</li></ul>

CAT API查看集群信息

ES 分布式架构

Elasticseasrch的架构遵循其基本概念：一个采用Restful API标准的高扩展性和高可用性的实时数据分析的全文搜索引擎。

特性

高扩展性：体现在Elasticsearch添加节点非常简单，新节点无需做复杂的配置，只要配置好集群信息将会被集群自动发现。

高可用性：因为Elasticsearch是分布式的，每个节点都会有备份，所以宕机一两个节点也不会出现问题，集群会通过备份进行自动复盘。

实时性：使用倒排索引来建立存储结构，搜索时常在百毫秒内就可完成。

分层

第一层 —— Gateway

Elasticsearch支持的索引快照的存储格式，es默认是先把索引存放到内存中，当内存满了之后再持久化到本地磁盘。gateway对索引快照进行存储，当Elasticsearch关闭再启动的时候，它就会从这个 gateway里面读取索引数据；支持的格式有： 本地的Local FileSystem、分布式的Shared FileSystem、 Hadoop的文件系统HDFS、Amazon（亚马逊）的S3。

第二层 —— Lucene框架

Elasticsearch基于Lucene（基于Java开发）框架

第三层 —— Elasticsearch数据的加工处理方式

index Module（创建Index模块）、Search Module（搜索模块）、Mapping（映射）、River 代表es的一个数据源（运行在Elasticsearch集群内部的一个插件，主要用来从外部获取获取异构数据，然后在Elasticsearch里创建索引；常见的插件有RabbitMQ River、Twitter River）。

第四层 —— Elasticsearch发现机制、脚本

Discovery 是Elasticsearch自动发现节点的机制的模块，Zen Discovery和 EC2 discovery。

- EC2：亚马逊弹性计算云 EC2 discovery主要在亚马云平台中使用。Zen Discovery作用就相当于solrcloud中的 zookeeper。

- zen Discovery 从功能上可以分为两部分，第一部分是集群刚启动时的选主，或者是新加入集群的节点发现当前集群的Master。第二部分是选主完成后，Master 和 Folower 的相互探活。

Scripting 是脚本执行功能，有这个功能能很方便对查询出来的数据进行加工处理。

3rd Plugins 表示Elasticsearch支持安装很多第三方的插件，例如elasticsearch-ik分词插件、 elasticsearch-sql sql插件。

第五层 —— Elasticsearch的交互方式

有Thrift、Memcached、Http三种协议，默认的是用Http协议传输

第六层 —— Elasticsearch的API支持模式：

RESTFul Style API风格的API接口标准是当下十分流行的。Elasticsearch作为分布式集群，客户端到服务端，节点与节点间通信有TCP和Http通信协议，底层实现为Netty框架

解析ES分布式架构

分布式架构的透明隐藏特性

- 分片机制：将文本数据切割成n个小份存储在不同的节点上，减少大文件存储在单个节点上对设备带来的压力。

- 分片的副本：在集群中某个节点宕掉后，通过副本可以快速对缺失数据进行复盘

- 集群发现机制（cluster discovery）：在当前启动了一个Elasticsearch进程，在启动第二个 Elasticsearch进程时，这个进程将作为一个node自动就发现了集群，并自动加入，前提是这些 node都必须配置一套集群信息。

- Shard负载均衡：例如现在由10个 shard （分片），集群中由三个节点，Elasticsearch会进行均 衡的分配，以保持每个节点均衡的负载请求。

扩展机制

- 垂直扩容：用新机器替换已有的机器，服务器台数不变容量增加。

- 水平扩容：直接增加新机器，服务器台数和容量都增加。

rebalance

增加或减少节点时会自动负载

主节点

主节点的主要职则是和集群操作的相关内容，如创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。

节点对等

每个节点都能接受请求，每个节点接受到请求后都能把该请求路由到有相关数据的其它节点上，接受原始请求的节点负责采集数据并返回给客户端。

集群搭建（见笔记）

集群规划

需要多大规模的集群？

需要从以下两个方面考虑

当前的数据量有多大？数据增长情况如何？

你的机器配置如何？cpu、多大内存、多大硬盘容量？

推算的依据

Elasticsearch JVM heap 最大可以设置32G 。 30G heap 大概能处理的数据量 10 T。如果内存很大如128G，可在一台机器上运行多个ES节点实例。 备注：集群规划满足当前数据规模+适量增长规模即可，后续可按需扩展。

两类应用场景

用于构建业务搜索功能模块，且多是垂直领域的搜索。数据量级几千万到数十亿级别。一般2-4台机 器的规模。

用于大规模数据的实时OLAP（联机处理分析），经典的如ELK Stack，数据规模可能达到千亿或更 多。几十到上百节点的规模

集群中的数据节点怎么分配？

- Master ：node.master: true 节点可以作为主节点

- DataNode： node.data: true 默认是数据节点

- Coordinate node 协调节点：一个节点只作为接收请求、转发请求到其他节点、汇总各个节点返回数据等功能的节点，就叫协调节点，如果仅担任协调节点，将上两个配置设为false。

节点角色如何分配

小规模集群，不需严格区分。

中大规模集群（十个以上节点），应考虑单独的角色充当。特别并发查询量大，查询的合并量大，可以增加独立的协调节点。角色分开的好处是分工分开，不互影响。如不会因协调角色负载过高而影响数据节点的能力。

如何避免脑裂问题？

脑裂问题：一个集群中只有一个A主节点，A主节点因为需要处理的东西太多或者网络过于繁忙，从而导致其他从节点ping不通A主节点，这样其他从节点就会认为A主节点不可用了，就会重新选出一个新的主节点B。过了一会A主节点恢复正常了，这样就出现了两个主节点，导致一部分数据来源于A主节点，另外一部分数据来源于B主节点，出现数据不一致问题，这就是脑裂

6.x和之前版本尽量避免脑裂，需要添加最小数量的主节点配置： discovery.zen.minimum_master_nodes: (有master资格节点数/2) + 1，这个参数控制的是，选举主节点时需要看到最少多少个具有master资格的活节点，才能进行选举。官方的推荐值是(N/2)+1，其中N是具有master资格的节点的数量。 在新版7.X的ES中，对es的集群发现系统做了调整，不再有discovery.zen.minimum_master_nodes这个控制集群脑裂的配置，转而由集群自主控制，并且新版在启动一个新的集群的时候需要有 cluster.initial_master_nodes初始化集群列表。在es7中，discovery.zen.* 开头的参数，有些已经失效

常用做法（中大规模集群）

① Master 和 dataNode 角色分开，配置奇数个master，如3

② 单播发现机制，配置master资格节点(5.0之前)：discovery.zen.ping.multicast.enabled: false —— 关闭多播发现机制，默认是关闭的

③ 延长ping master的等待时长discovery.zen.ping_timeout: 30（默认值是3秒）——其他节点ping主节点多久时间没有响应就认为主节点不可用了。es7中换成了         discovery.request_peers_timeout

索引应该设置多少个分片？

分片数指定后不可变，除非重建索引

分片设置的可参考原则： ElasticSearch推荐的最大JVM堆空间是30~32G，所以把你的分片最大容量限制为30GB, 然后再对分片数量做合理估算。例如, 你认为你的数据能达到200GB, 推荐你最多分配7到8个分片。 在开始阶段, 一个好的方案是根据你的节点数量按照1.5~3倍的原则来创建分片，例如，如果你有3个节点, 则推荐你创建的分片数最多不超过9(3x3)个。当性能下降时，增加节点，ES会平衡分片的放置。 对于基于日期的索引需求, 并且对索引数据的搜索场景非常少. 也许这些索引量将达到成百上千, 但每个索引的数据量只有1GB甚至更小. 对于这种类似场景, 建议只需要为索引分配1个分片。如日志管理就是 一个日期的索引需求，日期索引会很多，但每个索引存放的日志数据量就很少

分片数设置过小

- 导致后续无法增加节点实现水平扩展

- 单个分片的数据量太大，导致数据重新分配耗时

分片数设置过大

// 查看集群的健康状况 GET _cluster/health

分片应该设置几个副本？

副本设置基本原则： 为保证高可用，副本数设置为2即可。要求集群至少要有3个节点，来分开存放主分片、副本。 如发现并发量大时，查询性能会下降，可增加副本数，来提升并发查询能力。 注意：新增副本时主节点会自动协调，然后拷贝数据到新增的副本节点，副本数是可以随时调整的！

分布式集群调优策略

Index 写调优

拉勾网的职位数据和简历数据，首先都是进入MySQL集群的，我们从MySQL的原始表里面抽取并存储到ES 的Index，而MySQL的原始数据也是经常在变化的，所以快速写入Elasticsearch、以保持 Elasticsearch和MySQL的数据及时同步也是很重要的。 拉勾网的工程师主要是下面几个方面优化来提高写入的速度：

副本数为0

如果是集群首次灌入数据，可以将副本数设置为0，写入完毕再调整回去，这样副本分片只需要拷贝，节省了索引过程。

自动生成doc ID

通过Elasticsearch写入流程可以看出，如果写入doc时如果外部指定了id，则Elasticsearch会先尝试读取原来doc的版本号，以判断是否需要更新。这会涉及一次读取磁盘的操作，通过自动生成doc ID可 以避免这个环节

合理设置mappings

将不需要建立索引的字段index属性设置为not_analyzed或no。对字段不分词，或者不索引，可以减少很多运算操作，降低CPU占用。 尤其是binary类型，默认情况下占用CPU非常高，而这种类型进行分词通常没有什么意义。

减少字段内容长度，如果原始数据的大段内容无须全部建立索引，则可以尽量减少不必要的内容

使用不同的分析器（analyzer），不同的分析器在索引过程中运算复杂度也有较大的差异

调整_source字段

_source 字段用于存储 doc 原始数据，对于部分不需要存储的字段，可以通过 includes excludes过滤，或者将source禁用，一般用于索引和数据分离，这样可以降低 I/O 的压力，不过实际场景中大多不会禁用_source

_source 字段默认是存储的，什么情况下不用保留_source字段？

如果某个业务内容非常多，业务里面只需要能对该字段进行搜索，最后返回文档id，查看文档内容再次到Mysql或者Hbase中取数据，把大字段的内容在ElasticSearch 中只会增大索引，这一点文档数量越大越明显。

对analyzed的字段禁用norms（禁止评分）

Norms用于在搜索时计算doc的评分，如果不需要评分，则可以将其禁用

调整索引的刷新间隔

该参数缺省是1s，强制ES每秒创建一个新segment，从而保证新写入的数据近实时的可见、可被搜索到。比如该参数被调整为30s，降低了刷新的次数，把刷新操作消耗的系统资源释放出来给index操作使用。

这种方案以牺牲可见性的方式，提高了index操作的性能。

批处理

批处理把多个index操作请求合并到一个batch中去处理，和mysql的jdbc的bacth有类似之处。如图：

比如每批1000个documents是一个性能比较好的size。每批中多少document条数合适，受很多因素影响而不同，如单个document的大小等。ES官网建议通过在单个node、单个shard做性能基准测试来确定这个参数的最优值

Document的路由处理

当对一批中的documents进行index操作时，该批index操作所需的线程的个数由要写入的目的shard的个数决定。看下图：

上图中，有2批documents写入ES，每批都需要写入4个shard，所以总共需要8个线程。如果能减少 shard的个数，那么耗费的线程个数也会减少。例如下图，两批中每批的shard个数都只有2个，总共线程消耗个数4个，减少一半。 默认的routing就是id，也可以在发送请求的时候，手动指定一个routing value，比如说put /index/doc/id?routing=user_id

值得注意的是线程数虽然降低了，但是单批的处理耗时可能增加了。和提高刷新间隔方法类似，这有可能会延长数据不见的时间。

Search 读调优

在存储的Document条数超过10亿条后，我们如何进行搜索调优。

数据分组

可以基于日期，或者基于租户/用户分组

使用Filter替代Query（不打分））

ID字段定义为keyword

一般情况，如果ID字段不会被用作Range 类型搜索字段，都可以定义成keyword类型。这是因为 keyword会被优化，以便进行terms查询。Integers等数字类的mapping类型，会被优化来进行range类 型搜索。 将integers改成keyword类型之后，搜索性能大约能提升30%。

别让用户的无约束的输入拖累了ES集群的性能

生产环境常见集群部署方案

不同角色的节点：Master eligible / Data / Ingest / Coordinating /Machine Learning

一个节点只承担一个角色的配置

单一 master eligible nodes:  负责集群状态(cluster state)的管理

使用低配置的CPU，RAM和磁盘

单一 data nodes: 负责数据存储及处理客户端请求

使用高配置的CPU，RAM和磁盘

单一ingest nodes: 负责数据处理

使用高配置CPU; 中等配置的RAM; 低配置的磁盘

单一 Coordinating Only Nodes(Client Node)

使用高配置CPU; 高配置的RAM; 低配置的磁盘

生产环境中，建议为一些大的集群配置Coordinating Only Nodes

- 扮演Load Balancers，降低Master和 Data Nodes的负载

- 负责搜索结果的Gather/Reduce

- 有时候无法预知客户端会发送怎么样的请求。比如大量占用内存的操作，一个深度聚合可能会引发OOM

单一 master eligible nodes

从高可用 & 避免脑裂的角度出发：

一般在生产环境中配置3台

一个集群只有1台活跃的主节点（master node）

- 负责分片管理，索引创建，集群管理等操作

如果和数据节点或者Coordinate节点混合部署

- 数据节点相对有比较大的内存占用

- Coordinate节点有时候可能会有开销很高的查询，导致OOM

- 这些都有可能影响Master节点，导致集群的不稳定

增加节点水平扩展场景

当磁盘容量无法满足需求时，可以增加数据节点；

磁盘读写压力大时，增加数据节点

当系统中有大量的复杂查询及聚合时候，增加Coordinating节点，增加查询的性能

读写分离架构

异地多活架构（两地三中心）

集群处在三个数据中心，数据三写，GTM分发读请求

全局流量管理（GTM）和负载均衡（SLB）的区别

GTM 是通过DNS将域名解析到多个IP地址，不同用户访问不同的IP地址，来实现应用服务流量的分配。同时通过健康检查动态更新DNS解析IP列表，实现故障隔离以及故障切换。最终用户的访问直接连接服务的IP地址，并不通过GTM。而 SLB 是通过代理用户访问请求的形式将用户访问请求实时分发到不同的服务器，最终用户的访问流量必须要经过SLB。一般来说，相同Region使用SLB进行负载均衡，不同region的多个SLB地址时，则可以使用GTM进行负载均衡。

ES 跨集群复制（Cross-Cluster Replication）是ES 6.7的的一个全局高可用特性。CCR允许不同的索引复制到一个或多个ES 集群中。

Hot & Warm 架构

为什么要设计Hot & Warm 架构？

<ul><li>- ES数据通常不会有 Update操作;</li><li>- 适用于Time based索引数据，同时数据量比较大的场景。</li><li>- 引入 Warm节点，低配置大容量的机器存放老数据，以降低部署成本</li></ul>

两类数据节点，不同的硬件配置： <ul><li>Hot节点(通常使用SSD)︰索引不断有新文档写入。</li><li>Warm 节点（通常使用HDD)︰索引不存在新数据的写入，同时也不存在大量的数据查询</li></ul>

Hot Node

用于数据的写入： <ul><li>lndexing 对 CPU和IO都有很高的要求，所以需要使用高配置的机器</li><li>存储的性能要好，建议使用SSD</li></ul>

Warm Nodes

用于保存只读的索引，比较旧的数据。通常使用大容量的磁盘

配置Hot & Warm 架构

如何对集群的容量进行规划

ES跨集群搜索（CCS）

ES水平扩展存在的问题

单集群水平扩展时，节点数不能无限增加

当集群的meta 信息(节点，索引，集群状态）过多会导致更新压力变大，单个Active Master会成为性能瓶颈，导致整个集群无法正常工作

早期版本，通过Tribe Node可以实现多集群访问的需求，但是还存在一定的问题

- Tribe Node会以Client Node的方式加入每个集群，集群中Master节点的任务变更需要Tribe Node 的回应才能继续。

- Tribe Node 不保存Cluster State信息，一旦重启，初始化很慢

- 当多个集群存在索引重名的情况时，只能设置一种 Prefer 规则

跨集群搜索实战

早期Tribe Node 的方案存在一定的问题，现已被弃用。Elasticsearch 5.3引入了跨集群搜索的功能(Cross Cluster Search)，推荐使用 <ul><li>允许任何节点扮演联合节点，以轻量的方式，将搜索请求进行代理</li><li>不需要以Client Node的形式加入其他集群</li></ul>

配置集群

CCS的配置

分片的设计和管理

单个分片

7.0开始，新创建一个索引时，默认只有一个主分片。单个分片，查询算分，聚合不准的问题都可以得以避免

单个索引，单个分片时候，集群无法实现水平扩展。即使增加新的节点，无法实现水平扩展

两个分片

集群增加一个节点后，Elasticsearch 会自动进行分片的移动，也叫 Shard Rebalanci

算分不准的原因

相关性算分在分片之间是相互独立的，每个分片都基于自己的分片上的数据进行相关度计算。这会导致打分偏离的情况，特别是数据量很少时。当文档总数很少的情况下，如果主分片大于1，主分片数越多，相关性算分会越不准

解决算分不准的方法

数据量不大的时候，可以将主分片数设置为1。当数据量足够大时候，只要保证文档均匀分散在各个分片上，结果一般就不会出现偏差

使用DFS Query Then Fetch

搜索的URL中指定参数“_search?search_type=dfs_query_then_fetch"

到每个分片把各分片的词频和文档频率进行搜集，然后完整的进行一次相关性算分，耗费更加多的CPU和内存，执行性能低下，—般不建议使用

如何设计分片数

当分片数 > 节点数时

一旦集群中有新的数据节点加入，分片就可以自动进行分配

分片在重新分配时，系统不会有downtime

多分片的好处： 一个索引如果分布在不同的节点，多个节点可以并行执行

- 查询可以并行执行

- 数据写入可以分散到多个机器

分片过多所带来的副作用

Shard是Elasticsearch 实现集群水平扩展的最小单位。过多设置分片数会带来一些潜在的问题： <ul><li>每个分片是一个Lucene的索引，会使用机器的资源。过多的分片会导致额外的性能开销。</li><li>每次搜索的请求，需要从每个分片上获取数据</li><li>分片的Meta 信息由Master节点维护。过多，会增加管理的负担。经验值，控制分片总数在10W以内</li></ul>

如何确定主分片数

从存储的物理角度看

搜索类应用，单个分片不要超过20 GB

日志类应用，单个分片不要大于50 GB

为什么要控制分片存储大小

提高Update 的性能

进行Merge 时，减少所需的资源

丢失节点后，具备更快的恢复速度

便于分片在集群内 Rebalancing

如何确定副本分片数

副本是主分片的拷贝

- 提高系统可用性︰响应查询请求，防止数据丢失

- 需要占用和主分片一样的资源

对性能的影响

副本会降低数据的索引速度： 有几份副本就会有几倍的CPU资源消耗在索引上

会减缓对主分片的查询压力，但是会消耗同样的内存资源。如果机器资源充分，提高副本数，可以提高整体的查询QPS

ES的分片策略会尽量保证节点上的分片数大致相同，但是有些场景下会导致分配不均匀

扩容的新节点没有数据，导致新索引集中在新的节点

热点数据过于集中，可能会产生性能问题

可以通过调整分片总数，避免分配不均衡

- "index.routing.allocation.total_shards_per_node"，index级别的，表示这个index每个Node总共允许存在多少个shard，默认值是-1表示无穷多个；

- "cluster.routing.allocation.total_shards_per_node"，cluster级别，表示集群范围内每个Node允许存在有多少个shard。默认值是-1表示无穷多个。

如果目标Node的Shard数超过了配置的上限，则不允许分配Shard到该Node上。注意：index级别的配置会覆盖cluster级别的配置。

思考：5个节点的集群。索引有5个主分片，1个副本，index.routing.allocation.total_shards_per_node应该如何设置?

- (5+5)/ 5= 2

- 生产环境中要适当调大这个数字，避免有节点下线时，分片无法正常迁移

数据模型构建

什么是数据模型

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象实体及实体之间联系的形式，用图形化的形式去描述业务规则的过程，从而表示现实世界中事务以及相互关系的一种映射。 核心概念：  <ul><li>实体：现实世界中存在的可以相互区分的事物或概念称为实体。           实体可以分为事物实体和概念实体。例如：一个学生、一个程序员等是事物实体。一门课、一个班级等称为概念实体。</li><li>实体的属性：每个实体都有自己的特征，利用实体的属性可以描述不同的实体。例如。学生实体的 属性为姓名、性别、年龄等。</li></ul>

数据建模的过程

数据建模大致分为三个阶段，概念建模阶段，逻辑建模阶段和物理建模阶段。

① 概念建模阶段

概念建模阶段，主要做三件事： 客户交流、理解需求、形成实体

确定系统的核心需求和范围边界，设计实体与实体之间的关系。 在概念建模阶段，我们只需要关注实体即可，不用关注任何实现细节。很多人都希望在这个阶段把具体 表结构，索引，约束，甚至是存储过程都想好，没必要！因为这些东西是我们在物理建模阶段需要考虑 的东西，这个时候考虑还为时尚早。

概念模型在整个数据建模时间占比：10%左右。

② 逻辑建模阶段

逻辑建模阶段，主要做二件事： <ul><li>进一步梳理业务需求</li><li>确定每个实体的属性、关系和约束等。</li></ul>

逻辑模型是对概念模型的进一步分解和细化，描述了实体、实体属性以及实体之间的关系，是概念模型延伸，一般的逻辑模型有第三范式，星型模型和雪花模型。模型的主要元素为主题、实体、实体属性和关系

逻辑模型的作用主要有两点

一是便于技术开发人员和业务人员以及用户进行沟通交流，使得整个概念模型更易于理解，进一 步明确需求。

二是作为物理模型设计的基础，由于逻辑模型不依赖于具体的数据库实现，使用逻辑模型可以生成 针对具体 数据库管理系统的物理模型，保证物理模型充分满足用户的需求。

逻辑模型在整个数据建模时间占比：60—70%左右。

③ 物理建模阶段

物理建模阶段，主要做一件事： 结合具体的数据库产品（mysql/oracle/mongo/elasticsearch），在满足业务读写性能等需求的前提下 确定最终的定义

物理模型是在逻辑模型的基础上描述模型实体的细节，包括数据库产品对应的数据类型、长度、索引等因素，为逻辑模型选择一个最优的物理存储环境。 逻辑模型转化为物理模型的过程也就是实体名转化为表名，属性名转化为物理列名的过程。 在设计物理模型时，还需要考虑数据存储空间的分配，包括对列属性必须做出明确的定义

数据建模的意义

数据模型支撑了系统和数据，系统和数据支撑了业务系统。

一个好的数据模型： <ul><li>能让系统更好的集成、能简化接口。</li><li>能简化数据冗余、减少磁盘空间、提升传输效率。</li><li>兼容更多的数据，不会因为数据类型的新增而导致实现逻辑更改。</li><li>能帮助更多的业务机会，提高业务效率。</li><li>能减少业务风险、降低业务成本。</li></ul>

ES数据建模Mapping设置

ES Mapping 属性

ES Mapping 字段设置流程图

ES Mapping 样例

这个索引 Mapping中，_source设置为false，同时各个字段的store根据需求设置了true和false。 url的 doc_values设置为false，该字段url不用于聚合和排序操作。 建 mapping 时，可以为字符串（专指 keyword）指定 ignore_above ，用来限定字符长度。超过 ignore_above 的字符会被存储，但不会被索引。

注意，是字符长度，一个英文字母是一个字符，一个汉字也是一个字符。 在动态生成的 mapping 中， keyword 类型会被设置 ignore_above: 256 。 ignore_above 可以在创建 mapping 时指定。

ES关联关系处理

关系型数据库范式化（Normalize）设计的主要目标是减少不必要的更新，往往会带来一些副作用： <ul><li>- 一个完全范式化设计的数据库会经常面临“查询缓慢”的问题。数据库越范式化，就需要Join越多的表；</li><li>- 范式化节省了存储空间，但是存储空间已经变得越来越便宜；</li><li>- 范式化简化了更新，但是数据读取操作可能更多。</li></ul>

反范式化(Denormalize)的设计不使用关联关系，而是在文档中保存冗余的数据拷贝。 <ul><li>- 优点： 无需处理Join操作，数据读取性能好。Elasticsearch可以通过压缩_source字段，减少磁盘空间的开销</li><li>- 缺点： 不适合在数据频繁修改的场景。一条数据的改动，可能会引起很多数据的更新</li></ul>

关系型数据库，一般会考虑 Normalize 数据；在Elasticsearch，往往考虑Denormalize 数据。

Application-side joins（应用端关联）

类似于Mysql Join 这种方式，索引之间完全独立（利于对数据进行标准化处理），由应用端的多次查询来实现近似关联关系查询。这种方法适用于关联的实体只有少量的文档记录的情况（使用ES的terms查询具有上限，默认 1024，具体可在elasticsearch.yml中修改），并且最好它们很少改变。这将允许应用程序对结果进行缓存，并避免经常运行第一次查询

应用端自己程序逻辑进行回表

Data denormalization（数据的非规范化）

这种方式，通俗点就是通过字段冗余，以一张大宽表来实现粗粒度的index，这样可以充分发挥扁平化的优势。但是这是以牺牲索引性能及灵活度为代价的。使用的前提：冗余的字段应该是很少改变的，比较适合与一对少量关系的处理。当业务数据库并非采用非规范化设计时，这时要将数据同步到作为二级索引库的ES中，就需要进行定制化开发，基于特定业务进行应用开发来处理join关联和实体拼接。  说明：宽表处理在处理一对多、多对多关系时，会有字段冗余问题，适合“一对少量”且这个“一”更新不 频繁的应用场景。

Nested objects（嵌套文档）

索引性能和查询性能二者不可兼得，必须进行取舍。嵌套文档将实体关系嵌套组合在单文档内部，这种方式牺牲建立索引性能（文档内任一属性变化都需要重新索引该文档）来换取查询性能，比较适合于一对少量的关系处理。 当使用嵌套文档时，使用通用的查询方式是无法访问到的，必须使用合适的查询方式（nested query、 nested filter、nested facet等），很多场景下，使用嵌套文档的复杂度在于索引阶段对关联关系的组织拼装

Parent/child relationships（父子文档）

父子文档牺牲了一定的查询性能来换取索引性能，适用于写多读少的场景。父子文档相比嵌套文档较灵活，适用于“一对大量”且这个“一”不是海量的应用场景，该方式比较耗内存和CPU，这种方式查询比嵌套方式慢5~10倍，且需要使用特定的has_parent和has_child过滤器查询语法，查询结果不能同时返回父子文档（一次join查询只能返回一种类型的文档）。受限于父子文档必须在同一分片上（可以通过 routing指定父文档id即可）操作子文档时需要指定routing。

嵌套文档 VS 父子文档

ingest Pipeline & Painless Script

应用场景：修复与增强写入数据

案例

Ingest Node

Elasticsearch 5.0后，引入的一种新的节点类型。默认配置下，每个节点都是Ingest Node： <ul><li>- 具有预处理数据的能力，可拦截lndex或 Bulk API的请求</li><li>- 对数据进行转换，并重新返回给Index或 Bulk APl</li></ul> 无需Logstash，就可以进行数据的预处理，例如： <ul><li>- 为某个字段设置默认值；重命名某个字段的字段名；对字段值进行Split 操作</li><li>- 支持设置Painless脚本，对数据进行更加复杂的加工</li></ul>

Pipeline & Processor

<ul><li>Pipeline ——管道会对通过的数据(文档)，按照顺序进行加工</li><li>Processor——Elasticsearch 对一些加工的行为进行了抽象包装</li></ul>

一些内置的Processors

- Split Processor ： 将给定字段值分成一个数组

- Remove / Rename Processor ：移除一个重命名字段

- Append ： 为商品增加一个新的标签

- Convert：将商品价格，从字符串转换成float 类型

- Date / JSON：日期格式转换，字符串转JSON对象

- Date lndex Name Processor︰将通过该处理器的文档,分配到指定时间格式的索引中

- Fail Processor︰一旦出现异常，该Pipeline 指定的错误信息能返回给用户

- Foreach Process︰数组字段，数组的每个元素都会使用到一个相同的处理器

- Grok Processor︰日志的日期格式切割)

- Gsub / Join / Split︰字符串替换│数组转字符串/字符串转数组

- Lowercase / upcase︰大小写转换

Ingest Node VS Logstash

Painless

自Elasticsearch 5.x后引入，专门为Elasticsearch 设计，扩展了Java的语法。6.0开始，ES只支持 Painless。Groovy，JavaScript和 Python 都不再支持。Painless支持所有Java 的数据类型及Java API子集。

Painless Script具备以下特性： <ul><li>高性能/安全</li><li>支持显示类型或者动态定义类型</li></ul>

Painless的用途

可以对文档字段进行加工处理

更新或删除字段，处理数据聚合操作

Script Field：对返回的字段提前进行计算

Function Score：对文档的算分进行处理

在lngest Pipeline中执行脚本

在Reindex APl，Update By Query时，对数据进行处理

ElasticSearch数据建模最佳实践

如何处理关联关系

<ul><li>- Object: 优先考虑反范式（Denormalization）</li><li>- Nested: 当数据包含多数值对象，同时有查询需求</li><li>- Child/Parent：关联文档更新非常频繁时</li></ul>

避免过多字段

一个文档中，最好避免大量的字段

 过多的字段数不容易维护

Mapping 信息保存在Cluster State 中，数据量过大，对集群性能会有影响

删除或者修改数据需要reindex

默认最大字段数是1000，可以设置index.mapping.total_fields.limit限定最大字段数。

思考：什么原因会导致文档中有成百上千的字段?

生产环境中，尽量不要打开 Dynamic，可以使用Strict控制新增字段的加入 <ul><li>- true ：未知字段会被自动加入</li><li>- false ：新字段不会被索引，但是会保存在_source</li><li>- strict ：新增字段不会被索引，文档写入失败</li></ul> 对于多属性的字段，比如cookie，商品属性，可以考虑使用Nested

避免正则，通配符，前缀查询

正则，通配符查询，前缀查询属于Term查询，但是性能不够好。特别是将通配符放在开头，会导致性能的灾难

避免空值引起的聚合不准

为索引的Mapping加入Meta 信息

Mappings设置非常重要，需要从两个维度进行考虑

功能︰搜索，聚合，排序

性能︰存储的开销; 内存的开销; 搜索的性能

Mappings设置是一个迭代的过程

加入新的字段很容易（必要时需要update_by_query)

更新删除字段不允许(需要Reindex重建数据)

最好能对Mappings 加入Meta 信息，更好的进行版本管理

可以考虑将Mapping文件上传git进行管理

深度应用及原理

ES整体结构

ElasticSearch整体结构

<ul><li> 一个 ES Index 在集群模式下，有多个 Node （节点）组成。每个节点就是 ES 的Instance (实例)。</li><li> 每个节点上会有多个 shard （分片）， P1 P2 是主分片, R1 R2 是副本分片</li><li> 每个分片上对应着就是一个 Lucene Index（底层索引文件）</li></ul> Lucene Index 是一个统称 <ul><li>  由多个 Segment （段文件，就是倒排索引）组成。每个段文件存储着就是 Doc 文档集合。</li><li>  commit point记录了所有 segments 的信息</li></ul>

Lucene索引结构

更多文件类型可参考 http://lucene.apache.org/core/7_2_1/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description

文件的关系如下：

Lucene处理流程

创建索引的过程： <ul><li>准备待索引的原文档，数据来源可能是文件、数据库或网络</li><li>对文档的内容进行分词组件处理，形成一系列的Term</li><li>索引组件对文档和Term处理，形成字典和倒排表</li></ul>

搜索索引的过程： <ul><li>对查询语句进行分词处理，形成一系列Term</li><li>根据倒排索引表查找出包含Term的文档，并进行合并形成符合结果的文档集</li><li>比对查询语句与各个文档相关性得分，并按照得分高低返回</li></ul>

ElasticSearch分析器

内置分析器

什么时候使用分析器

索引文档写入和近实时搜索原理

基本概念

Segments in Lucene

众所周知，Elasticsearch 存储的基本单元是 shard ， ES 中一个 Index 可能分为多个 shard，事实上 每个 shard 都是一个 Lucence 的 Index，并且每个 Lucence Index 由多个 Segment 组成，每个 Segment 事实上是一些倒排索引的集合，每次创建一个新的 Document ，都会归属于一个新的 Segment，而不会去修改原来的 Segment 。且每次的文档删除操作，会仅仅标记 Segment 中该文档为删除状态，而不会真正的立马物理删除，所以说 ES 的 index 可以理解为一个抽象的概念。就像下图所示：

Commits in Lucene

Commit 操作意味着将 Segment 合并，并写入磁盘。保证内存数据尽量不丢。但刷盘是很重的 IO 操作， 所以为了机器性能和近实时搜索， 并不会刷盘那么及时。

Translog（事务日志）

新文档被索引意味着文档会被首先写入内存 buffer 和 translog 文件。每个 shard 都对应一个 translog 文件

Refresh in Elasticsearch

在 Elasticsearch 中， _refresh 操作默认每秒执行一次，意味着将内存 buffer 的数据写入到一个新的 Segment 中，这个时候索引变成了可被检索的。写入新Segment后会清空内存buffer。

Flush in Elasticsearch

Flush 操作意味着将内存 buffer 的数据全都写入新的 Segments 中，并将内存中所有的 Segments 全部刷盘，并且清空 translog 日志的过程。

近实时搜索

概述

提交（Commiting）一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。 我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。在 Elasticsearch 和磁盘之间是文件系统缓存。像之前描述的一样， 在内存索引缓冲区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存--这一步代价会比较低，稍后再被刷新到磁盘--这一步代价比较高。不过只要文件已经在系统缓存中，就可以像其它文件一样被打开和读取了 ps: 在内存缓冲区中包含了新文档的 Lucene 索引

Lucene 允许新段被写入和打开——使其包含的文档在未进行一次完整提交时便对搜索可见。这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。 ps：缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交

原理

下图表示是 es 写操作流程，当一个写请求发送到 es 后，es 将数据写入 memory buffer 中，并添加事务日志（ translog ）。如果每次一条数据写入内存后立即写到硬盘文件上，由于写入的数据肯定是离散的，因此写入硬盘的操作也就是随机写入了。硬盘随机写入的效率相当低，会严重降低es的性能。因此 es 在设计时在 memory buffer 和硬盘间加入了 Linux 的高速缓存（ File system cache ）来提高 es 的写效率。        当写请求发送到 es 后，es 将数据暂时写入 memory buffer 中，此时写入的数据还不能被查询到。默认设置下，es 每1秒钟将 memory buffer 中的数据 refresh 到 Linux 的 File system cache ，并清空 memory buffer ，此时写入的数据就可以被查询到了。

Refresh API

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时搜索： 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

强制让某次请求直接refresh

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件，你可能想优化索引速度而不是近实时搜索，可以通过设置 refresh_interval ，降低每个索引的刷新频率

refresh_interval 可以在既存索引上进行动态更新。在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来：

持久化变更

原理

如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。 在动态更新索引时，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。 Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。 即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。

Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。通过 translog ，整个流程看起来是下面这样： 新的文档被添加到内存缓冲区并且被追加到了事务日志

① 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog

② 刷新（refresh）使分片处于下图描述的状态，分片每秒被刷新（refresh）一次：  <ul><li> 这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。 </li><li> 这个段被打开，使其可被搜索。 </li><li> 内存缓冲区被清空。</li></ul>

③ 这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志

④ 每隔一段时间--例如 translog 变得越来越大--索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行 <ul><li> 所有在内存缓冲区的文档都被写入一个新的段。 </li><li> 缓冲区被清空。 </li><li> 一个提交点被写入硬盘。 </li><li> 文件系统缓存通过 fsync 被刷新（flush）。 </li><li> 老的 translog 被删除。</li></ul> translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候，它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。        translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前，首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

flush API

执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush 。分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候（默认大小 512MB）也会刷新。

flush API 可以被用来执行一个手工的刷新（flush）:

<ul><li> 刷新（flush） blogs 索引。 </li><li> 刷新（flush）所有的索引并且等待所有刷新在返回前完成。我们很少需要自己手动执行一个的 flush 操作；通常情况下，自动刷新就足够了。</li></ul>

这就是说，在重启节点或关闭索引之前执行 flush有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引，它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。

TransLog 有多安全？

在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘，或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终，基本上，这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。在每次写请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。

但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。 这个行为可以通过设置 durability 参数为 async 来启用：

这个选项可以针对索引单独设置，并且可以动态进行修改。如果你决定使用异步 translog 的话，你需要保证在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。如果你不确定这个行为的后果，最好是使用默认的参数（ "index.translog.durability": "request" ）来避免数据丢失。

索引文档存储段合并机制

段合并机制（segment merge）

由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 CPU 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。 Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中

启动段合并在进行索引和搜索时会自动进行

1、当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。

2、合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

3、合并完成时的活动：  <ul><li>新的段被刷新（flush）到了磁盘。 写入一个包含新段且排除旧的和较小的段的新提交点。 </li><li>新的段被打开用来搜索。</li><li>老的段被删除。</li></ul>

合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。默认情况下，归并线程的限速配置 indices.store.throttle.max_bytes_per_sec 是 20MB。对于写入量较大，磁盘转速较高，甚至使用 SSD 盘的服务器来说，这个限速是明显过低的。对于 ELK Stack 应用，建议可以适当调大到 100MB或者更高。

用于控制归并线程的数目，推荐设置为cpu核心数的一半。如果觉得自己磁盘性能跟不上，可以降低配置，免得IO情况瓶颈 index.merge.scheduler.max_thread_count

归并策略 policy

optimize API

optimize API 大可看做是 强制合并 API。它会将一个分片强制合并到 max_num_segments 参数指定 大小的段数目。 这样做的意图是减少段的数量（通常减少到一个），来提升搜索性能。  在特定情况下，使用 optimize API 颇有益处。例如在日志这种用例下，每天、每周、每月的日志被存 储在一个索引中。 老的索引实质上是只读的；它们也并不太可能会发生变化。在这种情况下，使用optimize 优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以 使搜索更加快速

并发冲突处理

悲观锁

乐观锁

Elasticsearch的乐观锁（_version）

Elasticsearch的多线程异步并发修改是基于自己的_version版本号进行乐观锁并发控制的。 在后修改的先到时，比较版本号，版本号相同修改可以成功，而当先修改的后到时，也会比较一下 _version版本号，如果不相等就再次读取新的数据修改。这样结果会就会保存为一个正确状态，删除操作也会对这条数据的版本号加1

在删除一个document之后，可以从一个侧面证明，它不是立即物理删除掉的，因为它的一些版本号等信息还是保留着的。先删除一条document，再重新创建这条document，其实会在delete version基础 之上，再把version号加1

基于external version进行乐观锁并发控制

es提供了一个feature，就是说，你可以不用它提供的内部_version版本号来进行并发控制，可以基于你自己维护的一个版本号来进行并发控制。

区别在于，_version方式，只有当你提供的version与es中的version一模一样的时候，才可以进行修改，只要不一样，就报错；当version_type=external的时候，只有当你提供的version比es中的_version大的时候，才能完成修改

es，if_seq_no=0&if_primary_term=1  和文档中的值相等才能更新成功 es，_version=1，?version>1&version_type=external，才能成功，比如说? version=2&version_type=external

分布式数据一致性保证

ES5.0之前

命令：PUT /index/indextype/id?consistency=quorum

参数

One（primary shard）

要求我们这个写操作，只要有一个primary shard是active状态，就可以执行

All（all shard）

要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写 操作。

quorum（default）

默认值，要求所有的shard中，必须是法定数的shard都是活跃的，可用的，才可以执行这个写操作。

quorum机制

写之前必须确保法定数shard可用

timeout机制

quorum不齐全时，会wait（等待）1分钟（默认）

等待期间，期望活跃的shard数量可以增加，最后无法满足shard数量就会timeout，我们其实可以在写操作的时候，加一个timeout参数，比如说 PUT /index/_doc/id?timeout=30s，这个就是说自己去设定,quorum不齐全的时候，ES的timeout时长。默认是毫秒，加个s代表秒

ES5.0以及以后

从ES5.0后，原先执行put 带 consistency=all / quorum 参数的，都报错了，提示语法错误。 原因是consistency检查是在Put之前做的。然而，虽然检查的时候，shard满足quorum，但是真正从 primary shard写到replica之前，仍会出现shard挂掉，但Update Api会返回succeed。因此，这个检查并不能保证replica成功写入，甚至这个primary shard是否能成功写入也未必能保证。 因此，修改了语法，用了下面的 wait_for_active_shards，因为这个更能清楚表述，而没有歧义。

Query文档搜索机制剖析

2.0之前四种 QUERY_AND_FETCH、 DFS_QUERY_AND_FETCH、QUERY_THEN_FETCH、 DFS_QUERY_THEN_FETCH 2.0版本之后只有两种了：DFS_QUERY_THEN_FETCH、QUERY_THEN_FETCH

可以通过java的API 设置

query and fetch

向索引的所有分片（ shard）都发出查询请求，各分片返回的时候把元素文档（ document）和计算后的排名信息一起返回。这种搜索方式是最快的。因为相比下面的几种搜索方式，这种查询方法只需要去 shard查询一次。但是各个 shard 返回的结果的数量之和可能是用户要求的 size 的 n 倍。

优点：这种搜索方式是最快的。因为相比后面的几种es的搜索方式，这种查询方法只需要去shard 查询一次。

缺点：返回的数据量不准确， 可能返回(N*分片数量)的数据并且数据排名也不准确，同时各个 shard返回的结果的数量之和可能是用户要求的size的n倍。

DFS（distributed frequency scatter） query and fetch

这个D是Distributed，F是frequency的缩写，至于S是Scatter的缩写，整个DFS是分布式词频率和文档频率散发的缩写。 DFS 其实就是在进行真正的查询之前，先把各个分片的词频率和文档频率收集一下，然后进行词搜索的时候，各分片依据全局的词频率和文档频率进行搜索和排名。这种方式比第一种方式多了一个 DFS 步骤(初始化散发(initial scatter))，可以更精确控制搜索打分和排名。也就是在进行查询之前，先对所有分片发送请求，把所有分片中的词频和文档频率等打分依据全部汇总到一块，再执行后面的操作。

优点：数据排名准确

缺点： 性能一般 返回的数据量不准确， 可能返回(N*分片数量)的数据

query then fetch（es 默认的搜索方式）

如果你搜索时， 没有指定搜索方式， 就是使用的这种搜索方式。 这种搜索方式， 大概分两个步骤：  第一步， 先向所有的 shard 发出请求， 各分片只返回文档 id（注意， 不包括文档 document）和排名相关的信息（也就是文档对应的分值）， 然后按照各分片返回的文档的分数进行重新排序和排名， 取前 size 个文档。  第二步， 根据文档 id 去相关的 shard 取 document。 这种方式返回的 document 数量与用户要求的大小是相等的。

详细步骤

1.发送查询到每个shard  2.找到所有匹配的文档，并使用本地的Term/Document Frequency信息进行打分  3.对结果构建一个优先队列（排序，标页等）  4.返回关于结果的元数据到请求节点。注意，实际文档还没有发送，只是分数  5.来自所有shard的分数合并起来，并在请求节点上进行排序，文档被按照查询要求进行选择  6.最终，实际文档从他们各自所在的独立的shard上检索出来  7.结果被返回给用户

优点：返回的数据量是准确的。

缺点：性能一般，并且数据排名不准确

DFS query then fetch

比第 3 种方式多了一个 DFS 步骤。也就是在进行查询之前，先对所有分片发送请求，把所有分片中的词频和文档频率等打分依据全部汇总到一块，再执行后面的操作。

详细步骤

1.预查询每个shard，询问Term和Document frequency 2.发送查询到每个shard 3.找到所有匹配的文档，并使用全局的Term/Document Frequency信息进行打分 4.对结果构建一个优先队列（排序，标页等） 5.返回关于结果的元数据到请求节点。注意，实际文档还没有发送，只是分数 6.来自所有shard的分数合并起来，并在请求节点上进行排序，文档被按照查询要求进行选择 7.最终，实际文档从他们各自所在的独立的shard上检索出来 8.结果被返回给用户

优点： 返回的数据量是准确的、数据排名准确

缺点： 性能最差【 这个最差只是表示在这四种查询方式中性能最慢， 也不至于不能忍受，如果对查询性能要求不是非常高， 而对查询准确度要求比较高的时候可以考虑这个】

文档增删改和搜索请求过程

写入/索引文件（增删改）

增删改流程 （1）客户端首先会选择一个节点node发送请求过去，这个节点node可能是协调节点coordinating node （2）协调节点coordinating node会对document数据进行路由，将请求转发给对应的node（含有 primary shard） （3）实际上node的primary shard会处理请求，然后将数据同步到对应的含有replica shard的node （4）协调节点coordinating node如果发现含有primary shard的node和所有的含有replica shard的 node符合要求的数量之后，就会返回响应结果给客户端

文档索引过程详解

整体流程

① 协调节点默认使用文档ID参与计算（也支持通过routing），以便为路由提供合适的分片。         shard = hash(document_id) % (num_of_primary_shards)

②  当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到 Filesystem Cache，这个从Momery Buffer到Filesystem Cache的过程就叫做refresh；

③ 当然在某些情况下，存在Momery Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush。

④ 在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog。 flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时。

分步骤看数据持久化过程

write 过程

一个新文档过来，会存储在 in-memory buffer 内存缓存区中，顺便会记录 Translog（Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录）。 这时候数据还没到 segment ，是搜不到这个新文档的。数据只有被 refresh 后，才可以被搜索到。

refresh 过程

refresh 默认 1 秒钟，执行一次上图流程。ES 是支持修改这个值的，通过 index.refresh_interval 设置 refresh （冲刷）间隔时间。refresh 流程大致如下： <ol><li>in-memory buffer 中的文档写入到新的 segment 中，但 segment 是存储在文件系统的缓存中。此时文档可以被搜索到</li><li>最后清空 in-memory buffer。注意: Translog 没有被清空，为了将 segment 数据写到磁盘</li><li>文档经过 refresh 后， segment 暂时写到文件系统缓存，这样避免了性能 IO 操作，又可以使文档搜索到。refresh 默认 1 秒执行一次，性能损耗太大。一般建议稍微延长这个 refresh 时间间隔，比如 5 s。因此，ES 其实就是准实时，达不到真正的实时。</li></ol>

flush 过程

每隔一段时间—例如 translog 变得越来越大—索引被刷新（flush）；一个新的 translog 被创建，并且一个全量提交被执行

上个过程中 segment 在文件系统缓存中，会有意外故障文档丢失。那么，为了保证文档不会丢失，需要将文档写入磁盘。那么文档从文件缓存写入磁盘的过程就是 flush。写入磁盘后，清空 translog。具体过程如下： <ol><li>所有在内存缓冲区的文档都被写入一个新的段。</li><li>缓冲区被清空。</li><li>一个Commit Point被写入硬盘。</li><li>文件系统缓存通过 fsync 被刷新（flush）。</li><li>老的 translog 被删除。</li></ol>

merge 过程

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。 Elasticsearch通过在后台进行Merge Segment来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会中断索引和搜索。

一旦合并结束，老的段被删除： <ol><li>新的段被刷新（flush）到了磁盘。  写入一个包含新段且排除旧的和较小的段的新提交点。</li><li>新的段被打开用来搜索。</li><li>老的段被删除。</li></ol>

合并大的段需要消耗大量的I/O和CPU资源，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行

深入ElasticSearch索引文档的实现机制

写操作的关键点

可靠性：或者是持久性，数据写入系统成功后，数据不会被回滚或丢失。

一致性：数据写入成功后，再次查询时必须能保证读取到最新版本的数据，不能读取到旧数据。

原子性：一个写入或者更新操作，要么完全成功，要么完全失败，不允许出现中间状态。

隔离性：多个写入操作相互不影响。

实时性：写入后是否可以立即被查询到。

性能：写入性能，吞吐量到底怎么样。

Lucene的写

众所周知，Elasticsearch内部使用了Lucene完成索引创建和搜索功能，Lucene中写操作主要是通过IndexWriter类实现，IndexWriter提供三个接口：

通过这三个接口可以完成单个文档的写入，更新和删除功能，包括了分词，倒排创建，正排创建等等所有搜索相关的流程。只要Doc通过IndesWriter写入后，后面就可以通过IndexSearcher搜索了，看起来功能已经完善了，但是仍然有一些问题没有解： <ul><li>- 上述操作是单机的，而不是我们需要的分布式。</li><li>- 文档写入Lucene后并不是立即可查询的，需要生成完整的Segment后才可被搜索，如何保证实时性？</li><li>- Lucene生成的Segment是在内存中，如果机器宕机或掉电后，内存中的Segment会丢失，如何保证数据可靠性？</li><li>- Lucene不支持部分文档更新，但是这又是一个强需求，如何支持部分更新？</li></ul>

Elasticsearch的写

Elasticsearch采用多Shard方式，通过配置 routing规则 将数据分成多个数据子集，每个数据子集提供独立的索引和搜索功能。当写入文档的时候，根据routing规则，将文档发送给特定Shard中建立索引。这样就能实现分布式了。 此外，Elasticsearch整体架构上采用了一主多副的方式：

每个Index由多个Shard组成，每个Shard有一个主节点和多个副本节点，副本个数可配。但每次写入的时候，写入请求会先根据_routing规则选择发给哪个Shard，Index Request中可以设置使用哪个Filed的值作为路由参数，如果没有设置，则使用Mapping中的配置，如果mapping中也没有配置，则使用_id作为路由参数，然后通过_routing的Hash值选择出Shard（在OperationRouting类中），最后从集群的Meta中找出出该Shard的Primary节点。 请求接着会发送给Primary Shard，在Primary Shard上执行成功后，再从Primary Shard上将请求同时发送给多个Replica Shard，请求在多个Replica Shard上执行成功并返回给Primary Shard后，写入请求执行成功，返回结果给客户端。 这种模式下，写入操作的延时就等于 latency = Latency(Primary Write) + Max(Replicas Write)。只要有副本在，写入延时最小也是两次单Shard的写入时延总和，写入效率会较低，但是这样的好处也很明显，避免写入后，单机或磁盘故障导致数据丢失，在数据重要性和性能方面，一般都是优先选择数据，除非一些允许丢数据的特殊场景。 采用多个副本后，避免了单机或磁盘故障发生时，对已经持久化后的数据造成损害，但是Elasticsearch里为了减少磁盘IO保证读写性能，一般是每隔一段时间（比如5分钟）才会把Lucene的Segment写入磁盘持久化，对于写入内存，但还未Flush到磁盘的Lucene数据，如果发生机器宕机或者掉电，那么内存中的数据也会丢失，这时候如何保证？ 对于这种问题，Elasticsearch学习了数据库中的处理方式：增加CommitLog模块，Elasticsearch中叫TransLog。

在每一个Shard中，写入流程分为两部分，先写入Lucene，再写入TransLog。 写入请求到达Shard后，先写Lucene文件，创建好索引，此时索引还在内存里面，接着去写TransLog，写完TransLog后，刷新TransLog数据到磁盘上，写磁盘成功后，请求返回给用户。这里有几个关键点: <ul><li>一是和数据库不同，数据库是先写CommitLog，然后再写内存，而Elasticsearch是先写内存，最后才写TransLog，一种可能的原因是Lucene的内存写入会有很复杂的逻辑，很容易失败，比如分词，字段长度超过限制等，比较重，为了避免TransLog中有大量无效记录，减少recover的复杂度和提高速度，所以就把写Lucene放在了最前面。</li><li>二是写Lucene内存后，并不是可被搜索的，需要通过Refresh把内存的对象转成完整的Segment后，然后再次reopen后才能被搜索，一般这个时间设置为1秒钟，导致写入Elasticsearch的文档，最快要1秒钟才可被从搜索到，所以Elasticsearch在搜索方面是NRT（Near Real Time）近实时的系统。</li><li>三是当Elasticsearch作为NoSQL数据库时，查询方式是GetById，这种查询可以直接从TransLog中查询，这时候就成了RT（Real Time）实时系统。</li><li>四是每隔一段比较长的时间，比如30分钟后，Lucene会把内存中生成的新Segment刷新到磁盘上，刷新后索引文件已经持久化了，历史的TransLog就没用了，会清空掉旧的TransLog。</li></ul>

上面介绍了Elasticsearch在写入时的两个关键模块，Replica和TransLog，接下来，我们看一下Update流程：

Lucene中不支持部分字段的Update，所以需要在Elasticsearch中实现该功能，具体流程如下： <ol><li>收到Update请求后，从Segment或者TransLog中读取同id的完整Doc，记录版本号为V1。</li><li>将版本V1的全量Doc和请求中的部分字段Doc合并为一个完整的Doc，同时更新内存中的VersionMap。获取到完整Doc后，Update请求就变成了Index请求。 加锁。</li><li>再次从versionMap中读取该id的最大版本号V2，如果versionMap中没有，则从Segment或者TransLog中读取，这里基本都会从versionMap中获取到。</li><li>检查版本是否冲突(V1==V2)，如果冲突，则回退到开始的“Update doc”阶段，重新执行。如果不冲突，则执行最新的Add请求。</li><li>在Index Doc阶段，首先将Version + 1得到V3，再将Doc加入到Lucene中去，Lucene中会先删同id下的已存在doc id，然后再增加新Doc。写入Lucene成功后，将当前V3更新到versionMap中。</li><li>释放锁，部分更新的流程就结束了。</li></ol>

Elasticsearch写入请求类型

Elasticsearch中的写入请求类型，主要包括下列几个：Index(Create)，Update，Delete和Bulk，其中前3个是单文档操作，后一个Bulk是多文档操作，其中Bulk中可以包括Index(Create)，Update和Delete。 在6.0.0及其之后的版本中，前3个单文档操作的实现基本都和Bulk操作一致，甚至有些就是通过调用Bulk的接口实现的。估计接下来几个版本后，Index(Create)，Update，Delete都会被当做Bulk的一种特例化操作被处理。这样，代码和逻辑都会更清晰一些。

<ul><li>- 红色：Client Node。</li><li>- 绿色：Primary Node。</li><li>- 蓝色：Replica Node。</li></ul>

Client Node

① Ingest Pipeline

在这一步可以对原始文档做一些处理，比如HTML解析，自定义的处理，具体处理逻辑可以通过插件来实现。在Elasticsearch中，由于Ingest Pipeline会比较耗费CPU等资源，可以设置专门的Ingest Node，专门用来处理Ingest Pipeline逻辑。 如果当前Node不能执行Ingest Pipeline，则会将请求发给另一台可以执行Ingest Pipeline的Node。

② Auto Create Index

判断当前Index是否存在，如果不存在，则需要自动创建Index，这里需要和Master交互。也可以通过配置关闭自动创建Index的功能。

③ Set Routing

设置路由条件，如果Request中指定了路由条件，则直接使用Request中的Routing，否则使用Mapping中配置的，如果Mapping中无配置，则使用默认的_id字段值。 在这一步中，如果没有指定id字段，则会自动生成一个唯一的_id字段，目前使用的是UUID。

④ Construct BulkShardRequest

由于Bulk Request中会包括多个(Index/Update/Delete)请求，这些请求根据routing可能会落在多个Shard上执行，这一步会按Shard挑拣Single Write Request，同一个Shard中的请求聚集在一起，构建BulkShardRequest，每个BulkShardRequest对应一个Shard

⑤ Send Request To Primary

将每一个BulkShardRequest请求发送给相应Shard的Primary Node

Primary Node

① Index or Update or Delete

循环执行每个Single Write Request，对于每个Request，根据操作类型(CREATE/INDEX/UPDATE/DELETE)选择不同的处理逻辑。 其中，Create/Index是直接新增Doc，Delete是直接根据_id删除Doc，Update会稍微复杂些，我们下面就以Update为例来介绍

② Translate Update To Index or Delete

这一步是Update操作的特有步骤，在这里，会将Update请求转换为Index或者Delete请求。首先，会通过GetRequest查询到已经存在的同_id Doc（如果有）的完整字段和值（依赖_source字段），然后和请求中的Doc合并。同时，这里会获取到读到的Doc版本号，记做V1

③ Parse Doc

这里会解析Doc中各个字段。生成ParsedDocument对象，同时会生成uid Term。在Elasticsearch中，_uid = type # _id，对用户，_Id可见，而Elasticsearch中存储的是_uid。这一部分生成的ParsedDocument中也有Elasticsearch的系统字段，大部分会根据当前内容填充，部分未知的会在后面继续填充ParsedDocument

④ Update Mapping

Elasticsearch中有个自动更新Mapping的功能，就在这一步生效。会先挑选出Mapping中未包含的新Field，然后判断是否运行自动更新Mapping，如果允许，则更新Mapping。

⑤ Get Sequence Id and Version

由于当前是Primary Shard，则会从SequenceNumber Service获取一个sequenceID和Version。SequenceID在Shard级别每次递增1，SequenceID在写入Doc成功后，会用来初始化LocalCheckpoint。Version则是根据当前Doc的最大Version递增1。

⑥ Add Doc To Lucene

这一步开始的时候会给特定_uid加锁，然后判断该_uid对应的Version是否等于之前Translate Update To Index步骤里获取到的Version，如果不相等，则说明刚才读取Doc后，该Doc发生了变化，出现了版本冲突，这时候会抛出一个VersionConflict的异常，该异常会在Primary Node最开始处捕获，重新从“Translate Update To Index or Delete”开始执行。 如果Version相等，则继续执行，如果已经存在同id的Doc，则会调用Lucene的UpdateDocument(uid, doc)接口，先根据uid删除Doc，然后再Index新Doc。如果是首次写入，则直接调用Lucene的AddDocument接口完成Doc的Index，AddDocument也是通过UpdateDocument实现。

这一步中有个问题是，如何保证Delete-Then-Add的原子性，怎么避免中间状态时被Refresh？ 答案是在开始Delete之前，会加一个Refresh Lock，禁止被Refresh，只有等Add完后释放了Refresh Lock后才能被Refresh，这样就保证了Delete-Then-Add的原子性。

Lucene的UpdateDocument接口中就只是处理多个Field，会遍历每个Field逐个处理，处理顺序是invert index，store field，doc values，point dimension，后续会有文章专门介绍Lucene中的写入。

⑦ Write Translog

写完Lucene的Segment后，会以keyvalue的形式写TransLog，Key是_id，Value是Doc内容。当查询的时候，如果请求是GetDocByID，则可以直接根据_id从TransLog中读取到，满足NoSQL场景下的实时性要去。

需要注意的是，这里只是写入到内存的TransLog，是否Sync到磁盘的逻辑还在后面。 这一步的最后，会标记当前SequenceID已经成功执行，接着会更新当前Shard的LocalCheckPoint。

⑧ Renew Bulk Request

这里会重新构造Bulk Request，原因是前面已经将UpdateRequest翻译成了Index或Delete请求，则后续所有Replica中只需要执行Index或Delete请求就可以了，不需要再执行Update逻辑，一是保证Replica中逻辑更简单，性能更好，二是保证同一个请求在Primary和Replica中的执行结果一样

⑨ Flush Translog

这里会根据TransLog的策略，选择不同的执行方式，要么是立即Flush到磁盘，要么是等到以后再Flush。Flush的频率越高，可靠性越高，对写入性能影响越大。

⑩ Send Requests To Replicas

这里会将刚才构造的新的Bulk Request并行发送给多个Replica，然后等待Replica的返回，这里需要等待所有Replica返回后（可能有成功，也有可能失败），Primary Node才会返回用户。如果某个Replica失败了，则Primary会给Master发送一个Remove Shard请求，要求Master将该Replica Shard从可用节点中移除。 这里，同时会将SequenceID，PrimaryTerm，GlobalCheckPoint等传递给Replica。 发送给Replica的请求中，Action Name等于原始ActionName + [R]，这里的R表示Replica。通过这个[R]的不同，可以找到处理Replica请求的Handler。

11. Receive Response From Replicas

Replica中请求都处理完后，会更新Primary Node的LocalCheckPoint。

Replica Node

① Index or Delete

根据请求类型是Index还是Delete，选择不同的执行逻辑。这里没有Update，是因为在Primary Node中已经将Update转换成了Index或Delete请求了。

② Parse Doc

③ Update Mapping

以上都和Primary Node中逻辑一致。

④ Get Sequence Id and Version

Primary Node中会生成Sequence ID和Version，然后放入ReplicaRequest中，这里只需要从Request中获取到就行

⑤ Add Doc To Lucene

由于已经在Primary Node中将部分Update请求转换成了Index或Delete请求，这里只需要处理Index和Delete两种请求，不再需要处理Update请求了。比Primary Node会更简单一些。

⑥ Write Translog

⑦ Flush Translog

介绍了Elasticsearch的写入流程及其各个流程的工作机制， 我们在这里再次总结下之前提出的分布式系统中的六大特性

可靠性：由于Lucene的设计中不考虑可靠性，在Elasticsearch中通过Replica和TransLog两套机制保证数据的可靠性。

一致性：Lucene中的Flush锁只保证Update接口里面Delete和Add中间不会Flush，但是Add完成后仍然有可能立即发生Flush，导致Segment可读。这样就没法保证Primary和所有其他Replica可以同一时间Flush，就会出现查询不稳定的情况，这里只能实现最终一致性。

原子性：Add和Delete都是直接调用Lucene的接口，是原子的。当部分更新时，使用Version和锁保证更新是原子的。

隔离性：仍然采用Version和局部锁来保证更新的是特定版本的数据。

实时性：使用定期Refresh Segment到内存，并且Reopen Segment方式保证搜索可以在较短时间（比如1秒）内被搜索到。通过将未刷新到磁盘数据记入TransLog，保证对未提交数据可以通过ID实时访问到。

性能：性能是一个系统性工程，所有环节都要考虑对性能的影响，在Elasticsearch中，在很多地方的设计都考虑到了性能

一是不需要所有Replica都返回后才能返回给用户，只需要返回特定数目的就行；

二是生成的Segment现在内存中提供服务，等一段时间后才刷新到磁盘，Segment在内存这段时间的可靠性由TransLog保证；

三是TransLog可以配置为周期性的Flush，但这个会给可靠性带来伤害；

四是每个线程持有一个Segment，多线程时相互不影响，相互独立，性能更好；

五是系统的写入流程对版本依赖较重，读取频率较高，因此采用了versionMap，减少热点数据的多次磁盘IO开销。Lucene中针对性能做了大量的优化

文件查询流程（查）

search流程 （1）客户端首先会选择一个节点node发送请求过去，这个节点node可能是协调节点coordinating node （2）协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ，都可以。 （3）query phase：每个shard将自己的搜索结果的元数据到请求节点（其实就是一些doc id和打分信息等返回给协调节点），由协调节点进行数据的合并、排序、分页等操作，产出最终结果。 （4）fetch phase：接着由协调节点根据doc id去各个节点上拉取实际的document数据，最终返回给客户端。

文档读取过程详解

所有的搜索系统一般都是两阶段查询，第一阶段查询到匹配的DocID，第二阶段再查询DocID对应的完整文档，这种在Elasticsearch中称为query_then_fetch。（这里主要介绍最常用的2阶段查询，其它方式可以参考这里 https://zhuanlan.zhihu.com/p/34674517  ）

① 在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS：在2. 搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。

② 每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

③ 接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

深入ElasticSearch读取文档的实现机制

读操作

一致性指的是写入成功后，下次读操作一定要能读取到最新的数据。对于搜索，这个要求会低一些，可以有一些延迟。但是对于NoSQL数据库，则一般要求最好是强一致性的。 <ul><li>结果匹配上，NoSQL作为数据库，查询过程中只有符合不符合两种情况，而搜索里面还有是否相关，类似于NoSQL的结果只能是0或1，而搜索里面可能会有0.1，0.5，0.9等部分匹配或者更相关的情况。</li><li>结果召回上，搜索一般只需要召回最满足条件的Top N结果即可，而NoSQL一般都需要返回满足条件的所有结果。</li></ul>

搜索系统一般都是两阶段查询，第一个阶段查询到对应的Doc ID，也就是PK；第二阶段再通过Doc ID去查询完整文档，而NoSQL数据库一般是一阶段就返回结果。在Elasticsearch中两种都支持。 目前NoSQL的查询，聚合、分析和统计等功能上都是要比搜索弱的。

Lucene的读

Elasticsearch使用了Lucene作为搜索引擎库，通过Lucene完成特定字段的搜索等功能，在Lucene中这个功能是通过IndexSearcher的下列接口实现的

第一个search接口实现搜索功能，返回最满足Query的N个结果；第二个doc接口通过doc id查询Doc内容；第三个count接口通过Query获取到命中数。 这三个功能是搜索中的最基本的三个功能点，对于大部分Elasticsearch中的查询都是比较复杂的，直接用这个接口是无法满足需求的，比如分布式问题。这些问题都留给了Elasticsearch解决，我们接下来看Elasticsearch中相关读功能的剖析。

Elasticsearch的读

Elasticsearch中每个Shard都会有多个Replica，主要是为了保证数据可靠性，除此之外，还可以增加读能力，因为写的时候虽然要写大部分Replica Shard，但是查询的时候只需要查询Primary和Replica中的任何一个就可以了。

在上图中，该Shard有1个Primary和2个Replica Node，当查询的时候，从三个节点中根据Request中的preference参数选择一个节点查询。preference可以设置 _local，_primary，_replica 以及其他选项。如果选择了primary，则每次查询都是直接查询Primary，可以保证每次查询都是最新的。如果设置了其他参数，那么可能会查询到R1或者R2，这时候就有可能查询不到最新的数据。

Elasticsearch中通过分区实现分布式，数据写入的时候根据_routing规则将数据写入某一个Shard中，这样就能将海量数据分布在多个Shard以及多台机器上，已达到分布式的目标。这样就导致了查询的时候，潜在数据会在当前index的所有的Shard中，所以Elasticsearch查询的时候需要查询所有Shard，同一个Shard的Primary和Replica选择一个即可，查询请求会分发给所有Shard，每个Shard中都是一个独立的查询引擎，比如需要返回Top 10的结果，那么每个Shard都会查询并且返回Top 10的结果，然后在Client Node里面会接收所有Shard的结果，然后通过优先级队列二次排序，选择出Top 10的结果返回给用户。 这里有一个问题就是请求膨胀，用户的一个搜索请求在Elasticsearch内部会变成Shard个请求，这里有个优化点，虽然是Shard个请求，但是这个Shard个数不一定要是当前Index中的Shard个数，只要是当前查询相关的Shard即可，这个需要基于业务和请求内容优化，通过这种方式可以优化请求膨胀数。 Elasticsearch中的查询主要分为两类，Get请求：通过ID查询特定Doc；Search请求：通过Query查询匹配Doc。

上图中内存中的Segment是指刚Refresh Segment，但是还没持久化到磁盘的新Segment，而非从磁盘加载到内存中的Segment 对于Search类请求，查询的时候是一起查询内存和磁盘上的Segment，最后将结果合并后返回。这种查询是近实时（Near Real Time）的，主要是由于内存中的Index数据需要一段时间后才会刷新为Segment。 对于Get类请求，查询的时候是先查询内存中的TransLog，如果找到就立即返回，如果没找到再查询磁盘上的TransLog，如果还没有则再去查询磁盘上的Segment。这种查询是实时（Real Time）的。这种查询顺序可以保证查询到的Doc是最新版本的Doc，这个功能也是为了保证NoSQL场景下的实时性要求。

所有的搜索系统一般都是两阶段查询，第一阶段查询到匹配的DocID，第二阶段再查询DocID对应的完整文档，这种在Elasticsearch中称为query_then_fetch，还有一种是一阶段查询的时候就返回完整Doc，在Elasticsearch中称作query_and_fetch，一般第二种适用于只需要查询一个Shard的请求。 除了一阶段，两阶段外，还有一种三阶段查询的情况。搜索里面有一种算分逻辑是根据TF（Term Frequency）和DF（Document Frequency）计算基础分，但是Elasticsearch中查询的时候，是在每个Shard中独立查询的，每个Shard中的TF和DF也是独立的，虽然在写入的时候通过_routing保证Doc分布均匀，但是没法保证TF和DF均匀，那么就有会导致局部的TF和DF不准的情况出现，这个时候基于TF、DF的算分就不准。为了解决这个问题，Elasticsearch中引入了DFS查询，比如DFS_query_then_fetch，会先收集所有Shard中的TF和DF值，然后将这些值带入请求中，再次执行query_then_fetch，这样算分的时候TF和DF就是准确的，类似的有DFS_query_and_fetch。这种查询的优势是算分更加精准，但是效率会变差。另一种选择是用BM25代替TF/DF模型。

Elasticsearch查询流程

Elasticsearch中的大部分查询，以及核心功能都是Search类型查询，上面我们了解到查询分为一阶段，二阶段和三阶段，这里我们就以最常见的的二阶段查询为例来介绍查询流程。

Client Node

① Get Remove Cluster Shard

判断是否需要跨集群访问，如果需要，则获取到要访问的Shard列表

② Get Search Shard Iterator

获取当前Cluster中要访问的Shard，和上一步中的Remove Cluster Shard合并，构建出最终要访问的完整Shard列表。 这一步中，会根据Request请求中的参数从Primary Node和多个Replica Node中选择出一个要访问的Shard

③ For Every Shard:Perform

遍历每个Shard，对每个Shard执行后面逻辑。

④ Send Request To Query Shard

将查询阶段请求发送给相应的Shard。

⑤ Merge Docs

上一步将请求发送给多个Shard后，这一步就是异步等待返回结果，然后对结果合并。这里的合并策略是维护一个Top N大小的优先级队列，每当收到一个shard的返回，就把结果放入优先级队列做一次排序，直到所有的Shard都返回 翻页逻辑也是在这里，如果需要取Top 30~ Top 40的结果，这个的意思是所有Shard查询结果中的第30到40的结果，那么在每个Shard中无法确定最终的结果，每个Shard需要返回Top 40的结果给Client Node，然后Client Node中在merge docs的时候，计算出Top 40的结果，最后再去除掉Top 30，剩余的10个结果就是需要的Top 30~ Top 40的结果。 上述翻页逻辑有一个明显的缺点就是每次Shard返回的数据中包括了已经翻过的历史结果，如果翻页很深，则在这里需要排序的Docs会很多，比如Shard有1000，取第9990到10000的结果，那么这次查询，Shard总共需要返回1000 * 10000，也就是一千万Doc，这种情况很容易导致OOM。 另一种翻页方式是使用search_after，这种方式会更轻量级，如果每次只需要返回10条结构，则每个Shard只需要返回search_after之后的10个结果即可，返回的总数据量只是和Shard个数以及本次需要的个数有关，和历史已读取的个数无关。这种方式更安全一些，推荐使用这种。 如果有aggregate，也会在这里做聚合，但是不同的aggregate类型的merge策略不一样，具体的可以在后面的aggregate文章中再介绍。

⑥ Send Request To Fetch Shard

选出Top N个Doc ID后发送给这些Doc ID所在的Shard执行Fetch Phase，最后会返回Top N的Doc的内容。

Query Phase

① Create Search Context

创建SearchContext，之后Search过程中的所有中间状态都会存在Context中，这些状态总共有50多个，具体可以查看DefaultSearchContext或者其他SearchContext的子类。

② Parse Query

解析Query的Source，将结果存入Search Context。这里会根据请求中Query类型的不同创建不同的Query对象，比如TermQuery、FuzzyQuery等，最终真正执行TermQuery、FuzzyQuery等语义的地方是在Lucene中 这里包括了dfsPhase、queryPhase和fetchPhase三个阶段的preProcess部分，只有queryPhase的preProcess中有执行逻辑，其他两个都是空逻辑，执行完preProcess后，所有需要的参数都会设置完成。 由于Elasticsearch中有些请求之间是相互关联的，并非独立的，比如scroll请求，所以这里同时会设置Context的生命周期。 同时会设置lowLevelCancellation是否打开，这个参数是集群级别配置，同时也能动态开关，打开后会在后面执行时做更多的检测，检测是否需要停止后续逻辑直接返回

③ Get From Cache

判断请求是否允许被Cache，如果允许，则检查Cache中是否已经有结果，如果有则直接读取Cache，如果没有则继续执行后续步骤，执行完后，再将结果加入Cache。

④ Add Collectors

Collector主要目标是收集查询结果，实现排序，对自定义结果集过滤和收集等。这一步会增加多个Collectors，多个Collector组成一个List。

FilteredCollector：先判断请求中是否有Post Filter，Post Filter用于Search，Agg等结束后再次对结果做Filter，希望Filter不影响Agg结果。如果有Post Filter则创建一个FilteredCollector，加入Collector List中。

PluginInMultiCollector：判断请求中是否制定了自定义的一些Collector，如果有，则创建后加入Collector List。

MinimumScoreCollector：判断请求中是否制定了最小分数阈值，如果指定了，则创建MinimumScoreCollector加入Collector List中，在后续收集结果时，会过滤掉得分小于最小分数的Doc。

EarlyTerminatingCollector：判断请求中是否提前结束Doc的Seek，如果是则创建EarlyTerminatingCollector，加入Collector List中。在后续Seek和收集Doc的过程中，当Seek的Doc数达到Early Terminating后会停止Seek后续倒排链。

CancellableCollector：判断当前操作是否可以被中断结束，比如是否已经超时等，如果是会抛出一个TaskCancelledException异常。该功能一般用来提前结束较长的查询请求，可以用来保护系统。

EarlyTerminatingSortingCollector：如果Index是排序的，那么可以提前结束对倒排链的Seek，相当于在一个排序递减链表上返回最大的N个值，只需要直接返回前N个值就可以了。这个Collector会加到Collector List的头部。EarlyTerminatingSorting和EarlyTerminating的区别是，EarlyTerminatingSorting是一种对结果无损伤的优化，而EarlyTerminating是有损的，人为掐断执行的优化。

TopDocsCollector：这个是最核心的Top N结果选择器，会加入到Collector List的头部。TopScoreDocCollector和TopFieldCollector都是TopDocsCollector的子类，TopScoreDocCollector会按照固定的方式算分，排序会按照分数+doc id的方式排列，如果多个doc的分数一样，先选择doc id小的文档。而TopFieldCollector则是根据用户指定的Field的值排序。

⑤ lucene::search

这一步会调用Lucene中IndexSearch的search接口，执行真正的搜索逻辑。每个Shard中会有多个Segment，每个Segment对应一个LeafReaderContext，这里会遍历每个Segment，到每个Segment中去Search结果，然后计算分数。 搜索里面一般有两阶段算分，第一阶段是在这里算的，会对每个Seek到的Doc都计算分数，为了减少CPU消耗，一般是算一个基本分数。这一阶段完成后，会有个排序。然后在第二阶段，再对Top 的结果做一次二阶段算分，在二阶段算分的时候会考虑更多的因子。二阶段算分在后续操作中。

⑥ rescore

根据Request中是否包含rescore配置决定是否进行二阶段排序，如果有则执行二阶段算分逻辑，会考虑更多的算分因子。二阶段算分也是一种计算机中常见的多层设计，是一种资源消耗和效率的折中。 Elasticsearch中支持配置多个Rescore，这些rescore逻辑会顺序遍历执行。每个rescore内部会先按照请求参数window选择出Top window的doc，然后对这些doc排序，排完后再合并回原有的Top 结果顺序中。

⑦ suggest::execute()

如果有推荐请求，则在这里执行推荐请求。如果请求中只包含了推荐的部分，则很多地方可以优化

⑧ aggregation::execute()

如果含有聚合统计请求，则在这里执行。Elasticsearch中的aggregate的处理逻辑也类似于Search，通过多个Collector来实现。在Client Node中也需要对aggregation做合并。aggregate逻辑更复杂一些，就不在这里赘述了，后面有需要就再单独开文章介绍。

上述逻辑都执行完成后，如果当前查询请求只需要查询一个Shard，那么会直接在当前Node执行Fetch Phase。

Fetch Phase

Elasticsearch作为搜索系统时，或者任何搜索系统中，除了Query阶段外，还会有一个Fetch阶段，这个Fetch阶段在数据库类系统中是没有的，是搜索系统中额外增加的阶段。搜索系统中额外增加Fetch阶段的原因是搜索系统中数据分布导致的，在搜索中，数据通过routing分Shard的时候，只能根据一个主字段值来决定，但是查询的时候可能会根据其他非主字段查询，那么这个时候所有Shard中都可能会存在相同非主字段值的Doc，所以需要查询所有Shard才能不会出现结果遗漏。同时如果查询主字段，那么这个时候就能直接定位到Shard，就只需要查询特定Shard即可，这个时候就类似于数据库系统了。另外，数据库中的二级索引又是另外一种情况，但类似于查主字段的情况，这里就不多说了

Fetch阶段的目的是通过DocID获取到用户需要的完整Doc内容。这些内容包括了DocValues，Store，Source，Script和Highlight等，具体的功能点是在SearchModule中注册的，系统默认注册的有： <ul><li> ExplainFetchSubPhase</li><li> DocValueFieldsFetchSubPhase</li><li> ScriptFieldsFetchSubPhase</li><li> FetchSourceSubPhase</li><li> VersionFetchSubPhase</li><li> MatchedQueriesFetchSubPhase</li><li> HighlightPhase</li><li> ParentFieldSubFetchPhase</li></ul>

除了系统默认的8种外，还有通过插件的形式注册自定义的功能，这些SubPhase中最重要的是Source和Highlight，Source是加载原文，Highlight是计算高亮显示的内容片断。 上述多个SubPhase会针对每个Doc顺序执行，可能会产生多次的随机IO，这里会有一些优化方案，但是都是针对特定场景的，不具有通用性。