Elasticsearch 运维实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 微盟 Elasticsearch 运维实践
金端 - 组件运维
2023 Weimob Technical Salon
2. 讲师介绍
金端
微盟运维组件专家，Elasticsearch 官方认
证工程师，搜索客社区日报编辑。主要负
责微盟 ES 产品运维工作，保障线上稳定
性。在 ES 运维使用方面具有丰富的实战
经验。对 ES/lucene 搜索分析方向保持学
习和关注。
3. 目
录
01. ES
使用的建议
如何平稳地使用 ES，一些运维 ES 常见的技巧。
02. ES
监控体系
在指标上挖掘隐患，从数据中预判风险。
03. 字段类型选择
ES 查询的核心问题，常踩坑的地方。
04. 日常遇到的问题
微盟在使用 ES 的实战经验。
4. 01.
ES 使用的建议
简介：介绍在使用 Elasticsearch 进行数据搜
索和分析时，应该遵循的一些规范和建议，包
括 ES 架构的选择、查询语句的优化、写入优
化等等，以提高 Elasticsearch 的性能、可靠
性、安全性和可维护性。
5. 整体使用建议
01.
实际
压测性能
合理的资源规划
官方的建议和安全参数
不要超出基础使用的安全参数，比如分片最大 lucene 文档数，
索引字段深度等等。
官方的使用建议，比如避免昂贵查询，分片大小不超过 50GB，
主节点与分片数的配比等等。
具体地址：
https://www.elastic.co/guide/en/elasticsearch/reference/c
urrent/how-to.html
02.
合理设计集群和索引的配置。
做到集群资源（扩缩容）和索引分片数量的动态均衡
资源的规划是立足于节点的配置，而性能的上限往往与分片的规
划设计有关。
03.
每个索引查询和写入都是不一样的，完整的压测是对 ES 生产安
全使用的背书。
6. 微盟的使用规范细则
业务数据必须设置副本，但是不要设置过量的副本，最多 3 个，避免数据量过于膨胀。
主分片数不得设置为 1，最小为数据节点的数量。
查询应避免使用 wildcard /正则/脚本等昂贵查询。
业务数据索引大小不得超过 1TB，单分片不得超过 50GB。做好数据量增长的评估和及
时的索引拆分。
单集群分片数量不超过 30000 或 平均每个数据节点不超过 1000 分片。
选择合理的 routing key 以避免数据倾斜，倾斜度=最小分片文档数/最大分片文档数。
禁止业务数据索引 close 状态。
7. 架构选择
专用主
双活
冷热架构
8. 查询语句优化
9. 查询语句优化
01
02
03
关注耗时 查询类型 结合业务需求
1. 自耗时占比是否过大，
超过 50% 查询类型是否合理，是否存
在 pointrange，multiterm
（这里需要一定 lucene 查
询知识） 查询的业务目的（查询场
景）是什么？是否有替代
方案
2. 最大的自耗时查询
10. 查询语句优化
• constantscore exists 查询耗时过大
• is_delete 的字段类型待修改
11. 查询语句优化
wildcard *
1. 官方建议规避
2. 资源消耗不可控
3. 性能差
范围查询合并
1. 同个字段进行多次范围查询
case：
1<a,a<10
转换成
{"query": {
"bool": {"must": [
{"range": {"a": {"gte": 1}}},
{"range": {"a": {"lte": 10}}}
]
}
}
}
2. ES 解析并不会合并多个条件
12. 写入优化
调优 Bulk 参数
•
•
•
•
减少线程调用
有效利用磁盘io
日志场景尤为合适
具体 size 根据实测效果，需要兼顾写入速度和
内存的使用
Refresh Interval
•
•
设置 refresh interval，尽量不要让客户端主动发
起 refresh 操作
Refresh Interval 设置合理，写入更新较大的情
况下，可以调低 refresh interval 的值。
Index API VS Update API
•
•
•
•
update 允许部分修改
index 是直接覆盖更新的操作
update = get + index
结合具体场景使用，能 index 尽量 index
其他
• 设计好 mapping ，不用于搜索的字段不要进行索
引。
• 更好的硬件，比如 SSD
• 批量操作（比如reindex）的时候，可以禁用副本
来调低写入压力
13. 02.
Elasticsearch 监控体系
简介：介绍如何基于 Prometheus 和 Grafana
搭建一套 Elasticsearch 的监控体系。无侵入
兼容自建 ES 与云 ES，实现微盟整个 ES 监控
体系的落地。
14. 监控架构
• 数据归类，node层关注资源使用，index 层提供业务使用支持
• prometheus 存储数据。利用 prometheus 强大的监控数据分析，提取深层指标
• 完成告警的推送和指标的展示
15. ES 监控的要点
•
1. delete 是标记删除，也是写入的过程
2. update = get + delete + add
3. bulk = indices_indexing_index_total（索引/写入文档总数）
/thread_pool_write_completed（写入线程完成数）
4. query/fetch/index/get 都有耗时统计
•
•
线程的高使用：cpu 使用可能会变高，
资源开始紧张
线程队列的使用：队列相关的操作会有
延迟，资源已经不足
线程的拒绝：ES 服务已经不能保证，
请求无效
16. 去读懂监控数据
图1.数据的更新
怎么去判断
1.持续的写入
2.文档总数和被删除文档总数都在增加
【知识点】：被删除文档总数不计算在文档总数内
图2 图3 routing 倾斜
图2 节点间线程使用不均衡
图3 节点间写入 qps 随之也是不均衡
经过验证，索引存在 routing，造成了资源使用热点
17. 慢查询日志自动分析
18. 慢查询日志自动分析
规则判断
• 针对自耗时进行规则分析
• 针对查询类型进行分析，暴
露风险查询，比如
wildcard
• 分析结果上报治理平台，告
Profile 解析
知研发
• DSL 采样
• 进行 profile 操作，获取慢查询细节
获取 DSL 明细
• 清洗慢日志，提取字段
• 聚合去重 DSL，提高效率
19. 03.
字段类型选择
简介：介绍 Elasticsearch 支持的多种字段类
型，根据查询场景的特点和需求，选择最合适
的类型的原则和建议，包括
keyword/text/wildcard/long 类型等，以及分
词器、查询方式等相关使用方法的影响和调优。
20. 查询场景/查询方法/字段类型
21. 模糊匹配/精确查询/全文检索
22. 关于词元
【词元的产生】
>
• keyword 类型写入和 term-level 查询都是将原文本内容作为词元
• text 类型在写入和 match 查询过程中可以分别设置分词器去产生词
元
• 分词器其实就是产生词元的规则设置
>
>
【查询方式-词元的使用】
• 在倒排索引中不同查询方式遍历词元的范围也不同，这也是查询效
率的主要影响因素
• 范围：模糊查询（wildcard *）>=全文检索（match）>=精确查询
（term）
【分词器设计】
• 设计有效且区分度高的词元
• 贴合业务设计
23. 04.
日常遇到的问题
简介：分享一些在使用 Elasticsearch 过程中
遇到的问题，以及解决或避免的方法和经验，
例如索引迁移，Deleted 文档占比问题，搜索
可见性优化等。
24. 数据reindex操作-原有的问题
增量不同步 操作时间不稳定 占用线上资源
• reindex 读取的还是
源索引的快照，并
不是实时同步。
• reindex 处理全量数
据最好要求源数据
停写 reindex 的影响因素有：
• 集群资源
• 索引大小
• 索引分片数。等等
线上变更的时长也因此
不可控 大索引的 reindex
需要较高的并发，
也就导致了线上明
显的资源占用
25. 数据reindex操作-解决方案
增量处理
前提条件：
1. 一个固定的非线上集群作为专门
数据镜像
同步线上
处理 reindex 的集群
2. 源索引有有效的时间戳
3. 可以进行数据镜像同步
OL 对增量差异的数据进行
reindex补足,新旧索引切换
存量处理
将 reindex 完的新索引镜像同
镜像复制·异
步处理
步至线上集群
在处理集群对存量数据进行 reindex
镜像复制当前的数据到处理集群
记录镜像生成的时间戳
效果和影响：
• 镜像同步的操作有效规避了存量数据在
线上操作的时间
• 增量小范围的数据同步也降低了资源的
占用
• 操作期间 delete 的操作不可复现。
• 建议核心数据有 binlog 或者队列缓冲的，
做增量时间的数据同步。
26. 大索引下Deleted 文档占比问题
默认参数：
merge 策略 deletesPctAllowed 是 33%，即日常索引
中 deleted 文档占比最大能达到 33%
forcemerge 策略 forceMergeDeletesPctAllowed 是
10%，forcemerge 后deleted文档占比能达到最大的
10%
实际效果：
假设一个索引 500GB，则最大有 166GB 的 deleted 文
档占用。这么多的 deleted 文档有损查询的效率，并占
用了集群资源。
• 调整 merge 参数有可能对现有集群产生并发压力。
• forcemerge 则需要专门且较长的操作时间，并且运
行期间对 io 有着明显的压力
27. 大索引Deleted 文档占比问题
• forcemerge 期间文件大小明显膨胀，最大膨胀
30%
• 查询耗时增高，query 和 fetch 阶段平均耗时最大
翻倍。
• 多次合并后形成巨大的 segment，左图的分片为
60GB 左右，而最大的 segment 就有 54GB。
28. Deleted 文档占比问题-merge策
略优化
具体实现条件如下：
主动对每个 segment 进行检查
• 该 segment 的 deleted 文档占比是否大
于 forceMergeDeletesPctAllowed
（10%）
• 该 segment 的大小是否大于
large_merge_floor_segment_bytes
• 本次任务与上次任务时间差是否达到
large_merge_idle_time
以上条件均达到后，对该 segment 发起单
独的 forcemerge
调整参数：
"index.merge.policy.large_merge_enabled" : "true", #是否开启该策略
"index.merge.policy.large_merge_floor_segment_bytes" : "200mb", #segment 大小阈值
"index.merge.policy.large_merge_idle_time" : "10m" #策略间隔时间
29. 搜索可见性的问题
业务反馈
• 数据更新后不可见； • 数据写入 translog 后就反馈写入成功
• refresh 设置为 500ms； • 数据可被搜索需要被 refresh 进入 segment
• 探测发现需要接近10s才能获取更新 因此数据可被搜索的延迟=写入耗时 +refresh 耗时
后的值
此时这个索引的 refresh 操作的平均耗时相加接近 10s
30. 搜索可见性的问题-原因分析
数据更新操作 deleted文档占比 soft delete属性
纯更新操作会导
致明显的
refresh 高耗时 降低索引中 deleted
文档的占比也能降低
refresh 的高耗时 soft delete 属性用
于分片间数据同步
和恢复。
关闭该属性能有效
降低 refresh 耗时
31. THANK YOU
谢谢你的观看
金端 - 运维组件专家
2023 Weimob Technical Salon