构建追随者/关注MySQL数据库的最佳实践

我将为社交网络样式的网站构建一个MySQL数据库，其中用户关注其他用户，然后从其用户获得更新。构建追随者/关注MySQL数据库的最佳实践

我的DB是由一个表与用户的基本信息构成：

| ID | username | password | email | ... other few columns |

的“ID”是主要的，“用户名”和“电子邮件”是独特的和索引。

然后我有用户饲料的表应该如果另一个用户按照它只能显示，“ID”始终是主要的：

| ID | feed_to_show_in_home |

然后与跟随者统计数据的表格，以加快用户的个人资料页：

| ID | followers_count | following_count |

而且至少真正的追随者网表存储在那里谁跟着谁：

| ID | following |

在此表中，“ID”和“跟随”都是主要的，因为用户只能跟随其他用户一次。

现在我想问一下，从性能的角度来看，我的结构是否良好。我特别担心如何检查用户是否关注其他用户，停止关注用户，以及如何仅在我关注特定用户时才显示供稿。

在这种情况下，我想到的解决方案总是扫描整个表的长度，但我认为这不是一个好的选择，因为这个DB计划存储超过10,000个用户。

来源

2016-09-26 Philip

简答：10,000是很少的，任何设计都会“足够好”。

龙答：欲了解更多缩放，请考虑以下...

这些设计通常不好的做法：1的关系：在1

两个表。
存储可以计算的东西。

我说“通常是”，因为你正在涉及例外情况的保证。但首先，请允许我提一些其他架构设计：

CREATE TABLE Follow (
    er ..., -- user id of the the follower 
    ed ..., -- user id of the the followed 
    PRIMARY KEY(er, ed), 
    INDEX(ed, er) 
) ENGINE=InnoDB; 

SELECT COUNT(*) FROM Follow WHERE ed = ?; -- number of followers for `ed`. 
SELECT er FROM Follow WHERE ed = ? -- list of such followers 
(Similarly for the flip direction)

注：

没有替代AUTO_INCREMENT，因为有一个完美的PK。和查询将运行得更快，我们将在一分钟内看到。
直到你有100K追随者，COUNT查询是“足够快”，所以你不需要预先计算计数。

如果您要计算“喜欢”的数量，那么为该频繁更新的值设置一个单独的表格会比较谨慎。这样的表格与用户表格是1：1，因此违反了第一个不好的做法。这里的理由是将非常高的写入活动中，从低，但重要读活动在其余的“用户”信息。

来源

2016-09-27 16:19:08

对于这样的事情，我更喜欢图数据库，因为你试图解决的现实世界问题有一个图作为它的自然结构。

从关系的角度来看，你的想法看起来不错。我不太清楚你是否已经拥有所有你需要的关系，但是基本的概念你可能是正确的。

对于性能问题，您应该使用一些任意测试数据和EXPLAIN语句（see this）进行一些测试。现在，您可以尝试在要过滤的列上设置一些索引并再次进行测试。哪些索引最适合您的查询，哪些索引最好不要设置取决于更新/插入内容的频率或次数。还有很多其他文章可以比我更好地解释它，所以您应该查看一些索引编制中的一些最佳实践，并在实际发生时询问具体的性能问题。

来源

2016-09-26 11:44:37

感谢您提供'EXPLAIN'提示。你认为作为一个开始的项目足够使用MySQL而不是图形数据库吗？ – Philip

当然。这并不是真的依赖于特定的DBMS。即使在生产环境中，我也喜欢MySQL，但它忽略了例如'CHECK'约束，您必须手动强制执行此操作。所以我不断放弃它的使用。这对草图来说绝对可以。对于图形数据库，您必须习惯其他查询语言，例如neo4j中的Cypher。所以当你从关系图移植到图时，你将面临更多的努力。 –

构建追随者/关注MySQL数据库的最佳实践

回答

相关问题