ElasticSearch 中一定要掌握的七个概念

今天来和大家分享下这个 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

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

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

链接

详情请从这里获取~

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

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

Elasticsearch：Node roles 介绍 - 7.9 之后版本_Elastic-CSDN博客_node.roles

分片 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

最后

本文就分享到这里啦🐖