1、问题背景：
数据写入后，refresh耗时过长，能达到1s-5s。
想通过测试，探索确认影响refresh的因素，比如：写入操作是新增还是更新，deleted文档占比是否有影响，是否有其他索引配置，等等。
2、测试过程全记录
旧索引：24主分片，1副本，经过长期forcemerge，最大segmeng 33gb，镜像后deleted占比 8%左右。
noforcemerge 索引：24主分片，1副本，reindex后最大segmeng 5gb，deleted占比0%。
nosoftedelete 索引：关闭softdelete策略，24主分片，0副本，reindex后最大segmeng 5gb，deleted占比0%。
| 旧索引更新 | 旧索引新增 | 旧索引forcemerge后新增(带少量更新) | noforcemerge索引更新 | 旧索引低更新 | noforcemerge索引低更新 | nosoftedelete索引更新 | |
|---|---|---|---|---|---|---|---|
| 时间段 | 2023-10-12 21:30:00至2023-10-13 15:00:00 | 2023-10-13 15:55:00至2023-10-13 16:10:00 | 2023-10-13 20:40:00至2023-10-13 22:00:00 | 2023-10-16 10:40:00至2023-10-17 11:00:00 | 2023-10-17 16:20:00至2023-10-17 17:15:00 | 2023-10-17 17:20:00至2023-10-17 18:30:00 | 2023-10-19 11:00:00至今 |
| 写入速度 | 2k/s | 2k/s | 2k/s | 2k/s | 2k/s | 2k/s | 2k/s |
| deleted占比增长 | 最大 32%，最小 8% | 22%左右 | 0%-2% | 0%-9% | 1.5%-2% | 7%-6% | 0%-8% |
| refresh耗时 | 最大12s，最低3s | 200ms-400ms | 300ms-800ms | 1s-3s | 50ms-250ms | 500ms-1.5s | 200ms-300ms |
| refresh_external耗时 | 最大12s，最低3s | 200ms-400ms | 300ms-800ms | 1s-3s | 50ms-250ms | 500ms-1.5s | 基本无 |
| cpu使用 | 50%-100% | 50%-100% | 50%-100% | 50%-100% | 30%-60% | 30%-60% | 10%-40%（查询条件优化） |
3、查询测试
| 旧索引查询 | noforcemerge索引查询 |
|---|---|
| 时间段 | 10-17 15:06:00 - 10-17 15:42:00 |
| 查询qps | 100/s |
| 查询耗时 | 平均45ms左右 |
| cpu使用 | 10%-30% |
4、观测到的现象
1. 纯更新操作会导致明显的 refresh 高耗时。
2. 降低索引中 deleted文档的占比也能降低refresh的高耗时。
3. noforcemerge 索引的更新测试中，通过es热线程的抓取，refresh 的出现降低了（但依旧是100%），merge线程出现增多了不少。
4. soft delete 关闭的索引，refresh 耗时明显下降了，并且与 deleted 文档占比明显无关联。
5、测试初步结论
5.1 结论1. large segment 策略对索引日常使用无明显变化。
large segment 策略的修改对索引日常的查询和写入没有额外的资源占用。
同时也达到了预期自动清理deleted文档的效果。
5.2 结论2. refresh 影响因素。
1.soft delete：soft delete模式是否开始直接影响refresh的耗时。关闭soft delete可降低refresh耗时，但不推荐。
2.写入操作类型：开启 soft delete后，数据更新操作会明显增加 refresh耗时，而单纯的新增数据则没有太多的refresh耗时。
3.deleted 占比：deleted 文档占比越高，refresh耗时越大。
6、扩展：关于soft delete
6.1 soft delete 用途
用于分片间数据同步和恢复，属于 ES 分布式基础实现。
具体内容详见：
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/index-modules-history-retention.html
soft delete详解：默认为开启，只能在索引创建时设定，不可通过开关索引操作修改。官方后期准备把这个参数去掉，这也是不建议修改soft_delete参数的一个原因。
6.2 soft delete对 refresh 的影响
在测试过程以及社区文档中，均发现了soft_delete索引下 update 操作增加了refresh耗时的现象。
https://mp.weixin.qq.com/s/_l8JAtqK_NOSP8b7OqSVDg
作者介绍
金多安，Elastic 认证专家，Elastic资深运维工程师，死磕Elasticsearch知识星球嘉宾，星球Top活跃技术专家，搜索客社区日报责任编辑
铭毅天下审稿并做了部分微调。
推荐阅读
全网首发！从 0 到 1 Elasticsearch 8.X 通关视频
重磅 | 死磕 Elasticsearch 8.X 方法论认知清单
如何系统的学习 Elasticsearch ？
2023，做点事
更短时间更快习得更多干货！
和全球 近2000+ Elastic 爱好者一起精进！
比同事抢先一步学习进阶干货！
![[MySQL binlog实战] 增量同步与数据搜索～从入门到精通](https://img-blog.csdnimg.cn/img_convert/aaf6b932169e50ac55f53acb28b55be0.png)
