Elasticsearch 进阶

 一、核心概念

1.1 索引（Index）

一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母)，并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。

能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录就是索引的意思，目录可以提高查询速度。

Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。

1.2 类型（Type）

在一个索引中，你可以定义一种或多种类型。

一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。不同的版本，类型发生了不同的变化。

版本	Type
5.x	支持多种 type
6.x	只能有一种 type
7.x	默认不再支持自定义索引类型（默认类型为： _doc）

1.3 文档（Document）

一个文档是一个可被索引的基础信息单元，也就是一条数据。 

比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然也可以拥有某个订单的一个文档。文档以JSON格式来表示，而JSON是一个到处存在的互联网数据交互格式。

在一个 Index/Type 里面，你可以存储任意多的文档。

1.4 字段（Field）

相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。 

1.5 映射（Mapping）

mapping 是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，并且需要思考如何建立映射才能对性能更好。

1.6 分片（Shards）

一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有10亿文档数据的索引占据 1TB的磁盘空间，而任一节点都可能没有这样大的磁盘空间。 或者单个节点处理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片很重要，主要有两方面的原因：

1. 允许你水平分割/扩展你的内容容量。
2. 允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。

至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。 

被混淆的概念是，一个Lucene索引，我们在Elasticsearch称作分片。一个Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候，它发送查询到每一个属于索引的分片（Lucene 索引），然后合并每个分片的结果到一个全局的结果集。

1.7 副本（Replicas）

在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的， Elasticsearch允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。

复制分片之所以重要，有两个主要原因：

• 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
• 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。

总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下，Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片（1 个完全拷贝），这样的话每个索引总共就有 2 个分片， 我们需要根据索引需要确定分片个数。

1.8 分配（Allocation）

将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程，这个过程是由 master 节点完成的。 

二、系统架构

一个运行中的Elasticsearch实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name配置的节点组成，它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道
任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回给客户端。 Elasticsearch 对这一切的管理都是透明的。

三、分布式集群

3.1 单节点集群

我们在一个单节点的集群内创建名一个为users的索引，为了演示目的，我们将分配3个主分片和3个副本（每个主分片拥有一个副本分片)。在Postman中，向ES服务器发PUT请求：

http://192.168.1.108:9200/users

请求体中的内容如下：

{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 1
    }
}

number_of_shards：是指索引要做多少个分片，只能在创建索引时指定，后期无法修改。
number_of_replicas：是指每个分片有多少个副本，后期可以动态修改。 

我们的集群现在是拥有一个索引的单节点集群，所有3个主分片都被分配在一个节点上。

此处由于我之前是采用Docker部署的单节点Elasticsearch服务，没有给该节点设置名称，因此需要在elasticsearch.yml文件中添加下述配置：

node.name: node-1

通过elasticsearch-head查看集群情况：

• 集群健康值:yellow( 3 of 6 )：黄色表示当前集群的全部主分片都正常运行，但是副本分片没有全部处在正常状态。

：三个主分片正常，带星表示Master

 ：3个副本分片都是 Unassigned，它们都没有被分配到任何节点。 在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点 上的所有副本数据。

当前集群是正常运行的，但存在丢失数据的风险。

3.2 故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题（没有冗余）。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。

但是在不同机器(198.168.1.108和192.168.1.109)上启动节点的时候，为了加入到同一集群，需要在elasticsearch.yml配置文件新增一个可连接到的单播主机列表，如下所示：

# es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["192.168.1.108:9300","192.168.1.109:9300","192.168.1.110:9300"]

配置为使用单播发现的原因是：以防止其它节点无意中加入集群。

当前集群环境有192.168.1.108(node-1)和192.168.1.109(node-2)两个节点，并且192.168.1.109为主节点(Master)。

在Postman中，向ES服务器发PUT请求：

http://192.168.1.108:9200/users

请求体中的内容如下： 

{
    "settings": {
        "number_of_shards": 3,
        "number_of_replicas": 1
    }
}

通过elasticsearch-head查看集群情况：

可以看到集群中拥有两个节点时所有主分片和副本分片都已被成功分配 ！！！

• 集群健康值:green(6 of 6)：绿色表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行。

 ：node-2节点是Master节点，含有一个主分片和两个副本分片；node-1节点含有两个主分片和1个副本分片。

第二个节点加入到集群后，3个副本分片也会被分配到不同的节点上（每个主分片对应一个副本分片）。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。所有新增被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获取文档数据。

3.3 水平扩容 

怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会拥有三个节点的集群，为了分散负载Elasticsearch集群而对分片进行重新分配 。 

在上述集群服务的基础之上，启动了第三个节点，即现在有三台机器(198.168.1.108、192.168.1.109和192.168.1.110)。

通过elasticsearch-head查看集群情况： 

• node-1：两个主分片
• node-2：一个副本分片和一个主分片
• node-3：两个副本分片 

node-1和node-2上各有一个分片被迁移到了新的node-3节点，现在每个节点上都拥有2个分片， 而不是之前的3个。这表示每个节点的硬件资源(CPU、RAM、I/O)将被更少的分片所共享，每个分片的性能将会得到提升。

分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有6个分 片(3个主分片和3个副本分片)的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

但是如果我们想要扩容超过6个节点（超过6台服务器提供服务）怎么办呢？

主分片的数目在索引创建时就已经确定了下来，实际上这个数目定义了这个索引能够存储的最大数据量（实际大小取决于你的数据、硬件和使用场景）。例如当主分片数目定义为2时，那么所对应的索引能够存储的最大数据量就是集群环境中两台存储容量最小的容量之和。读操作（搜索和返回数据）可以同时被主分片或副本分片所处理，所以当我们拥有越多的副本分片时，将拥有越高的吞吐量。 

在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群，因此我们可以把副本数从默认的1增加到 2。

在Postman中，向ES服务器发PUT请求：

http://192.168.1.108:9200/users/_settings

请求体中的内容如下： 

{
    "number_of_replicas" : 2
}

通过elasticsearch-head查看集群情况：  

现在users索引拥有9个分片：3个主分片和6个副本分片，这意味着我们可以将集群最高扩容到9个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍。 

• 当然如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少，你需要增加更多的硬件资源来提升吞吐量。
• 更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去 2 个节点的情况下不丢失任何数据。

3.4 应对故障

当前Elasticsearch集群中有3个节点，users索引拥有9个分片：3个主分片和6个副本分片，如下图所示：

如果这个时候主节点node-2突然宕机了，我们再通过elasticsearch-head查看集群情况：  

前面宕机的节点node-2是一个主节点，而集群必须拥有一个主节点来保证正常工作，所以发生
的第一件事情就是选举一个新的主节点： node-3。

为什么我们集群状态是yellow而不是green呢？

虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此
时只存在一份副本分片，所以集群不能为green的状态。

如果想恢复为原来的样子，我们只需要重新启动node-2节点中的Elasticsearch服务就可以。集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。如果node-2节点依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是Master节点切换了。

3.5 路由计算和分片控制

路由计算： 

当索引中插入一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch如何知道一个文档应该存放到哪个分片(P0、P1和P2)中呢？

首先这肯定不会是随机的，如果都存放到了一个分片中，会显得这一个分片的数据量相对而已特别大，不是很适合，另外将来要获取文档的时候我们就不知道该从哪个主分片及其对应的副本分片查找。实际上，这个过程是根据下面这个公式决定的：

hash(id)%主分片数量=【0、1、2】 

分片控制：

我们可以发送请求到集群中的任一节点。每个节点都有能力处理任意请求。当某一个节点的负载比较多、压力比较大的时候，可以将请求转发到另外一个节点中。一般情况下，分片控制就是轮询，有三个节点时，第一次处理请求是第一个节点，第二次处理请求是第二个节点，第三次处理请求是第三个节点。用户可以访问任何一个节点获取数据，这个节点称之为协调节点。

3.6 数据写流程

新建、索引和删除请求都是写操作，必须在主分片上面完成之后才能被复制到相关的副本分片。

1. 客户端请求集群节点（任意）- 协调节点
2. 协调节点将请求转发到指定的节点
3. 主分片需要将数据保存
4. 主分片需要将数据发送给副本
5. 副本保存后，进行反馈
6. 主分片进行反馈
7. 客户端获取反馈

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。 

这部分内容的前部分是懂了，后面这些不是很清楚，仅作模糊了解！！！ 

consistency：即一致性，在默认设置下在试图执行一个读操作之前，必须要有规定数量的分片副本为更新成功状态，才会去执行读操作(其中分片副本可以是主分片或者副本分片)。这是为了避免在发生网络分区故障的时候进行写操作，进而导致数据读写不一致。

consistency参数的值可以设为：

• one ：只要主分片文档数据状态为更新成功就允许进行读操作，其它副本分片慢慢进行数据同步就可以。
• all：必须要主分片和所有副本分片的文档数据状态全部为更新成功才允许进行读操作。
• quorum：默认值为quorum，即大多数的分片副本文档数据状态为更新成功就允许进行读操作。 

规定数量(quorum)的计算公式为，其中number_of_replicas指的是设定副本分片数： 

规定数量即： int((primary + number_of_replicas) / 2 ) + 1

如果你的索引设置中指定了当前索引拥有3个副本分片，那规定数量的计算结果即：int((1 primary + 3 replicas) / 2) + 1 = 3，如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数量，也因此您将无法索引和删除任何文档。

timeout： 如果没有足够的副本分片会发生什么？Elasticsearch会等待，希望更多的分片出现。默认情况下，它最多等待1分钟。 如果你需要，你可以使用timeout参数使它更早终止，例如30s是30秒。

3.7 数据读流程

1. 客户端发送查询请求到协调节点
2. 协调节点计算数据所在的分片以及全部的副本位置
3. 为了能够负载均衡，可以轮询所有节点
4. 将请求转发给具体的节点
5. 节点返回查询结果，将结果反馈给客户端

在处理读取请求时，协调节点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

3.8 更新流程

部分更新一个文档的步骤如下：

1. 客户端向Node 1 发送更新请求。
2. 它将请求转发到主分片所在的Node 3 。
3. Node 3从主分片检索文档，修改_source字段中的JSON，并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改，它会重试步骤3，超过retry_on_conflict次后放弃。
4. 如果Node 3成功地更新文档，它将新版本的文档并行转发到Node 1和 Node 2上的副本分片，重新建立索引。一旦所有副本分片都返回成功，Node 3向协调节点也返回成功，协调节点向客户端返回成功。

当主分片把更改转发到副本分片时，它不会转发更新请求。相反，它转发的是完整文档的新版本。请记住这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。如果 Elasticsearch仅转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。 

3.9 多文档操作流程

mget和bulk API的模式类似于单文档模式，区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成每个分片的多文档请求，并且将这些请求并行转发到每个参与节点。

协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端。

用单个mget请求取回多个文档所需的步骤顺序： 

1. 客户端向Node 1节点发送mget请求
2. Node 1节点为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复，Node 1 构建响应并将其返回给客户端。

bulk API 按如下步骤顺序执行：

1. 客户端向Node 1 发送 bulk请求
2. Node 1为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。

四、分片原理

4.1 倒排索引

分片是Elasticsearch最小的工作单元。传统的数据库每个索引字段只能存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要一个索引字段有索引多值的能力，支持一个索引字段索引多值的数据结构是“倒排索引”。

倒排索引原理：

Elasticsearch使用一种称为“倒排索引”的结构，它适用于快速的全文搜索。见其名，知其意，有倒排索引，肯定会对应有正向索引。

所谓的正向索引，就是搜索引擎会将待搜索的文档都对应一个文件ID，搜索时将这个文件ID和搜索关键字进行对应，形成K-V对，然后对关键字进行统计计数，如下图所示：

但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回排名结果的要求。所以搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，这些文件中都出现这个关键词，如下图所示：

倒排索引的例子： 

一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文档列表。例如我们有两个文档，每个文档中的内容如下：

The quick brown fox jumped over the lazy dog
Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的内容拆分成单独的词（我们称它为词条)，创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档，其结果如下所示（其中X表示存在）：

现在如果我们想搜索 quick brown，我们只需要查找包含每个词条的文档：

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单相似性算法，那么对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

1. Quick和quick以独立的词条出现，然而用户可能认为它们是相同的词。
2. fox和foxes非常相似，就像dog和dogs，它们有相同的词根。
3. jumped（跳）和leap（跳跃）尽管没有相同的词根，但它们的意思很相近，它们是同义词。

使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档，使用＋前缀表明这个词必须存在。只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含quick fox，第二个文档包含 Quick foxes。

我们的用户可以合理的期望两个文档与查询匹配，我们可以做的更好。 

如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档，例如： 

• Quick可以小写化为quick。
• foxes可以词干提取变为词根的格式为fox，类似的，dogs可以为提取为dog。
• jumped和leap是同义词，可以索引为相同的单词jump。

现在索引看上去像这样： 

这还远远不够，我们搜索 +Quick +fox 仍然会失败，因为在我们的索引中，已经没有 Quick了。但是，如果我们对搜索的字符串使用与content域相同的标准化规则，会变成查询 +quick +fox，这样两个文档都会匹配！

分词和标准化的过程称为分析，这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。

4.2 不可改变的倒排索引

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。 

倒排索引被写入磁盘后是不可改变的：它永远不会修改。

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘IO和需要被缓存到内存的索引的使用量。

当然一个不变的索引也有不好的地方，主要原因是它是不可变的，你不能修改它。如果你需要让一个新的文档可被搜索，你需要重建整个索引。这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。 

4.3 动态更新索引

如何在保留不变性的前提下实现倒排索引的更新？

答案：用更多的索引。通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到，从最早的开始查询完后再对结果进行合并。

Elasticsearch基于Lucene这个Java库引入了按段搜索的概念，每一段本身都是一个倒排索引。但索引在 Lucene 中除表示所有段的集合外，还增加了提交点的概念（一个列出了所有已知段的文件）。

段是不可改变的，所以既不能把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。取而代之的是，每个提交点会包含一个 .del文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

这些在 .del文件中被标记的文档只有在索引被合并的时候才会真正的删除！！！

4.4 近实时搜索

随着按段（per-segment）搜索的发展，一个新的文档从生成索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索，但这样还是不够快。磁盘在这里成为了瓶颈。提交一个新的段到磁盘需要一个fsync(同步内存中所有已修改的文件数据到储存设备)来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。但是fsync操作代价很大；如果每次索引一个文档都去执行一次的话会造成很大的性能问题。

优化前的新增文档数据的模型流程：

1. 和关系型数据库不同的是，关系型数据库先写入日志再写入内存，而我们的Elasticsearch是先写入内存再写入日志。这个可能的原因是Elasticsearch中数据的内存写入有很复杂的逻辑，很容易失败（比如说有分词、过滤和转换等等这些复杂逻辑，有可能会出现问题）。为了避免Translog中有大量的无效记录，所以先写内存再写日志。 
2. 当我们的数据写入内存后，数据并不能被搜索，必须把数据刷写到磁盘中才能被搜索到。这个的话，我们就会发现性能稍微有点低。

优化后的新增文档数据的模型流程：

我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着fsync要从整个过程中被移除。在Elasticsearch和磁盘之间是文件系统缓存。像之前描述的一样，在内存中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存（这一步代价会比较低），稍后再被刷新到磁盘（这一步代价比较高）。不过只要文件已经在缓存中，就可以像其它文件一样被打开和读取了。

由于自动刷新(reflush)流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。

1. 段数目太多会带来较大的麻烦，每一个段都会消耗文件句柄、内存和 cpu运行周期
2. 每个搜索请求都必须轮流检查每个段，所以段越多，搜索也就越慢

为了解决上述这个问题：Elasticsearch在后台会进行段合并操作，小的段被拷贝合并到大的段，然后这些大的段再被拷贝合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除，被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

在某些时刻，当某种条件满足时，多个索引段会被拷贝合并到一个更大的索引段，而那些旧的索引段会被抛弃并从磁盘中删除，这操作叫做段合并。 

1. 新的段被刷新(flush)到了磁盘，写入一个包含新段且排除旧的和较小的段的新提交点。
2. 新的段被打开用来搜索，老的段被删除。

启动段合并不需要你做任何事，进行索引（即新增文档操作）和搜索时会自动进行。

五、文档分析

文档分析包含下面的过程：

• 将一块文本分成适合于倒排索引的独立的词条
• 将这些词条统一化为标准格式以提高它们的“可搜索性”

我们可以调用分析器完成上面的工作，分析器实际上是将三个功能封装到了一个包里：

• 字符过滤器：首先，字符串按顺序通过每个字符过滤器 。它们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成 and。
• 分词器：其次，字符串被分词器分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。
• Token 过滤器：最后，词条按顺序通过每个token过滤器 。这个过程可能会改变词条（例如，小写化Quick）、删除词条（例如， 像 a， and， the 等无用词）、或者增加词条（例如，像jump和leap这种同义词）

5.1 内置分析器 

Elasticsearch附带了可以直接使用的预包装的分析器，接下来我们会列出最重要的分析器。为了证明它们的差异，我们看看每个分析器会从下面的字符串得到哪些词条：

"Set the shape to semi-transparent by calling set_trans(5)"

标准分析器：是Elasticsearch 默认使用的分析器，它是分析各种语言文本最常用的选择。它根据Unicode联盟定义的单词边界划分文本，然后删除绝大部分标点，最后将词条小写。它会产生下述词条：

set, the, shape, to, semi, transparent, by, calling, set_trans, 5

简单分析器：在任何不是字母的地方分隔文本，将词条小写。它会产生下述词条：

set, the, shape, to, semi, transparent, by, calling, set, trans

空格分析器：在空格的地方划分文本。它会产生下述词条：

Set, the, shape, to, semi-transparent, by, calling, set_trans(5)

语言分析器：特定语言分析器可用于很多语言，它们可以考虑指定语言的特点。例如英语分析器附带了一组英语无用词（常用单词，例如and或者the，它们对相关性没有多少影响），它们会被删除。由于理解英语语法的规则，这个分词器可以提取英语单词的词干。英语分词器会产生下述词条（注意看transparent、calling和set_trans已经变为词根格式）：

set, shape, semi, transpar, call, set_tran, 5

5.2 分析器使用场景

当我们索引一个文档，它的全文域被分析成词条以用来创建倒排索引。当我们在全文域搜索的时候，我们也需要将查询字符串通过相同的分析过程，以保证我们搜索的词条格式与索引中的词条格式一致。

全文查询，理解每个域是如何定义的，因此它们可以做正确的事：

• 当你查询一个全文域时，会对查询字符串应用相同的分析器，以产生正确的搜索词条列表。

• 当你查询一个精确值域时，不会分析查询字符串，而是搜索你指定的精确值。

5.3 测试分析器

有些时候很难理解分词的过程和实际被存储到索引中的词条，特别是你刚接触Elasticsearch。为了理解发生了什么，你可以使用 analyze API 来看文本是如何被分析的。

在Postman中，向ES服务器发送GET请求：

​http://192.168.1.108:9200/_analyze

请求体里面的内容为（在请求体里指定分析器和要分析的文本）：

{
    "analyzer": "standard",
    "text": "Text to analyze"
}

其接口返回内容如下，结果中每个元素（token）代表一个单独的词条：

{
    "tokens": [
        {
            "token": "text",
            "start_offset": 0,
            "end_offset": 4,
            "type": "<ALPHANUM>",
            "position": 0
        },
        {
            "token": "to",
            "start_offset": 5,
            "end_offset": 7,
            "type": "<ALPHANUM>",
            "position": 1
        },
        {
            "token": "analyze",
            "start_offset": 8,
            "end_offset": 15,
            "type": "<ALPHANUM>",
            "position": 2
        }
    ]
}

• token是实际存储到索引中的词条
• start_ offset 和end_ offset指明字符在原始字符串中的位置
• position指明词条在原始文本中出现的区域位置。

5.4 指定分析器

当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文字符串域，使用标准分析器对它进行分析。你不希望总是这样，可能你想使用一个不同的分析器，适用于你的数据使用的语言(例如我们可以指定IK分词器，已有相关的案例)。有时候你想要一个字符串域就是一个字符串域，不使用分析，直接索引你传入的精确值，例如用户ID或者一个内部的状态域或标签。要做到这一点，我们必须手动指定这些域的映射（也就是之前遇到过的Mapping）。

5.5 自定义分析器

虽然Elasticsearch带有一些现成的分析器，然而在分析器上Elasticsearch真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单元过滤器来创建自定义的分析器。在分析与分析器我们说过，一个分析器就是在一个包里面组合了三种函数的一个包装器，三种函数按照顺序被执行：

字符过滤器

字符过滤器用来整理一个尚未被分词的字符串。例如如果我们的文本是HTML格式的，它会包含像<p>或者<div>这样的HTML标签，这些标签是我们不想索引的。我们可以使用html清除字符过滤器来移除掉所有的HTML标签，并且像把&Aacute;转换为相对应的Unicode字符Á这样，转换HTML实体。一个分析器可能有0个或者多个字符过滤器。

分词器

• 一个分析器必须有一个唯一的分词器，分词器把字符串分解成单个词条或者词汇单元。标准分析器里使用的标准分词器把一个字符串根据单词边界分解成单个词条，并且移除掉大部分的标点符号，然而还有其他不同行为的分词器存在。
• 例如，关键词分词器完整地输出接收到的同样的字符串，并不做任何分词。空格分词器只根据空格分割文本。正则分词器根据匹配正则表达式来分割文本。 

词单元过滤器

经过分词，作为结果的词单元流会按照指定的顺序通过指定的词单元过滤器。词单元过滤器可以修改、添加或者移除词单元。我们已经提到过lowercase和stop词过滤器，但是在Elasticsearch里面还有很多可供选择的词单元过滤器。词干过滤器把单词遏制为词干。ascii_folding过滤器移除变音符，把一个像 “très” 这样的词转换为 “tres”。

接下来，我们看看如何创建自定义的分析器（这个仅仅演示了解一下即可）：

第一步：在Postman中，向ES服务器发送 PUT 请求：

http://192.168.1.108:9200/my_index

请求体里面的内容如下所示（在请求体里指定自定义分析器）：

{
	"settings": {
		"analysis": {
			"char_filter": {
				"&_to_and": {
					"type": "mapping",
					"mappings": [
						"&=> and "
					]
				}
			},
			"filter": {
				"my_stopwords": {
					"type": "stop",
					"stopwords": [
						"the",
						"a"
					]
				}
			},
			"analyzer": {
				"my_analyzer": {
					"type": "custom",
					"char_filter": [
						"html_strip",
						"&_to_and"
					],
					"tokenizer": "standard",
					"filter": [
						"lowercase",
						"my_stopwords"
					]
				}
			}
		}
	}
}

第二步：索引被创建以后，使用 analyze API 来 测试这个新的分析器

# GET http://192.168.1.108:9200/my_index/_analyze
{
    "text":"The quick & brown fox",
    "analyzer": "my_analyzer"
}

返回结果为（此处自定义的分析器做了词单元过滤、词单元转换和停用词过滤操作）：

{
    "tokens": [
        {
            "token": "quick",
            "start_offset": 4,
            "end_offset": 9,
            "type": "<ALPHANUM>",
            "position": 1
        },
        {
            "token": "and",
            "start_offset": 10,
            "end_offset": 11,
            "type": "<ALPHANUM>",
            "position": 2
        },
        {
            "token": "brown",
            "start_offset": 12,
            "end_offset": 17,
            "type": "<ALPHANUM>",
            "position": 3
        },
        {
            "token": "fox",
            "start_offset": 18,
            "end_offset": 21,
            "type": "<ALPHANUM>",
            "position": 4
        }
    ]
}

六、文档处理 

6.1 文档冲突

当我们使用index API更新文档，可以一次性读取原始文档，做我们的修改，然后重新索引整个文档。最近的索引请求将获胜：无论最后哪一个文档被索引，都将被唯一存储在Elasticsearch中。如果其它人同时更改这个文档，它们的更改将丢失。

很多时候这是没有问题的，我们的主数据存储是一个关系型数据库，我们只是将数据复制到Elasticsearch中并使其可被搜索。也许两个人同时更改相同的文档的几率很小。或者对于我们的业务来说偶尔丢失更改并不是很严重的问题。

但有时丢失了一个变更就是非常严重的：试想我们使用Elasticsearch存储我们网上商城商品库存的数量，每次我们卖一个商品的时候，我们在Elasticsearch 中将库存数量减少。有一天，管理层决定做一次促销，突然地，我们一秒要卖好几个商品。假设有两个web程序并行运行，每一个都同时处理所有商品的销售。

这个时候web_1 对stock_count所做的更改已经丢失，因为web_2不知道它的stock_count的拷贝已经过期。结果我们会认为有超过商品的实际数量的库存，因为卖给顾客的库存商品并不存在，我们将让他们非常失望。 

变更越频繁，读数据和更新数据的间隙越长，也就越可能丢失变更。在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：

• 悲观并发控制：这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。
• 乐观并发控制：Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。

6.2 乐观并发控制

Elasticsearch是分布式的，当文档创建、更新或删除时，新版本的文档必须复制到集群中的其它节点。Elasticsearch也是异步和并发的，这意味着这些复制请求被并行发送，并且到达目的地时也许顺序是乱的，因此Elasticsearch需要一种方法确保文档的旧版本不会覆盖新的版本。

我们之前讨论Index、GET和DELETE请求时，我们指出每个文档都有一个_version（版本号）。当文档被修改时版本号递增，Elasticsearch使用这个version号来确保变更以正确顺序得到执行，如果旧版本的文档在新版本之后到达，它可以被简单的忽略。

我们可以利用version号来确保应用中相互冲突的变更不会导致数据丢失，我们通过指定想要修改文档的version号来达到这个目的。如果该版本不是当前版本号，我们的请求将会失败。

在Postman中，向ES服务器发送 POST 请求，创建一个索引并插入一个文档数据：

http://192.168.1.108:9200/shopping/_create/1001

请求体中的内容如下：

{
    "doc":{
        "title":"华为手机"
    }
}

返回内容： 

{
    "_index": "shopping",
    "_id": "1001",
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 0,
    "_primary_term": 1
}

接着我们更新上述插入的文档数据：

#POST http://192.168.1.108:9200/shopping/_update/1001
{
    "doc":{
        "title":"小米手机"
    }
}

返回结果为：

{
    "_index": "shopping",
    "_id": "1001",
    "_version": 2,
    "result": "updated",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 1,
    "_primary_term": 1
}

我们使用旧版本使用的防止冲突更新方法：

#POST http://192.168.1.108:9200/shopping/_update/1001?version=2
{
    "doc":{
        "title":"苹果手机"
    }
}

返回结果为：

{
    "error": {
        "root_cause": [
            {
                "type": "action_request_validation_exception",
                "reason": "Validation Failed: 1: internal versioning can not be used for optimistic concurrency control. Please use `if_seq_no` and `if_primary_term` instead;"
            }
        ],
        "type": "action_request_validation_exception",
        "reason": "Validation Failed: 1: internal versioning can not be used for optimistic concurrency control. Please use `if_seq_no` and `if_primary_term` instead;"
    },
    "status": 400
}

老的版本es使用version，但是新版本不支持了，会报下面的错误，提示我们用if_seq _no和if _primary_term。 

新版本使用的防止冲突更新方法：

#POST http://192.168.1.108:9200/shopping/_update/1001?if_seq_no=1&if_primary_term=1
{
    "doc":{
        "title":"苹果手机"
    }
}

返回结果为：

{
    "_index": "shopping",
    "_id": "1001",
    "_version": 3,
    "result": "updated",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 2,
    "_primary_term": 1
}

6.3 外部系统版本控制

一个常见的设置是使用其它数据库作为主要的数据存储，使用Elasticsearch做数据检索，这意味着主数据库的所有更改发生时都需要被复制到Elasticsearch，如果多个进程负责这一数据同步，你可能遇到类似于之前描述的并发问题。

如果你的主数据库已经有了版本号，或一个能作为版本号的字段值比如timestamp，那么你就可以在Elasticsearch请求地址中通过增加 version=外部版本号&version_type=extermal 这些请求参数的方式重用这些相同的版本号，版本号必须是大于零的整数。

外部版本号的处理方式和我们之前讨论的内部版本号的处理方式有些不同，Elasticsearch不是检查当前_version和请求中指定的版本号是否相同，而是检查当前_version是否小于指定的版本号。如果请求成功，外部的版本号作为文档的新_version进行存储。

在Postman中，向ES服务器发送 POST 请求：

http://192.168.1.108:9200/shopping/_doc/1001?version=300&version_type=external

请求体中的内容如下：

{
	"title":"三星手机"
}

返回结果为：