Elasticsearch嵌套字段场景下运行时查询高延迟性能优化问询

看起来你踩中了Elasticsearch嵌套字段结合运行时字段的典型性能陷阱，我来帮你梳理几个不用动核心架构的优化方向，一步步解决20秒的查询延迟问题：

1. 先给运行时脚本做“瘦身”优化 #

你当前的脚本多次重复访问params['_source']，还有不少冗余逻辑，这些都是拖慢速度的关键，先从脚本本身开刀：

• 用doc API替代params['_source']获取根字段：你的cadenceDaysOut是根级别字段（非嵌套字段），完全可以用doc['cadenceDaysOut'].value来获取——doc直接访问Lucene的文档值存储，比加载整个_source快N倍，后者需要读取全量原始文档内容。
• 减少重复属性访问：把params['_source'].actTypeCadence先存成变量，避免多次重复读取；同时用Groovy的安全导航符?.简化空判断逻辑。
• 提前终止脚本逻辑：当判断到cadenceDaysOut不存在（也就是要输出Unknown的场景），直接emit结果并return，不用执行后面的upcomingCutoff计算逻辑，减少无效运算。

优化后的脚本示例：

long ci = 100;
long co = -999;
// 缓存嵌套字段变量，减少重复读取开销
def actTypeCadences = params._source.actTypeCadence;
if (actTypeCadences?.length > 0) {
    def firstCadence = actTypeCadences[0];
    if (firstCadence.containsKey('cadenceInterval')) {
        ci = firstCadence.cadenceInterval;
    }
}
// 用doc API快速获取根字段值
if (doc.containsKey('cadenceDaysOut')) {
    co = doc['cadenceDaysOut'].value;
} else {
    // 符合Unknown条件，直接输出并终止脚本
    emit('Unknown');
    return;
}

// 后续的upcomingCutoff计算逻辑
long upcomingCutoff = 14;
if (ci == 1) {
    upcomingCutoff = -1;
} else if (ci == 2) {
    upcomingCutoff = 1;
} else if (ci <=7) {
    upcomingCutoff =2;
} else if (ci <=25) {
    upcomingCutoff=5;
} else if (ci <=70) {
    upcomingCutoff = Math.round(0.2 * ci);
}

String status;
if (co >=0) {
    status = 'Past due';
} else if (Math.abs(co) <= upcomingCutoff) {
    status = 'Upcoming';
} else {
    status = 'Unknown';
}
emit(status);

2. 缩小需要执行运行时脚本的文档范围 #

从你的搜索profiler结果来看，瓶颈在cadenceStatus: Unknown的过滤环节——当前逻辑是先给所有符合orgId的文档计算cadenceStatus，再过滤出Unknown的结果，属于“先算后筛”的低效模式。

我们可以反过来先筛后算：提前用bool过滤出cadenceStatus可能为Unknown的文档，再让运行时脚本只处理这部分文档：
Unknown的触发条件是cadenceDaysOut不存在，且嵌套字段actTypeCadence.cadenceInterval不存在，把这个逻辑加到查询的filter里：

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "orgId": 22687 } },
        // 提前过滤出可能是Unknown的文档，大幅减少后续计算量
        {
          "bool": {
            "must": [
              { "bool": { "must_not": { "exists": { "field": "cadenceDaysOut" } } } },
              { "bool": { "must_not": { "exists": { "field": "actTypeCadence.cadenceInterval" } } } }
            ]
          }
        }
      ],
      // ... 其他原有查询逻辑
    }
  }
}

这样一来，需要执行运行时脚本的文档数量会大幅缩减，查询延迟自然会显著下降。

3. 预计算字段并非“ naive”，而是长期最优解 #

你提到的把计算结果存成新的keyword字段，其实是Elasticsearch性能优化的经典方案，完全不算naive——当数据量上去之后，“预计算”永远比“实时计算”性能更优：

• 用Ingest Pipeline处理新增数据：在数据写入/更新时，通过管道脚本提前计算cadenceStatus并写入新字段，比如新增一个precomputed_cadenceStatus的keyword字段。
• 用Update By Query批量处理历史数据：对已有的存量文档，执行一次Update By Query，批量计算并写入这个预计算字段。
• 后续查询直接用预计算字段过滤：完全抛弃运行时脚本，直接用term: { precomputed_cadenceStatus: "Unknown" }过滤，性能拉满。

这个方案的维护成本极低：只需要确保当actTypeCadence或cadenceDaysOut变更时，同步更新预计算字段即可，用业务代码或者Watcher触发都很容易实现。

4. 嵌套字段的额外小优化 #

如果你的业务逻辑只需要actTypeCadence数组的第一个元素（看脚本里只取了actTypeCadence[0]），可以考虑：

• 在数据写入时，单独把第一个嵌套元素的cadenceInterval提取成根级别字段，比如first_cadence_interval，这样运行时脚本可以直接用doc['first_cadence_interval']获取，不用从_source里读取整个嵌套数组。

内容来源于stack exchange