MongoDB中引用超16MB时，多对多关系的最优建模方案

原数据结构 #

现有两个核心集合：

• files集合的文件文档：

_id: file1
fileGroups: ["group1"]

• file_groups集合的文件组文档：

_id: group1

该结构能高效查询特定文件组下的所有文件，但无法满足新业务需求。

新需求 #

允许同一文件多次加入同一文件组，且支持文件组内文件的手动排序。

已尝试方案及缺陷 #

方案1：文件组反向存储文件ID #

修改file_groups集合，直接存储文件ID数组：

_id: group1
files: ["file1"]

缺陷：受限于MongoDB单文档16MB的大小限制，若文件ID为16字节，单文件组最多仅能存储约100万个文件，无法支撑1000万到1亿的规模。

方案2：文件中存储单一排序值 #

在files集合中添加排序字段：

_id: file1
fileGroups: ["group1"]
manualSorting:
    group1: 1

缺陷：无法支持同一文件多次加入同一组；调整排序位置时，可能需要更新数百万文档，性能极差。

方案3：文件中存储多排序值数组 #

将同一组的多个排序值存入数组：

_id: file1
fileGroups: ["group1"]
manualSorting:
    group1: [1, 10]

缺陷：无法高效执行排序查询，查询逻辑复杂且性能低下。

方案4：复制文件文档 #

通过复制文件生成不同ID来实现多实例，缺陷：数据冗余严重，维护成本极高，完全不可行。

方案5：创建关联集合 #

考虑建立单独的关联集合存储文件与文件组的关系及排序信息，但担心违背NoSQL设计理念。

推荐解决方案：使用关联集合（中间表） #

这其实是MongoDB处理多对多且需附加属性（如排序）场景的标准方案，并不违背NoSQL设计理念——NoSQL并非完全排斥关系型设计，而是强调根据查询模式优化数据模型。

创建一个file_group_memberships集合，每个文档代表文件在文件组中的一个实例，包含以下字段：

_id: ObjectId("...")
fileId: "file1"          # 关联files集合的_id
groupId: "group1"        # 关联file_groups集合的_id
sortOrder: 5             # 该实例在文件组中的排序值
# 可附加其他属性，如添加时间、备注等

优势分析 #

1. 支持多实例：同一文件可在同一组中存在多个文档，每个文档对应一个独立实例，完美满足需求。
2. 无存储上限：每个关联关系是独立文档，不受单文档大小限制，轻松支撑千万到亿级规模。
3. 高效排序与查询：
   • 查询某文件组的所有文件（带排序）：

     db.file_group_memberships.find({ groupId: "group1" })
                               .sort({ sortOrder: 1 })
     

     若使用Mongoose等ODM，可直接通过关联查询获取文件详情。
   • 调整排序位置：仅需更新对应文档的sortOrder字段，无需批量更新大量文件文档。
4. 灵活扩展：可随时添加其他关联属性（如实例创建时间、操作人等），扩展性强。

索引优化 #

为保证查询性能，需创建以下复合索引：

• { groupId: 1, sortOrder: 1 }：优化文件组内的排序查询
• { fileId: 1, groupId: 1 }：快速查询某文件所属的所有组实例

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