基本概念
-
文档(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)
- 索引是文档的容器,是一类文档的集合(类似于mongo中的集合)
-
Type
- 7.0开始,一个Index只能创建一个Type,也就是
_doc
- 7.0开始,一个Index只能创建一个Type,也就是
分布式系统
-
高可用性
- 服务可用性:允许有节点停止服务
- 数据可用性:部分节点丢失,不会丢失数据
-
可扩展性
- 请求量提升 / 数据不断增长,将数据分布到所有节点上(存储的水平扩展)
-
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
- 负责跑机器学习的任务,用来做异常检查
- Hot & Warm 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
- Node1
-
示例2:在一个2节点的集群中,如果有3个索引(集)的分片情况
PUT /index1 { "settings": { "number_of_shards": 1, // 主分片数1 "number_of_replicas": 1 // 副本1份 } }
- Node1
- Index1P1,Index2P1, Index3P1
- Node2
- Index1R1, Index2R1, Index3R1
- Node1
-
示例3: 一个2节点的集群中,blog索引在如下设置下的分片情况
PUT /blogs { "settings": { "number_of_shards": 3, // 主分片数3 "number_of_replicas": 1 // 副本1份 } }
- Node1
- P1
- R2
- R3
- Node2
- P2
- P3
- R1
- Node1
-
分片的设定:在生产环境中,需要提前做好容量的规划
- 分片数设置过小
- 导致后续无法增加节点实现水平扩展
- 单个分片数据量太大,导致数据重新分配耗时
- 分片数设置过大
- 影响搜索结果的相关性打分,影响统计结果的准确性
- 单个节点傻姑娘过多的分片,会导致资源浪费,同时也会影响性能(7.0开始,默认分片数由5改为1)
- 分片数设置过小
-
-
查看集群健康状态
GET _cluster/health
状态说明:
- green:主分片和副本都分配正常
- yellow:主分片分配正常,有副本未能正常分配
- red:有主分片未能正常分配。例如,当服务器磁盘容量操作85%时,去创建一个新的索引(集)
GET _cat/nodes # 查看节点信息 GET _cat/shards # 查看分片信息
-
通过cerebro查看集群的分片及详细信息