提高 facebook 风格的墙页面的数据库性能答案

【问题标题】：improving database performance for a facebook style walling page提高 facebook 风格的墙页面的数据库性能
【发布时间】：2012-01-10 11:03:26
【问题描述】：

这是关于社交网站的。让 Facebook 成为我们的榜样。

在 mysql 服务器中有一个表：'posts' 用于保存所有帖子的 precord（为简单起见，不包括 cmets）。它的列是：

id, post, user_id, frnd_id_1, frnd_id_2。

id：主键，自增。

post：写在墙上的帖子（无论是登录用户的墙还是他/她的任何朋友的墙）

user_id：登录用户的id（假设为A）

friend_id_1：登录用户的好友（假设为 B）。当 A 在 B 的墙上写字时使用此字段。

friend_id_2：登录用户好友的好友（假设为C）

如果A和B之间有相应的消息对应记录在mysql表中。

假设 B 在 C 的墙上写了一些东西，然后 B 的朋友会在他们各自的墙上看到它。假设 B 有 100 个朋友。我们可以这样在表中记录：frnd_id_2将用于记录C的id；

如果frind_2的记录为'0'，则消息的对应关系只有user_id和frnd_id_1，否则表示frnd_id_1已经写在frnd_id_2的墙上，frind_id_1是user_id的朋友。

到目前为止，我认为，一切都与 FACEBOOK 完全相同。

但是-

假设 B 有 100 个朋友。在这种情况下，如果 B 在 C 的墙上写字（假设所有隐私设置都对朋友的朋友开放）。如果采取上述策略，表中将有101条记录：

1) 一条记录仅表示 B 已在 C 的墙上发帖 (frnd_id_2=0) 。（我们称之为 MAIN RECORD）

2) B 的 100 位朋友的另外 100 条记录。(frnd_id_2!=0)

这就是我脑子里的样子。我可以通过插入“post”列（或将“post”列保持空白并创建另一个即“main_record_id”）而不是完整消息，而是主记录的id来改进它。

但问题是：对于单个帖子，需要执行 101 个数据库查询（在这种情况下）。还有其他方法可以提高数据库性能吗？

我使用 PHP 作为脚本语言。

【问题讨论】：

【解决方案1】：

或 1 个数据库查询，在一次网络往返中带回所有信息。我会将它们批处理到一个 JOIN 查询中。

如果您打算保留所有这些记录，您将无法摆脱这些记录，但您可以控制访问它们的方式。

要记住的另一个想法是控制返回的结果集的大小。你真的同时需要所有 100 个朋友吗？你能同时用十个吗？当您要返回 1,000 或 10,000 条记录时，这将变得尤为重要。

【讨论】：

' 1 个数据库查询，可在一次网络往返中返回所有信息。我会将它们批处理到一个 JOIN 查询中。请解释一下，因为我无法理解。要加入哪些表？ “你一次处理 10 条记录也很好”——什么时候处理剩下的 90 条记录？
Google for SQL JOIN 第一个。我假设用户和朋友或用户和帖子之间存在一对多的关系。如何处理剩余的 90 条记录？首先，编写您的查询，这样您就不会返回它们。其次，为用户提供“next 10”链接，以便他们可以获取记录 11-20、21-30 等。
我知道 SQL 连接。对于所有用户，墙上的帖子将存储在一个表中。那么要加入哪些表呢？至于这 90 条记录，我不是说一次显示墙页中的所有帖子。而是当 B 在 C 的墙上写字时，对于 B 的 100 个朋友，需要将 100 条记录插入到数据库中，以便 100 个朋友在查看墙壁时得到他们的墙壁。 100 条记录是关于在墙页中显示这些记录的 npt
我认为@duffymo 试图说而不是插入 100 条记录，只插入一条，并使用 join 根据您的朋友显示墙中的帖子。换句话说，规范化数据库
您能帮忙解决此处所述表格的规范化问题吗？在这种情况下，应该做些什么来规范化 db（插入 101 查询）？

【解决方案2】：

一个简短的回答：不要将 MYSQL 用于类似 facebook 的墙 - 对于这样的目的，它是非常无效的。

改用 no-sql 数据库，例如 MongoDB。我保证您会惊讶于它对于具有不同类型对象的实时新闻提要更加方便。

您还可以组合两个数据库：用于新闻源的 MongoDB 和用于其他所有内容的 MySQL。

【讨论】：