39-43-Elasticsearch-部分相关概念-02

39-Elasticsearch-部分相关概念-02：

路由计算

当索引一个文档的时候，文档会被存储到一个主分片中。通过路由

后得到余数 。这个分布在 0 到 主分片数量-1 之间的余数，就是我们所寻求

的文档所在分片的位置。

这就是在创建索引的时候就确定好主分片的数量 并且永远不会改变

这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一

个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定

义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被

存储到同一个分片中。

分片控制 （轮询，协调）

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

通过 elasticsearch-head 插件查看集群情况，所以我们的集群是一个有三个节点和一个索

引的集群。 我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知

道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将

所有的请求发送到 Node 1，我们将其称为 协调节点(coordinating node) 。当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。

写流程

新建、索引和删除 请求都是 写 操作，

必须在主分片上面完成之后才能被复制到相关

的副本分片

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

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

2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的

主分片目前被分配在 Node 3 上。

3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2

的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调

节点向客户端报告成功。

在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。

有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很

少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面参数：

参数 consistency和timeout

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 的时候，规定数量才会执行。

读流程

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

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

1. 客户端向 Node 1 发送获取请求。

2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个

节点上。 在这种情况下，它将请求转发到 Node 2 。

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

更新流程（了解）

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

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 最小的工作单元。

传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需

要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值

需求的数据结构是倒排索引

倒排索引

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 域拆分成单独的 词（我们称它为 词条

或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文

档。结果如下所示：

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

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量

的简单相似性算法，那么我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文

档更佳。

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

Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。

fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。

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，这样两个文档都会匹配！分词和标准化的过程称为分析