Es读写调优、深度分页

分手后的思念是犯贱 2024-03-22 14:03 49阅读 0赞

## 写入 ##

### ES支持四种对文档的数据写操作 ###

create：如果在PUT数据的时候当前数据已经存在，则数据会被覆盖，如果在PUT的时候加上操作类型create，此时如果数据已存在则会返回失败，因为已经强制指定了操作类型为create，ES就不会再去执行update操作。

delete：删除，ES对文档的删除是懒删除机制，即标记删除。（.del文件）

index：创建索引

update：包括全量替换、部分替换

### 写流程 ###

es中数据写入都是在主分片中；副本分片不支持写入，只读的

客户端发起写入请求到node x，node x根据文档id进行一系列计算，在路由表中确定当前数据在分片a，分片a的主分片位于node y上，将数据转发至node y

数据在node y写入成功后，将数据的同步请求转发至分片a的副本分片上，等待所有副本数据写入成功（根据写入一致性策略），将结果报告给node x，并由node x将结果返回给客户端

### 写入一致性策略 ###

参数：`wait_for_active_shards`

确定客户端返回数据之前必须处于active 的分片数（包括主分片和副本）

默认为 wait\_for\_active\_shards = 1，即只需要主分片写入成功

设置为 `all`或任何正整数，最大值为索引中的分片总数 ( `number_of_replicas + 1` )。

如果当前 active 状态的副本没有达到设定阈值，写操作必须等待并且重试，默认等待时间30秒，直到 active 状态的副本数量超过设定的阈值或者超时返回失败为止。

如果主分片写入失败，默认等待1分钟

### 写入原理 ###

![79ff3141b37642918d047a274730f9e1.png][]

1. 客户端的操作会先写入内存缓冲区，内存缓冲区有固定大小，等内存缓冲区满了或者时间间隔到了（1s）

2. 执行**refresh**操作，生成对应的segment文件（lucene的索引文件），并立刻同步到OS cache中

3. segment文件同步到OS chache后，segment处于open状态，此时，segment中的数据就可以查询了（此时，数据还没有同步到磁盘中）

4. OS cache中的数据满了会执行fsync操作，将数据同步到OS disk

5. OS cache中的数据是断电易失的，需要Translog来保证数据安全，translog是append的形式写的，直接写在磁盘上。OS cache同步到OS disk后，会同步后会清空translog

**refresh**操作可以手动执行，减少数据延迟

segment文件越来越多，segment消耗操作系统句柄，需要定期进行合并，

**merge操作**：

将多个segment文件合并成一个大的segment文件

merge操作也消耗资源，不能过于频繁

OS cache满了，或者translog满了，都会触发fsync操作

flush：是把内存中的数据(包括translog和segments)都刷到磁盘

### 写入调优 ###

分为两种情况，高频低量和低频高量

1. 关闭副本，写入成功后再打开副本（低频高量）

2. 增加 flush 时间间隔：减小数据写入磁盘的频率

3. 增加refresh\_interval的参数值：减少segment文件的创建

4. 增加Buffer大小：本质也是减少refresh

5. 禁用swap

6. 使用多个工作线程

7. 避免使用稀疏数据

8. max\_result\_window参数：分页返回的最大数值，默认10000，对JVM的一种保护机制

## 查询调优 ##

写入性能和查询性能不可能都会好的，要看项目更侧重哪个

要写入实时性换取查询性能

1. 避免大单页查询

2. 避免单个文档过大

3. 增加内存：OS cache

4. 使用filter代替query

5. 避免深度分页

6. 使用keyword类型：不分词，integer、long

7. 避免使用脚本

## 深度分页 ##

#### 问题 ####

当`from + size`大于`10000`的时候，就会出现问题

![ccc20ea22f1848b7ace4dfeb71e6ef35.png][]

没有指定排序字段的情况下，默认按照评分score来排序

### scroll search ###

一般情况下要避免进行深度分页，无法避免可以使用[scroll search][] 滚动查询

es7开始，官方不推荐使用滚动查询，因为无法保存索引状态

滚动查询适用于**单个请求中检索大量结果**，不适用与To C端

![417ad7f62d204bd5ab4973bb32a40627.png][]

#### scroll用法 ####

**查询条件加scroll**

GET my-index-000001/_search?scroll=1m
    {
      "size": 100,
      "query": {
        "match": {
          "message": "foo"
        }
      }
    }
    '

scroll的值是时间，例如，上面的查询结果只在1分钟内生效，时间单位越小越好

![b642a7f28cae4fd9a8fc770194c30e2d.png][]

**查询结果会返回scroll\_id，用于下一页查询**

Scroll上下文的存活时间是滚动的，下次执行查询会刷新，也就是说，不需要足够长来处理所有数据，它只需要足够长来处理前一批结果。

保持旧段处于活动状态意味着需要更多的磁盘空间和文件句柄。

为防止因打开过多Scrolls而导致的问题，不允许用户打开超过一定限制的Scrolls。

默认情况下，打开Scrolls的最大数量为 500。此限制可以通过`search.max_open_scroll_context`集群设置进行更新 。

#### 问题 ####

scroll search很消耗资源，不要滥用

### search after ###

[search after][] 是无状态的，推荐使用

需要有固定唯一的排序

#### 用法 ####

查询条件需要有**固定唯一的排序**

查询结果会返回sort，

#### 问题 ####

search afer只能往后查询，不能查询前面的内容

[79ff3141b37642918d047a274730f9e1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/434a0b7fd8e04593aed5aa27b8c6e539.png
[ccc20ea22f1848b7ace4dfeb71e6ef35.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/6a5711f024ad4d22a5c83836b2b56eb0.png
[scroll search]: https://www.elastic.co/guide/en/elasticsearch/reference/7.13/paginate-search-results.html#scroll-search-results
[417ad7f62d204bd5ab4973bb32a40627.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/91e54b52d0c14f02beca55a80f297366.png
[b642a7f28cae4fd9a8fc770194c30e2d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/5014e99a33cc42ed95bdb9acdfd1a2c7.png
[search after]: https://www.elastic.co/guide/en/elasticsearch/reference/7.13/paginate-search-results.html#search-after