构建类似 Facebook 的个性化新闻源：SQL、MongoDB？

我正在构建一个类似 Facebook 的新闻源。这意味着它是由许多 SQL 表构建的，并且每种数据类型都有特定的布局。但它的负载变得非常重，我希望让它变得更加复杂......

这就是我现在所做的：

用户模型：

  def updates(more_options = {})
        (games_around({},more_options) + friends_statuses({},more_options).sort! { |a,b| b.updated_at <=> a.updated_at }.slice(0,35) + friends_stats({:limit  => 10},more_options) + friends_badges({:limit  => 3},more_options)).sort! { |a,b| b.updated_at <=> a.updated_at }
  end

徽章数据示例：

  def friends_badges(options = {:limit  => 3}, more_options = {})
    rewards = []
      rewards = Reward.find(:all, options.merge!(:conditions  => ["rewards.user_id IN (?)",self.players_around({},more_options).collect{|p| p.id}], :joins  => [:user, :badge], :order  => "rewards.created_at DESC"))            
    rewards.flatten
  end

新闻源视图：

<% for update in @current_user.updates %>
        <% if update.class.name == "Status" %>
            <% @status = update %>
            <%= render :partial  => "users/statuses/status_line", :locals  => {:status  => update} %>
        <% elsif update.class.name == "Game" %>
            <%= render :partial => "games/game_newsfeed_line", :locals  => {:game  => update} %>
        <% elsif update.class.name == "Stat" %>
            <%= render :partial => "stats/stat_newsfeed_line", :locals  => {:stat  => update} %>
        <% elsif update.class.name == "Reward" %>
            <%= render :partial => "badges/badge_newsfeed_line", :locals  => {:reward  => update} %>
        <% end %>
    <% end %>

我想到的选项：

• 构建“Feed”表并通过后台作业预处理每个用户的大部分更新。最有可能是每小时一次的 cron。我会存储每次更新的完整 HTML 代码。
• 保留初始结构，但单独缓存每个更新（现在我没有缓存）
• 切换到 MongoDB 以更快地访问数据库

我不得不说，我并不是真正的专家，Rails 使第一步变得简单，但现在每页加载超过 150 个 SQL 请求，我觉得它已经失控，需要专家的观点......

你会怎么办？

感谢您的宝贵帮助，

你的代码并没有告诉我很多信息；我认为如果你能用简单的 JSON / SQL 来布局你的数据结构将会很有帮助。

不管怎样，我会将每个用户的流序列化到 MongoDB。由于各种原因，我不会将 HTML 存储在数据库中（至少不会在软件的那个级别）；相反，您应该将相关数据保存在（可能是多态的）集合中。那么获取新闻源就非常容易，索引也很简单，等等。视图结构基本上不会改变。如果您稍后想要更改 HTML，也很容易。

缺点是这会重复大量数据。如果人们可以拥有很多追随者，这可能会成为一个问题。使用用户 ID 数组而不是单个用户 ID 可能会有所帮助（如果所有关注者的信息都相同），但它也是有限的。

对于非常大的关联问题，只有缓存。据我了解，facebook 和 twitter 的神奇之处在于它们不会经常访问数据库并将大量数据保存在 RAM 中。如果您要关联数十亿个项目，即使在 RAM 中，这样做也是一个挑战。

更新应该连续写入，而不是每小时写入。假设您的流量很大，每小时更新一次需要 30 分钟。现在，最坏的情况是 90 分钟。延迟。如果您及时处理更改，则可以将其缩短到大约 5 分钟。

您必须在某些时候提出假设，使用缓存和一些启发式方法。一些例子：

• 推文越新，流量就越多。它被转发的机会更高，而且出现的频率也更高。将其保存在 RAM 中。
• 您的 1991 年 Facebook 时间线概述页面可能不会每天都发生变化，因此这是长期输出缓存的候选者。
• 当前的 Facebook 活动可能会经历大量写入。输出缓存在这里没有多大帮助。同样，该对象应该保存在 RAM 中。