基本概念-CSDN博客

本文链接：https://blog.csdn.net/Ayhan_huang/article/details/100096046

基本概念

文档（Document）

es是面向文档的，文档是所有可搜索数据的最小单位
文档会被序列化为JSON格式，保存在es中
每个文档都有一个Unique ID
- 可以自己指定
- 也可以由es自动生成

示例

{
  "year": 1995,
  "@version": "1",
  "genre": [
    "Adventure", "Animation",
    "Children", "Comedy", "Fantasy"
  ],
  "id": "1",
  "title": "Toy Story"
}

文档的元数据

{
	"_index": "movies",  // 文档所在的索引名
	"_type": "_doc",  // 文档所属的类型名
	"_id": "1",  // 文档的uid
	"_score": 14.69302,  // 相关性打分
	"_source": {  // 文档的原始json数据
		"year": 1995,
		"@version": "1",  // 文档的版本信息
		"genre": [
			"Adventure", "Animation",
			"Children", "Comedy", "Fantasy"
		],
		"id": "1",
		"title": "Toy Story"
	}
}

其他：_all整合所有字段内容到该字段，已被废除

索引（index）
- 索引是文档的容器，是一类文档的集合（类似于mongo中的集合）
  - Index体现逻辑空间的概念，每个索引都有自己的Mapping定义，用于定义文档的字段及类型（类似于表结构schema）
  - Shard体现物理空间的概念，索引中的数据分散在Shard上
- Mapping和Settings
  - Mapping等一文档字段及类型
  - Settings定义不同的数据分布
- 其他语义：保存一个文档到es中的过程，也叫索引（indexing）
Type
- 7.0开始，一个Index只能创建一个Type，也就是_doc

分布式系统

高可用性
- 服务可用性：允许有节点停止服务
- 数据可用性：部分节点丢失，不会丢失数据
可扩展性
- 请求量提升 / 数据不断增长，将数据分布到所有节点上（存储的水平扩展）
es的分布式架构
- 不同集群通过不同的名字区分，默认是”elasticsearch“
  - 可以通过配置文件，或者启动时指定
```
-E cluster.name=xxx
```
  - 一个集群可以有一个或多个节点
节点
- 节点是一个Elasticsearch的实例
  - 本质是一个JAVA进程
  - 一台机器可以运行多个Elasticsearch进程，但是生产环境一般建议一台机器只运行一个Elasticsearch实例
- 节点的名字可以通过配置文件或启动时指定
```
-E node.name=xxx
```
- 每个节点启动之后，会被分配一个UID，保存在data目录下
Master-eligible Node和Master Node
- 每个节点启动后，默认就是一个master-eligible节点
- master-eligible节点可以参加选主流程，成为master节点
- 当地一个节点启动后，它会将自己选举成为master节点
- 每个节点上都保存了集群的状态，只有master节点上才能修改集群的状态信息（cluster state）：
  - 所有节点信息
  - 所有的索引（集）以及相关的Mapping和Setting信息
  - 分片的路由信息
Data Node 和Coordinating Node
- data节点负责保存分片数据，是实现水平扩容的基本单位
- coordinating节点负责接受客户端的请求，将请求分发到合适的节点，最终把结果汇集到一起
- 每个节点默认都起到coordinating节点的职责
其他节点类型
- Hot & Warm Node （冷热节点）
  - 热节点是配置比较高的节点data node，用于存储较新的数据，冷节点相反，以此降低集群部署的成本
- Machine Learning Node
  - 负责跑机器学习的任务，用来做异常检查
节点启动时，读取elasticsearch.yml配置文件，来决定自己承担的角色
- master eligible 对应的配置项是 node.master，默认值是true
- data对应的是node.data，默认值true
- 一个节点可以承担多种角色
- 在生产环境中，推荐设置单一角色的节点
分片
- 主分片（Primary Shard），用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点上
  - 一个分片是一个运行Lucene的实例
  - 主分片数在索引创建时指定，后续不允许修改，除非Reindex
- 副本（Replica Shard），用以解决数据高可用问题，是主分片的拷贝
  - 副本分片数，可以动态调整
  - 增加副本数，还可以一定程度上提高服务的可用性（吞吐性能）
- 示例1：在一个3节点的集群中，blogs索引（集）的分片分布情况
```
PUT /blogs
{
  "settings": {
    "number_of_shards": 3,  // 主分片数3
    "number_of_replicas": 1  // 副本1份
  }
}
```
  - Node1
    - P1
    - R2
  - Node2
    - P2
    - R3
  - Node3
    - P3
    - R1
- 示例2：在一个2节点的集群中，如果有3个索引（集）的分片情况
```
PUT /index1
{
  "settings": {
    "number_of_shards": 1,  // 主分片数1
    "number_of_replicas": 1  // 副本1份
  }
}
```
  - Node1
    - Index1P1，Index2P1, Index3P1
  - Node2
    - Index1R1, Index2R1, Index3R1
- 示例3: 一个2节点的集群中，blog索引在如下设置下的分片情况
```
PUT /blogs
{
  "settings": {
    "number_of_shards": 3,  // 主分片数3
    "number_of_replicas": 1  // 副本1份
  }
}
```
  - Node1
    - P1
    - R2
    - R3
  - Node2
    - P2
    - P3
    - R1
- 分片的设定：在生产环境中，需要提前做好容量的规划
  - 分片数设置过小
    - 导致后续无法增加节点实现水平扩展
    - 单个分片数据量太大，导致数据重新分配耗时
  - 分片数设置过大
    - 影响搜索结果的相关性打分，影响统计结果的准确性
    - 单个节点傻姑娘过多的分片，会导致资源浪费，同时也会影响性能（7.0开始，默认分片数由5改为1）
查看集群健康状态
```
GET _cluster/health
```
状态说明：
- green：主分片和副本都分配正常
- yellow：主分片分配正常，有副本未能正常分配
- red：有主分片未能正常分配。例如，当服务器磁盘容量操作85%时，去创建一个新的索引（集）
```
GET _cat/nodes  # 查看节点信息
GET _cat/shards  # 查看分片信息
```
通过cerebro查看集群的分片及详细信息