【ES】图解原理

190 阅读5分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第21天,点击查看活动详情

0. 认识倒排索引

正排索引 VS 倒排索引:

2022-05-0414-44-25.png

倒排索引包括两个部分:

  • 单词词典(Term Dictionary):记录所有文档的单词,记录单词到倒排列表的关联关系

    单词词典一般比较大,可以通过 B+ 树 或 哈希拉链法实现,以满足高性能的插入与查询

  • 倒排列表(Posting List):记录了单词对应的文档结合,由倒排索引项(Posting)组成:

    • 文档 ID
    • 词频 TF:该单词在文档中出现的次数,用于相关性评分
    • 位置(Position):单词在文档中分词的位置。用于语句搜索(Phrase Query
    • 偏移(Offset):记录单词的开始结束位置,实现高亮显示

2022-05-0414-50-19.png

ElasticSearch 的倒排索引:

  • ElasticSearchJSON 文档中的每个字段,都有自己的倒排索引
  • 可以针对某些字段不做索引
    • 优点:节省存储空间
    • 缺点:字段无法被搜索

1. 分布式架构原理

分片 shard:一个索引可以拆分成多个 shard 分片。

  • 主分片 primary shard:每个分片都有一个主分片。
  • 备份分片 replica shard:主分片写入数据后,会将数据同步给其他备份分片。

ES 集群部署在 3个 机器上(esnode1esnode2esnode3):

创建个索引,分片为 3 个,副本数设置为 1:

PUT /sku_index/_settings
{
    "settings": {
        "number_of_shards" : 3,
        "number_of_replicas": 1
    }
}

响应:
{
  "acknowledged" : true
}

2022-04-0918-47-18.png

ES 集群中有多个节点,会自动选举一个节点为 master 节点,如上图的 esnode2节点:

  • 主节点(master):管理工作,维护索引元数据、负责切换主分片和备份分片身份等。
  • 从节点(node):数据存储。

集群中某节点宕机:

  • 主节点宕机:会重新选举一个节点为 主节点。
  • 从节点宕机:由 主节点,将宕机节点上的 主分片身份转移到其他机器上的 备份分片上。

2. 写入数据的工作原理

写单个文档所需的步骤:

  1. 客户端选择一个 Node 发送请求,那么这个 Node 就称为 协调节点(Coorinating Node

  2. Node 使用文档 ID 来确定文档属于分片 0,通过集群状态中的内容路由表信息获知分片0 的主分片在 Node1 上,因此将请求转发到 Node1 上。

  3. Node1 上的主分片执行写操作。如果写入成功,则将请求并行转发到 Node3 的副分片上,等待返回结果。

    当所有的副分片都报告成功,Node1 将向 Node (协调节点)报告成功。

2022-05-04-2109.png

Tips:客户端收到成功响应时,意味着写操作已经在主分片和所有副分片都执行完成。

写数据底层原理

1_vqjpyFZnYbHSauBJ1fGaug.png

写操作可分为 3 个主要操作:

  1. **写入新文档:**这时候搜索,是搜索不到。

    • 将数据写入内存
    • 将这操作写入 translog 文件中
  2. **refresh 操作:**默认每隔 1s ,将内存中的文档写入文件系统缓存(filesystem cache)构成一个 segment

    这时候搜索,可以搜索到数据。

    • 1s 时间: ES 是近实时搜索,即数据写入 1s后可以搜索到。
  3. **flush 操作:**默认每隔 30 分钟 或者 translog 文件 512MB ,将文件系统缓存中的 segment 写入磁盘,并将 translog 删除。

translog 文件:来记录两次 flush(fsync) 之间所有的操作,当机器从故障中恢复或者重启,可以根据此还原

  • translog 是文件,存在于内存中,如果掉电一样会丢失。
  • 默认每隔 5s 刷一次到磁盘中

3. 读取数据的工作原理

读取文档所需的步骤:

  1. 客户端选择一个 Node 发送请求,那么这个 Node 就称为 协调节点(Coorinating Node
  2. Node 使用文档 ID 来确定文档属于分片 0,通过集群状态中的内容路由表信息获知分片0 有 2 个副本数据(一主一副),会使用随机轮询算法选择出一个分片,这里将请求转发到 Node1
  3. Node1 将文档返回给 NodeNode 将文档返回给客户端。

2022-05-04-2120.png

在读取时,文档可能已经存在于主分片上,但还没有复制到副分片,这种情况下:

  • 读请求命中副分片时,可能会报告文档不存在。
  • 读请求命中主分片时,可能成功返回文档。

4. 搜索工作原理

搜索数据过程:

  1. 客户端选择一个 Node 发送请求,那么这个 Node 就称为 协调节点(Coorinating Node
  2. Node 协调节点将搜索请求转发到所有的 分片(shard):主分片 或 副分片,都可以。
  3. query 阶段:每个分片 shard 将自己的搜索结果(文档 ID)返回给协调节点,由协调节点进行数据的合并、排序、分页等操作,产出最终结果。
  4. fetch 阶段:由协调节点根据 文档 ID 去各个节点上拉取实际的文档数据。

2022-05-04-2208.png

**举个栗子:**有 3 个分片,查询返回前 10 个匹配度最高的文档

  1. 每个分片都查询出当前分片的 TOP 10 数据
  2. 协调节点3 * 10 = 30 的结果再次排序,返回最终 TOP 10 的结果。

5. 删除/更新数据底层原理

  • 删除操作commit 的时候会生成一个 .del 文件,里面将某个 doc 标识为 deleted 状态,那么搜索的时候根据 .del 文件就知道这个 doc 是否被删除了。
  • 更新操作:就是将原来的 doc 标识为 deleted 状态,然后新写入一条数据。

底层逻辑是:

  • Index Buffer 每次 refresh 操作,就会产生一个 segment file。(默认情况:1秒1次)
  • 定制执行 merge 操作:将多个 segment file 合并成一个,同时将标识为 deleteddoc 物理删除,将新的 segment file 写入磁盘,最后打上 commit point 标识所有新的 segment file