我正在研究构建活动源的物流，类似于Facebook或Twitter的时间表。
StackOverlfow和Quora以及我在google上发现的其他文章中有大量的答案，这些文章描述了读或写的风扇。这一切都有道理。您将所有活动记录在一个主活动表/集合中，然后在某个时刻，将该数据的副本写入每个用户的单独的适当表中。
我不完全理解为什么需要扇出？也就是说，为什么需要在单个用户Feed上记录活动？你有什么理由不能只使用一个活动表/集合吗？它将具有适当的索引，并具有代理用户的ID。然后，当有人想要查看他们的活动流时，只需查询当前用户关注的用户的活动流。
我知道这可能效率不高，因为活动数量超过数据库中的实际对象几次。也就是说，数据库中可能有100个帖子，但是帖子上有超过1,000个帖子，因此当行号变得非常高时，活动表/集合上的查询可能会很慢。
但是这不行吗？你不能只是扩展数据库，以便它可以更有效地处理查询？是否真的有需要来展开？
答案 0 :(得分：0)
没有必要一直扇出，但决定取决于很多因素。
例如。 Twitter同时做了这两件事，但Facebook跟随着粉丝出货。
你可以想象，Facebook的活动流程比Twitter更加复杂。 FB需要在每个用户/组的基础上应用大量过滤器/隐私设置，因此他们有必要即时提取和构建流。他们的TAO图形基础设施（基于MySQL +缓存的图形化）使他们可以轻松地为每个用户快速构建和获取源。