Database 以适度可扩展的方式交付活动提要项

我正在开发的应用程序有一个活动提要，每个用户都可以在这里看到他们朋友的活动（很像Facebook）。我正在寻找一种适度可伸缩的方式来动态显示给定用户的活动流。我之所以说“适度”，是因为我希望只使用一个数据库（Postgresql）和memcached。例如，我希望此解决方案扩展到20万用户，每个用户有100个朋友

目前，有一个主活动表存储给定活动的呈现html（Jim添加了一个朋友，George安装了一个应用程序等）。此主活动表保存源用户、html和时间戳

然后，有一个单独的（'join'）表，它只保留一个指向应该在其好友提要中查看此活动的人的指针，以及一个指向主活动表中的对象的指针

因此，如果我有100个朋友，并且我做了3项活动，那么join表将增长到300项

很明显，这张桌子将快速增长。不过，它有一个很好的特性，即要向用户显示的获取活动只需要一个（相对）便宜的查询

另一个选项是只保留主活动表，并通过如下方式进行查询：

select * from activity where source_user in (1, 2, 44, 2423, ... my friend list)

这样做的缺点是，您查询的用户可能永远不会处于活动状态，并且随着好友列表的增长，此查询可能会越来越慢

我看到了双方的优点和缺点，但我想知道是否有人可以帮我权衡各种选择，并提出一种或另一种方法。我也对其他解决方案持开放态度，不过我希望保持简单，不要安装CouchDB之类的东西

---

非常感谢

我倾向于只使用主活动表。如果你同意的话，这就是我要考虑的：

从数据库中获取数据时，您可以创建多个活动表并进行联合。例如，每月滚动一次-activity_2010_02，等等。仅以您的示例为例-200K用户x 100个朋友x 3个activities=6000万行。对于PostgreSQL来说，这并不是一个明智的选择，但现在你可以考虑纯粹为了方便，最终为将来的轻松扩展而努力。

这样做的缺点是，您查询的用户可能永远不会处于活动状态，并且随着好友列表的增长，此查询可能会越来越慢

是否要显示整个活动提要，返回到时间的开头？在最初的问题中，您没有提供太多细节，但我猜您将显示按时间戳排序的最后10/20/100项。几个索引和LIMIT子句应该足以提供即时响应（正如我刚刚在一个大约有2000万行的表上测试的那样）。在繁忙的服务器上速度可能会较慢，但这应该通过硬件和缓存解决方案来解决，Postgres不会成为瓶颈

即使您确实提供了追溯到时间黎明的活动反馈，也要对输出进行分页！限制条款可以帮你在那里省钱。如果对其进行限制的基本查询是不够的，或者如果用户有一个不再活跃的朋友的长尾，则可以考虑首先限制查找到最后一天/周/月，然后提供朋友ID的列表：

select * from activity 
  where ts <= 123456789 
    and source_user in (1, 2, 44, 2423, ... my friend list)

从活动中选择*
ts在哪里