企业官网建设流程全解析

南京市住房和城乡建设网站,cn wordpress,下载安装微信,作风建设年活动网站3.7 Elasticsearch-查询性能剖析#xff1a;profile API、DFS query_then_fetch 3.7.1 profile API 能看什么、不能看什么 profile API 把一次查询在 Coordinator 节点和每个 Shard 上的执行过程拆成可读的“时间线”与“调用树”#xff0c;粒度到 Lucene 的 Weight→Scorer…3.7 Elasticsearch-查询性能剖析profile API、DFS query_then_fetch3.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 等阶段耗时单位 nscollector数组TopScoreDocCollector、TopDocsCollector 的 reduce 时间、收集文档数、提前结束early_termination次数children嵌套布尔查询的 should/must/filter 子句各自耗时可一眼定位“慢子句”breakdown明细底层统计如set_min_competitive_score调用次数用于判断是否真的触发了 WAND 优化不能看的网络往返、序列化、GC 停顿——这些在 JVM Stas 里profile 不采集磁盘读 IO、page cache miss——需要借助 iostat、hot_threads、async profilerfetch 阶段的 _source 解析、字段抽取——profile 只到收集 docID 为止fetch 另算。3.7.2 打开 profile 的三种姿势Kibana → Inspect → View profileDSL 加顶层profile: true代码RestHighLevelClient 已废弃推荐 Java API ClientSearchRequestreqSearchRequest.of(b-b.index(shop).query(q-q.term(t-t.field(brand).value(sony))).profile(true));SearchResponseMaprespclient.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 片段已换算 msquery:[{type:BooleanQuery,time:1934.2ms,breakdown:{build_scorer:1821ms,next_doc:78ms,advance:12ms},children:[{type:TermQuerybrand,time:41ms},{type:RangeQueryonShelfTime,time:1890ms}]}]结论RangeQuery 占 97% 时间build_scorer 阶段爆炸说明 Lucene 在倒排链合并时做了巨量 advance该字段是毫秒级 long 型每日新增 2000 万值倒排链极长优化把 onShelfTime 改成“天”粒度 预热 index.sort把 Range 变成 Keyword 的 TermsQuery 集合响应降到 120 ms。3.7.4 DFS query_then_fetch 原理解剖Elasticsearch 默认使用“Query Then Fetch”QTFQuery 阶段每个 Shard 本地算分只返回 docIDscore 的 TopNFetch 阶段Coordinator 按 score 排序后去对应 Shard 拉取 _source。问题当 Shard 之间 TF-IDF 统计差异大时局部分数不可比导致“好文档”被提前截断。典型症状副本数越多、数据越倾斜同一查询的 Top10 结果在不同副本上不一致。DFS query_then_fetchDFSDistributed Frequency Search在 Query 前增加一轮“广播收集”DFS 阶段各 Shard 把本次查询涉及的所有 Term 的 df、ttf 返回给 CoordinatorCoordinator 合并全局统计生成统一的 Similarity再走标准 QTF用全局统计重新算分。代价两次 RPC多一轮序列化若查询包含大量高基数字段DFS 报文体可能膨胀到几十 MBCoordinator 节点网络与内存压力骤增。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 不一致 → 看分片大小差异 副本切换再决定 DFSDFS 开销高 → 减 Term 数量或放弃评分网络/IO 看不到 → 补 hot_threads、iostat、async-profiler。更多技术文章见公众号: 大城市小农民