房产多租户SaaS：跨MongoDB租户库高效查询分页最优方案

问题背景 #

我正在构建面向房产中介的多租户SaaS，采用每个租户独立MongoDB数据库的架构，主数据库存储租户元数据（如数据库名称、状态）。每个租户数据库内有结构统一的properties集合，示例文档如下：

{ 
   "_id": ObjectId,
   "createdAt": ISODate,
   "forSale": boolean,
   "forRental": boolean,
   // 其他业务字段
}

需要实现一个无需认证的公开页面，展示所有活跃租户中forSale=true或forRental=true的房产，页面需支持：

• 排序（默认按createdAt降序）
• 包含总数、偏移量、限制的分页

补充条件：租户列表变化频率极低（每周/每月更新一次），但需动态获取主库中状态为active的租户。

现有方案分析 #

我已评估三种初步方案，各有局限：

• 后端循环查询：逐个查询租户数据库，在内存中合并结果后进行排序、分页 → 租户数量增长到数十/数百个时，内存消耗和响应时间会急剧上升，扩展性差。
• 数据库端跨库联合视图：希望在主库创建聚合所有租户properties集合的视图，利用MongoDB原生的统计、排序等特性 → 但不确定能否在聚合中动态引用租户数据库列表。
• 主库汇总集合：维护public_properties集合，仅存储分页/排序所需字段及租户库、文档ID的引用，在房产增删改（且forSale/forRental为true时）通过API更新 → 可行，但担心数据一致性和额外维护复杂度。

核心问题 #

当租户数量增长至数十/数百个时，实现该跨租户查询、分页与排序的最健壮且可扩展的方式是什么？是否有适配此场景的MongoDB特性或模式（如跨库$unionWith、变更流填充汇总集合）？

最优方案推荐 #

结合场景特性（租户数量数百级、租户列表更新低频、需原生MongoDB查询能力），推荐**「基于变更流的主库汇总集合」**方案，搭配租户列表缓存优化，这是兼顾一致性、性能和扩展性的最优选择，具体实现细节如下：

1. 用MongoDB变更流保障汇总集合一致性 #

放弃API手动更新的方式，改用MongoDB**变更流（Change Streams）**自动同步符合条件的房产数据到主库public_properties集合：

• 对每个租户的properties集合开启变更流，监听insert/update/delete事件
• 过滤规则：仅处理forSale=true或forRental=true的文档；更新操作需判断前后状态变化，触发新增/移除逻辑
• 同步逻辑：
  • 新增/更新后符合条件的文档：将createdAt、forSale、forRental、租户数据库名、原文档_id等必要字段写入public_properties
  • 删除或更新后不符合条件的文档：从public_properties中移除对应记录
• 优势：无需业务代码介入同步，由MongoDB原生保障数据一致性，避免API更新遗漏或延迟问题

2. 租户列表的缓存优化 #

由于租户列表更新频率极低，可在后端用Redis等缓存层缓存活跃租户列表（缓存时效设为12-24小时），无需每次查询都访问主库。当主库租户状态变更时，主动更新缓存即可，既减少主库压力，又保证租户列表的动态性。

3. 汇总集合的查询优化 #

在public_properties集合上创建针对性索引：

• 复合索引：{ createdAt: -1, forSale: 1, forRental: 1 }，覆盖默认排序和过滤条件
• 确保分页查询能利用索引，避免全表扫描

分页查询直接在public_properties上执行，利用MongoDB原生的skip()/limit()获取分页数据，用countDocuments()获取总数，性能和单集合查询一致，扩展性极强。

备选方案：跨库$unionWith（适用于租户数量较少场景） #

如果租户数量在50个以内，也可以考虑用$unionWith结合动态生成聚合管道的方式：

• 从主库获取活跃租户列表，动态生成包含所有租户properties集合的$unionWith阶段
• 示例聚合管道：

[
  { $match: { $or: [{ forSale: true }, { forRental: true }] } },
  { $unionWith: { db: "tenant_db_1", coll: "properties", pipeline: [{ $match: { $or: [{ forSale: true }, { forRental: true }] } }] } },
  { $unionWith: { db: "tenant_db_2", coll: "properties", pipeline: [{ $match: { $or: [{ forSale: true }, { forRental: true }] } }] } },
  // 其他租户的$unionWith阶段
  { $sort: { createdAt: -1 } },
  { $skip: offset },
  { $limit: limit }
]

• 局限：租户数量过多时，聚合管道会非常庞大，MongoDB执行效率下降，且无法高效获取总数量（需额外统计每个租户符合条件的文档数再求和），仅适合租户数量较少的场景。

方案对比总结 #

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