【问题标题】:Firestore social network data structureFirestore 社交网络数据结构
【发布时间】:2019-10-06 04:21:03
【问题描述】:

如何构建一个社交网络数据库结构,例如twitter,我们可以在其中关注用户并在我们的时间线中获取他们的所有推文,我已经检查了这个Firestore - how to structure a feed and follow system ,但帖子中的解决方案看起来有缺陷。

Firestore 的不同之处在于它需要冗余数据才能有效地访问数据,但假设我正在关注 1000 人,如果我需要通过查询我关注的每 15 个用户的数据并使用 limit(10) 来获取所有这些用户的帖子方法然后orderBy(timeStamp) 查询之间可能有未读帖子,因为我们正在使用last post timeStamp 获取帖子,如何在Firestore 中为社交媒体应用程序构造数据

【问题讨论】:

  • 你想出解决办法了吗?
  • 切换到图数据库,NoSQL 对于社交网络来说是丑陋的。 @MobDev

标签: firebase google-cloud-firestore


【解决方案1】:

在 NoSQL 数据库上为用例建模时,您倾向于针对应用程序的功能和频繁的读取操作进行优化。

因此,在社交媒体应用程序中,您的主要功能可能是用户可以看到他们关注的每个人的最新帖子。要针对频繁读取优化此操作,您需要将每个用户应该看到的帖子存储在该用户的文档中。因此,与 Twitter 相比,您几乎拥有一个包含每个用户的 twitter 提要的文档。或者,如果单个文档的数据过多,您可能希望将其放入集合中。我经常将其解释为在数据库中对应用的屏幕进行建模。

这与关系数据库中的典型数据模型非常不同,因此需要时间来适应是正常的。对于一个好的介绍,我建议:

【讨论】:

    【解决方案2】:

    开发像 Twitter 这样的社交媒体应用程序。 Firestore 查询是不够的。 Twitter 为每个用户生成个性化的时间线。 这就是云功能发挥作用的地方。

    您需要一个云功能来监控新帖子并将其复制到其关注用户的时间线中。 您不需要复制整个推文数据。您可以只复制推文 ID 和其他需要排序的字段,例如时间戳。

    所以当我查询我的时间线时,我会得到所有的推文 ID。 然后我可以在用户即将滚动时加载原始推文。 因为喜欢和不喜欢应该会影响原始推文。

    【讨论】:

      猜你喜欢
      • 2012-04-19
      • 1970-01-01
      • 2014-01-31
      • 2021-04-22
      • 2019-02-26
      • 2023-03-26
      • 2012-02-27
      • 2011-04-10
      • 1970-01-01
      相关资源
      最近更新 更多