[Instagram] Follow & Post Table 设计以及数据库相关的扩展容灾

系统设计
1

  1. 请问follow table和post table 的数据库类型分别是什么？ 是SQL吗？ 如果是SQL能支持ins所需要的读写速度吗？

  2. 在pull celebrity 的 post的时候，老师提到要用following table和post table进行join。 这部分是怎么完成的？ 接上一个问题，如果是SQL，请问如果Post Table的 Partition Key 如果是post ID而不是Author ID，在进行Join的时候是否会效率很低？ 如果是Non-SQL，会选择哪个数据库，都有哪些Non-SQL数据库支持JOIN操作？

  3. 在扩展性/容灾设计中，粗略的讲到了有Consistent Hashing 和 Master Slave。 这两者之间的选择的trade off是什么？有没有什么例子关于怎么选择？

1 个赞
2

问题1、2 我们一起讨论 - 我写的题解的意思是使用 Cassandra 来实现 Follow Table 和 Post Table。这里说的 JOIN 是在应用层实现的。对于查 Celebrity Post Table, 我们做两次 Request，第一次读所有 Following，第二次拿所有 Following 去找 Celebrity Post。Post Table 的 Partition Key 确实应该是拿 Author ID 做 Partition Key，谢谢指正。

问题3 - Consistent Hashing 和 Master-slave 是可以同时使用的，Consistent Hashing 里的每个 Node 可以用 Master-slave 来做冗余，也可以用下一个 Node 做冗余。
Consistent Hashing 解决的问题 1）动态增减机器 2）更多 QPS 3) 冗余 4）存储更多信息。相对的，Master-slave 解决的问题 1）更多 QPS 2）冗余。

3

问题1和2我都理解了，解答的很好，谢谢:pray:。

关于问题三，是不是理解Master Slave是更早更简单的基础概念， 工程实现很简单就可以实现备份，更多QPS，对于设计没那么复杂的，流量没那么大的系统就用这个就好了。Consistent Hashing更新更复杂一点， 除了支持了Master Slave的备份功能，还能动态增减机器，还能存更多数据，如果采用NonSQL数据库，且该数据库有比较成熟的Consistent Hashing实现方案，就用这个方案更好？

4

Master-slave （单一Master,多个Slave) 是可以支持很高的 Read QPS 的，只要 Slave 够多，Read 可以 Scale 到很大，但是 Write QPS 支持不高，因为全靠 Master 来写。一般在大规模系统是中会配合一些 Sharding Scheme 来使用，比如 Consistent Hashing，或者是更简单的固定 Keys-to-nodes 的 Hash-based Sharding。
Consistent Hashing 较固定的 Hash-based Sharding 而言，主要解决的问题是动态增减机器。
Cassandra 和 Dynamo 都使用 Consistent Hashing.

1 个赞