Elasticsearch跨异构索引关联查询与过滤方案咨询

方案1：预合并索引（大数据量场景首选，性能最优） #

• 核心逻辑：放弃查询时做关联，在数据写入环节完成文档拼接。通过消费双写流量、CDC同步等方式，拿到matching_pair_key后将两个索引的对应字段合并写入一个新的宽表索引，后续所有过滤、查询、统计直接操作该宽表索引即可。
• 优势：完全复用ES原生查询能力，不存在跨索引关联的性能损耗，支持任意字段过滤、分页、排序，不会出现缺字段被误过滤的问题，千万级以上数据量下查询耗时可以稳定在毫秒级。
• 落地注意点：需要处理双索引写入时序差问题，可设置短暂等待窗口，等同一matching_pair_key的两份文档都到齐后再写入宽表，加超时兜底逻辑处理单边缺失的异常数据。

方案2：改造现有聚合方案（临时查询/低QPS场景可用） #

你之前的聚合逻辑问题根源是：把跨索引的过滤条件写在了最外层query上下文，ES执行时会直接把不包含过滤字段的文档（比如所有index_b的文档都没有status_code字段）全部排除在结果集外，根本无法进入分桶完成配对。
调整思路是把过滤逻辑下沉到子聚合内部，保证两个索引的文档都能进入分桶，再单独对每个索引的文档做条件过滤，最后通过桶选择器筛掉无效配对，参考DSL如下：

{
  "size": 0,
  "query": {
    "match_all": {}
  },
  "aggs": {
    "joined_docs": {
      "terms": {
        "field": "matching_pair_key.keyword",
        "size": 10000
      },
      "aggs": {
        "index_a_filtered": {
          "filter": {
            "term": {
              "status_code": 2
            }
          },
          "aggs": {
            "a_hits": {
              "top_hits": {
                "_source": ["matching_pair_key", "status_code"],
                "size": 10
              }
            }
          }
        },
        "index_b_all": {
          "filter": {
            "exists": {
              "field": "age"
            }
          },
          "aggs": {
            "b_hits": {
              "top_hits": {
                "_source": ["age"],
                "size": 10
              }
            }
          }
        },
        "valid_pair_filter": {
          "bucket_selector": {
            "buckets_path": {
              "aCount": "index_a_filtered>_count",
              "bCount": "index_b_all>_count"
            },
            "script": "params.aCount > 0 && params.bCount > 0"
          }
        }
      }
    }
  }
}

• 返回结果中每个桶下会分别返回index_a符合条件的文档、index_b的匹配文档，业务层做简单字段拼接就能得到你要的完整文档结构。
• 大数据量查询时不要把terms聚合的size设置过大，单批次拉取超过1万条建议使用partition参数分片拉取，避免ES节点内存溢出。
• 如果过滤条件同时涉及两个索引的字段，分别在index_a_filtered和index_b_all的filter中添加对应条件即可，同步调整桶选择器的判断规则。

方案3：ES原生关联能力（不推荐大数据量场景使用） #

• 7.17及以上版本ES支持enrich索引、lookup运行时字段做查询时字段关联，但这类能力在数据量级超过百万后性能衰减明显，远低于预合并索引、甚至低于改造后的聚合方案，仅适合极小数据量的临时查询场景。
• 不建议使用父子文档、nested嵌套类型实现，这类能力要求文档存储在同一索引下，跨索引场景改造成本高，查询性能也无优势。

选型建议：如果是长期运行的业务场景，优先选预合并宽表索引方案，长期维护成本、查询性能都是最优解；聚合方案仅适合临时取数、低QPS的内部查询场景使用。

内容的提问来源于stack exchange，提问作者Bruno Gehlen