名词解释-Elastic Stack 实战手册-阿里云开发者社区

创作人：刘晓国

当我们开始使用 Elasticsearch 时，我们必须理解其中的一些重要的概念。这些概念的理解对于以后我们使用 Elastic Stack 是非常重要的。在今天的这篇文章里，我们先来介绍一下在 Elastic Stack 中最重要的一些概念。

首先，我们来看下一下如下的这个图：

Cluster

Cluster 也就是集群的意思。

Elasticsearch 集群由一个或多个节点组成，可通过其集群名称进行标识。通常这个 Cluster 的名字是可以在 Elasticsearch 里的配置文件中设置的。在默认的情况下，如我们的 Elasticsearch 已经开始运行，那么它会自动生成一个叫做 “Elasticsearch” 的集群。我们可以在 config/elasticsearch.yml 里定制我们的集群的名字：

一个 Elasticsearch 的集群就像是下面的一个布局：

带有 NginX 代理及 Balancer 的架构图是这样的：

我们可以通过：

GET _cluster/state

来获取整个 cluster 的状态。这个状态只能被 master node 所改变。上面的接口返回的结果是：

{
  "cluster_name": "elasticsearch",
  "compressed_size_in_bytes": 1920,
  "version": 10,
  "state_uuid": "rPiUZXbURICvkPl8GxQXUA",
  "master_node": "O4cNlHDuTyWdDhq7vhJE7g",
  "blocks": {},
  "nodes": {...},
  "metadata": {...},
  "routing_table": {...},
  "routing_nodes": {...},
  "snapshots": {...},
  "restore": {...},
  "snapshot_deletions": {...}
}

Node

单个 Elasticsearch 实例。

在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。一个集群由一个或多个 node 组成。在测试的环境中，我可以把多个 node 运行在一个 server 上。在实际的部署中，大多数情况还是需要一个 server 上运行一个 node。

根据 node 的作用，可以分为如下的几种：

master-eligible：可以作为主 node。一旦成为主 node，它可以管理整个 cluster 的设置及变化：创建，更新，删除 index；添加或删除 node；为 node 分配 shard
data：数据 node
ingest: 数据接入（比如 pipepline)
machine learning (Gold/Platinum License)

一般来说，一个 node 可以具有上面的一种或几种功能。我们可以在命令行或者 Elasticsearch 的配置文件（Elasticsearch.yml）来定义：

Node类型	配置参数	默认值
master-eligible	node.master	true
data	node.data	true
ingest	node.ingest	true
machine learning	node.ml	true (除了OSS发布版）

你也可以让一个 node 做专有的功能及角色。如果上面 node 配置参数没有任何配置，那么我们可以认为这个 node 是作为一个 coordination node。在这种情况下，它可以接受外部的请求，并转发到相应的节点来处理。针对 master node，有时我们需要设置 cluster.remote.connect: false。

在实际的使用中，我们可以把请求发送给 data 节点，而不能发送给 master 节点。

我们可以通过对 config/elasticsearch.yml 文件中配置来定义一个 node 在集群中的角色：

在有些情况中，我们可以通过设置 node.voting_only 为 true 从而使得一个 node 在 node.master 为真的情况下，只作为参加 voting 的功能，而不当选为 master node。这种情况为了避免脑裂情况发生。它通常可以使用一个 CPU 性能较低的 node 来担当。

在一个集群中，我们可以使用如下的一个命令来获取当前可以进行 vote 的所有 master-eligible 节点：

GET /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config

你可能获得类似如下列表的结果：

{
  "metadata" : {
    "cluster_coordination" : {
      "last_committed_config" : [
        "Xe6KFUYCTA6AWRpbw84qaQ",
        "OvD79L1lQme1hi06Ouiu7Q",
        "e6KF9L1lQUYbw84CTAemQl"
      ]
    }
  }
}

在整个 Elastic 的架构中，Data Node 和 Cluster 的关系表述如下：

上面的定义适用于 Elastic Stack 7.9 发布版以前。在 Elastic Stack 7.9 之后，有了新的改进。

请详细阅读文章 “Elasticsearch：Node roles 介绍 - 7.9 之后版本”： https://elasticstack.blog.csdn.net/article/details/110947372

Document

Elasticsearch 是面向文档的，这意味着您索引或搜索的最小数据单元是文档。

文档在 Elasticsearch 中有一些重要的属性：

它是独立的。文档包含字段（名称）及其值。
它可以是分层的。可以将其视为文档中的文档。字段的值可以很简单，就像位置字段的值可以是字符串一样。它还可以包含其他字段和值。例如，位置字段可能包含城市和街道地址。
结构灵活。您的文档不依赖于预定义的架构。例如，并非所有事件都需要描述值，因此可以完全省略该字段。但它可能需要新的字段，例如位置的纬度和经度。

文档通常是数据的 JSON 表示形式。JSON over HTTP 是与 Elasticsearch 进行通信的最广泛使用的方式，它是我们在本书中使用的方法。

例如，您的聚会网站中的事件可以在以下文档中表示：

        {
          "name": "Elasticsearch Denver",
          "organizer": "Lee",
          "location": "Denver, Colorado, USA"
        }

很多人认为 Document 相比较于关系数据库，它相应于其中每个 record。

Type

类型是文档的逻辑容器，类似于表是行的容器。

您将具有不同结构（模式）的文档放在不同类型中。例如，你可以使用一种类型来定义聚合组，并在人们聚集时为事件定义另一种类型。

每种类型的字段定义称为映射。例如，name 将映射为字符串，但 location 下的 geolocation 字段将映射为特殊的 geo_point 类型。（我们探讨如何使用附录A中的地理空间数据。）每种字段的处理方式都不同。例如，你在名称字段中搜索单词，然后按位置搜索组以查找位于您居住地附近的组。

很多人认为 Elasticsearch 是 schema-less 的。大家都甚至认为 Elasticsearch 中的数据库是不需要 mapping 的。其实这是一个错误的概念。schema-less 在 Elasticsearch 中正确的理解是，我们不需要事先定义一个类型关系数据库中的 table 才使用数据库。

在 Elasticsearch 中，我们开始可以不定义一个 mapping，而直接写入到我们指定的 index 中。这个 index 的 mapping 是动态生成的（当然我们也可以禁止这种行为）。其中的数据项的每一个数据类型是动态识别的。比如时间，字符串等，虽然有些数据类型，还是需要我们手动调整，比如 geo_point 等地理位置数据。

另外，它还有一个含义，同一个 type，我们在以后的数据输入中，可能增加新的数据项，从而生产新的 mapping。这个也是动态调整的。

Elasticsearch 具有 schema-less 的能力，这意味着无需显式指定如何处理文档中可能出现的每个不同字段，即可对文档建立索引。启用动态映射后，Elasticsearch 自动检测并向索引添加新字段。这种默认行为使索引和浏览数据变得容易-只需开始建立索引文档，Elasticsearch 就会检测布尔值，浮点数和整数值，日期和字符串，并将其映射到适当的 Elasticsearch 数据类型。

由于一些原因，在 Elasticsearch 6.0 以后，一个 Index 只能含有一个 type。这其中的原因是：相同 index 的不同映射 type 中具有相同名称的字段是相同；在 Elasticsearch 索引中，不同映射 type 中具有相同名称的字段在 Lucene 中被同一个字段支持。在默认的情况下是 _doc。在未来8.0的版本中，type 将被彻底删除。

Index

在 Elasticsearch 中，索引是文档的集合。

每个 Index 一个或许多的 documents 组成，并且这些 document 可以分布于不同的 shard 之中。

很多人认为 index 类似于关系数据库中的 database。这中说法是有些道理，但是并不完全相同。其中很重要的一个原因是，在Elasticsearch 中的文档可以有 object 及 nested 结构。一个 index 是一个逻辑命名空间，它映射到一个或多个主分片，并且可以具有零个或多个副本分片。

每当一个文档进来后，根据文档的 id 会自动进行 hash 计算，并存放于计算出来的 shard 实例中，这样的结果可以使得所有的 shard 都比较有均衡的存储，而不至于有的 shard 很忙。

shard_num = hash(_routing) % num_primary_shards

在默认的情况下，上面的 _routing 既是文档的 _id。如果有 routing 的参与，那么这些文档可能只存放于一个特定的 shard，这样的好处是对于一些情况，我们可以很快地综合我们所需要的结果而不需要跨 node 去得到请求。比如针对 join 的数据类型。

从上面的公式我们也可以看出来，我们的 shard 数目是不可以动态修改的，否则之后也找不到相应的 shard 号码了。必须指出的是，replica 的数目是可以动态修改的。

Shard

由于 Elasticsearch 是一个分布式搜索引擎，因此索引通常会拆分为分布在多个节点上的称为分片的元素。 Elasticsearch 自动管理这些分片的排列。它还根据需要重新平衡分片，因此用户无需担心细节。

一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有 10 亿文档的索引占据1TB 的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，这些份就叫做分片（shard）。当你创建一个索引的时候，你可以指定你想要的分片 (shard) 的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片之所以重要，主要有两方面的原因：

允许你水平分割/扩展你的内容容量
允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量

有两种类型的分片：Primary shard 和 Replica shard。

Primary shard: 每个文档都存储在一个Primary shard。索引文档时，它首先在 Primary shard上编制索引，然后在此分片的所有副本上（replica）编制索引。索引可以包含一个或多个主分片。此数字确定索引相对于索引数据大小的可伸缩性。创建索引后，无法更改索引中的主分片数。
Replica shard: 每个主分片可以具有零个或多个副本。副本是主分片的副本，有两个目的：
1. 增加故障转移：如果主要故障，可以将副本分片提升为主分片
2. 提高性能：get 和 search 请求可以由主 shard 或副本 shard 处理。

默认情况下，每个主分片都有一个副本，但可以在现有索引上动态更改副本数。永远不会在与其主分片相同的节点上启动副本分片。

下面的图表示的是一个 index 有5个 shard 及1个 replica

这些 Shard 分布于不同的物理机器上：

我们可以为每个 Index 设置相应的 Shard 数值：

curl -XPUT http://localhost:9200/another_user?pretty -H 'Content-Type: application/json' -d '
{
    "settings" : {
        "index.number_of_shards" : 2,
        "index.number_of_replicas" : 1
    }
}

比如在上面的 REST 接口中，我们为 another_user 这个 index 设置了2个 shards，并且有一个 replica。一旦设置好 primary shard 的数量，我们就不可以修改了。这是因为 Elasticsearch 会依据每个 document 的 id 及 primary shard 的数量来把相应的 document 分配到相应的 shard 中。如果这个数量以后修改的话，那么每次搜索的时候，可能会找不到相应的 shard。

我们可以通过如下的接口来查看我们的 index 中的设置：

curl -XGET http://localhost:9200/twitter/_settings?pretty

上面我们可以得到 twitter index 的设置信息：

{
  "twitter" : {
    "settings" : {
      "index" : {
        "creation_date" : "1565618906830",
        "number_of_shards" : "1",
        "number_of_replicas" : "1",
        "uuid" : "rwgT8ppWR3aiXKsMHaSx-w",
        "version" : {
          "created" : "7030099"
        },
        "provided_name" : "twitter"
      }
    }
  }
}

Replica

默认情况下，Elasticsearch 为每个索引创建一个主分片和一个副本。这意味着每个索引将包含一个主分片，每个分片将具有一个副本。

分配多个分片和副本是分布式搜索功能设计的本质，提供高可用性和快速访问索引中的文档。主副本和副本分片之间的主要区别在于，只有主分片可以接受索引请求。副本和主分片都可以提供查询请求。

在上图中，我们有一个 Elasticsearch 集群，由默认分片配置中的两个节点组成。 Elasticsearch 自动排列分割在两个节点上的一个主分片。有一个副本分片对应于每个主分片，但这些副本分片的排列与主分片的排列完全不同。

请允许我们澄清一下：请记住，number_of_shards 值与索引有关，而不是与整个群集有关。此值指定每个索引的分片数（不是群集中的主分片总数）。

我们可以通过如下的接口来获得一个 index 的健康情况：

http://localhost:9200/_cat/indices/twitter

上面的接口可以返回如下的信息：

更进一步的查询，我们可以看出：

如果一个 index 显示的是红色，表面这个 index 至少有一个 primary shard 没有被正确分配，并且有的 shard 及其相应的 replica 已经不能正常访问。如果是绿色，表明 index 的每一个 shard 都有备份（replica），并且其备份也成功复制在相应的 replica shard 之中。如果其中的一个 node 坏了，相应的另外一个 node 的 replica 将起作用，从而不会造成数据的丢失。

shard 健康

红色：集群中未分配至少一个主分片
黄色：已分配所有主副本，但未分配至少一个副本
绿色：分配所有分片

创作人简介：
刘晓国，现为 Elastic 社区资深布道师。新加坡国立大学硕士，西北工业大学本硕。
曾就职于新加坡科技，康柏电脑，通用汽车，爱立信，诺基亚，Linaro 非营利组织（
Linux for ARM），Ubuntu，LinkMotion，Vantiq 等企业。从事过通信，电脑设计，计
算机操作系统，物联网，汽车电子，云实时事件处理，大数据搜索等行业。从爱立信开
始，到后来的诺基亚，Ubuntu 从事社区工作有超过 15 年以上经历。喜欢分享自己所学
到的知识，希望和大家一起分享及学习。
博客： https://elasticstack.blog.csdn.net/

名词解释-Elastic Stack 实战手册

Cluster

Node

Document

Type

Index

Shard

Replica

检索分析服务 Elasticsearch版

热门文章

最新文章

相关电子书

相关实验场景