在朋友圈发布动态的项目中,如果有一个大V用户,他发的数量远超于其他用户。他的数据导致了mysql分表中的某一个表数量变得很大,而其他表相对很小的问题如何解决。

在上一篇文章《使用hash+range分库分表的思考》中介绍到的分库分表方案能解决这样的问题,但是相对来说有点复杂。这里思考另一种更简单的可行方案。

1.分析

首先,我们需要的是按照用户id去区分。所以第一步需要使用一致性hash算法。使用这个算法方便日后进行扩容,代价是需要迁移其中一部分数据,具体可以在文章《一致性hash算法》中找到相关描述。

hash到的结果,我们暂时称为group。这个时候我们需要对消息id做range,保证每一个表的数量都在允许范围之内。如果这个group压力太大,则进行扩容。

2.结果

这样能保证每一个表不至于会太大导致性能问题。

这种方案相比前面文章介绍的系统复杂度更低一些,代价是扩容时需要做一定的数据迁移。

当然,在查询的时候肯定要有一定的复杂度。软件工程没有银弹。

3.nosql

对于使用MongoDB这种存储来说,可以设置分片的key为消息id,或者选择一个出现频率比较多的字段进行组合。这种主要还是用来做精准查询的,就比如使用消息id查询而不是用用户id查询,所以如果是这种场景不需要考虑使用用户id查询导致的需要多分片查询产生的性能消耗了。