Cassandra中高活跃度字段是否应当单独存储在独立数据表中？

核心前提 #

当前业务仅需存储帖子总评分、无需留存用户点赞/点踩记录，评分操作属于极高频次写场景，底层存储为Cassandra分布式数据库。

方案1：rating作为POSTS表的内置字段 #

将评分作为普通字段和帖子内容、发布时间等信息同存于POSTS表。

优势 #

• 查询逻辑极简：拉取帖子列表、详情时仅需查询单表，完全符合Cassandra「一表对应一个查询场景」的最佳实践，无需做多表拼接，查询延迟最低
• 运维成本低：无需额外维护表结构，数据写入、更新逻辑不需要考虑跨表一致性，开发量更小

劣势 #

• 严重拉低POSTS表查询性能：Cassandra基于LSM树实现，所有更新都是写入带时间戳的新版本，高频的评分更新会给对应帖子行生成大量冗余版本，读请求需要合并大量仅rating字段变更的版本数据，而POSTS表还包含大体积的帖子内容字段，读合并的开销会成倍上升
• 热点影响范围大：爆款帖子短时间内的大量评分更新，会把请求压力全部集中在POSTS表对应post_id所在的分区节点，不仅会拖慢评分更新速度，还会连带影响同分区其他帖子的读写请求，甚至引发节点过载
• 无法使用原生计数器：Cassandra规定COUNTER类型字段不能和普通非主键字段共存于同一张表，所以POSTS表的rating只能用普通数值类型，并发更新时需要自行处理冲突，计数准确性和更新性能都远低于原生计数器

方案2：独立RATINGS(post_id, rating)表存储 #

单独建表仅存帖子ID和对应评分，rating字段使用Cassandra原生COUNTER类型。

优势 #

• 负载完全隔离：高频评分更新的写入、版本合并操作完全和低频更新的帖子主数据隔离，RATINGS表的碎片、热点都不会影响POSTS表的查询性能，主表的读延迟会长期保持稳定
• 性能更高：适配Cassandra的COUNTER类型使用要求，原生支持原子增减，不需要额外加锁，更新性能比普通数值类型高30%以上；且RATINGS表字段极小，每次更新的payload只有十几字节，网络、落盘开销都远低于更新POSTS整行
• 热点容错性更强：就算出现爆款帖子的评分更新热点，影响范围也仅限RATINGS表，业务侧可以单独对RATINGS表做热点拆分（比如给post_id加随机后缀做分片），调整成本极低，不会影响帖子主数据的存储结构

劣势 #

• 查询逻辑更复杂：拉取帖子数据时需要同时查询POSTS和RATINGS两张表做拼接，要么应用侧发起两次查询合并结果，要么额外构建一张同时包含帖子内容和评分的宽表，开发和维护成本更高
• 存在短暂不一致风险：如果两张表的写入没有配置原子批次，极端情况下会出现帖子创建成功但评分未初始化、评分更新成功但查询未拿到最新值的问题，需要业务侧增加简单的补偿逻辑
• 存储成本小幅提升：需要额外存储一份post_id主键数据，但因为RATINGS表整体体积极小，增量基本可以忽略不计

选型建议 #

如果你的论坛规模较大，评分更新QPS长期高于100，或者经常出现短时间内点赞量破万的爆款内容，优先选择独立RATINGS表的方案；如果是小型论坛，评分更新频率极低，直接存在POSTS表的方案更简单省心。

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