Elasticsearch 54M记录索引KNN搜索耗时超100秒问题排查求助

• 近似KNN（a-knn）超时原因：你使用的带前置过滤的原生a-knn逻辑为先全量检索向量索引的Top K结果，再匹配过滤条件，54M的全量向量检索本身开销极大，再叠加过滤匹配的计算，最终导致请求超时超过60s。
• script_score方案延迟陡增原因：该方案逻辑为先执行前置过滤拿到匹配文档集，再对所有匹配文档的向量做暴力相似度计算，2km半径匹配5万条数据时，64维余弦相似度的暴力计算开销还在可承受范围内，当半径提升到2.5km匹配量翻倍到10万条时，计算量、向量字段读取IO开销同步翻倍，直接导致延迟暴涨。

索引侧优化 #

• 调整分片配置：当前10个分片对应54M数据，单分片向量规模达到5.4M，建议拆分到20~30个分片，将单分片向量规模控制在2M以内，降低单分片的搜索计算开销。
• 新增路由规则：利用已有的cityId字段作为索引路由键，查询时指定对应城市的路由值，直接过滤掉其他城市的所有数据，大幅缩小前置过滤的匹配量级。
• 优化向量索引参数：给knn_vector字段增加HNSW索引配置"ef_construction": 128, "m": 16，平衡索引构建和查询性能；调整集群knn.memory.circuit_breaker.limit参数到集群可用内存的50%，避免向量索引频繁换页产生磁盘IO。
• 关闭冗余配置：将auto_expand_replicas调整为固定1~2个副本，避免过多副本占用内存资源。

查询侧优化 #

• 切换为预过滤a-knn方案：如果集群版本为OpenSearch 2.4及以上，直接使用官方支持的带前置过滤的近似KNN查询，逻辑为先执行过滤拿到候选集，再在候选集上做近似KNN检索，相比暴力计算的script_score方案性能可提升10倍以上。
• 限制过滤最大匹配数：在bool查询中增加"max_docs": 80000配置，强制前置过滤最多返回8万条结果，避免匹配量过大导致暴力计算超时。
• 优化相似度计算逻辑：提前对向量做归一化处理，将余弦相似度计算替换为内积计算，降低CPU计算开销。

集群资源优化 #

• 优先选择内存占比高的节点类型（如AWS r6g系列），确保集群可用内存至少可以容纳全量向量索引的30%以上，减少磁盘IO开销。
• 查询时指定preference: _local参数，优先读取本地节点的副本数据，减少跨节点数据传输开销。

内容的提问来源于stack exchange，提问作者Raghunandan J