MongoDB建模需分层设计：videos集合嵌套静态元数据，高频更新字段、弹幕、用户进度须分离；分片键优选video_id哈希以均衡写入；用户行为按天分桶存储；封面与播放地址仅存标识符。

设计视频点播系统的MongoDB模型，最忌讳的就是“一个集合包打天下”。核心挑战其实很明确：视频的元数据（比如标题、标签）需要被高频读取，视频文件本身又不会存进数据库，而用户行为数据（像观看进度、弹幕）还得能和视频快速关联上。嵌套文档和分片策略确实是利器，但用错了地方，反而会成为性能的拖累。

用 videos 集合嵌套基础元数据，但别塞太多

像标题、简介、分类、标签、审核状态、封面图URL、时长、分辨率列表这些静态信息，它们通常总是一起被查询，完全可以嵌套在videos文档里。这样一来，一次简单的find()操作就能拿到详情页需要的所有信息，省去了多次查表或者$lookup关联的麻烦。

但是，下面这几类数据，**坚决不能往里塞**：

• play_count、like_count等高频更新字段——频繁更新会导致文档大小变化，甚至触发数据迁移，影响性能。更优解是使用独立的计数集合，配合原子操作来更新。
• 完整的弹幕列表——单条视频的弹幕量动辄上万，全部嵌套很容易让单个文档突破16MB的限制。必须拆分成独立的danmaku集合，并且考虑按时间进行分片。
• 用户观看进度——这本质上是用户维度的数据，应该存放在user_watch_progress这样的专用集合里，并以{ user_id: ObjectId, video_id: ObjectId }建立索引，确保查询效率。

分片键选 video_id 还是 category？看查询模式

如果系统的主要流量来自首页推荐、搜索和分类浏览，并且查询条件常常包含category或tag，那么直接用category做分片键（即便是哈希分片）会带来一个问题：同一分类的视频会集中在少数几个分片上。对于那些热门类目（比如“游戏”），对应的分片节点很容易成为性能瓶颈。

更稳妥的策略是：采用video_id的哈希分片。这能确保新视频的写入均匀分布到所有分片上。同时，为videos集合建立一个复合索引，例如{ category: 1, publish_time: -1 }，来高效支撑分类页的分页查询。

什么情况下才考虑用其他字段呢？只有当超过90%的查询都明确指向某个固定的region（地区）或tenant_id（租户ID）时——这在多租户的SaaS点播平台中比较常见——才值得将这些字段作为分片键的前缀。

user_beha vior 集合必须按时间范围分桶

用户产生的播放、暂停、点赞、分享等行为日志，数据量极其庞大。如果全部堆积在一个集合里，即使做了分片，也难逃巨大的写入压力和TTL（生存时间）清理延迟。

正确的做法是按天进行“分桶存储”。例如，将集合命名为user_beha vior_20240520，并在应用层根据日期路由写入操作。

这么做，至少能带来三个实实在在的好处：

• 精准的TTL管理：可以为每张表单独设置过期时间，避免在大集合上进行全表扫描来删除旧数据。
• 高效的冷数据处理：归档或删除历史数据时，直接drop掉整个集合即可，毫秒级完成。
• 查询性能提升：当需要查询某一天的用户行为时，MongoDB能直接定位到对应的集合，无需在整个分片集群中扫描。

这里有个关键点需要注意：千万不要用date字段作为分片键。因为日期是单调递增的，这会导致所有新数据都持续写入最后一个分片，让分片策略彻底失效。

最后，还有一个容易被忽略的细节：封面图的URL和视频播放地址，不应该由MongoDB直接返回给前端。更佳实践是，数据库只存储相对路径或标识符（例如cover_key: “v123456/cover.jpg”），具体的完整URL由CDN或网关层动态拼接生成。否则，一旦存储目录结构或CDN域名发生变更，就需要对数据库进行全量更新，这无疑是场运维噩梦。