Firestore - 如何构建提要和关注系统

Question

我将 Firebase 实时数据库用于我的测试社交网络应用程序，您可以在其中关注并接收您关注的人的帖子。传统的社交网络。 我像这样构建了我的数据库 -

Users
--USER_ID_1
----name
----email
--USER_ID_2
----name
----email

Posts
--POST_ID_1
----image
----userid
----date
--POST_ID_2
----image
----userid
----date

Timeline
--User_ID_1
----POST_ID_2
------date
----POST_ID_1
------date

我还有另一个节点“内容”，它只包含所有用户帖子的 ID。因此，如果“A”跟在“B”之后，那么 B 的所有帖子 ID 都会添加到 A 的时间轴中。如果 B 发布了一些内容，那么它也会被添加到其所有追随者的时间线中。

现在这是我的实时数据库解决方案，但它显然存在一些可扩展性问题

• 如果某人有 10,000 名关注者，则新帖子会添加到所有 10,000 名关注者的时间轴中。
• 如果某人的帖子数量多于每个新关注者在其时间轴中收到的所有帖子。

这些是一些问题。

现在，我正在考虑将整个事情转移到 Firestore，因为它被称为“可扩展”。那么我应该如何构建我的数据库，以便在 Firestore 中消除我在实时数据库中遇到的问题。

Answer 1

如果您的网络上有大量活动（例如关注 1,000 人的人，或发布 1,000 条帖子的人），其他答案将变得非常昂贵。

我的解决方案是为每个用户文档添加一个名为“recentPosts”的字段，该字段将是一个数组。

现在，无论何时发布帖子，都有一个检测 onWrite() 的云函数，并在其 userDocument 上更新该发布者的 recentPosts 数组以添加有关该帖子的信息。

因此，您可以将以下地图添加到 recentPosts 数组的前面：

{
"postId": xxxxxxxxxxx,
"createdAt": tttttt
}

将 recentPosts 数组限制为 1,000 个对象，超过限制时删除最旧的条目。

现在，假设您正在关注 1,000 个用户并想要填充您的提要...获取所有 1,000 个用户文档。这将计为 1k 次读取。

拥有 1,000 个文档后，每个文档都会有一个 recentPosts 数组。将客户端上的所有这些数组合并到一个主数组中，并按 createdAt 排序。

现在您可能拥有多达 100 万个帖子的 docID，所有这些都按时间顺序排序，仅用于 1000 次阅读。现在，当您的用户滚动他们的提要时，只需根据需要通过他们的 docID 查询这些文档，大概一次 10 个或其他什么。

您现在可以加载来自 Y 个关注者的 X 个帖子供 X + Y 阅读。

因此，来自 100 个关注者的 2,000 条帖子只有 2,100 次阅读。
因此，来自 1,000 名关注者的 1,000 条帖子只有 2,000 次阅读。
等等...

---

编辑 1) 进一步优化。加载 userDocuments 时，您可以使用 in query 一次将它们批处理 10 个...通常这没有什么区别，因为即使它已批处理，它仍然是 10 个读取...但是您也可以通过像 @987654327 这样的字段进行过滤@ 并检查它是否大于该用户文档的缓存值，那么任何尚未更新其 recentPosts 数组的用户文档都不会被读取。理论上，这可以为您节省 10 倍的碱基读取。

编辑 2) 您也可以将侦听器附加到每个 userDocument，以便在他们的 recentPosts 更改时获取新帖子，而无需在每次需要刷新提要时查询每个关注者。 （虽然 1,000 多个快照监听器可能是不好的做法，但我不知道它们是如何工作的）（Edit3：Firebase 将一个项目限制为只有 1k 个监听器，因此 edit2 不是可扩展的优化）

Answer 2

更新：21 年 8 月 28 日

我创建了一个理论上可扩展的解决方案。见here。

还有一些其他选项here。

---

我的可扩展想法是，用户可能有 1,000,000 多个关注者，但真正的用户关注的人不会超过 1000 人。我们可以简单地聚合他们的提要（帖子的集合）。这是我的理论：

收藏

/users
/users/{userId}/follows
/users/{userId}/feed
/posts

1。填充提要

填充提要需要首先运行，并且应该在云功能中。为避免费用，它只会将新帖子添加到您的提要中，而不是超过 10 天（或无论多么旧）的帖子。

populateFeed() - 类似这样的......

numFollowing = get('users/numFollowing');
lastUpdate = get('users/lastUpdate');
tenDaysOld = timestamp 10 days ago

// maybe chunk at 20 here...
for (numFollowing) {
  docs = db.collection('posts')
    .where('userId', '==', userId)
    .where('createdAt', '>', lastUpdate)
    .where('createdAt', '<', tenDaysOld);
  db.collection('users/${userId}/feed').batch.set(docs);

将users/${userId}/lastUpdate 更新为当前时间戳...

这样，您不会获得太多文档（例如只有 10 天），也不会浪费阅读已有文档。

2) 阅读提要

Feed 将是聚合的帖子。

loadFeed() - 在populateFeed() 之后调用它

db.collection('/users/${userId}/feed').orderBy('createdAt');

feed 中的文档只需要 createdAt 日期和 postId，因为您可以在前端拉出帖子，尽管您可以如果您不希望它发生变化，请存储所有数据：

postId: {
  createdAt: date
}

您的 userDoc 还将拥有：

{
  numFollowing: number,
  lastUpdate: date
}

应用应在加载时自动调用loadFeed()。可能有一个按钮运行populateFeed() 作为可调用的云功能（最好的），或者在本地运行。如果您的提要是可观察到的 firebase，它将在填充时自动更新...

只是一个想法...我认为可能有一些其他更清洁的方法来解决这个规模庞大的问题...

J

更新

我越想越觉得，我确实认为可以将帖子 onWrite 上的字段更新到所有关注者供稿。唯一的限制是时间，通常为 60 秒，最长可达 9min。实际上，您只需要确保异步批量更新即可。查看我的 adv-firestore-functions 包here:

Answer 3

我稍后才看到您的问题，但我也会尝试为您提供我能想到的最佳数据库结构。所以希望你会发现这个答案很有用。

我正在考虑一个架构，其中包含 users、users that a user is following 和 posts 的三个顶级集合：

Firestore-root
   |
   --- users (collection)
   |     |
   |     --- uid (documents)
   |          |
   |          --- name: "User Name"
   |          |
   |          --- email: "email@email.com"
   |
   --- following (collection)
   |      |
   |      --- uid (document)
   |           |
   |           --- userFollowing (collection)
   |                 |
   |                 --- uid (documents)
   |                 |
   |                 --- uid (documents)
   |
   --- posts (collection)
         |
         --- uid (documents)
              |
              --- userPosts (collection)
                    |
                    --- postId (documents)
                    |     |
                    |     --- title: "Post Title"
                    |     |
                    |     --- date: September 03, 2018 at 6:16:58 PM UTC+3
                    |
                    --- postId (documents)
                          |
                          --- title: "Post Title"
                          |
                          --- date: September 03, 2018 at 6:16:58 PM UTC+3

如果某人有 10,000 名关注者，则将新帖子添加到所有 10,000 名关注者的时间轴中。

这完全没有问题，因为这就是集合在 Firestore 中的原因。根据modeling a Cloud Firestore database的官方文档：

Cloud Firestore 针对存储大量小文档进行了优化。

这就是我将userFollowing 添加为集合而不是可以容纳其他对象的简单对象/映射的原因。请记住，根据有关limits and quota 的官方文档，文档的最大大小是1 MiB (1,048,576 bytes)。在集合的情况下，集合下的文档数量没有限制。事实上，Firestore 已经针对这种结构进行了优化。

因此，以这种方式拥有这 10,000 名追随者，将非常有效。此外，您可以以无需在任何地方复制任何内容的方式查询数据库。

如您所见，数据库非常非规范化，您可以非常简单地查询它。让我们举个例子，但在创建与数据库的连接并使用以下代码行获取用户的uid 之前：

FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
String uid = FirebaseAuth.getInstance().getCurrentUser().getUid();

如果您想查询数据库以获取用户关注的所有用户，您可以在以下参考中使用get() 调用：

CollectionReference userFollowingRef = rootRef.collection("following/" + uid + "/userFollowing");

因此，通过这种方式，您可以获得用户关注的所有用户对象。有了他们的 uid，您就可以轻松获取他们所有的帖子。

假设您想在时间轴上显示每位用户的最新三篇帖子。当使用非常大的数据集时，解决这个问题的关键是以更小的块加载数据。我在这个 post 的回答中解释了一种推荐的方式，您可以通过将查询游标与limit() 方法组合来对查询进行分页。我还建议您查看此 video 以获得更好的理解。因此，要获取每个用户的最新三个帖子，您应该考虑使用此解决方案。因此，首先您需要获取您关注的前 15 个用户对象，然后根据他们的uid，获取他们最近的三个帖子。要获取单个用户的最新三个帖子，请使用以下查询：

Query query = rootRef.collection("posts/" + uid + "/userPosts").orderBy("date", Query.Direction.DESCENDING)).limit(3);

当您向下滚动时，加载其他 15 个用户对象并获取他们最近的三个帖子等等。除了date，您还可以向post 对象添加其他属性，例如点赞数、cmets、分享等。

如果某人的帖子数量多于每个新关注者在其时间轴中收到的所有帖子。

没办法。没有必要做这样的事情。我已经在上面解释了原因。

2019 年 5 月 20 日编辑：

另一个优化用户应该看到他关注的每个人的所有最近帖子的操作的解决方案是将用户应该看到的帖子存储在该用户的文档中。

因此，如果我们举个例子，比如说 facebook，您需要有一个包含每个用户的 facebook 提要的文档。但是，如果单个文档可以容纳的数据过多 (1 Mib)，您需要将这些数据放入一个集合中，如上所述。

Answer 4

我认为一种可能性是创建另一个名为"users_following" 的顶级集合，其中包含一个名为"user_id" 的文档和一个包含用户关注的所有用户的数组的字段。在该"users_following" 文档中，可以拥有该特定用户的所有帖子的子集合或顶级集合也可以完成这项工作。下一个重要的事情是必须将最近的一篇帖子存储在"users-following" 文档中作为数组或映射。基本上，这些标准化数据将用于填充关注您的人的提要。但它的缺点是，即使该人最近添加了两个帖子，或者即使您以标准化方式存储两到三个帖子，您也只会看到每个人的一个帖子，而不是一次显示所有三个帖子（比如三个帖子同一用户连续）。但是，如果您只需要为每个用户显示一篇帖子，这仍然是一件好事。

Answer 5

我一直在为她建议的解决方案苦苦挣扎，主要是由于技术差距，所以我想出了另一个适合我的解决方案。

对于每个用户，我都有一个文档，其中包含他们关注的所有帐户，以及所有关注该用户的所有帐户的列表。

当应用启动时，我获得了关注当前用户的帐户列表，当用户发布帖子时，帖子对象的一部分是关注他们的所有用户的数组。

当用户 B 也想获得他们关注的人的所有帖子时，我只需在查询中添加一个简单的whereArrayContains("followers", currentUser.uid)。

我喜欢这种方法，因为它仍然允许我按我想要的任何其他参数对结果进行排序。

基于：

• 每个文档 1mb，根据我所做的谷歌搜索，它似乎包含 1,048,576 个字符。
• Firestore 生成的 UID 的长度似乎约为 28 个字符。
• 对象中的其余信息不会占用太多大小。

这种方法应该适用于拥有多达 37,000 名关注者的用户。

Answer 6

有两种情况

1. 您应用中的用户拥有少量关注者。

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

---

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

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

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

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

Answer 7

我浏览了一些 Firebase 文档，但我很困惑为什么 https://firebase.google.com/docs/database/android/structure-data#fanout 建议的实现不适用于您的情况。像这样的：

users
--userid(somedude)
---name
---etc
---leaders: 
----someotherdude
----someotherotherdude

leaders:
--userid(someotherdude)
---datelastupdated
---followers
----somedude
----thatotherdude
---posts
----postid

posts
--postid
---date
---image
---contentid

postcontent
--contentid
---content

该指南继续提到“这是双向关系的必要冗余。它允许您快速有效地获取 Ada 的成员资格，即使用户或组的列表扩展到数百万。”，所以它没有似乎可扩展性并不是 Firestore 独有的东西。

除非我遗漏了什么，否则主要问题似乎是时间线节点本身的存在。我知道它可以更轻松地生成特定用户时间线的视图，但这是以必须维护所有这些关系为代价的，并且会大大延迟您的项目。根据提交的用户，使用查询从与上述类似的结构中动态构建时间线是否效率太低？