优化百万级文档Full Text Search查询性能，将延迟降至50ms

可以实现，以下是针对你的4-5百万文档场景的具体优化方案：

一、索引配置优化 #

1. 重构精确匹配字段的索引类型 #

当前tenant、status、locale、productIds、id字段使用text类型+keyword分析器，改为keyword专用类型并开启docvalues:true，减少文本处理开销，让过滤操作直接从索引读取数据，避免回源KV存储。示例修改：

"tenant": {
  "enabled": true,
  "dynamic": false,
  "fields": [
    {
      "name": "tenant",
      "type": "keyword",
      "store": false,
      "index": true,
      "include_term_vectors": false,
      "include_in_all": false,
      "docvalues": true
    }
  ]
}

2. 解决ID后缀通配查询的性能问题 #

后缀通配符（*documentId）会触发全索引扫描，新增id_reversed字段存储反转后的ID字符串，索引时用keyword类型配置。查询时将{{searchText}}反转，改用前缀通配符查询（wildcard:"{{reversedSearchText}}*"），利用前缀索引大幅提速。示例ID字段配置：

"id": {
  "enabled": true,
  "dynamic": false,
  "fields": [
    {
      "name": "id",
      "type": "keyword",
      "store": false,
      "index": true,
      "include_term_vectors": false,
      "include_in_all": false,
      "docvalues": true
    },
    {
      "name": "id_reversed",
      "type": "keyword",
      "store": false,
      "index": true,
      "include_term_vectors": false,
      "include_in_all": false,
      "docvalues": true
    }
  ]
}

3. 优化排序字段的索引能力 #

lastUpdateTime已开启docvalues:true，可在索引planParams中调整Scorch索引的排序优化参数，让排序操作直接利用预排序结构，避免实时排序开销。同时确保indexPartitions数量与FTS节点CPU核心数匹配（1个分区对应1个核心），提升并行处理效率。

二、查询语句优化 #

1. 清理无效查询条件 #

移除查询中无意义的"match":"{{searchText}}","field":"prod"条件（索引中无prod字段），避免无效扫描。

2. 合并同字段多值匹配 #

将status字段的两个term查询合并为terms查询，减少解析与执行开销：

{"terms":["Approved","Rejected"],"field":"status"}

3. 调整查询条件执行顺序 #

在conjuncts中优先放置过滤条件（tenant、locale、status、lastUpdateTime范围），让FTS先过滤掉90%以上的无关文档，再执行文本匹配，大幅缩小处理范围。

4. 减少回源开销 #

如果业务无需返回完整文档，在查询中指定返回字段，利用docvalues直接获取数据，避免读取完整文档的IO开销：

"fields":["id","lastUpdateTime"]

5. 优化后的完整查询示例 #

{"query":{"conjuncts":[
  {"term":"abc-123","field":"tenant"},
  {"term":"en","field":"locale"},
  {"terms":["Approved","Rejected"],"field":"status"},
  {"field":"lastUpdateTime","min":1603799414000,"max":1730029814000,"inclusive_min":true,"inclusive_max":true},
  {"disjuncts":[
    {"wildcard":"{{reversedSearchText}}*","field":"id_reversed"},
    {"match_phrase":"{{searchText}}","field":"text"},
    {"match_phrase":"{{searchText}}","field":"summary"}
  ]}
]},"sort":["-lastUpdateTime"],"size":10,"from":0,"fields":["id","lastUpdateTime"]}

三、集群资源与运行时优化 #

• 分配充足CPU与内存：FTS是CPU密集型服务，每个FTS节点核心数需≥索引分区数；内存需满足索引缓存需求（建议为索引磁盘体积的60%以上），确保大部分索引数据常驻内存，减少磁盘IO。
• 启用索引副本：将numReplicas设置为1或2，分散查询负载到主副节点，提升并发能力与容错性。
• 优化Scorch索引缓存：在索引store配置中添加"cacheSize":"20%"（根据内存调整），让高频访问的索引段缓存到内存，加速查询。
• 控制网络延迟：将FTS节点与KV节点部署在同一可用区，避免跨区域网络延迟影响查询速度。

验证与调优 #

优化后通过Couchbase Web Console的FTS监控面板，查看查询延迟、索引扫描数、回源次数等指标，逐步调整分区数、缓存大小等参数，直到延迟稳定在50ms以内。

内容的提问来源于stack exchange，提问作者Mohithraj Kulal