企业官网建设流程全解析

3.7 Elasticsearch-查询性能剖析：profile API、DFS query_then_fetch

3.7.1 profile API 能看什么、不能看什么

profile API 把一次查询在 Coordinator 节点和每个 Shard 上的执行过程拆成可读的“时间线”与“调用树”，粒度到 Lucene 的 Weight→Scorer→BulkScorer→TwoPhaseIterator。返回 JSON 里包含：

• query数组：每个 Shard 的 rewrite、create_weight、build_scorer、next_doc、advance、match 等阶段耗时（单位 ns）
• collector数组：TopScoreDocCollector、TopDocsCollector 的 reduce 时间、收集文档数、提前结束（early_termination）次数
• children嵌套：布尔查询的 should/must/filter 子句各自耗时，可一眼定位“慢子句”
• breakdown明细：底层统计，如set_min_competitive_score调用次数，用于判断是否真的触发了 WAND 优化

不能看的：

1. 网络往返、序列化、GC 停顿——这些在 JVM Stas 里，profile 不采集；
2. 磁盘读 IO、page cache miss——需要借助 iostat、hot_threads、async profiler；
3. fetch 阶段的 _source 解析、字段抽取——profile 只到收集 docID 为止，fetch 另算。

3.7.2 打开 profile 的三种姿势

1. Kibana → Inspect → View profile
2. DSL 加顶层"profile": true
3. 代码（RestHighLevelClient 已废弃，推荐 Java API Client）：

SearchRequestreq=SearchRequest.of(b->b.index("shop").query(q->q.term(t->t.field("brand").value("sony"))).profile(true));SearchResponse<Map>resp=client.search(req,Map.class);resp.profile().shards().forEach(shard->{shard.searches().forEach(s->s.query().forEach(q->{System.out.println(q.type()+" "+q.timeInNanos());}));});

3.7.3 一条慢查询的解剖实战

场景：商品索引 1.2 亿 doc，查询“品牌=sony 且 上架时间≥now-7d”，响应 2.3 s。

profile 片段（已换算 ms）：

"query":[{"type":"BooleanQuery","time":"1934.2ms","breakdown":{"build_scorer":1821ms,"next_doc":78ms,"advance":12ms},"children":[{"type":"TermQuery@brand","time":"41ms"},{"type":"RangeQuery@onShelfTime","time":"1890ms"}]}]

结论：

1. RangeQuery 占 97% 时间，build_scorer 阶段爆炸，说明 Lucene 在倒排链合并时做了巨量 advance；
2. 该字段是毫秒级 long 型，每日新增 2000 万值，倒排链极长；
3. 优化：把 onShelfTime 改成“天”粒度 + 预热 index.sort，把 Range 变成 Keyword 的 TermsQuery 集合，响应降到 120 ms。

3.7.4 DFS query_then_fetch 原理解剖

Elasticsearch 默认使用“Query Then Fetch”（QTF）：

1. Query 阶段：每个 Shard 本地算分，只返回 docID+score 的 TopN；
2. Fetch 阶段：Coordinator 按 score 排序后去对应 Shard 拉取 _source。

问题：当 Shard 之间 TF-IDF 统计差异大时，局部分数不可比，导致“好文档”被提前截断。典型症状：副本数越多、数据越倾斜，同一查询的 Top10 结果在不同副本上不一致。

DFS query_then_fetch（DFS=Distributed Frequency Search）在 Query 前增加一轮“广播收集”：

1. DFS 阶段：各 Shard 把本次查询涉及的所有 Term 的 df、ttf 返回给 Coordinator；
2. Coordinator 合并全局统计，生成统一的 Similarity；
3. 再走标准 QTF，用全局统计重新算分。

代价：两次 RPC，多一轮序列化；若查询包含大量高基数字段，DFS 报文体可能膨胀到几十 MB，Coordinator 节点网络与内存压力骤增。

3.7.5 DFS 的适用边界

推荐打开的场景：

• 索引总分片数 > 50，且每个分片数据量差异 > 3 倍；
• 使用 BM25、LM Dirichlet 等需要全局 df 的相似度算法；
• 对排序一致性要求极高，如法律、金融搜索，不能容忍副本切换导致结果跳动。

不建议打开：

• 日志、监控类场景，只按时间序 + 简单过滤，不用相关性打分；
• 查询本身带“sort”字段，完全不走 score；
• 单个索引分片 < 10 GB，副本数据量均匀，全局 DF 与局部 DF 差异 < 5%。

3.7.6 在 profile 里识别 DFS 开销

profile 返回根节点新增dfs段：

"dfs":{"time_in_nanos":842000000,"statistics":{"term_count":3,"df_fetch_count":15}}

若 DFS 时间占比 > 30% 且 term_count 很小，说明分片之间全局统计差异大，可继续保留 DFS；若 term_count 上千，DFS 时间反而超过 Query 阶段，就应考虑：

• 把高基数字段改成 bool filter，不评分；
• 或者提前用 rollover 把索引按固定维度拆小，降低分片间差异。

3.7.7 小结速查表

• profile 定位“慢子句”→看 build_scorer/advance 时间；
• Range 慢 → 粒度升维、预索引、sort 字段；
• score 不一致 → 看分片大小差异 + 副本切换，再决定 DFS；
• DFS 开销高 → 减 Term 数量或放弃评分；
• 网络/IO 看不到 → 补 hot_threads、iostat、async-profiler。
  更多技术文章见公众号: 大城市小农民