今天来和大家分享下这个 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-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: 权威指南 》 中介绍到~ 图文并茂!地址👇
最后
本文就分享到这里啦🐖