关于design facebook/instg/twitter 中的detabase的shard的讨论

最近在深入研究设计社交网络数据库分块这一部分的内容，这类问题一般都会有三张表格，user table, user-follower table and post table. 我想讨论的是这三张表格都需要shard吗？其实id可以两个类型，userid和postid，我的想法是这两个id公用一个64位的id，其中36位给local index，10位给db type，16位给sharding index， 8位保留。然后如果要某一个用户要post一个feed的话就去找用户所在的shard，然后找到里面的post table，插入新的一行. 这样做的弊端是冷热不均衡，我们可以用monitor来进行traffic的log，对traffic大的instance进行scalaing，加入更多的slave nodes以便于提高availability. 如果表格持续变大可以进一步的shard. 这就是我的思路.

这种方法本质上把同一个用户的信息放在了一个instance 上，还有一种方法貌似可以解决这种冷热不均匀的现象，求高人指点！

对于traffic大的instance 最简单的方法不应该是加cache嘛？

我觉得post table需要根据Post ID 来shard, User Table 和 User Follower Table 可以根据User ID 来shard.

User table 的大小相对于 post table 来说应该小好几个数量级，可以按userid shard也可以不shard，多加几个slave distribute load应该就行了。
Post table 自然还是按postid shard比较合理，需要找一个user的post就需要搜寻所有的partition然后用aggregator merge/sort