关于elastic-stack:Elastic-Stack基础概念

7次阅读

共计 4532 个字符,预计需要花费 12 分钟才能阅读完成。

Cluster(集群)

Elasticsearch 集群由一个或多个节点组成,可通过其集群名称进行标识。在默认的状况下,如咱们的 Elasticsearch 曾经开始运行,那么它会主动生成一个叫做“Elasticsearch”的集群。当然咱们能够在 config/elasticsearch.yml 里定制咱们的集群的名字:

[root@cb71f81b72b7 config]# cat elasticsearch.yml 
cluster.name: "docker-cluster"
network.host: 0.0.0.0
[root@cb71f81b72b7 config]# 

一个 Elasticsearch 的集群就像是上面的一个布局:

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

​ 咱们能够通过:

GET _cluster/state

​ 来获取整个 cluster 的状态。这个状态只能被 master node 所扭转。下面的接口 返回的后果是:

{
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "Lmv7APZ4QemXB88AGZZfcA",
  "version" : 163,
  "state_uuid" : "7nh2_aWaT9aJHiVaOo5UjQ",
  "master_node" : "bhsEXqpaT7K2PEmXSYlbsg",
  "blocks" : { },
  "nodes" : {...},
  "metadata" : {...},
  "routing_table" : {...},
  "routing_nodes" : {...}
}

Node(节点)

节点就是单个 Elasticsearch 实例。在大多数环境中,每个节点都在独自的盒子或虚拟机上运行。一个集群由一个或多 个 node 组成。在测试的环境中,我能够把多个 node 运行在一个 server 上。在理论 的部署中,大多数状况还是须要一个 server 上运行一个 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" : [
        "bhsEXqpaT7K2PEmXSYlbsg",
        "chsEXqpaT7K2PEmXSYlbsg",
        "dhsEXqpaT7K2PEmXSYlbsg"
      ]
    }
  }
}

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

Document(文档)

​ Elasticsearch 是面向文档的,这意味着你索引或搜寻的最小数据单元是文档。

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

  • 独立的:

    文档蕴含字段 (名称) 及其值。

  • 能够是分层的:

    能够将其视为文档中的文档,它还能够蕴含其余字段和值。

  • 构造灵便

    文档不依赖于预约义的架构。

​ Document 相比拟于关系数据库,它相应于其中每个 record。

Type(类型)

​ 类型是文档的逻辑容器,相似于表是行的容器。

​ 你将具备不同构造(模式)的文档放在不同类型中。例如,你能够应用一种类型来 定义聚合组,并在人们汇集时为事件定义另一种类型。

​ 在 Elasticsearch 中,咱们开始能够不定义一个 mapping,而间接写入到咱们指定 的 index 中。这个 index 的 mapping 是动静生成的(当然咱们也能够禁止这种行 为)。其中的数据项的每一个数据类型是动静辨认的。比方工夫,字符串等,尽管有些 数据类型,还是须要咱们手动调整,比方 geo_point 等地理位置数据。

Index(索引)

在 Elasticsearch 中,索引是文档的汇合。

每个 Index 由一个或多个 documents 组成,并且这些 document 能够散布于不 同的 shard 之中。

​ 很多人认为 index 相似于关系数据库中的 database。这中说法是有些情理,然而 并不完全相同。其中很重要的一个起因是,在 Elasticsearch 中的文档能够有 object 及 nested 构造。一个 index 是一个逻辑命名空间,它映射到一个或多个主分片,并且可 以具备零个或多个正本分片。

​ 每当一个文档进来后,依据文档的 id 会主动进行 hash 计算,并寄存于计算出来 的 shard 实例中,这样的后果能够使得所有的 shard 都比拟有平衡的存储,而不至于 有的 shard 很忙。

shard_num = hash(_routing) % num_primary_shards

下面的公式咱们也能够看进去,咱们的 shard 数目是不能够动静批改的,否则之 后也找不到相应的 shard 号码了。必须指出的是,replica 的数目是能够动静批改的。

Shard

​ Elasticsearch 是一个分布式搜索引擎,因而索引通常会拆分为散布在多个节 点上的称为分片的元素。Elasticsearch 主动治理这些分片的排列。它还依据须要从新 均衡分片,因而用户无需放心细节。

​ 因为分片的作用,一个索引能够存储单个节点硬件限度的大量数据。比方一个具备 20 亿,大小为 2TB 的磁盘空间,而任一节点都没有这样大的磁盘空间;或者单个节点解决 搜寻申请,响应太慢。为了解决这个问题,Elasticsearch 提供了将索引划分成多份的能力,这些份就叫做 分片(shard)。当你创立一个索引的时候,你能够指定你想要的分片 (shard) 的数量。每个分片自身也是一个功能完善并且独立的“索引”,这个“索引”能够被搁置到集群 中的任何节点上。

分片作用:

  • 容许你程度宰割 / 扩大你的内容容量。
  • 容许你在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而 进步性能 / 吞吐量。

    分片品种:

  • Primary shard

    每个文档都存储在一个 Primary shard。索引文档时,它首先在 Primary shard 上编制索引,而后在此分片的所有正本上(replica)编制索引。索 引能够蕴含一个或多个主分片。此数字确定索引绝对于索引数据大小的可伸缩性。创立索引后,无奈更改索引中的主分片数。

  • Replica shard

    每个主分片能够具备零个或多个正本。正本是主分片的正本,有两 个目标:

    减少故障转移:如果主分片故障,能够将正本分片晋升为主分片。

    进步性能:get 和 search 申请能够由主 shard 或正本 shard 解决。

默认状况下,每个主分片都有一个正本,但能够在现有索引上动静更改正本数。永远不会在与其主分片雷同的节点上启动正本分片。

​ 如一个索引:index 有 5 个 shard 及 1 个 replica 的状况如下:

​ 这些 Shard 散布于不同的物理机器上:

能够为每个 Index 设置相应的 Shard 数值:

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

下面的 REST 接口中,咱们为 wechat 这个 index 设置了 2 个 shards,并且有一个 replica。一旦设置好 primary shard 的数量,咱们就不能够批改 了。这是因为 Elasticsearch 会根据每个 document 的 id 及 primary shard 的数量来把相应的 document 调配到相应的 shard 中。如果这个数量当前批改的话,那么每 次搜寻的时候,可能会找不到相应的 shard。

咱们能够通过如下的接口来查看咱们的 index 中的设置:

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

Replica(正本)

​ 默认状况下,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 衰弱

  • 红色:集群中未调配至多一个主分片。
  • 黄色:已调配所有主正本,但未调配至多一个正本。
  • 绿色:调配所有分片。
正文完
 0