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

Posted 2023-02-24

【中文标题】在社交网络设计中使用外键 - 好/坏？

【英文标题】：Using foreign keys in a social network design - good/bad?

【发布时间】：2011-01-15 22:33:37

【问题描述】：

在我的架构中，我已经规范化了我的数据库，并且到处都有 FK，因为社交网络中有如此多的链接关系，尤其是将用户链接到所有事物。

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

【问题讨论】：

您现在有多少用户？如果它更接近于 0 而不是 100 万，那么你可能在这个阶段想多了。

无。即将推出 :) 但我的预算非常有限，现在当我有时间和团队时，我希望获得正确的数据模型以防止以后发生更改，然后不得不四处寻找 DBA，这将花费 $$$。

用过早优化的架构给自己戴上手铐也会花费 $$$。听起来您正试图在遇到高级问题之前解决它们。设计一些有效且能适应变化的东西。然后对其进行分析并优化出现问题的位置，但也准备好在发布后进行迭代。

这个问题真的是关于外键，还是关于代理或人工键？这些表有 30% 的外键，键只是 ID 号吗？在@Joe Holloway 之后，我花了很多时间问自己：“我能做的最简单的事情是什么？”

关于 FK。是的，它们是父表的 ID 号。但在那里，它们被转移到一个键值对表中，该表包含系统的主查找。

【参考方案1】：

1) 我假设我的阅读比写作更好的假设是社交网络所需要的？

通常，内容的阅读次数多于编写次数。但听起来你做了很多过早的优化。

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

声明外键与性能关系不大。

要么你的数据库被规范化，要么没有。在您知道自己遇到了性能问题之前，不要尝试破坏规范化。

3) 每个表最好有 2 组表 - 一组用于选择（读取）和一组用于具有不同架构的插入（写入），以便可以相应地设计它们以获得更好的性能？

您是说在这里实现materialized views 吗？听起来像是过早的优化 - 如果您认为它可能会使用视图来访问当前的数据，然后等到您知道您遇到了性能问题，然后再用物化视图替换底层实体。

4) 如果我将 80% 的列作为 fks 有什么害处？ （请记住，这是一个社交网络，以后可能会或可能不会有很多流量）

否 - 与上述相同 - 标准化您的数据。声明您的 FK，等到出现性能问题后再尝试修复它。

【参考方案2】：

1) 可能。但是使用缓存，这会超过数据库读取性能。

2) 两者兼而有之。 FK 隐含索引，索引通常对读取性能有积极影响，但会增加写入所需的时间。

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

4) 如果您的信息是这样构造的，那没有什么坏处。

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

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

【讨论】：

我很快就会（下个月）推出这个，所以现在它是 1 个数据库。但这是一个针对城市的地理定位社交网络，所以我预计它会快速赶上，然后需要多个服务器。然而，我们的目标是从第一天起就做好架构。

所以对于第 2 点，您说增加写入时间。问题是如果有很长的项目队列等待写入，我假设数据库自己处理它还是我们需要为它编码？如果由于项目排长而导致信息写入延迟 1 小时，我不想 DB 将项目从队列中删除。

【参考方案3】：

您可以使用 MASTERS/SLAVE 结构。

设置一个 MASTER sql-database 用于写入，并设置一个（或多个当您真正想要扩展时）从属用于读取。

这样，您的中间件需要知道 SELECTS 是从 SLAVES 完成的，而其余的基本上是在 MASTER 上完成的。但这取决于您在后端使用什么。