AG评论业务回顾（2）模型设计

评论表的设计：

最初的设计中，使用mysql单表+历史表作为数仓，主键从外部产生，后期单表大小超过两千万，性能出现瓶颈。

后期进行了一次重构，改为32张review表，主键使用雪花算法生成。使用应用Id%32作为分表号。评论Id中也冗余了分表号。

这个设计后来发现还是出现数据倾斜，大表和小表的数据规模差距多达3倍左右。主要是一些头部应用比如王者，评论数量远超其他应用。这个后来也出现了性能问题， 在我们切换到高斯云库后，出现了索引失效，产生了明显性能问题，cpu负载极高。

回复的数据量相对于评论较少，我们也使用了32张分表，通过评论Id进行分表，实际上同一个应用的回复也会落在一个回复表里面，这样主要是为了方便查询。

用户级的数据比如我的评论、我的回复、我的收藏、消息列表，放在了nosql的数仓Cassandra中，这个在设计的时候有一些问题没想清楚，导致数据的物理顺序和期望的返回顺序不完全一致，后来只能读出最后1000条，进行排序后存入redis。给用户带来的体验可能就是第一次进入的时候会比较或者失败，不过在客户端上我的收藏是在一个子tab，在页面打开的时候会进行预加载。体验上可以接受。

为了方便做排序和做运营审核管理台的搜索能力，还使用了ElasticSearch作为mysql的外挂索引。实际上ES中的数据比较多，几乎是全量的，这是因为早期的团队把ES作为数仓使用，而不仅仅是作为一个索引。