抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

ElasticSearch 概述

img

概述

Elasticsearch 是什么

Elasticsearch(简称ES)是一个基于Apache Lucene(TM)的开源搜索引擎

​ Elasticsearch 是一个高伸缩的开源全文搜索和分析引擎,是一个基于JSON的分布式搜索和分析引擎,基于restful web接口,Elasticsearch是用Java语言开发的,基于Apache协议的开源项目,是目前最受欢迎的企业搜索引擎。

​ 它可以快速地、近实时的存储,搜索和分析大规模的数据。一般被用作底层引擎/技术,为具有复杂搜索功能和要求的应用提供强有力的支撑。

ElasticSearch特点

Elasticsearch是实时的分布式搜索分析引擎,内部使用Lucene做索引与搜索,有以下特点

  • 近实时性:新增到 ES 中的数据在1秒后就可以被检索到,这种新增数据对搜索的可见性称为“近实时搜索”

  • 全文检索:将全文检索、数据分析以及分布式技术,合并在了一起,才形成了独一无二的ES

  • 分布式:意味着可以动态调整集群规模,弹性扩容

  • 集群规模:可以扩展到上百台服务器,处理PB级结构化或非结构化数据

  • 开箱即用:对用户而言,是开箱即用的,非常简单,作为中小型的应用,直接3分钟部署一下ES

  • 不支持事务:数据库的功能面对很多领域是不够用的,事务,还有各种联机事务型的操作

使用场景

ElasticSearch广泛应用于各行业领域, 比如维基百科, GitHub的代码搜索,电商网站的大数据日志统计分析, BI系统报表统计分析等。

记录和日志分析

ELK结合使用可以实现日志数据的收集整理

img

​ 围绕Elasticsearch建立的生态系统使其成为实施和扩展日志记录解决方案最简单的系统之一,利用这一点将日志添加到他们的主要用例中,或者纯粹将我们用于日志记录。

​ 从Beats到Logstash,再到Ingest Nodes,Elasticsearch为您提供了很多选择,可以随时随地获取数据并将其编入索引,从那里,像Kibana这样的工具使您能够创建丰富的仪表板和分析。

搜集和合并公共数据

像日志数据一样,Elastic Stack有很多工具可以使远程数据的获取和索引编制变得容易。

​ 而且,像大多数文档存储一样,缺乏严格的架构也使Elasticsearch可以灵活地接收多种不同的数据源,并且仍然可以使所有数据源易于管理和搜索。

全文搜索

全文搜索作为Elasticsearch的核心功能,得到了广泛的应用,远远超出了传统的企业搜索或电子商务

​ 从欺诈检测/安全性到协作及其他方面,Elasticsearch的搜索功能强大,灵活,并且包含许多工具,可以使搜索变得更加容易,Elasticsearch拥有自己的查询DSL以及内置的功能,可自动完成

事件数据和指标

Elasticsearch在如指标和应用程序事件之类的时间序列数据上也能很好地运行

​ 这是巨大的Beats生态系统允许您轻松获取常见应用程序数据的另一个区域,无论您使用哪种技术,Elasticsearch都有很大的机会拥有可以立即获取指标和事件的组件。

可视化数据

Kibana拥有大量图表选项,用于地理数据的图块服务以及用于时间序列数据的TimeLion,是功能强大且易于使用的可视化工具。

img

​ 对于上述每个用例,Kibana都会处理一些可视组件,熟悉了各种数据提取工具后,您会发现Elasticsearch + Kibana将成为您可视化试图包裹数据的必备工具。

能做什么

要使用ElasticSearch我们需要知道ElasticSearch能够做什么

提供快速查询

试想一下,当你打开一个博客网站,搜索一篇博客的时候,等待了一分钟才有搜索结果,那将会是一个极差的体验。

​ 可想而知,这个博客网站肯定没有使用搜索引擎处理搜索的请求,而是使用了传统的关系型数据库查询,在庞大的数据面前,关系型数据库的查询就显得力不从心,相当耗时。Elasticsearch在这个时候可以帮上忙,使用博客数据建立索引库,依赖倒排索引的优势,为用户快速的呈现搜索的相关结果。

确保结果的相关性

接下来有一个难题: 如何将真正描述选举的帖子排序在前呢?有了 Elasticsearch,就可以使 用几个算法来计算相关性的得分( relevancy score ),然后根据分数来将结果逐个排序 。

​ 默认情况下,计算文档相关性得分的算法是TF-IDF(term frequency-inverse document frequency),词频逆文档频率。我们将在后面讨论这个概念。除了选择算法,Elasticsearch还提供了很多其他内置的功能来计算概相关性得分,以满足定制需求。

处理错误的拼写

当我们在使用搜索时,会出现英文拼写错误,中文错别字等情况时有发生。

​ 我们可以通过配置让Elasticsearch容忍一些错误,而不仅仅只是查找精确匹配,如我们输入“book”的时候由于手误输入了“bok”,如果搜索引擎能够意识到这一错误并且在搜索时帮我们修正这个错误,那么搜索会更快让人满意。

给予自动提示

当用户开始输入时,你可以帮助他们发现主流的查询和结果。

​ 还可以通过自动提示技术预测 他们所要输入的内容,就像 Web 上很多搜索引擎做的那样,你同样可以展示主流的结果,通过 特殊的查询类型来匹配前缀、通配符或正则表达式。

使用统计信息

当用户不太清楚具体要搜索什么的时候,可以通过几种方式来协助他们 。

​ 一种方法是聚集统计数据, 聚集是在搜索结果里得到一些统计数据,如每个分类有多少议题、每个分 类中“赞”和“分享”的平均数量。

​ 假想一下,进入博客时,用户会在右侧看见最近流行的议题。 其中之一是自行车。 对其感兴趣的读者会点击这个标题,进一步缩小范围。 然后, 可能还有另外 的聚集方式 ,将自行车相关的帖子分为“ 自行车鉴赏”“自行车大事件”等。

ElasticSearch的发展

image-20220825112512298

起源Lucene

Lucene 是一个用 Java 编写的非常古老的搜索引擎工具 包,用来构建倒排索引(一种数据结构)和对这些索引进行检索,从而实现全文检索功能。

缺点

Lucene,必须使用Java来作为开发语言并将其直接集成到你的应用中,并且Lucene的配置及使用非常复杂,你需要深入了解检索的相关知识来理解它 是如何工作的,有以下缺点

  • 只能在Java项目中使用,并且要以jar包的方式直接集成项目中
  • 使用非常复杂-创建索引和搜索索引代码繁杂
  • 不支持集群环境-索引数据不同步(不支持大型项目)
  • 索引数据如果太多就不行,索引库和应用所在同一个服务器,共同占用硬盘,共用空间少。

lunce 单独占用内存?

诞生

ElasticSearch的创始人期初是为了能够为妻子开发一个菜谱搜索应用而接触的Lucene

​ 它本身不是一个应用程序无法直接提供用户使用,同样对其他语言不友好的,那么ElastiSearch的开发者在使用过程中遇到的一系列问题,他就在Lucene的基础上对之进行不断的优化形成了自己的一套应用程序‘Compass’。

​ 后来它自己在工作中同样遇到了一个需要高性能,分布式的搜索服务,所以他就在‘Compass’的基础之上重新构建起了ElasticSearch,从设计之初的目标就是打造成分布式、高性能、基于JSON、Restful的易用性可易用与其他语言的独立服务。

发展

围绕ElasticSearch后来成立一家公司(Elastic公司)全面围绕ElasticSearch或者说是数据生态进行发展,该公司已经在去年上市(ESTC),上市当天暴涨

img

​ ELasticSearch当前已经可以与多种客户端进行集成Python、PHP、.NET、Java等,当前同样支持与Hadoop、Spark等大数据分析平台进行集成。

​ ElasticSearch衍生出一系列的开源项目,例如业内较火的ELK Stack,ELK Stack是负责数据检索服务的ElasticSearch、数据采集解析服务的Logstash和负责数据可视化服务的Kibana的简称,Logstash是由Java语言编写的,同时负责数据的采集与解析工作,会导致服务的CPU与内存资源占用过高,后来ELastic又推出采用Go语言编写的Beats家族

ElasticSearch基本概念

索引类型

我们常见的索引包括正排索引和倒排索引

正排索引

正排索引是以文档的ID为关键字,表中记录文档中每个字段的位置信息,查找时扫描表中每个文档中字段的信息直到找出所有包含查询关键字的文档

正排索引说明

​ 拿MySQL Innodb的聚簇索引来说,如下图所示,一个极简版(无页属性)的B+树索引结构大概是这样,叶子节点存放完整数据,非叶子节点存放建立对应聚簇索引对应的字段(主键),一条可以使用到聚簇索引的SQL,会依次从上到下进行B+树的查找直到字段一致;

1
2
3
4
5
CREATE TABLE user_info (
id int,
name varchar(16),
hobby varchar(256)
);

image-20220819094000248

索引查询

​ 而对应非聚簇索引只是叶子节点的内容存放的是该表的主键信息,查询的顺序则是 先通过非聚簇索引的字段找到叶子节点中一致的 单个或者多个主键id,再使用这些主键id进行回表,最终获得对应的完整实体数据。

全表扫描

如果我们看上面在mysql中表的hobby爱好字段,如果我们有业务需求:根据用户爱好关键字如“篮球”去查询对应用户列表,我们怎么做,只能是写个字符串的like sql,全表扫描的逻辑。

1
2
3
SELECT *
FROM user_info
WHERE hobby LIKE '%篮球%';

​ 即使我们对hobby字段创建了普通索引,在Innodb引擎下,在查询中想使用字符串类型的索引也只能走最左前缀索引的逻辑,即 LIKE ‘篮球%’。

全文索引

​ 幸好Innodb在5.6版本后支持了全文索引full text,在创建完全文索引后,查询中使用MATCH、AGAINST就能够使用全文索引了,比全表扫B+树效率会高很多,但是对应全文索引会占据相当的磁盘空间,全文索引与我们要说的倒排索引就是一个意思了。

1
2
3
SELECT *
FROM user_info
WHERE MATCH (hobby) AGAINST ('篮球');
倒排索引

倒排索引源于实际应用中需要根据属性的值来查找记录,也就是说,不是由记录来确定属性值,而是由属性值来确定记录,因而称为倒排索引

​ 相比B+树的正排索引,如果我们对hobby字段建立了索引,他的倒排索引极简的数据格式如下。

​ 创建倒排索引的field,会通过分词器根据语义将字段中的field分成一个一个对应的词索引(term index),构成该类型数据的全部词索引集合,如“喜欢篮球、唱歌”会被分成 “篮球”和“唱歌”两个term index;

​ 第二列是含有这些term index对应的文档Id,这个数据可以帮助我们最终溯源到完整实体数据;

​ 第三列则是对应term index在该文档字段中的位置,0表示在开头的位置,这个可以帮助标注检索出来数据的高亮信息。

image-20220819095714172

两种索引查找顺序

正排索引倒排索引查询顺序.jpg

逻辑概念

假设我们在一个业务系统中选择MySQL做数据存储,那么我们需要先创建一个database,再创建一组相关的table,Elasticsearch同样具有这样的概念,使用indexmapping来组织数据,下面是Elasticsearch的一些基本概念

概念 关系型数据库 说明
索引库(indices) Databases 数据库 indices是index的复数,代表许多的索引
类型(type) Table 数据表 类型是模拟mysql中的table概念,一个索引库下可以有不同类型的索引,比如商品索引,订单索引,其数据格式不同,不过这会导致索引库混乱,因此未来版本中会移除这个概念
文档(document) Row 行 存入索引库原始的数据,比如每一条商品信息,就是一个文档
字段(field) Columns 列 文档中的属性
映射配置(mappings) 表结构 字段的数据类型、属性、是否索引、是否存储等特性
索引(Index)

一个索引由一个名字来标识(必须全部是小写字母),并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候,都要使用到这个名字。

​ 一个索引相当于数据库,是多个相似文档的集合,必须通过索引才能进行搜索,使用使用能够极大的提升查询速度,类似于词典里面的目录。

​ 当然在底层,肯定用到了倒排索引,最基本的结构就是“keyword”和“PostingList”,Postinglist就是一个int的数组,存储了所有符合某个term的文档id,另外,这个倒排索引相比特定词项出现过的文档列表,会包含更多其它信息。

​ 它会保存每一个词项出现过的文档总数,在对应的文档中一个具体词项出现的总次数,词项在文档中的顺序,每个文档的长度,所有文档的平均长度等等相关信息。

类型(Type)

一个类型过去是索引的逻辑类别/分区,允许你在同一索引中存储不同类型的文档

​ 例如,一种类型用于用户,另一种类型用于博客文章,在索引中创建多个类型不再可能,类型的整个概念将在稍后的版本中删除,相当于sql领域中表的概念。

类型的变化

在不同的elasticsearch中,类型发生了不同的变化

版本 Type
5.x 支持多种Type
6.x 只有一种Type
7.x 默认不在支持自定义的索引类型,默认类型为_doc
文档(Document)

一个文档是可以被索引的一个基本单元,相当于数据库中的一条数据,索引和搜索数据的最小单位是文档

字段(Field)

相当于数据库表的字段,每个字段有不同的类型

映射(Mapping)

Mapping是对处理数据时的方式和规则作出一定的限制,如字段的类型、默认值、分析器、是否被索引等,映射定义了每个字段的类型、字段所使用的分词器等。

​ 可以显式映射,由我们在索引映射中进行预先定义,也可以动态映射,在添加文档的时候,由es自动添加到索引,这个过程不需要事先在索引进行字段数据类型匹配等等,es会自己推断数据类型。

1
get itheima/_mapping

image-20220804105342845

物理概念

Elasticsearch是一个分布式系统,其数据会分散存储到不同的节点上,为了实现这一点,需要将每个index中的数据划分到不同的块中,然后将这些数据块分配到不同的节点上存储

集群 (cluster)

一个集群就是由一个或多个节点组织在一起,它们共同持有整个的数据,并一起提供索引和搜索功能

img 集群(cluster)是一个或多个节点(node)的集合,这些节点 将共同拥有完整的数据,并跨节点提供联合索引、搜索和分析功能。

​ 一个集群由一个唯一的名字标识,这个名字默认就是“elasticsearch”,这个名字是重要的,因为一个节点只能通过指定某个集群的名字,来加入这个集群。

​ ES集群是一个 P2P类型(使用 gossip 协议)的分布式系统,除了集群状态管理以外,其他所有的请求都可以发送到集群内任意一台节点上,这个节点可以自己找到需要转发给哪些节点,并且直接跟这些节点通信,所以从网络架构及服务配置上来说,构建集群所需要的配置极其简单

​ 集群中节点数量没有限制,一般大于等于2个节点就可以看做是集群了,一般处于高性能及高可用方面来考虑一般集群中的节点数量都是3个及3个以上。

节点(node)

一个节点是集群中的一个服务器,作为集群的一部分,它存储数据,参与集群的索引和搜索功能

​ 和集群类似,一个节点也是由一个名字来标识的,默认情况下,这个名字是一个随机的漫威漫画角色的名字,这个名字会在启动的时候赋予节点

​ 一个节点可以通过配置集群名称的方式来加入一个指定的集群,默认情况下,每个节点都会被安排加入到一个叫做“elasticsearch”的集群中,这意味着,如果你在你的网络中启动了若干个节点,并假定它们能够相互发现彼此,它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。

分片(Shards)

分片的存在是为了解决单个索引大量文档的存储问题、以及搜索是响应慢等问题。

​ 比如,一个具有10亿文档的索引占据1TB的磁盘空间,而任一节点都没有这样大的磁盘空间,或者单个节点处理搜索请求,响应太慢,为了解决这个问题,Elasticsearch提供了将索引划分成多份的能力,这些份就叫做分片。

​ 将一个索引划分成了多份,每一份就称之为分片,每个分片也是一个功能完善的“索引”,这个“索引”可以被放置到集群的任意节点上,通过”分”的思想,可以突破单机在存储空间和处理性能上的限制,这是分布式系统的核心目的

​ 至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由Elasticsearch管理的,对于作为用户的你来说,这些都是透明的。

副本(Replicas)

而对于分布式存储而言,还有一个重要特性是”冗余”,因为分布式的前提是:接受系统中某个节点因为某些故障退出,为了保证在故障节点退出后数据不丢失,同一份数据需要拷贝多份存在不同节点上

​ 在一个网络 / 云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由于任何原因消失了,这种情况下,有一个故障转移机制是非常有用并且是强烈推荐的。为此目的,Elasticsearch 允许你创建分片的一份或多份拷贝,这些拷贝叫做复制分片(副本)。

​ 复制之所以重要,有两个主要原因: 在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。扩展你的搜索量/吞吐量,因为搜索可以在所有的复制上并行运行。总之,每个索引可以被分成多个分片。一个索引也可以被复制0次(意思是没有复制)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变复制的数量,但是你事后不能改变分片的数量。

段(segment)

segment来自于lucene,因为ES底层就是使用的lucene,一个shard包含一组segment,segment是最小的数据单元

img

​ Elasticsearch每隔一段时间产生一个新的segment,里面包含了新写入的数据,lucene的数据写入会先写如到缓存(buffer)中,当达到一定数量以后,会flush成文一个segment,写入到磁盘当中,每个segement有自己独立的索引,可以单独查询。

​ segment不会被修改,数据的的写入都是进行批量的追加,避免了随机写的存在,提高了吞吐量,segement可以被删除,但也不是修改segement文件,而是由另外的文件记录需要被删除的documentId。

​ index的查询是对多个segement文件的查询,其中也包含了处理被删除文件的处理,并对查询结果进行合并,为了进行查询优化,lucene有策略对多个segment进行优化。

节点的角色

一个Elasticsearch实例代表了一个ES 节点,如果不通过 node.roles 设置节点的角色,一个ES节点默认的节点角色有:master 、data 、data_content、data_hot、data_warm、data_cold、ingest、ml、remote_cluster_client。

主节点介绍?元数据保存哪里,整体集群介绍

​ 每个节点既可以是候选主节点也可以是数据节点,通过在配置文件../config/elasticsearch.yml中设置即可,默认都为true,ES节点有如下角色:

img

master角色

其实这个是master准确的来说是具有成为master节点资格的节点,即master-eligible node

​ 候选主节点,master节点的职责是创建索引、删除索引、监控集群中的所有节点、决定分片应当分配到哪一个节点上,拥有一个稳定的主节点对集群非常重要,候选主节点可以通过节点选举过程被选举为主节点,主节点最好是专用的,不和其他角色共用,以免其他的操作对master节点负载造成影响,导致集群不可用

​ 主节点负责轻量级集群范围的操作,例如创建或删除索引、跟踪哪些节点是集群的一部分以及决定将哪些分片分配给哪些节点,任何不是仅投票节点的主合格节点都可以通过主选举过程选举成为主节点。

​ 主节点必须有一个path.data目录,其内容在重启后仍然存在,就像数据节点一样,因为这是存储集群元数据的地方,集群元数据描述了如何读取存储在数据节点上的数据,因此如果丢失,则无法读取存储在数据节点上的数据。

​ 如果小型或轻负载集群的主节点具有其他角色和职责,则其可能运行良好,但是一旦您的集群包含多个节点,使用专用的主节点通常是有意义的。

voting_only 仅投票节点

只能参与主节点的投票选举环节,但是自己不能被选举为master

​ 高可用性 (HA) 集群需要至少三个符合主节点的节点,其中至少两个不是仅投票节点,这样即使其中一个节点发生故障,集群也能够选举出一个主节点。

​ 仅投票节点用来凑数的,如果只部署了两个候选主节点,当一个节点挂掉后集群将会不可用,加入了候选主节点则不一样,有了仅投票节点可以帮助快速选择一个主节点出来,并且仅投票节点不会选为主节点,不存储数据,所以消耗的资源也很小。

data 数据节点

负责数据的存储和相关的操作,例如对数据进行增、删、改、查和聚合等操作

​ 保存包含已编入索引的文档的分片,数据节点处理数据相关操作,如 CRUD、搜索和聚合这些操作是 I/O 密集型、内存密集型和 CPU 密集型的,监控这些资源并在它们过载时添加更多数据节点非常重要

ingest 摄取节点

摄取节点可以执行由一个或多个摄取处理器组成的预处理管道

​ 能执行预处理管道,有自己独立的任务要执行, 在索引数据之前可以先对数据做预处理操作, 不负责数据存储也不负责集群相关的事务,类似于 logstash 中 filter 的作用,功能相当强大。

​ 在实际文档索引发生之前,使用Ingest节点预处理文档,Ingest节点拦截批量和索引请求,它应用转换,然后将文档传递回索引,在数据被索引之前,通过预定义好的处理管道对数据进行预处理。

coordinating 仅协调节点

如果您取消了处理主职责、保存数据和预处理文档的能力,那么您就剩下一个只能路由请求、处理搜索减少阶段和分发批量索引的协调节点

​ 本质上,仅协调节点的行为就像智能负载均衡器,通过从数据和符合主节点的节点卸载协调节点角色,仅协调节点可以使大型集群受益,他们加入集群并接收完整的集群状态,就像其他每个节点一样,他们使用集群状态将请求直接路由到适当的地方。

配置节点类型
节点类型 配置参数 默认值
master eligible node.master true
data node.data true
ingest node.ingest true
Coordianting only 每个节点默认都是 Coordianting。设置其他类型为 false
machine learning node.ml true (需要 enable x-pack)

ElasticSearch集群概念

集群角色

一个Elasticsearch实例代表了一个ES 节点,如果不通过 node.roles 设置节点的角色,一个ES节点默认的节点角色有很多个不同的角色

img

​ 每个节点既可以是候选主节点也可以是数据节点,通过在配置文件../config/elasticsearch.yml中设置即可,默认都为true,ES节点有如下角色:

Master节点

其实这个是master准确的来说是具有成为master节点资格的节点,即master-eligible node

主要职责

​ Master角色的主要职责是负责集群层面的相关操作,管理集群变更,如创建或删除索引,跟踪哪些节点是群集的一部分,并决定哪些分片分配给相关的节点。

​ 拥有一个稳定的主节点对集群非常重要,候选主节点可以通过节点选举过程被选举为主节点,主节点最好是专用的,不和其他角色共用,以免其他的操作对master节点负载造成影响,导致集群不可用

角色介绍

主节点负责轻量级集群范围的操作,任何不是仅投票节点的合格节点都可以通过选举成为主节点

​ 主节点必须有一个path.data目录,其内容在重启后仍然存在,就像数据节点一样,因为这是存储集群元数据的地方,集群元数据描述了如何读取存储在数据节点上的数据,因此如果丢失,则无法读取存储在数据节点上的数据。

仅投票节点

只能参与主节点的投票选举环节,但是自己不能被选举为master

主要职责

​ 仅投票节点用来凑数的,如果只部署了两个候选主节点,当一个节点挂掉后集群将会不可用,加入了仅投票节点则不一样,有了仅投票节点可以帮助快速选择一个主节点出来,并且仅投票节点不会选为主节点,不存储数据,所以消耗的资源也很小。

角色介绍

​ 高可用性 (HA) 集群需要至少三个符合主节点的节点,其中至少两个不是仅投票节点,这样即使其中一个节点发生故障,集群也能够选举出一个主节点。

数据节点

负责数据的存储和相关的操作,例如对数据进行增、删、改、查和聚合等操作

主要职责

数据节点主要是存储索引数据的节点,执行数据相关操作:CRUD、搜索,聚合操作等。

​ 数据节点对cpu,内存,I/O要求较高, 在优化的时候需要监控数据节点的状态,当资源不够的时候,需要在集群中添加新的节点。

角色介绍

​ 保存包含已编入索引的文档的分片,数据节点处理数据相关操作,如 CRUD、搜索和聚合这些操作是 I/O 密集型、内存密集型以及 CPU 密集型的,监控这些资源并在它们过载时添加更多数据节点非常重要

预处理节点

这是从5.0版本开始引入的概念,预处理节点可以执行由一个或多个摄取处理器组成的预处理管道

主要职责

​ 预处理操作运行在索引文档之前,即写入数据之前,通过事先定义好的一系列processors(处理器)和pipeline(管道),对数据进行某种转换、富化

角色介绍

​ 能执行预处理管道,有自己独立的任务要执行, 在索引数据之前可以先对数据做预处理操作, 不负责数据存储也不负责集群相关的事务,类似于 logstash 中 filter 的作用,功能相当强大。

​ 在实际文档索引发生之前,使用Ingest节点预处理文档,Ingest节点拦截批量和索引请求,它应用转换,然后将文档传递回索引,在数据被索引之前,通过预定义好的处理管道对数据进行预处理。

仅协调节点

如果您取消了候选主节点的职责、保存数据和预处理文档的能力,那么您就剩下一个只能路由请求、处理搜索减少阶段和分发批量索引的协调节点

只要职责

协调节点将请求转发给保存数据的数据节点,每个数据节点在本地执行请求,并将结果返回给协调节点。

​ 协调节点收集完数据合,将每个数据节点的结果合并为单个全局结果,对结果收集和排序的过程可能需要很多CPU和内存资源。

角色介绍

​ 本质上,仅协调节点的行为就像智能负载均衡器,通过从数据和符合主节点的节点卸载协调节点角色,仅协调节点可以使大型集群受益,他们加入集群并接收完整的集群状态,就像其他每个节点一样,他们使用集群状态将请求直接路由到适当的地方。

节点配置方式

以下是个个节点的配置方式

节点类型 配置参数 默认值
master eligible node.master true
data node.data true
ingest node.ingest true
Coordianting only 每个节点默认都是 Coordianting,设置其他类型为 false
machine learning node.ml true (需要 enable x-pack)

集群脑裂问题

脑裂是因为集群中的节点失联导致的

脑裂分析

例如一个集群中,主节点与其它节点失联:

image-20210723223804995

重新选主

此时,node2和node3认为node1宕机,就会重新选主:

image-20210723223845754

出现脑裂

当node3当选后,集群继续对外提供服务,node2和node3自成集群,node1自成集群,两个集群数据不同步,出现数据差异,当网络恢复后,因为集群中有两个master节点,集群状态的不一致,出现脑裂的情况:

image-20210723224000555

解决方案

解决脑裂的方案是,要求选票超过 ( 候选主节点数量 + 1 )/ 2 才能当选为主

​ 因此候选主节点数量最好是奇数,对应配置项是discovery.zen.minimum_master_nodes,在es7.0以后,已经成为默认配置,因此一般不会发生脑裂问题

​ 例如:3个节点形成的集群,选票必须超过 (3 + 1) / 2 ,也就是2票,node3得到node2和node3的选票,当选为主,node1只有自己1票,没有当选,集群中依然只有1个主节点,没有出现脑裂。

评论