Firebase数据结构-Firefeed结构是否相关？

Firefeed是一个很好的例子，说明了Firebase是一个完全客户端的Twitter克隆。因此，这里有一个页面：这里解释了所采用的数据结构背后的逻辑。了解Firebase安全规则有很大帮助

演示结束时，有以下代码片段：

  var userid = info.id; // info is from the login() call earlier.
  var sparkRef = firebase.child("sparks").push();
  var sparkRefId = sparkRef.name();

  // Add spark to global list.
  sparkRef.set(spark);

  // Add spark ID to user's list of posted sparks.
  var currentUser = firebase.child("users").child(userid);
  currentUser.child("sparks").child(sparkRefId).set(true);

  // Add spark ID to the feed of everyone following this user.
  currentUser.child("followers").once("value", function(list) {
    list.forEach(function(follower) {
      var childRef = firebase.child("users").child(follower.name());
      childRef.child("feed").child(sparkRefId).set(true);
    });
  });

它展示了如何书写，以保持阅读的简单性-如前所述：

当我们需要为一个特定的用户显示提要时，我们只需要查看一个地方

---

所以我明白这一点。但如果我们看看推特，我们可以看到一些账户拥有数百万粉丝（大多数追随者是凯蒂·佩里，拥有超过6100万粉丝！）。这种结构和方法会发生什么？每当凯蒂发布一条新的推文时，就会有6100万次写操作。这难道不会简单地扼杀应用程序吗？更重要的是，它不是占用了很多不必要的空间吗？

对于非规范化数据，连接数据的唯一方法是将数据写入其读取的每个位置。所以是的，向6100万粉丝发布一条推特需要6100万次写作

您不会在浏览器中执行此操作。服务器将侦听新tweet的

child_added

事件，然后一组工作人员将一次分配一个子集追随者的负载分页。您可能会优先考虑在线用户，以便首先获得写入

---

使用规范化数据，您只需编写一次tweet，但需在读取时支付连接费用。如果你将tweets缓存在feed中以避免每次请求都访问数据库，那么每次Katy Perry tweet都会有6100万次写入redis。要实时推送tweet，您需要将tweet写入每个在线关注者的套接字

我必须说这只是一个演示…当然，这就是为什么我要求一个正确的方法来做这件事。这将帮助我更好地理解如何在Firebase上处理数据结构…我更愿意为您关注的帐户设置侦听器，因为您可以关注的帐户数量是有限制的，但对关注者没有限制。是的，凯蒂·佩里会杀了这个应用。然而，即使设置2000名听众也可能并不理想。也许它可以轮换，比如说当时有100个账户……在有很多追随者的情况下看起来更好，但对于小账户来说，几篇文章比不停的听众要好得多——正如你所说的，远远不够理想。也许可以这样做：向一个专用对象添加一个标记，由自定义服务器上的NodeJ监视，该标记将处理按100或1000个集群插入数据。。。尽管如此，您仍会为重复数据占用大量空间。我真的不确定是否有这样的解决方案可以像经典的关系数据库结构那样适用。另一种方法是这里讨论的方法，它将具有更好的写性能。但当凯蒂的6100万追随者在早上更新他们的订阅源时，这将导致交通瓶颈。