扩展数据、减少加载时间、让我的虚拟主机满意的最佳方式

Question

对于 Facebook 应用程序，我必须在我的 MySQL 数据库中存储用户的朋友列表。此列表是从我的数据库中请求的，与其他数据等进行比较。

目前，我将此朋友列表存储在我的用户表中，朋友的 uid 放在一个“文本”字段中，并带有“|”作为分隔符。例如：

ID - UID - 姓名 - 朋友 => 1 - 123456789 - John Doe - 987654321|123456|765432

我的 PHP 文件请求这一行并通过分解该字段 ('|') 来提取朋友列表。这一切都很好，每 1000 个用户大约有 5MB 磁盘空间。

现在的问题：

对于一个额外的功能，我还需要保存用户朋友的名字。我可以通过不同的方式做到这一点：

1) 将此数据保存在一个额外的表中。例如：

ID - UID - NAME => 1 - 1234321 - Jane Doe

如果我需要 ID 为 1234321 的朋友的姓名，我可以从该表中请求姓名。然而，问题是这个表会继续增长，直到 Facebook 上的所有用户都被索引（>5 亿行）。我的虚拟主机不会喜欢这样！这样的表将占用大约 25GB 的磁盘空间。

2) 另一种解决方案是扩展保存在用户表中的数据，方法是将名称添加到好友字段中的 UID（使用额外的分隔符，让我们使用“，”）。例如：

ID - UID - 姓名 - 朋友 => 1 - 123456789 - John Doe - 987654321,Mike Jones|123456,Tom Bright|765432,Rick Smith

对于这个解决方案，我必须更改脚本，添加另一个额外的爆炸（'，'）等。我不确定这将占用多少额外的磁盘空间......但数据没有得到这种方式很容易处理！

3) 第三种解决方案可以很好地概览所有数据，但会导致数据库非常庞大。在这个解决方案中，我们创建了一个朋友表，每个朋友都有一行。例如：

ID - UID - FRIENDUID => 1 - 123456789 - 54321

ID - UID - FRIENDUID => 3 - 123456789 - 65432

ID - UID - FRIENDUID => 2 - 987654321 - 54321

ID - UID - FRIENDUID => 4 - 987654321 - 65432

正如您在此示例中所见，它很好地概述了所有友谊。但是，对于大约 5 亿用户，假设每个用户平均有 300 个好友，这将创建一个包含 1500 亿行的表。我的主人肯定不会喜欢那样...而且我认为这种表会占用大量磁盘空间...

那么...如何解决这个问题？您认为，在 Facebook 上存储用户的 UID + 朋友姓名的最佳方式是什么？如何扩展这种数据？或者你有比上面提到的三种可能性的另一种（更好的）解决方案吗？

希望你能帮助我！

Answer 1

我真的认为你应该选择第三个选项。为了可扩展性，您希望这样做。
使用第一种方法，您有很多冗余数据，因为如果 1 是 2 的朋友，那么 2 也是 1 的朋友。但是您要存储这两个关系。
这也使得 1500 亿行计数变得不可能。这更有可能最多是一半，因为关系表可以双向工作！
所以第一个用户将在表中生成 300 行，但第二个用户（如果他是 1 的朋友）将只生成 299 行。继续这样做，最后一个用户甚至不会生成关系行，因为它们都是已经出现了！
此外，当您想开始搜索某些关系时，第三个选项会快得多，因为您将拥有 int 索引而不是 fulltext 索引，这可能会在存储和处理速度方面再节省 50%。

如果您的应用程序将达到 5 亿用户，您只需要获得更好的托管服务即可。

Answer 2

我同意 Amber 的观点，解决方案 1 将是存储这些数据的最有效方式。如果您想坚持当前的方法（类似于解决方案 2），您可能需要考虑将友谊数据存储为 JSON 字符串。它不会产生尽可能短的字符串，但它会很容易解析。

保存数据：

$friends = array(
    'uid1' => 'John Smith',
    'uid2' => 'Jane Doe'
);

$str = json_encode($friends);

// save $str to the database in the "friends" column

要取回数据：

// get $str from the database

$friends = json_decode($str, TRUE);

var_dump($friends);

Answer 3

如果我需要朋友的名字 ID 1234321，我可以要求名字 从这张表。然而，问题 是这张桌子会继续增长， 直到 Facebook 上的所有用户都 索引（> 5 亿行）。我的虚拟主机 不会喜欢这样的！这样一个 表大约需要 25GB 磁盘空间。

如果存储您需要的用户名确实需要 25GB，那么它需要 25GB。您不能四处移动数据并期望它变得更小 - 而且表的开销也不会那么。相反，您需要专注于仅存储您实际需要的数据。 Facebook 上的每个人 都不太可能使用您的应用程序（如果 是这种情况，您不应该使用担心 25GB 空间的主机）。 p>

因此，不要为整个 Facebook 编制索引（无论如何这都会很困难），只需存储与实际使用您的应用程序的人和他们的直接朋友相关的数据，这是一个小得多的数据集。

您提出的第一个解决方案是正确的方法；它消除了名称存储中的任何潜在冗余。