ElasticSearch 中需要掌握的七个概念_elasticsearch node role节点定义-优快云博客

今天来和大家分享下这个 ElasticSearch 中必须要掌握的几个概念。👇

整体关系

老规矩~ 先从整体上认识认识他们~ 😄

每个 Index 由一个或者多个 shard 组成，分布在不同的 node ，document 由 Field 组成，存储在这些 shard 中。

先有个大致的印象，下面我们再细讲这些概念~ 😋

ES vs 关系型数据库

和传统的关系型数据库有这么一种关系 👇

索引 Index

没想到，这么一个词，居然有这三层含义 🐷🐖 (*￣(oo)￣)

① 名词

Index (Indices，Indexes) 是文档的集合，类似传统的关系型数据库。

是分片的集合，每个分片相当于 Lucene 中的索引。

② 动词

索引一个文档，就是存储一个文档到一个索引中以便被检索

③ 数据结构

这里指：倒排索引 ，就是通过 value ——> Key ，如下👇 通过记录这个词和它所在的文档ID，对应 Lucene 中的 segments (分段)

类型 Type

这里指的是文档的类型，而不是字段的类型

先看看以前版本的样子 👇

以前的API 是 {index}/{type}/{id} ，现在是 {index}/_doc/{id} 🐖

这个 type 从 7.x 开始就被移除了！默认是这个 _doc （默认类型~，现在8.x 版本就也不再支持修改这个类型了），因为这个设计会降低 Lucene 压缩数据的能力，导致数据稀疏。从本质上来看，这个 Type是对索引进行逻辑分区，使用文档类型 _type 和文档 _id 组成 _uid ，形成文档的唯一ID，对索引进行细分~。

而在 Lucene 中，我们这个字段域在索引中是唯一的，所以原本的字段也会被细分，导致字段域增多的同时，数据的密度也就降低了，压缩效率也就降低了。

Tip: ElasticSearch 底层的全文检索是居于 Lucene 实现的。

移除 Type 的具体原因可以看官网的解释 👇

Removal of mapping types | Elasticsearch Guide [7.15] | Elastic

文档 Document

ElasticSearch 是面向文档的，文档是数据存储和索引的最小单位，是字段的集合（相当于 Lucene 中的文档），在 ElasticSearch 中以序列化 JSON 结构存储，文档结构如下👇，下划线开头的是官方提供的字段，称为元数据

{
    "_index" : "java4ye",
    "_type" : "_doc",
    "_id" : "1001",
    "_score" : 1.0,
    "_source" : {
     "user" : {
      "id" : "123456789",
      "name" : "4ye",
      "age" : 2,
      "desc" : "nice to meet you 2!"
     }
    }
   }

这个文档主要看 _source 字段，里面就是我们上传的文档数据

字段 Field

是文档中的基本单位，以键值对的形式存在，如上面的 "_id" : "1001" ，（相当于 Lucene 中的字段）

可以在官网中查看，有这么一些元字段🐖

映射 Mapping

用于表示这个字段的数据类型，如字符串，整数，浮点数，日期等，不指定时会自动创建（相当于 Lucene 中的字段类型）

如下👇

节点 node

ElasticSearch 是以集群的方式运行的，每个 ElasticSearch 实例就是一个节点。

而节点有很多种角色 👇，好复杂🙃

当你没有配置这个 node.roles ，这个节点默认有下面这些角色

主节点 MasterNode

负责集群节点状态的维护，索引的创建，删除，数据的 rebalance，分片的分配等工作，不负责具体数据的索引和检索

数据节点 DataNode

负责集群中数据的写入和检索，属于 IO，内存和 CPU 密集型操作，需要的计算资源大

提取节点 IngestNode

数据预处理通道，在数据被索引前预先处理文档。

协调节点 CoordinatingNode

接受客户端请求，然后转发到数据节点，最后将各个节点返回来的数据进行整合。对应着两个阶段

分散阶段，协调节点将请求转发到保存数据的数据节点
收集阶段，协调节点将每个数据节点的结果缩减为单个全局结果集

链接

详情请从这里获取~

官网地址：Node | Elasticsearch Guide [7.15] | Elastic

或者看看 Elastic 中国社区官方博客的这篇文章 👇

Elasticsearch：Node roles 介绍 - 7.9 之后版本_Elastic-优快云博客_node.role

分片 Shard 和副本 Replica

Elasticsearch 的索引是以分片的方式来组织的，每个分片就是 Lucene 中的索引。

分片分为 主分片 和 副本分片，默认配置是每个索引 5 个主分片，每个主分片都有一个副本分片，主分片和它的副本不在一个节点上，主要作用是 故障转移和负载均衡

文档怎么路由到对应的分片上呢？

公式如下 👇

shard = hash(routing) % number_of_primary_shards

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

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

—— 引用《Elasticsearch: 权威指南》

近实时 NRT

这个近实时 NRT（Near Realtime）是 Elasticsearch 的一大特点，为啥它是近实时的呢~🐖

原因还是和 Lucene 有关，简单来说，就是 ElasticSearch 在写入文档时，数据会先写入这个内存，然后再写到这个 Lucene 的 Segment 中，等到写到 Segment 中才可以被搜索到，此时文档处在文件系统缓存中，后面才会刷到磁盘中的。

这些都在官网的 《Elasticsearch: 权威指南》 中介绍到~ 图文并茂！地址👇

Elasticsearch: 权威指南 | Elastic