Firestore-如何构建Feed和关注系统

Question

我将Firebase实时数据库用于我的测试社交网络应用程序，您可以在其中跟踪和接收所关注的人的信息。传统的社交网络。我的数据库结构如下：Users--USER_ID_1----name----email--USER_ID_2----name----emailPosts--POST_ID_1----image----userid----date--POST_ID_2----image----userid----dateTimeline--User_ID_1----POST_ID_2------date----POST_ID_1------date我还有另一个节点“ Content”，其中仅包含所有用户帖子的ID。因此，如果“ A”跟在“ B”之后，那么B的所有帖子ID都会添加到A的时间轴中。如果B发布了一些内容，那么它也会被添加到其所有关注者的时间表中。现在这是我的实时数据库解决方案，但显然存在一些可伸缩性问题如果某人拥有10,000个关注者，而在10,000个关注者的时间轴中添加了新帖子。如果某人发布的帖子数量超过每个新关注者在其时间轴中收到的所有帖子。这些是一些问题。现在，我正在考虑将整个事情转移到Firestore上，因为它被称为“可伸缩”。因此，我应该如何构建数据库的结构，以便可以在Firestore中消除我在实时数据库中遇到的问题。

Answer 1

有两种情况

您应用中的用户只有少数关注者。

您应用中的用户拥有大量关注者。如果我们要将整个关注者存储在Firestore中的单个文档中的单个数组中。然后它将达到每个文档1 MiB的存储限制。

在第一种情况下，每个用户都必须保留一个文档，该文档将关注者列表存储在单个数组中的单个文档中。通过使用arrayUnion()和arrayRemove()，可以有效地管理关注者列表。而且，当您要在时间轴中发布内容时，必须在发布文档中添加关注者列表。

并使用下面给出的查询来获取帖子

postCollectionRef.whereArrayContains("followers", userUid).orderBy("date");

在第二种情况下，您只需要根据关注者数组的大小或数量来中断用户关注文档。在将数组的大小达到固定大小后，下一个关注者的ID必须添加到下一个文档中。并且第一个文档必须保留字段“ hasNext”，该字段存储布尔值。添加新帖子时，您必须复制帖子文档，并且每个文档都包含较早中断的关注者列表。我们可以进行与上面给出的相同的查询来获取文档。