ElasticSearch基础、分布式架构及读写流程

水深无声 2021-11-27 07:14 386阅读 0赞

# ElasticSearch #

### 文章目录 ###

*  ElasticSearch
 *   *  基础
     *   *  概念
         *   *  Index
             *  Type
             *  Mapper
             *  Document
             *  Field
         *  读取中的概念
         *   *  get
             *  query
             *  filter DSL
     *  分布式架构
     *   *  名词概念
         *   *  primary shard
             *  replica shard
         *  架构图
     *  读取流程
     *   *  get
         *  query
     *  写入流程
     *   *  几个基本名词
         *   *  内存buffer
             *  translog
             *  os-cache
             *  refresh
             *  segment-file
             *  commit/flush
             *  commit-point
             *  merge
         *  图片
         *  流程详细
         *   *  删除
             *  更新
             *  merge

## 基础 ##

### 概念 ###

#### Index ####

类似于表，也可以类比成库

#### Type ####

某一种类型的表，在Index下级

#### Mapper ####

表结构

#### Document ####

数据行

#### Field ####

字段

### 读取中的概念 ###

#### get ####

根据doc\_id获取document

#### query ####

根据筛选条件查询

在查询上下文中，查询会回答这个问题——“这个文档匹不匹配这个查询，它的相关度高么？”
    
    如何验证匹配很好理解，如何计算相关度呢？ES中索引的数据都会存储一个_score分值，分值越高就代表越匹配。另外关于某个搜索的分值计算还是很复杂的，因此也需要一定的时间。
    
    查询上下文 是在 使用query进行查询时的执行环境，比如使用search的时候。
    
    一些query的场景：
    
    与full text search的匹配度最高
    包含run单词，如果包含这些单词：runs、running、jog、sprint，也被视为包含run单词
    包含quick、brown、fox。这些词越接近，这份文档的相关性就越高

#### filter DSL ####

搜索

在过滤器上下文中，查询会回答这个问题——“这个文档匹不匹配？”
    
    答案很简单，是或者不是。它不会去计算任何分值，也不会关心返回的排序问题，因此效率会高一点。
    
    过滤上下文 是在使用filter参数时候的执行环境，比如在bool查询中使用Must_not或者filter
    
    另外，经常使用过滤器，ES会自动的缓存过滤器的内容，这对于查询来说，会提高很多性能。
    
    一些过滤的情况：
    
    创建日期是否在2013-2014年间？
    status字段是否为published？
    lat_lon字段是否在某个坐标的10公里范围内？

## 分布式架构 ##

### 名词概念 ###

#### primary shard ####

主节点

#### replica shard ####

从节点

### 架构图 ###

1.  图为3个shard，一个index包含多个shard
2.  每个shard为最小的操作单元。里面包含了Lucene实例
3.  其中一台机器为master，里面存有集群的信息
4.  写入数据，写到primary shard，然后同步到replica上
5.  master挂掉之后，会重新从primary中选一个master
6.  primary挂掉之后，replica会成为primary

![01\_elasticsearch分布式架构原理][01_elasticsearch]

![es002][]  
![es002][es002 1]  
![es002][es002 2]

## 读取流程 ##

### get ###

1.  拿着doc\_id，进行hash，找到对应的机器节点
2.  去该机器上面找到对应的数据

### query ###

1.  拿着查询条件，连接到协调节点
2.  协调节点将这个请求 发送给所有的节点
3.  所有节点查询到匹配的数据，返回给协调节点
4.  协调节点从这里面找到最匹配的N条
5.  // 这时候的协调节点拿到的数据，不是全的，只有一个doc\_id，要回表查
6.  返回数据

## 写入流程 ##

### 几个基本名词 ###

#### 内存buffer ####

数据先写到内存中

#### translog ####

translog日志文件的作用是什么？就是在你执行commit操作之前，数据要么是停留在buffer中，要么是停留在os cache中，无论是buffer还是os cache都是内存，一旦这台机器死了，内存中的数据就全丢了。

所以需要将数据对应的操作写入一个专门的日志文件，translog日志文件中，一旦此时机器宕机，再次重启的时候，es会自动读取translog日志文件中的数据，恢复到内存buffer和os cache中去。

#### os-cache ####

操作系统缓存

#### refresh ####

内存buffer数据—》os-cache----segment-file(还没有fsync)

#### segment-file ####

对应的数据文件

#### commit/flush ####

1.  当translog过大或者定时，执行
2.  创建从上一个commit时间点到这次commit中的segment-file保存

#### commit-point ####

保存点，保存的是这次commit保存的segment-file

#### merge ####

将多个segment-file合并

### 图片 ###

![01\_es读写底层原理剖析][01_es]

### 流程详细 ###

1.  往内存buffer中写入数据，同时往日志文件translog中写
2.  每隔1s，会将 内存buffer中的数据refresh到os-cache，再到磁盘文件segment-file中(这时候文件还没有保存)，清空内存buffer
3.  每次refresh都会生成一个segment-file，这时候可以提供对外的检索服务，会有很多个segment-file产生，NRT，near real-time，准实时
4.  translog文件也是先到os-cache中，每隔5s保存一次。所以，如果es在这5s挂掉，则会丢失这5s的数据
5.  translog不像内存buffer那样，1s钟就清空一次，所有会有大小限制，当大到一定程度的话就会执行commit操作
6.  commit操作：执行refresh，将os-cache文件fsync到磁盘文件中去，将所有的segment-file的名称写到commit-point文件中去，清空translog

#### 删除 ####

1.  commit会生成一个.del文件，表示某个doc为删除状态，搜索的时候根据.del文件表示为删除

#### 更新 ####

1.  先删除，再插入

#### merge ####

1.  用来合并segment-file
2.  写入一个新的segment-file，重新写一个commit-point

[01_elasticsearch]: /images/20211126/af8bee999a434c0b93aa8d011d125f06.png
[es002]: /images/20211126/b802772a1e4d48bca7c927323e28830d.png
[es002 1]: /images/20211126/53ae05a6c6954059adca7b724c7556e7.png
[es002 2]: /images/20211126/b73b9c44c0fe4b738afe6e077fff5a9e.png
[01_es]: /images/20211126/1fcc5ea963f44e36a09be96ba2f4b8c9.png