高用户量场景下视频观看记录存储的数据库表结构设计问题咨询

观看记录表设计思路参考 #

1. 先对齐核心场景优先级再做选型 #

• 先梳理所有涉及观看记录的读写请求，按访问频次、响应时延要求排序：比如最频繁的请求是判断单个用户是否看过某一集？还是拉取用户最近观看历史？还是统计单集的总观看人数？不同场景的优先级直接决定了存储结构的取舍方向，你最初考虑的单用户全量记录存一行的方案，仅适配「每次查询需要拉取用户全量观看数据」的场景，对单条记录的判断、更新效率会更低，这是首先要明确的前提。
• 可以先把所有涉及观看记录的业务逻辑都列出来，标注每个逻辑对读写性能、数据一致性的要求，再倒推存储结构的设计方向。

2. 评估单用户单条全量存储方案的边界 #

• 先算清楚量级边界：单用户最多会产生多少条观看记录？序列化后的单行数据大小会不会超过你所用数据库的单行存储上限？即便是支持JSON大字段的数据库，单行数据超过10KB之后读写性能就会出现明显下降，你可以先按业务的用户规模、人均观看量算一下未来1~2年的单条数据大小，判断是否在可接受范围内。
• 再评估更新成本：用户每次看新剧集都需要更新整条序列化字符串，写入放大的问题是否可控？比如用户每看一集就要读写几十KB甚至上百KB的数据，远高于写入单条独立记录的成本，这个代价是否符合业务的资源投入预期。
• 最后看查询成本：如果要判断用户是否看过某一集，是需要把全量记录拉到服务端遍历，还是你所用的数据库支持结构化字段内的索引查询？不同存储组件对嵌套结构的查询支持度差异极大，这个也要提前对齐。

3. 其他设计方向的核心权衡点 #

• 如果考虑「用户ID+剧集ID」做联合主键的窄表设计，可以先算清楚总行数规模：比如100万用户人均观看100集，总记录数也才1亿，大部分主流关系型数据库、KV数据库都能轻松支撑这个量级，不用提前过度担心存储成本，这种结构的读写灵活性、扩展能力都会高很多。
• 也可以考虑冷热数据分离的思路：用户近1~3个月的热观看记录存在窄表里，支撑高频的状态判断、最近历史拉取需求，超过时间阈值的冷数据归档到单用户单条的结构里，仅在用户拉取更早历史的时候访问，兼顾性能和存储成本。
• 还要考虑业务扩展可能性：后续是否需要存储观看进度、观看时间、观看设备这类附加信息？如果后续需要新增属性，单用户全量存储的结构迭代成本会高很多，这个也要提前纳入考量。

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