Elasticsearch 进阶

Elasticsearch 进阶

1  核心概念

1.1   索引(Index)

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

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

1.2   类型(Type)

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

1.3   文档(Document)

一个文档是一个可被索引的基础信息单元，也就是一条数据。文档以 JSON 格式来表示，而 JSON 是一个到处存在的互联网数据交互格式。在一个 index/type 里面，可以存储任意多的文档。

1.4   字段(Field)

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

1.5   映射(Mapping)

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

1.6   分片(Shards)

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

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

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

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

1.7   副本(Replicas)

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

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

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

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

1.8   分配(Allocation)

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

2  系统架构

Elasticsearch 是面向文档型的数据库，一条书记在这里就是一个文档。为了更好的理解，我将 Elasticsearch 里存储文档数据和关系型数据库 MySQL 存储数据的概念进行一个类比

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

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

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

3  分布式集群

3.1  单节点集群

我们在包含一个空节点的集群内创建名为 users 的索引，为了演示目的，我们将分配 3个主分片和 1 个副本（每个主分片拥有一个副本分片）

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

通过 elasticsearch-head 插件查看集群情况

3.2  故障转移

当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。

如果启动了第二个和第三个节点，我们的集群将会拥有两个节点的集群 : 所有主分片和副本分片都已被分配。

通过 elasticsearch-head 插件查看集群情况

3.3  水平扩容

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

通过 elasticsearch-head 插件查看集群情况

但是如果想要扩容超过 6 个节点怎么办呢？

主分片的数目在索引创建是就已经确定了下来。实际上，这个数目定义了这个索引能够存储的最大数据量。（实际大小取决于你的数据、硬件和使用场景）但是，读操作、搜索和返回数据可以同时被主分片或副分片锁处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。

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

{
	"number_of_replicas": 2
}

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

通过 elasticsearch-head 插件查看集群情况

当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获取的资源会变少。你需要增加更多的硬件资源来提升吞吐量。

但是更多的副本分片数提高了数据的冗余量：按照上面的节点配置，我们可以在失去 2 个节点的情况下不丢失任何数据。

3.4  应对故障

我们关闭第一个节点，这时集群的状态为：关闭了一个节点后的集群。

我们关闭的节点是一个主节点，而集群必须要有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点：node2，在我们关闭 node1 的同时也失去了主分片 1 和主分片 2 ，并且在确缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状态，我们看到的状态会为 red ：不是所有主分片都在正常工作。

幸运的是，在其他节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在 node2 和 node3 上对应的副本分片提升为主分片，此时集群的状态将会为 yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。

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

虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此时只存在一份副本分片。所以集群不能是 green 状态，不过我们不必过于担心：如果我们同样关闭了 node2 ，我们的程序依然可以保持在不丢任何数据的情况下运行，因为 node3 为每一个分片都保留了一份副本。

如果我们重启 node1 ，集群可以将缺失的副本再次进行分配，那么集群状态也恢复成之前的状态。如果 node1 依然拥有这之前的分片，它将尝试去重用他们，同时仅从主分片复制发生修改的数据文件，和之前的集群相比，只是 master 节点切换了。

4  路由计算

当索引一个文档的时候，文档将会存储到一个主分片中。Elasticsearch 如何知道一个文档应该存放在哪个分片中呢？当我们创建文档时，他如何决定这个文档应该存储在分片 1 还是分片 2 呢？首先这个肯定不是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这和过程是根据一下这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设定为一个自定义值。routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_parimary_shards (主分片数量) 后得到的余数。这个分布在 0 到 number_of_parimary_shards - 1 之间的余数，就是我们所寻求的文档所在的分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量，并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也就找不到了。

所有的文档 API (get、index、delete、update) 都接受一个叫做 routing 的路由参数，通过这个参数我们可以自定义文档到分片的银映射。一个自定义的路由参数可以用来确保所有相关的文档，例如：所有属于同一个用户的文档都被存储到同一个分片中。

5  分片控制

我们假设有一个集群有三个节点组成。包含一个名叫 emps 的索引，有两个主分片，每个主分片有两个副本分片。相同分片的副本不会放在同一节点上。

通过 elasticsearch-head 插件查看emps

我们可以发送请求到集群中的任何一个节点。每个节点都有能力处理任意请求。每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。下面的例子中，将所有请求发送到 node-3，我们将其称之为 协调节点

当发送请求的时候，为了扩展负载，更好的做法就是轮询集群中所有节点。

5.1  写流程

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

新建索引和删除文档所需要的步骤顺序：

1、客户端向 node-1 发送新建、索引或者删除请求。

2、节点使用文档的 _id 确定文档数据分片0，请求会被转发到 node-2 ，因为分片0 的主分片被分配在 node-2 上。

3、node-2 在主分片上执行请求。如果成功了，它将请求并行转发到 node-1 和 nod-3 的副本分片上。一旦所有的副本都报告成功，node-2 将向协调节点报告成功，协调节点向客户端报告成功。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片上执行完成，变更是安全的。有一些可选的请求参数允许你影响这个过程，可能以数据安全为代价提升性能。这些选项很少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面表格：

参数	含义
consistency	consistency，即一致性。在默认设置下，即使仅仅是在试图执行一个 写 操作之 前，主分片都会要求必须要有规定数量(quorum)（或者换种说法，也即必须要有大多数）的分片副本处于活跃可用状态，才会去执行 写 操作(其中分片副本可以是主分片或者副本分片)。这是为了避免在发生网络分区故障（network partition）的时候进行 写 操作，进而导致数据不一致。规定数量 即：int( (primary + number_of_replicas) / 2 ) + 1 consistency 参数的值可以设为 one （只要主分片状态 ok 就允许执行`写`操作）, all（必须要主分片和所有副本分片的状态没问题才允许执行 写 操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行写操作。 注意，规定数量的计算公式中 number_of_replicas 指的是在索引设置中的设定副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片，那规定数量的计算结果即：int( (primary + 3 replicas) / 2 ) + 1 = 3 如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数量，也因此您将无法索引和删除任何文档。
timeout	如果没有足够的副本分片会发生什么？ Elasticsearch 会等待，希望更多的分片出 现。默认情况下，它最多等待 1 分钟。 如果你需要，你可以使用 timeout 参数使它更早终止： 100 就是100 毫秒，30s 是 30 秒。

新索引默认有 1 个副本分片，这意味着为满足规定数量应该需要两个活动的分片副本。 但是，这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有当 number_of_replicas 大于 1 的时候，规定数量才会执行。

5.2  读流程

我们可以从主分片或者从其它任意副本分片检索文档

从主分片或者副本分片检索文档的步骤顺序：

1、客户端向 node-1 发送获取请求。

2、节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个节点上。 在这种情况下，它将请求转发到 node-3 。

3、node-3 将文档返回给 node-1，然后将文档返回给客户端。

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

5.3  更新流程

部分更新一个文档结合了先前说明的读取和写入流程：

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

1、客户端向 node-1 发送更新请求。

2、它将请求转发到主分片所在的 node-2 。

3、node-2 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃。

4、如果 node-2 成功地更新文档，它将新版本的文档并行转发到 node-1 和 node-3 上的副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功。

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

5.4  多文档操作流程

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

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

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

1、客户端向 node-1 发送 mget 请求。

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

可以对 docs 数组中每个文档设置 routing 参数。

bulk API， 允许在单个批量请求中执行多个创建、索引、删除和更新请求。

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

1、客户端向 node-2 发送 bulk 请求。

2、node-2 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节
点主机。

3、主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。

6  分片原理

分片是 Elasticsearch 最小的工作单元。但是究竟什么是一个分片，它是如何工作的？

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

6.1 倒排索引

Elasticsearch 使用一种称为 倒排索引 的结构，它适用于快速的全文搜索。

见其名，知其意，有倒排索引，肯定会有对应的正向索引。正向索引(forward index)，反向索引(inverted index) 更熟悉的名字是倒排索引。

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

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

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

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

为创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称之为 词条或tocken），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：

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

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

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

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

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

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

• Quick 可以小化为 quick
• foxes 可以词干提取，变为词根的形式为 fox
• jumped 和 leap 是同义词，可以索引为相同的单词 jump

6.2 文档搜索

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

倒排索引被写入后是不可改变的：它永远不会修改，不变性有重要的价值

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

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