在社交网络设计中使用外键 - 好/坏？

Question

在我的架构中，我已经对我的数据库进行了规范化并且在整个地方都有FK，因为在社交网络中存在如此多的链接关系，尤其是将用户链接到所有内容。

现在很明显，在社交网络中，性能会成败。这意味着“读取”时间比“写入”时间更重要。我的数据库是带有InnoDB的MySQL，用于所有表。所以问题是：
1）我认为我认为阅读比写作更好是社交网络需要什么？ 2）有很多FK（我估计每个表中几乎有30％的列都有FK），这会影响读取性能或写入性能，还是两者都没有？ 3）每个表最好有两组表 - 一个用于选择（读取），另一个用于具有不同模式的插入（写入），因此可以相应地设计它们以获得更好的性能？
4）如果我说80％的colunms是fks会有什么危害吗？ （请记住，这是一个社交网络，以后可能有或没有很多流量）

Answer 1

  

1）我认为我对阅读比写作更好的假设是社交网络需要的吗？

通常，内容的阅读频率高于写入内容。但听起来你做了很多过早的优化。

  

2）有很多FK（我估计每个表中几乎有30％的列都有FK），这会影响读取性能或写入性能，还是两者都没有？

声明外键与性能无关。

您的数据库是否已标准化。在你知道自己遇到性能问题之前，不要试图打破标准化。

  

3）每个表最好有两组表 - 一个用于选择（读取），另一个用于具有不同模式的插入（写入），因此可以相应地设计它们以获得更好的性能？

你在谈论在这里实施materialized views吗？听起来像是过早优化 - 如果您认为可能会使用视图来访问当前的数据，那么请等到您知道在使用物化视图替换基础实体之前遇到性能问题。

  4）如果我说80％的colunms是fks会有什么危害吗？ （请记住，这是一个社交网络，以后可能有或没有很多流量）

否 - 与上述相同 - 规范化您的数据。声明你的FK，等到你遇到性能问题然后再尝试修复它。

Answer 2

1）可能。但是使用缓存，这比db读取性能好。

2）两者。 FK意味着索引，索引通常会对读取性能产生积极影响，但会增加写入所需的时间。

3）不，我不知道该怎么做。在某些时候，数据必须写入选择表...再次，使用缓存。

4）如果您的信息结构如此，则无害。

如果您担心数据库性能，请考虑缓存数据库中的数据，不要让缓存的数据过时。

另外，您是否计划扩展多个数据库服务器？然后，您需要考虑如何同步数据库，如何传播更改。

Answer 3

您可以使用MASTERS / SLAVE构造。

设置MASTER sql-database进行写入，并设置一个（或者当你真的想要缩放时为多个）从属进行读取。

这样你的中间件就需要知道SELECTS是从SLAVES完成的，基本上其余的都是在MASTER上完成的。但这取决于你使用后端的内容。