ElasticSearch常见面试题

0    288    1

Tags:

👉 本文共约13027个字,系统预计阅读时间或需49分钟。

目录

什么是ElasticSearch?

Elasticsearch 之(2)Elasticsearch核心概念_vincent-CSDN博客_elasticsearch核心概念

Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式,多租户能力的全文搜索引擎。Elasticsearch是用Java开发的,根据Apache许可条款作为开源发布。

Lucene工作原理

  1. Lucene 是一个 JAVA 搜索类库,它本身并不是一个完整的解决方案,需要额外的开发工作。
  2. Document文档存储、文本搜索。
  3. Index索引,聚合检索。
  4. Analyzer分词器,如IKAnalyzer、word分词、Ansj、Stanford等
  5. 大数据搜索引擎解决方案原理
  6. NoSQL的兴起(Redis、MongoDB、Memecache)

img

ElasticSearch的特点

(1)可以作为一个大型分布式集群(数百台服务器)技术,处理PB级数据,服务大公司;也可以运行在单机上,服务小公司

(2)Elasticsearch不是什么新技术,主要是将全文检索、数据分析以及分布式技术,合并在了一起,才形成了独一无二的ES;lucene(全文检索),商用的数据分析软件(也是有的),分布式数据库(mycat)

(3)对用户而言,是开箱即用的,非常简单,作为中小型的应用,直接3分钟部署一下ES,就可以作为生产环境的系统来使用了,数据量不大,操作不是太复杂

(4)数据库的功能面对很多领域是不够用的(事务,还有各种联机事务型的操作);特殊的功能,比如全文检索,同义词处理,相关度排名,复杂数据分析,海量数据的近实时处理;Elasticsearch作为传统数据库的一个补充,提供了数据库所不不能提供的很多功能

关系型数据库和ElasticSearch对比

属性关系型数据库ElasticSearch
DBIndex
TableIndex Type
约束ConstraintID

ElasticSearch中的集群、节点、索引、文档、类型是什么?

  • 群集是一个或多个节点(服务器)的集合,它们共同保存您的整个数据,并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识,默认情况下为“elasticsearch”。此名称很重要,因为如果节点设置为按名称加入群集,则该节点只能是群集的一部分。
  • 节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
  • 索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间,映射到一个或多个主分片,并且可以有零个或多个副本分片。 MySQL =>数据库 ElasticSearch =>索引
  • 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段),但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows ElasticSearch => Indices => Types =>具有属性的文档
  • 类型是索引的逻辑类别/分区,其语义完全取决于用户。

ElasticSearch的核心概念

(1)Near Realtime(NRT):近实时,两个意思,从写入数据到数据可以被搜索到有一个小延迟(大概1秒);基于es执行搜索和分析可以达到秒级
(2)Cluster:集群,包含多个节点,每个节点属于哪个集群是通过一个配置(集群名称,默认是elasticsearch)来决定的,对于中小型应用来说,刚开始一个集群就一个节点很正常

(3)Node:节点,集群中的一个节点,节点也有一个名称(默认是随机分配的),节点名称很重要(在执行运维管理操作的时候),默认节点会去加入一个名称为“elasticsearch”的集群,如果直接启动一堆节点,那么它们会自动组成一个elasticsearch集群,当然一个节点也可以组成一个elasticsearch集群
(4)Document&field:文档,es中的最小数据单元,一个document可以是一条客户数据,一条商品分类数据,一条订单数据,通常用JSON数据结构表示,每个index下的type中,都可以去存储多个document。一个document里面有多个field,每个field就是一个数据字段。
product document

(5)Index:索引,包含一堆有相似结构的文档数据,比如可以有一个客户索引,商品分类索引,订单索引,索引有一个名称。一个index包含很多document,一个index就代表了一类类似的或者相同的document。比如说建立一个product index,商品索引,里面可能就存放了所有的商品数据,所有的商品document。
(6)Type:类型,每个索引里都可以有一个或多个type,type是index中的一个逻辑数据分类,一个type下的document,都有相同的field,比如博客系统,有一个索引,可以定义用户数据type,博客数据type,评论数据type。

(7)shard:单台机器无法存储大量数据,es可以将一个索引中的数据切分为多个shard,分布在多台服务器上存储。有了shard就可以横向扩展,存储更多数据,让搜索和分析等操作分布到多台服务器上去执行,提升吞吐量和性能。每个shard都是一个lucene index。

(8)replica:任何一个服务器随时可能故障或宕机,此时shard可能就会丢失,因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务,保证数据不丢失,多个replica还可以提升搜索操作的吞吐量和性能。primary shard(建立索引时一次设置,不能修改,默认5个),replica shard(随时修改数量,默认1个),默认每个索引10个shard,5个primary shard,5个replica shard,最小的高可用配置,是2台服务器。
img

解释一下 Elasticsearch Node?

节点是 Elasticsearch 的实例。实际业务中,我们会说:ES 集群包含 3 个点、7 个节点。这里节点实际就是:一个独立的 Elasticsearch 进程,一般将一个节点部署到 一台独立的服务器或者虚拟机、容器中。

不同节点根据角色不同,可以划分为:

主节点

帮助配置和管理在整个集群中添加和删除节点。

数据节点

存储数据并执行诸如 CRUD(创建/读取/更新/删除)操作,对数据进行搜索和聚合的操作。

1、 客户端节点(或者说:协调节点)

将集群请求转发到主节点,将与数据相关的请求转发到数据节点。

2、 摄取节点

用于在索引之前对文档进行预处理。

分片和副本机制

1.一个index中包含多个shard

2.每个shard都是一个最小工作单元,承载部分数据;每个shard都是一个Lucene实例,有完整的建立索引和处理请求的能力

3.增减节点时,shard会自动在nodes中负载均衡

4.primary shard 和 relica shard,每个document只会存在于某一个primary shard以及其对应的replica shard中,不可能存在于多个primary shard中

5.replica shard 是primary shard 的副本,负责容错,以及承担读请求的负载均衡

6.primary shard在创建索引的时候就固定了,relica shard的数量可以随时更改

7.primary shard 和 它对应的replica shard 不能放在同一台机器上,不然起不了容错的作用

shard&replica机制梳理总结

一个 CRUD 操作只对单个文档进行处理,文档的唯一性由 _index, _type, 和 routing values (通常默认是该文档的 _id )的组合来确定。 这表示我们确切的知道集群中哪个分片含有此文档。

搜索需要一种更加复杂的执行模型因为我们不知道查询会命中哪些文档: 这些文档有可能在集群的任何分片上。 一个搜索请求必须询问我们关注的索引(index or indices)的所有分片的某个副本来确定它们是否含有任何匹配的文档。

但是找到所有的匹配文档仅仅完成事情的一半。 在 search 接口返回一个 page 结果之前,多分片中的结果必须组合成单个排序列表。 为此,搜索被执行成一个两阶段过程,我们称之为 query then fetch

副本数量的选定原则

分布式模式

模式代表组件优点缺点
主从模式ES/HDFS/HBase简化系统设计,Master作为权威节点,负责维护集群原信息。Master节点存在单点故障,需要解决在被问题,并且集群规模会受限于Master节点的管理能力。
无主模式Cassandra分布式哈希表(DHT),支持每小时数千个节点的离开和加入。集群没有master的概念,所有节点都是同样的角色,彻底避免了整个系统的单点问题导致的不稳定性。多个节点可能操作同一条数据,数据一致性上可能比较难以保证。

为什么使用 Master

Elasticsearch的典型场景中的另一个简化是集群中没有那么多节点。 通常,节点的数量远远小于单个节点能够维护的连接数,并且网格环境不必经常处理节点加入和离开。 这就是为什么领导者的做法更适合Elasticsearch。

Elasticsearch是如何实现Master选举的

  1. Elasticsearch的选主是ZenDiscovery模块负责的,主要包含Ping(节点之间通过这个RPC来发现彼此)和Unicast(单播模块包含一个主机列表以控制哪些节点需要ping通)这两部分;
  2. 对所有可以成为master的节点(node.master: true)根据nodeId字典排序,每次选举每个节点都把自己所知道节点排一次序,然后选出第一个(第0位)节点,暂且认为它是master节点。
  3. 如果对某个节点的投票数达到一定的值(可以成为master节点数n/2+1)并且该节点自己也选举自己,那这个节点就是master。否则重新选举一直到满足上述条件。

master节点的职责主要包括集群、节点和索引的管理,不负责文档级别的管理;data节点可以关闭http功能。

Elasticsearch是如何避免脑裂现象的

当集群中master候选的个数不小于3个(node.master:true)。可以通过discovery.zen.minimum_master_nodes这个参数的设置来避免脑裂,设置为(N/2)+1。

这里node.master : true 是说明你是有资格成为master,并不是指你就是master。是皇子,不是皇帝。假如有10个皇子,这里应该设置为(10/2)+1=6,这6个皇子合谋做决策,选出新的皇帝。另外的4个皇子,即使他们全聚一起也才四个人,不足合谋的最低人数限制,他们不能选出新皇帝。

假如discovery.zen.minimum_master_nodes 设置的个数为5,有恰好有10个master备选节点,会出现什么情况呢?5个皇子组成一波,选一个皇帝出来,另外5个皇子也够了人数限制,他们也能选出一个皇帝来。此时一个天下两个皇帝,在es中就是脑裂。

假如集群master候选节点为2的时候,这种情况是不合理的,最好把另外一个node.master改成false。如果我们不改节点设置,还是套上面的(N/2)+1公式,此时discovery.zen.minimum_master_nodes应该设置为2。这就出现一个问题,两个master备选节点,只要有一个挂,就选不出master了。

我还是用皇子的例子来说明。假如先皇在位的时候规定,必须他的两个皇子都在的时候,才能从中2选1 继承皇位。万一有个皇子出意外挂掉了,就剩下一个皇子,天下不就没有新皇帝了么。

客户端在和集群连接时,如何选择特定的节点执行请求的?

TransportClient利用transport模块远程连接一个elasticsearch集群。它并不加入到集群中,只是简单的获得一个或者多个初始化的transport地址,并以 轮询 的方式与这些地址进行通信。

想了解该处,可以参考各个编程语言提供的es 库

Elasticsearch 文档索引过程描述**

协调节点默认使用文档ID参与计算(也支持通过routing),以便为路由提供合适的分片。

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信dbaup66,谢谢!
AiDBA后续精彩内容已被站长无情隐藏,请输入验证码解锁本文!
验证码:
获取验证码: 请先关注本站微信公众号,然后回复“验证码”,获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复