1、背景
集群配置为：8 个 node 节点，16 核 32G，索引 4 分片 1 副本。应用程序的查询逻辑是按经纬度排序后找前 200 条文档。
1、应用对查询要求比较高，search 没有慢查询的状态。
2、集群压测性能不能上去，cpu 使用未打满，查询的 qps 上不去，且有队列堆积。
2、优化方法
通过云厂商内核组的同学抓取火焰图发现，主要消耗在 fetch phrase 阶段。
ES 默认从_source 取，每次查询都会读取一行数据，并需要做解压，如果对查询耗时要求比较高，应当在查询时关闭 store fields ，查询语句 指定“stored_fields”: [“none”], 砍掉元数据字段，同时用 “docvalue_fields”: [“video_fact_id”], 指定只拉取需要的字段，降低序列化跟网络传输开销。约能提升40% 性能。
推荐DSL如下：
GET /your_index/_search
{
"query": {
"match_all": {} // 或者是其他符合你需求的查询
},
"stored_fields": ["none"], // 不获取任何存储的字段
"docvalue_fields": ["field1", "field2"] // 只获取需要的doc value字段
}3、优化后效率
3.1 查询耗时有进一步的提升
3.2 压测时cpu使用率和qps也有了明显的上升
压测最终的指标：优化前1800qps，优化后9200qps。
4、优化根因分析
在优化前，由于Elasticsearch默认从_source字段读取数据，这导致每次查询都需要读取整行数据并进行解压。这个过程不仅耗费CPU资源，还会增加响应时间，特别是当文档内容庞大时。
解压操作是CPU密集型的，而在高负载情况下，这可能成为系统瓶颈，从而限制了查询性能和吞吐量。
优化后，通过指定“stored_fields": ["none"]，我们有效地排除了_source字段的读取和解压过程，这显著减少了每个查询的CPU负载。
而使用“docvalue_fields”指定从列存中获取字段内容，没有压缩的转换，进一步减少了数据处理的开销。这种方法不仅降低了CPU的使用率，同时只提取必要的字段也减少了了网络传输的负担。
最终，通过这些优化措施，查询的QPS（每秒查询数）得到了显著提升，从1800qps提高到9200qps，这在高性能应用场景中是一个巨大的飞跃。
更高的QPS意味着系统能够更快地处理更多的查询请求，提高了整体的吞吐量和性能。
5、小结
总结来说，通过精细地调整查询策略和减少不必要的数据处理，我们可以显著提升Elasticsearch的性能，这在处理大规模数据和高并发查询的环境下尤为重要。
6、官方文档
https://www.elastic.co/guide/en/elasticsearch/reference/8.4/search-fields.html#disable-stored-fields
https://www.elastic.co/guide/en/elasticsearch/reference/8.4/search-fields.html#docvalue-fields
5、作者介绍
金多安，Elastic 认证专家，Elastic资深运维工程师，死磕Elasticsearch知识星球嘉宾，星球Top活跃技术专家，搜索客社区日报责任编辑
推荐阅读
全网首发！从 0 到 1 Elasticsearch 8.X 通关视频
重磅 | 死磕 Elasticsearch 8.X 方法论认知清单
如何系统的学习 Elasticsearch ？
2023，做点事
更短时间更快习得更多干货！
和全球 近2000+ Elastic 爱好者一起精进！
比同事抢先一步学习进阶干货！
