北京网站策划服务,网站域名收费,网站制作苏州,电商网站开发设计方法1、背景 集群配置为#xff1a;8 个 node 节点#xff0c;16 核 32G#xff0c;索引 4 分片 1 副本。应用程序的查询逻辑是按经纬度排序后找前 200 条文档。 1、应用对查询要求比较高#xff0c;search 没有慢查询的状态。 2、集群压测性能不能上去#xff0c;cpu 使用未打… 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 爱好者一起精进 比同事抢先一步学习进阶干货
