Elasticsearch多索引过滤及与MongoDB协同方案选型咨询

核心思路是职责拆分明确，不让任何组件干它不擅长的事，具体落地逻辑：

• 存储层分工：MongoDB 作为唯一可信数据源，存全量结构化业务数据，负责强一致事务、结构化数据聚合、权限校验这类对数据准确性要求高的操作；Elasticsearch 仅承担全文检索、高并发多维度模糊筛选的职责，不存全量源数据，只存检索必需的字段、关联外键、对应 MongoDB 文档的_id。
• 数据同步：不要做业务双写，直接用 MongoDB Change Stream 监听集合变更，做增量数据同步到 ES；全量初始化时按_id范围分批拉取数据导入，避免一次性拉取1亿条数据打满数据库带宽。
• 查询链路分流：纯结构化查询、无全文检索需求的请求直接走 MongoDB，不经过 ES；带全文检索、模糊匹配需求的请求，先查 ES 拿到匹配的文档 ID 集合，再拿 ID 批量去 MongoDB 做后续关联查询、字段补全，最终返回结果。
• 缓存兜底：高频查询的 ES 命中 ID 集合、Mongo 关联结果统一存入 Redis，设置合理过期时间，降低重复查库的压力。

1亿数据规模下，绝对不能把未收敛的大结果集拉到 Node.js 内存做过滤，原因很直接：

• V8 默认堆内存上限不到2G，单次查询如果命中几十万甚至上百万条结果，拉到内存直接会触发 OOM，导致进程退出。
• JS 是单线程模型，大结果集的遍历、匹配、关联计算会直接阻塞事件循环，整个服务的其他请求都会被卡住，接口延迟会飙升到不可用的程度。
• 数据库原生的查询、关联计算效率比 JS 内存计算高几个数量级，把计算压力扔给应用层属于典型的舍近求远。

只有极小范围的场景可以用内存过滤：ES 查询已经完成分页收敛，单页结果只有几十到上百条的时候，在内存里做少量字段拼装、简单规则过滤完全没问题，不会有性能问题。

ES 本质是搜索引擎，不是关系型数据库，不要硬套关系库的范式建模思路，选型优先级从高到低如下：

• 第一优先级：Denormalizing（反范式化扁平化）
  这是性能最高、最稳定的方案，适合绝大多数搜索场景。如果两个索引关联的字段更新频率极低（比如商品和品牌、文章和作者这类关联信息很少变更的场景），直接把关联表用来做过滤、展示的字段冗余到主检索索引里，查询时单索引直接完成所有过滤，没有任何关联开销，1亿数据规模下只要分片设置合理，查询延迟可以稳定在几十毫秒级。唯一的成本是关联字段变更时，需要批量更新所有冗余了该字段的文档，所以不适合关联字段高频变更的场景。
• 第二优先级：Nested objects（嵌套对象）
  适合关联数据是主文档的附属属性、和主文档是包含关系的场景，比如商品下的SKU、文章下的标签，这类数据不会被其他索引独立引用，本身就是主文档的一部分。嵌套对象在 ES 内部是独立隐藏存储的，查询开销比扁平字段稍高，但远低于其他关联方案，注意更新嵌套字段时需要重建整个主文档，不要用来存储更新过于频繁的关联数据。
• 谨慎选择：Parent-child relationships（父子文档关系）
  仅适合两个关联实体完全独立、更新频率差异极大的场景，比如用户和用户的操作日志——用户基础信息变更频率极低，但操作日志是持续高频写入的，这种场景下用 join 字段做父子关联，可以单独更新子文档，不需要重建父文档。但这个方案的坑非常明显：父子文档必须存储在同一个分片，查询内存开销是扁平结构的5-10倍，延迟高很多，数据量大了之后很容易触发 ES 长时间 GC，性能波动极大，非必要不要选。
• 兜底选择：Application-side joins（应用层关联）
  只适合关联关系极松散、关联查询请求量极低的场景，不值得为了少量请求做数据冗余或者建模调整。落地时先查第一个索引拿到关联外键集合，再用 terms 查询匹配第二个索引的文档，最后在应用层拼装结果，注意第一次查询返回的外键数量不要超过1万条，不然 terms 查询性能会急剧下降，绝对不要把这个方案用在高并发核心查询链路上。

针对你当前的1亿数据规模场景，最稳妥的落地路线是：ES 侧用反范式化冗余所有检索需要的字段，只负责返回匹配的 MongoDB 文档ID，所有结构化关联、数据补全、权限校验全扔给 MongoDB 处理，不要在 ES 里做复杂关联，也不要拉取大结果集到 Node 内存计算，改造成本最低，性能稳定性也最高。

内容的提问来源于stack exchange，提问作者Anonymous Creator