首页  思维导图  详情

ElasticSearch 原理详解（详解在注释里面，图片加载需要时间）

2023-07-04 08:50:17   0  举报





仅支持查看

AI智能生成

知识要点和原理解析，详细信息和图片均在黄色图标的注释中，鼠标移动到黄色图标上即会显示，图片加载有时较慢。

ElasticSearch

搜索引擎

作者其他创作

大纲/内容

主要功能

海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展

近实时搜索，性能卓越。对结构化、全文、地理位置等类型数据的处理

海量数据的近实时分析（聚合功能）

基础概念

整体架构图

Near Realtime（NRT）

Cluster - 集群

两个特性

高可用性

可扩展性

集群健康值

green：所有主要分片和复制分片都可用

yellow：所有主要分片可用，但不是所有复制分片都可用

red：不是所有的主要分片都可用

Node - 节点

节点角色

master 主节点

data 数据节点

一个节点可以既为Master节点，又为Data节点，但是为什么不推荐？

data_content 内容数据节点

voting_only 仅投票节点

coordinating 仅协调节点

data_hot 热点数据节点

data_warm 暖数据节点

data_cold 冷数据节点

data_frozen 冻结数据节点

ingest 摄取节点

注意

如果你设置了 node.roles，则节点只会分配你指定的角色。 如果不设置 node.roles，节点将被分配以上所有角色（除了voting_only 和coordinating角色例外）。

节点不等同于服务器，一个服务器上可以部署多个节点。

集群中的每个节点都可以处理 HTTP 和传输流量。

所有节点都知道集群中的所有其他节点，并且可以将客户端请求转发到适当的节点。

分片

Shard - 分片（重点理解）

Primary Shard(主分片）

ES中的shard用来解决节点的容量上限问题,，通过主分片，可以将数据分布到集群内的所有节点之上。

Replication- 副本

作用

1、服务高可用(容灾)

2、扩展性能

对于一个索引，除非重建索引否则不能调整主分片的数目（主分片数, number_of_shards），但可以随时调整replica数(number_of_replicas)。

读取时主副分片使用轮询实现负载均衡

分片的设定

分片数设置过小

分片数设置过大

Index - 索引

Type - 类型

从6.0.0 版本起已废弃，一个索引中只存放一类数据

Document - 文档

文档的源数据

_index：文档所属索引名称

_type：文档所属类型名

index、type的初衷

为什么现在要移除type？

_id ：Doc的主键。在写入的时候，可以指定该Doc的ID值，如果不指定，则系统自动生成一个唯一的UUID值

生成方式

_version：文档的版本信息。Elasticsearch通过使用version来保证对文档的变更能以正确的顺序执行，避免乱序造成的数据丢失。

_seq_no：严格递增的顺序号，每个文档一个，Shard级别严格递增，保证后写入的Doc的_seq_no大于先写入的Doc的_seq_no

primary_term：primary_term也和_seq_no一样是一个整数，每当Primary Shard发生重新分配时，比如重启，Primary选举等，_primary_term会递增1

found：查询的ID正确那么ture, 如果 Id 不正确，就查不到数据，found字段就是false

_source：文档的原始JSON数据

ES和数据库的对比

lucene

结构图

lucene文件内容

术语

Field域

最基本常用属性

边界值限制

单个索引的字段数量上限

映射字段最大嵌套深度

字段名称最大长度

分页查询最大文档查询数量

文档查询的最大召回数量

组合查询（bool query）最大子句限制

聚合查询最大分桶数量

单次查询最大词项数量

单个分片最大文档数量上限（shard max doc count）

单个文档最大容量上限

分段存储-segment

每个段都是一个独立的可被搜索的数据集，并且段具有不变性，一旦索引的数据被写入硬盘，就不可修改。

为了提升写的性能，Lucene 并没有每新增一条数据就增加一个段，而是采用延迟写的策略，每当有新增的数据时，就将其先写入内存中，然后批量写入磁盘中。

ES Segment Memory

本质上就是segment中加到内存的FST数据，因此segment越多，该内存越大

分段思想下对数据写操作过程

新增

删除

更新

段不可变性的优点

不需要锁

可以常驻内存

缓存友好

增量创建

段不可变性的缺点

删除

更新

新增

过滤

提交点

segment的数据结构

Inverted Index

Stored Fields

哪些情形下需要显式的指定store属性呢？

Document Values

Cache

Lucene为什么要加Segment概念

Lucene索引

倒排索引

数据结构

posting list的ID范围

索引结构

索引过程

全文索引

全文数据库

全文检索

正向文件-原始文档

结构

正排索引DocValues 列式存储

保存位置

倒排&正排

对比

倒排

正排

区别

倒排索引+正排索引结合的优势

为什么需要doc values 剖析

查询分析

有 3 个方法

方法一

缺点

方法二

缺点

方法三

Doc values 深入认识

特性

生成时机

数据结构

存储位置

在什么粒度上会生成 doc values

默认开启

使用方式

不适应 text 类型字段

text类型如何建索引

fielddata

语法

特点

内存管理和生成，常驻内存

更占内存

懒加载

全加载

与 doc values，倒排索引一样基于 segment 建立而不是基于整个索引建立。

默认关闭

存在问题

生成慢

解决

占空间

解决

Fielddata过滤

fielddata和doc value对比

问题

读取 doc values 的数据放置在内存，这个内存是应用内存还是系统内存呢?

Aggregations—聚合功能

示例

单点聚合，结果可能不准确

倒排表压缩方案

Frame Of Reference

增量编码

流程步骤

例子

编码排序整数的方法比较

Integer array

bitmap

bitmap缺点

那为什么用4096来区分采用数组还是bitmap的阀值呢？

roaring bitmaps

为什么是以65535为界限?

Roaring Bitmaps设计思路

每个桶都有对应的 Container，不同的 Container 存储方式不同

1、Array Container

示例

2、Bitmap Container

示例

3、RunContainer

ArrayContainer转换为BitmapContainer的阈值

与bitmap性能的对比

空间节省

更高效的做交、并操作

Roaring bitmaps 和 Frame Of Reference 的关系

多个SHOULD的Query的文档号合并

文档号合并

1、处理包含关键字“a”的文档

2、处理包含关键字“b”的文档

3、处理包含关键字“c”的文档

4、处理包含关键字“e”的文档

5、统计文档号

FixedBitSet

构造函数

void set(int index)方法

例子

添加 3

添加 67

添加 120

添加179、195、313

通过上面的例子可以看到，如果我们存储的是连续的值，那么压缩率是很高的。当然同时可以看出无法处理有相同值的问题。

boolean get(int index)方法

get()方法可以实现随机访问，来确定index的值是否在bit[]数组中

FixedBitSet类中还有一些其他的方法

Spark之BloomFilter有趣的bitwise运算

BitArray巧妙的核心设计

比较有意思的是set方法的实现

>>>和>>

那么index >>> 6又是什么？

1L << index

index大于64位呢

Java内部自动 % 64

1L << index按Java内部的处理拆解

BitArray的set方法

一些常用的bitwise运算实例

判断int型变量a是奇数还是偶数

取模运算转化成位运算 (在不产生溢出的情况下)

乘法运算转化成位运算 (在不产生溢出的情况下)

除法运算转化成位运算 (在不产生溢出的情况下)

取相反数

其他

lucenen索引层面的写入、更新、删除、合并

写入过程

过程分解

首先，document会被写入in-memory buffer和translog日志文件

每隔1秒，执行一次refresh操作

refresh操作完成后，buffer会被清空

图解

为什么说Elasticsearch是准实时（NRT，near real-time）？

实时查询 - GetById

Translog 事务日志

写入机制

图解

Translog的同步控制参数

flush过程

触发flush操作

第一步，将buffer中的现有数据refresh到os cache中生成segment，清空buffer

把之前所有没有落盘的 segment 强制刷盘，确保写入物理文件。

创建一个提交点，记录这次提交对应的所有 segment，写入 commit point 文件。

清空 Translog，因为 Segment 都已经踏实落地了，之前的 Translog 就不需要了。

触发清理动作的2个条件

大小触发设定的阈值；

30分钟

删除和更新

update流程（部分更新）

versionMap

主要用途在数据变更时的校验

_id与_uid的联系

segment 合并

定期合并

合并完成时的活动

合并也是在内存中完成的，此时数据还没有写到磁盘中

整体流程图

图1

图2

memory buffer的倒排索引，则必须等Segment内所有文档全部写入完毕后，会先对Term进行一个全排序，之后才能构建索引，所以必须要有一个memory-buffer先缓存所有文档。

Elasticsearch的写入流程特性

可靠性

一致性

原子性

实时性

隔离性

ES层面写流程

整体的索引流程

路由规则

目标分片接收数据并refresh

flush

一主多副架构

Primary、Replica 副本同步

索引更新机制

ES层面读流程

文档查询步骤顺序

单个文档

多个文档

文档读取过程

query_then_fetch

准备fetch doc源码

ElasticSearch读取文档的实现机制

Lucene的读

Elasticsearch的读

分布式查询

查询主要分为两类

Get请求：通过ID查询特定Doc

Search请求：通过Query查询匹配Doc

交并集方案比较

二重for循环法

拉链法，时间复杂度O(n)

水平分桶，多线程并行

bitmap，大大提高运算并行度，时间复杂度O(n)

跳表，时间复杂度为O(log(n))

倒排合并

一致性（Consistency）

三种设置来判断是否允许写操作

One

All

Quorum（k-wu-wo/reng，法定人数）

ES内存结构与使用

内存结构

On Heap内存占用

Indexing Buffer

缓存时机

失效或者回收

配置

Node Query Cache (Filter Cache)

缓存的构建过程

示例

缓存时机

失效或回收

Shard Request Cache

主要作用

缓存时机

失效或回收

Field Data Cache

Segment Cache（Segment FST Cache）

内存回收与释放

拿什么来防止 ES OOM ？

Parent circuit breaker 总断路器

Field data circuit breaker 字段数据断路器

Request circuit breaker 请求数据断路器

Off Heap内存占用

如何提高查询性能？

1、性能优化的杀手锏——filesystem cache

2、数据预热

3、 冷热分离

4、document模型设计

5、分页性能优化

Zen Discovery机制

es p2p机制

master node

cluster.name（默认值是elasticsearch）

节点发现方式

单播（unicast）

配置

ping

unicast

通俗理解

主要步骤

基于文件

配置

基于文件的发现插件会增强单播主机列表 elasticsearch.yml

示例

选举原理之Bully算法

触发选举的两种情况

当master-eligible（候选master）节点数量小于法定票数

当主节点宕机

选举流程

选举时间点

集群启动初始化

集群的Master崩溃的时候

任何一个节点发现当前集群中的Master节点没有得到n/2 + 1节点认可的时候，触发选举

选举流程图

1、筛选activeMasters列表

从activeMasters列表选举Master节点

2、筛选masterCandidates列表

从masterCandidates列表选举Master节点

选举流程

示例

Elasticsearch编号比较

Master假死

Elasticsearch是如何解决这个问题的呢？

脑裂问题

Elasticsearch脑裂解决方案-Quorum算法

Master更新集群状态时的防护

Master降级

异常检测

1、Master

NodesFaultDetection事件处理

2、非Master

MasterFaultDetection事件处理

ping参数

ES相关命令及操作

mapping

分片管理

基本概念

主分片（primary shard）

副本分片（replica shard

部署

分片管理官方建议

1、分片大小在 10GB 到 50GB 之间

大分片需要更长的恢复时间

小分片会带来更多的开销并且搜索效率较低

2、每 GB 堆内存 20 个或更少的分片

3. 分配管理小结

避免使用非常大的分片

分片数不是越多越好

分片最大容量限制

当数据量可以合理预测并且变化缓慢时，具有固定时间间隔的基于时间的索引很有效。

跨索引查询

为什么需要跨索引查询

技术限制

技术便利

ES提供两个维度的拆分方式

ES查询示意图：多索引+多分片

跨索引查询应用场景

示例1：实时数据与历史数据业务场景

示例2：大数据平台写数据到Elastic平台

日志

跨索引查询应用方式

直接型

模糊型

计算型

跨索引查询技术原理

索引分片

查询过程

跨索引查询注意事项

索引与分片等价关系

协调节点分离

路由机制

ES分页

三种分页技术

From+Size

介绍

query 和 fetch 阶段

Query阶段

coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。

Fetch阶段

From + size 查询优点

支持随机翻页

From + size 查询缺点

受制于 max_result_window 设置，不能无限制翻页

超出max_result_window

两个解决方案

方案一：大数据集召回数据使用：scroll api。

方案二：调大 index.max_result_window 默认值。

存在深度翻页问题，越往后翻页越慢

From + size 查询适用场景

深度翻页不推荐使用 From + size

Search After(指定排序字段+游标)

使用 search_after 机制需要注意点

用法举例

基本原理

search_after 优点

不严格受制于 max_result_window

无状态查询

不需要维护scroll_id

search_after 缺点

search_after 适用场景

Scroll

实时性

scroll可以分为初始化和遍历两部分

使用例子

实现原理

分三种情况

带 query，不带 sort

不带 query，不带 sort

带 sort

scroll 查询优点

支持全量遍历

适用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的

scroll 查询缺点

scroll_id会占用大量的资源（特别是排序的请求）

是生成的历史快照，对于数据的变更不会反映到快照上

scroll后接超时时间，频繁的发起scroll请求，会出现一些列问题

scroll 查询适用场景

全量或数据量很大时遍历结果数据，而非分页查询

Scroll Scan

基本使用

Scroll Scan与Scroll的区别

Sliced Scroll

小结

并发控制及乐观锁实现原理

常用的锁方案

悲观并发控制

乐观并发控制

Elasticsearch默认使用乐观锁

ES的乐观锁方案

案例

乐观锁方案

使用内置_version实战乐观锁控制效果

使用外部_version实战乐观锁控制效果

内置_version/外部_version的区别

内置_version

外部_version

Replica Shard数据同步并发控制

Shard的数据同步也是基于内置的_version进行乐观锁并发控制的

示例

那Elasticsearch内部是如何做的呢？

ElasticSearch 原理详解 （详解在注释里面，图片加载需要时间）

ElasticSearch 原理详解（详解在注释里面，图片加载需要时间）