如何构建社交网络数据库结构，例如twitter我们可以关注用户并在我们的时间轴中获取他们的所有推文，我已经检查了这个Firestore - 如何构建提要和关注系统
，但帖子中的解决方案看起来有缺陷。
Firestore 的不同之处在于它需要冗余数据才能有效地访问数据，但假设我正在关注 1000 人，如果我需要通过查询我关注的每 15 个用户的数据并使用limit(10)方法来获取所有这些用户的帖子，那么orderBy(timeStamp)可能会有未读查询之间的帖子，因为我们正在使用 获取帖子last post timeStamp，如何在 Firestore 中为社交媒体应用程序构建数据
在 NoSQL 数据库上对用例进行建模时，您倾向于针对应用程序的功能和频繁的读取操作进行优化。
因此，在社交媒体应用程序中，您的主要功能可能是用户可以看到他们关注的每个人的最新帖子。要针对频繁读取优化此操作，您需要将每个用户应该看到的帖子存储在该用户的文档中。因此，与 Twitter 相比，您几乎拥有一个包含每个用户的 twitter 提要的文档。或者，如果单个文档的数据过多，您可能希望将其放入集合中。我经常将其解释为在数据库中对应用程序的屏幕进行建模。
这与关系数据库中的典型数据模型非常不同，因此需要时间来适应是正常的。为了一个好的介绍，我建议：
开发像 Twitter 这样的社交媒体应用程序。Firestore 查询是不够的。Twitter 为每个用户生成个性化的时间线。这就是云功能发挥作用的地方。
您需要一个云功能来监控新帖子并将其复制到其后续用户的时间线中。您不需要复制整个推文数据。您可以只复制推文 ID 和其他需要排序的字段，例如时间戳。
所以当我查询我的时间线时，我会得到所有的推文 ID。然后我可以在用户即将滚动时加载原始推文。因为喜欢和不喜欢应该影响原始推文。