Elasticsearch是否支持单文档内部的聚合计算？

这个需求完全可实现，ES的能力不局限于跨文档聚合，单文档内部的字段计算有非常成熟的落地方案，结合你的场景具体方案如下：

前置提醒：你当前定义的items普通对象数组在ES中会被自动做扁平化处理，最终存储为items.itemName: [名称1, 名称2...]、items.itemRating: [评分1, 评分2...]两组独立的多值字段，不会保留单个item下itemName和itemRating的绑定关系。如果后续不需要针对单个item做过滤、聚合，这个结构完全不影响你当前的评分计算需求；如果需要保留item内部字段的关联，需要把items字段显式设置为nested类型。

1. 写入阶段预计算（优先推荐） #

这是性能最好、维护成本最低的方案：

• 在文档写入ES前，直接在业务层计算好整合后的平均评分，作为独立字段（比如compositeAvgRating）存入文档，查询时直接读取该字段即可，不需要运行时做任何额外计算。
• 计算逻辑完全可控：可以自动过滤掉未配置itemRating的商品，再结合seller的overallRating做平均值计算。举个例子：某seller的overallRating为4，名下有3个带评分的商品，评分分别为5、3、4，那么最终平均分就是(4+5+3+4)/(1+3) = 4，直接把结果写入compositeAvgRating即可。
• 优势：不管是做查询返回、排序、过滤还是跨文档聚合，都没有额外性能开销，也不会踩ES数组类型的兼容坑，完全匹配你单文档最多关联50个商品、计算逻辑固定的场景。

2. 查询时用脚本字段实时计算（适合无法修改写入流程的场景） #

如果暂时不方便调整写入逻辑，可以在查询时通过Painless脚本读取单文档内的字段，实时计算平均评分，直接随查询结果返回。
如果保持你当前的非nested普通对象数组结构，可以直接用doc_values读取字段计算，性能更好，示例代码如下：

GET 你的索引名/_search
{
  "script_fields": {
    "compositeAvgRating": {
      "script": {
        "lang": "painless",
        "source": """
          // 读取seller总评分，处理空值
          def overallScore = 0;
          def validCount = 0;
          if (doc['overallRating'].size() > 0) {
            overallScore = doc['overallRating'].value;
            validCount = 1;
          }
          // 累加所有有效商品评分
          for (def itemScore : doc['items.itemRating']) {
            overallScore += itemScore;
            validCount += 1;
          }
          // 避免无有效评分时除零
          return validCount > 0 ? overallScore / validCount : null;
        """
      }
    }
  }
}

如果你后续把items调整为nested类型，需要从_source读取字段做计算，示例如下：

GET 你的索引名/_search
{
  "script_fields": {
    "compositeAvgRating": {
      "script": {
        "lang": "painless",
        "source": """
          def overallScore = 0;
          def validCount = 0;
          // 读取seller总评分
          if (params._source['overallRating'] != null) {
            overallScore = params._source['overallRating'];
            validCount = 1;
          }
          // 遍历商品过滤无评分项，累加有效评分
          for (def item : params._source['items']) {
            if (item != null && item['itemRating'] != null) {
              overallScore += item['itemRating'];
              validCount += 1;
            }
          }
          return validCount > 0 ? overallScore / validCount : null;
        """
      }
    }
  }
}

这个方案的唯一缺点是脚本运行会带来少量性能开销，但你单文档最多50个商品的量级，开销完全在可接受范围内；如果需要基于这个计算结果做排序、过滤，性能会比预计算字段差一些。

3. 嵌套聚合回卷计算（适合有复杂嵌套统计需求的场景） #

如果你后续需要同时做大量商品维度的统计，可以把items设置为nested类型后，通过聚合框架实现单文档维度的计算：

• 先按文档_id做terms聚合，给每个seller文档单独分桶
• 每个seller桶内通过top_hits聚合取出该seller的overallRating
• 下钻做nested聚合到items层，统计所有有效itemRating的总和、计数
• 最后通过bucket_script管道聚合，把两部分评分合并计算平均值
  这个方案写法繁琐、性能也弱于前两个，除非你有复杂的嵌套统计需求，否则不优先选择。

• 日常业务场景优先选写入预计算方案，一劳永逸，适配所有后续查询需求
• 临时需求、无法调整写入逻辑时，直接用脚本实时计算即可，你的数据规模不会有性能问题
• 只有存在大量嵌套维度统计需求时，再考虑用nested聚合的方案

内容的提问来源于stack exchange，提问作者Catherine S.