Facebook 中的新闻提要数据库设计

Posted 2023-02-24

【中文标题】Facebook 中的新闻提要数据库设计

【英文标题】：News feed database design as in Facebook

【发布时间】：2008-11-21 03:31:27

【问题描述】：

如何使新闻提要“友好”的数据库设计，以便将所有项目（查询）放入新闻提要中不会非常昂贵？我能想到的唯一方法是联合几乎每个表（代表组、笔记、朋友等）并获取日期等，这似乎是为每个用户运行一个非常昂贵的查询，而且因为每个人都不同，所以很难缓存这样的东西。

【问题讨论】：

对于我们这些不使用 Facebook 的人，您能否再描述一下这个问题？

在这里讨论实现社交活动流：https://***.com/questions/202198/whats-the-best-manner-of-implementing-a-social-activity-stream

【参考方案1】：

首先，考虑制作一个性能原型，以检查您对联合是否过于昂贵的预感。您可能过早地优化了一些不成问题的东西。

如果这是一个真正的问题，请考虑一个纯粹为保存事件源数据而设计的表，该表必须与其他表并行更新。

例如当您创建注释记录时，还要在事件表中创建一个事件记录，其中包含日期、描述和所涉及的用户。

考虑基于 UserId（或 UserId 和 Date）索引 Event 表。也可以考虑在不再需要时清除旧数据。

这不是一个规范化的模式，但如果获取事件馈送是一种频繁的操作，它可能会更快。

【参考方案2】：

没有架构很难回答这个问题，但我的直觉是，涉及 10 个或更多正确索引的表的 UNION 什么都不是： 典型的 LAMP 应用程序，如 wordpress 或 phpBB，每次浏览量运行超过 10 个查询，没有问题。所以不用担心。

【讨论】：

我知道我不应该讨论这个话题，抱歉——但有没有可以链接到的资源来证实你的话：“一个典型的 LAMP 应用程序，如 wordpress 或 PHPBB，每次浏览量运行超过 10 个查询没有问题。”？

【参考方案3】：

UNION = 昂贵，因为完整的结果集受制于 DISTINCT 操作。 UNION ALL = 更便宜，因为它实际上是多个查询，每个查询的结果都附加在一起。

这取决于数据量或课程。

效率的主要驱动因素是联合在一起的单个查询，但没有理由为什么从 10 个表中的每一个表中选择最近的（例如）10 条记录应该花费不到一秒钟的时间。