4.1 核心概念
4.1.1 索引（Index）
一个索引就是一个拥有几分相似特征的文档的集合。在一个集群中，可以定义任意多的索引。
4.1.2 类型（Type）
在一个索引中，你可以定义一种或多种类型。（类似于MySQL中的表）
在 ES 7.x 中，默认不再支持自定义索引类型（默认类型为：_doc）
4.1.3 文档（Document）
ElasticSearch中 一条数据就是一个文档
4.1.3 字段（Field）
相当于是数据表的字段，是文档的属性。
4.1.5 映射（Mapping）
对 ES 中的每个字段做一些限制，这个就称之映射
如：某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的
4.1.6 分片（Shards）
一个索引可以存储超出单个节点硬件限制的大量数据。
比如，一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处
理搜索请求，响应太慢。
为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
分片很重要，主要有两方面的原因：
- 允许你水平分割 / 扩展你的内容容量。
- 允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。
4.1.7 副本（Replicas）
在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。
复制分片之所以重要，有两个主要原因：
- 在分片/节点失败的情况下，提供了高可用性。因为这个原因，复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
- 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行
总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和副本（主分片的拷贝）。分片和副本的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变副本的数量，但是你事后不能改变分片的数量。
4.1.8 分配（Allocation）
将分片分配给某个节点的过程，包括分配主分片或者副本。
4.2 系统架构
一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更（例如增加、删除索引，或者增加、删除节点等。） 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。
任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。
4.3 分布式集群
4.3.1 单节点集群
我们在包含一个空节点的集群内创建名为 users 的索引，为了演示目的，我们将分配 3个主分片和一份副本（每个主分片拥有一个副本分片）
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
我们的集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。
4.3.2 故障转移
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。
幸运的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。
但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
如果启动了第二个节点，我们的集群将会拥有两个节点的集群 : 所有主分片和副本分片都已被分配
4.3.3 水平扩容
怎样为我们的正在增长中的应用程序按需扩容呢？
当启动了第三个节点，我们的集群将会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配
但是如果我们想要扩容超过 6 个节点怎么办呢？
主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够存储 的最大数据量。
但是，读操作——搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量
在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2
users 索引现在拥有 9 个分片：3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能可以提升 3 倍
4.3.4 应对故障
我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。
我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作
幸运的是，在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为yellow。
4.4 路由计算
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？
这个过程是根据下面这个公式决定的：
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档都被存储到同一个分片中
4.5 分片控制
我们假设有一个集群由三个节点组成。 它包含一个叫 emps 的索引，有两个主分片，每个主分片有两个副本分片。相同分片的副本不会放在同一节点。
我们可以发送请求到集群中的任一节点， 每个节点都有能力处理任意请求， 每个节点都知道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将所有的请求发送到 Node 1，我们将其称为 协调节点(coordinating node) 。
4.5.1 写流程
新建、索引和删除 请求都是 写 操作， 必须在主分片上面完成之后才能被复制到相关的副本分片
新建，索引和删除文档所需要的步骤顺序：
- 客户端向 Node 1 发送新建、索引或者删除请求。
- 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的
主分片目前被分配在 Node 3 上。 - Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2
的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调
节点向客户端报告成功。
在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。
有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很
少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面表格：
4.5.2 读流程
我们可以从主分片或者从其它任意副本分片检索文档
从主分片或者副本分片检索文档的步骤顺序：
- 客户端向 Node 1 发送获取请求。
- 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个
节点上。 在这种情况下，它将请求转发到 Node 2 。 - Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。
在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均
衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分
片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一
旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的
4.5.3 更新流程
部分更新一个文档的步骤如下：
- 客户端向 Node 1 发送更新请求。
- 它将请求转发到主分片所在的 Node 3 。
- Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片
的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次
后放弃。 - 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的
副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回
成功，协调节点向客户端返回成功。
当主分片把更改转发到副本分片时， 它不会转发更新请求。 相反，它转发完整文档的新版本。请记住，
这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。 如果 Elasticsearch 仅
转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档
4.5.4 多文档操作流程
mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于
哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求，并且将这些请求并行转
发到每个参与节点。
协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返
回给客户端
用单个 mget 请求取回多个文档所需的步骤顺序:
- 客户端向 Node 1 发送 mget 请求。
- Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的
主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客
户端
bulk API 按如下步骤顺序执行：
- 客户端向 Node 1 发送 bulk 请求。
- Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节
点主机。 - 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或
删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，
该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。
4.6 分片原理
4.6.1 倒排索引
4.6.2 文档搜索
倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
4.6.3 动态更新索引
4.7 文档分析
分析 包含下面的过程：
- 将一块文本分成适合于倒排索引的独立的 词条
- 将这些词条统一化为标准格式以提高它们的“可搜索性”。
分析器实际上是将三个功能封装到了一个包里：
-
字符过滤器
首先，字符串按顺序通过每个 字符过滤器 。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉 HTML，或者将 & 转化成 and。 -
分词器
其次，字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条。 -
Token 过滤器
最后，词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条（例如，小写化Quick ），删除词条（例如， 像 a， and， the 等无用词），或者增加词条（例如，像 jump 和 leap 这种同义词）。
4.7.1 内置分析器
4.7.2 分析器使用场景
当我们 索引 一个文档，它的全文域被分析成词条以用来创建倒排索引。 但是，当我
们在全文域 搜索 的时候，我们需要将查询字符串通过 相同的分析过程 ，以保证我们搜索
的词条格式与索引中的词条格式一致。
全文查询，理解每个域是如何定义的，因此它们可以做正确的事：
- 当你查询一个 全文 域时， 会对查询字符串应用相同的分析器，以产生正确的搜索词条列表。
- 当你查询一个 精确值 域时，不会分析查询字符串，而是搜索你指定的精确值。
4.7.3 查看分析器的分词结果
有些时候很难理解分词的过程和实际被存储到索引中的词条，特别是你刚接触
Elasticsearch。为了理解发生了什么，你可以使用 analyze API 来看文本是如何被分析的。
在消息体里，指定分析器和要分析的文本
GET http://localhost:9200/_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
结果中每个元素代表一个单独的词条：
{
"tokens": [
{
"token": "text",
"start_offset": 0,
"end_offset": 4,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "to",
"start_offset": 5,
"end_offset": 7,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "analyze",
"start_offset": 8,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 3
}
]
}
token 是实际存储到索引中的词条。 position 指明词条在原始文本中出现的位置。
start_offset 和 end_offset 指明字符在原始字符串中的位置
4.7.4 指定分析器
当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文 字
符串 域，使用 标准 分析器对它进行分析。你不希望总是这样。可能你想使用一个不同的
分析器，适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域—不使
用分析，直接索引你传入的精确值，例如用户 ID 或者一个内部的状态域或标签。要做到这
一点，我们必须手动指定这些域的映射。
492
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
