Firestore + Twitter 克隆：使用子集合与根级集合存储推文？答案

【问题标题】：Firestore + Twitter Clone: Store tweets using subcollection vs root-level collection?Firestore + Twitter 克隆：使用子集合与根级集合存储推文？
【发布时间】：2019-01-27 01:24:22
【问题描述】：

出于学习目的，我打算使用 Firestore 创建 Twitter 克隆。

首先，我想我需要两个集合：users 和 tweets。我想提供所有users 的所有推文的主要提要，这很容易做到：

db.collection('tweets').get()
    .then(querySnapshot => {
    querySnapshot.forEach(tweet => {
        console.log(`${tweet.data()}`);
    })
})

如果我希望能够查询特定用户的推文列表（当查看该用户的个人资料时）怎么办？

据我了解，我有三种选择，但我不确定每种方法的所有优缺点：

选项 1：创建一个包含推文的用户子集合：

db.collection('users').doc('username_123').collection('tweets').get()

选项 2：创建一个具有合适名称的根级集合，该名称将显示数据的层次结构：

var username = 'username_123';
db.collections('tweets__' + username).get()

选项 3：使用相等运算符查询：

var username = 'username_456';
db.collection('tweets').where("username", "==", username).get()

我想选择一种在规模上具有成本效益的方法。

【问题讨论】：

几周前我开始使用 firebase，但我知道：如果您总是浏览朋友的帖子，选项 1 非常棒。但是效率低下，如果您想查询所有推文（您还必须查询父级（用户）。选项 3 非常适合查询所有推文（如提要），但如果您愿意，不如选项 1 快仅查询朋友的推文（当您显示他们的个人资料时。不能告诉选项 2。

标签： firebase google-cloud-firestore

【解决方案1】：

这是一个很好的问题，我自己一直在调查。我看到两个选项，并且更喜欢选项 1。

选项 1： 用户提要读取速度快，价格适中

每个新帖子都写在名为 post_user 的顶级集合中，并被赋予一个唯一标识符 postID_userID。文档中的字段是：

文本（字符串）
用户ID（字符串）
originalPosterID（字符串）
原始（布尔真或假）

然后，每个帖子都会根据需要为原始发布者的每个追随者重写多次，将 userID 替换为该特定追随者的 ID，并将 original 设置为 false。

当用户打开应用时，只需要一个 Firestore 查询：

查询：查找过去 20 天内 userID = currentUserID 的所有帖子

Firestore 查询速度与结果集成正比，而不是与整个数据集成正比，因此这是一个非常快的查询。

应用程序组合这些数据并以无限滚动的形式将其呈现给用户。由于不需要合并数据，因此完成得非常快。

当用户滚动到结果的末尾时，上述查询会在接下来 20 天的帖子中重复并加载（就像 Facebook 的无限滚动条一样）。

每个新帖子的写入次数（将帖子添加到所有关注者）可能会导致客户端体验变慢。因此，也许客户端只创建用户帖子，但是一旦创建并且用户得到确认，就会运行 Cloud Function 将其发布到所有关注者的提要。客户端应用程序不会等待所有这些，因此它会很快，并且关注者会在一分钟左右内看到新帖子。 CRON 作业也许也可以用于此目的，但我不确定这是否会节省任何成本。

选项 2：用户提要读取速度较慢，成本较低

每个新帖子仅在称为帖子的顶级集合中写入一次，并被赋予一个唯一标识符 postID。文档中的字段是：

文本（字符串）
用户ID（字符串）

当用户打开应用时，Firestore 查询很多，耗时更长（关注的人越多，耗时越长）：

查询 1：查找用户关注的所有人的用户 ID （followedUserA、followedUserB、followedUserC 等...）
查询 2A：查找 followUserA 在过去 20 天内的所有帖子
查询2B：查找followedUserB在过去20天内的所有帖子
查询2C：查找followedUserC在过去20天内的所有帖子
等等....（无论用户关注多少人）

然后在客户端，这些结果被合并。根据用户关注的人数，这可能需要一段时间。然后，该应用会以无限滚动条的形式将帖子呈现给用户。

当用户滚动到结果的末尾时，必须在接下来的 20 天内重复上述所有查询和结果合并。

【讨论】：

【解决方案2】：

我认为如果您选择选项 1 中提到的用户集合中的推文子集合会更好

因为很容易查询每个用户的推文
对于查询所有推文，您可以使用Firestore collection group query

【讨论】：