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

【问题标题】：Firebase data structure - is the Firefeed structure relevant?Firebase 数据结构 - Firefeed 结构是否相关？
【发布时间】：2014-12-20 16:17:36
【问题描述】：

Firefeed 是 Firebase 可以实现的一个非常好的示例 - 一个完全客户端的 Twitter 克隆。所以有这个页面：https://firefeed.io/about.html，其中解释了采用的数据结构背后的逻辑。了解 Firebase 安全规则有很大帮助。

演示结束时，有这个sn-p的代码：

  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);
    });
  });

它显示了如何完成写入以保持读取简单 - 如上所述：

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

所以我明白这一点。但是，如果我们看一下 Twitter，我们可以看到一些帐户拥有数百万粉丝（关注最多的是拥有超过 6100 万粉丝的 Katy Perry！）。这种结构和这种方法会发生什么？每当 Katy 发布一条新推文时，就会产生 6100 万次写入操作。这不会简单地杀死应用程序吗？更何况，这不是消耗了很多不必要的空间吗？

【问题讨论】：

我不得不说它只是一个演示......
当然，这就是为什么我要寻求一种正确的方法来做到这一点。它将帮助我更好地理解如何处理 Firebase 上的数据结构...
我宁愿为您关注的帐户设置监听器，因为您可以关注的帐户数量有限制，但关注者没有限制。所以是的，Katy Perry 会杀死该应用程序。然而，即使设置 2000 个听众也可能并不理想。也许它可以轮换，假设当时有 100 个帐户......
当有很多追随者时看起来更好，但对于小帐户，几次写入总比不停的听众更好 - 正如你所说，远非理想。也许做这样的事情：向专用对象添加一个标记，由自定义服务器上的 NodeJS 监视，这将处理按 100 或 1000 个集群插入数据......不过，你会为重复数据占用大量空间.我真的不确定是否有适合此类问题的解决方案以及经典的关系数据库结构。
另一种方法是这里讨论的方法：stackoverflow.com/q/27422534，这将具有更好的写入性能。但是，当 Katy 的所有 6100 万追随者都在早上更新他们的提要时，这将导致传输瓶颈。

标签： firebase

【解决方案1】：

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

您不会在浏览器中执行此操作。服务器将侦听child_added 事件以查找新推文，然后一组工作人员将分页负载，一次对一部分关注者进行分页。您可能会优先考虑在线用户以首先获得写入。

使用标准化数据，您只需编写一次推文，但需要为读取时的连接付费。如果您在提要中缓存推文以避免每次请求都访问数据库，那么每条 Katy Perry 推文都会向 redis 写入 6100 万次。要实时推送推文，无论如何您都需要将推文写入每个在线关注者的套接字。

【讨论】：