Mongoose一对多关系最佳建模方案：粉丝关注场景如何应对超大粉丝量

当前数组存储方案的瓶颈 #

你现在使用的数组存储方案仅适合小量级的粉丝场景，面对10亿级粉丝量完全不可行，核心问题如下：

• 硬限制：MongoDB单文档最大容量为16MB，按每个ObjectId占12字节计算，单文档的followers数组最多只能存储约130万条用户ID，远达不到10亿级的存储需求。
• 性能问题：随着数组元素增长，push操作、粉丝列表查询、重复关注校验的开销会线性上升，同时数组索引的维护成本也会急剧升高，多用户同时关注同一个头部账号的场景下，极易出现写冲突。
• 功能限制：如果后续需要扩展关注时间查询、粉丝排序、粉丝标签筛选等功能，数组方案基本无法支持。

10亿级量级的推荐建模方案 #

推荐采用独立关注关系集合的建模方式，完全规避单文档大小限制，扩展性最高：

示例Schema定义 #

const mongoose = require("mongoose");

const FollowSchema = new mongoose.Schema({
  // 关注者ID
  followerId: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  // 被关注者ID
  followeeId: { type: mongoose.Schema.Types.ObjectId, ref: 'User', required: true },
  // 关注时间
  createdAt: { type: Date, default: Date.now }
})

// 建立联合唯一索引，避免重复关注，同时提升关联查询性能
FollowSchema.index({ followerId: 1, followeeId: 1 }, { unique: true })
// 分别建立排序索引，适配「查询某人的关注列表」「查询某人的粉丝列表」分页场景
FollowSchema.index({ followerId: 1, createdAt: -1 })
FollowSchema.index({ followeeId: 1, createdAt: -1 })

const Follow = mongoose.model('Follow', FollowSchema)

关注操作示例 #

// 新增关注关系，自带重复关注校验
await Follow.create({
  followerId: 登录用户ID,
  followeeId: 被关注用户ID
})

超大量级可选优化 #

如果单用户粉丝量超过千万级，可以在此基础上加分桶逻辑，将单个用户的粉丝按每1万/10万条拆分到不同的桶文档中，进一步提升分页查询性能。

方案选型建议 #

• 如果产品用户规模较小，单用户最大粉丝量不超过100万，且无复杂的粉丝管理需求，原有数组方案可以继续使用，开发成本更低
• 如果预期存在百万粉以上的头部用户，必须采用独立关系集合的方案，支持水平扩展

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