Cassandra开发社交网络：哪种动态存储方案资源消耗最低？

结论先行 #

从长期运行的服务端响应速度优化角度，优先选择方案一（将用户昵称、头像等非频繁变更字段冗余写入动态表），投入产出比远高于方案二。

核心原因 #

• 读写场景量级差巨大：社交产品中动态拉取的请求QPS通常是用户个人信息更新请求的数百到数千倍，优化高频读请求的收益远高于优化低频写请求。普通用户平均3-6个月才会修改一次昵称/头像，而单用户每日拉取动态的请求可达数十次，每次请求返回数十条动态，读场景的资源消耗占比超过99%。
• 适配Cassandra的存储特性：Cassandra原生不支持关联查询，方案二需要先查动态表获取关联用户ID，再用IN语句批量查询用户表，不仅多了一次网络IO，多用户ID的跨分区IN查询在数据量较大时延迟会显著升高，高并发下极易成为性能瓶颈。方案一只需要单次分区查询即可返回动态展示所需的全量字段，查询延迟稳定，服务端资源消耗仅为方案二的1/2甚至更低。长期来看随着用户规模和动态数据量增长，方案一的性能优势会进一步放大，不需要处理关联查询的复杂度，服务端的性能瓶颈更少。
• 方案一的短板可通过工程手段优化：用户修改信息后需要同步更新历史动态的问题，不需要做实时同步，可通过异步消息队列削峰处理后台更新任务，甚至可以根据业务特性做分层更新：仅同步最近3个月的100条动态，更早的历史动态保留发布时的用户信息即可，多数用户并不会对历史动态的用户信息不一致产生感知，也符合社交场景的使用习惯。

特殊场景例外 #

如果你的业务明确要求用户修改个人信息后所有历史动态必须实时同步最新信息，且用户修改个人信息的频次极高（比如日均修改次数超过动态拉取请求的1/10），才需要考虑选择方案二。

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