在firestore中使用子集合有什么好处吗？

Question

我为我的应用的用户集合中的每个文档都有一个子集合。此子集合存储与用户相关的文档，但是它们也可以保存到主集合中，每个文档都有一个关联的 userId。

我选择了这种结构，因为它在当时似乎是最明显的，但我可以想象，如果我需要进行数据库维护，它将使事情变得更加困难。例如，如果我想清理这些文档，我必须先查询每个用户，然后再查询每个用户的文档，而如果我有一个主集合，我可以只查询所有文档。

这让我不禁要问，如果可以将这些文档与一个ID关联起来，那么子集合到底有什么意义呢？如果你的文档接近1MB的限制，你可以扩展它吗？

Answer 1

很惊讶这之前没有提到过，但子集合可以（在某些情况下）帮助绕过订单通过限制：

不能按等式 （==） 或子句中包含的字段对查询进行排序。

假设您要获取用户最近 10 次登录：

顶级：

//We can't use .orderBy after .where('==')
USER_LOGINS.where('userId', '==', {uid}).limit(10) 

子集合:

//With a subcollection we can order and limit properly
USERS.doc({uid}).collection('LOGINS').orderBy('unixCreated', 'desc').limit(10);

Answer 2

我发现子集合的一个最大优点是它们有自己的写速率限制，因为每个子集合都有自己的索引(假设没有集合组索引)。对于小型应用程序来说，这可能不是一个问题，但是对于中型/大型应用程序来说，这可能非常重要。

想象一个聊天应用程序，其中每个聊天都有一系列消息。您需要按时间戳为邮件编制索引，以便按时间顺序显示邮件。顺序值的 Firestore 写入限制为 500/秒，这绝对是中型应用所能达到的（特别是如果您考虑恶意用户编写脚本消息的可能性 - 目前使用安全规则不容易防止）

// root collection

/messages {
  chatId: string
  timeSent: timestamp // the entire app would be limited to 500/second
}

// sub-collection

/chat/{chatId}/messages {
  timeSent: timestamp // each chat could safely write up to 500/second
}

Answer 3

编辑： 2021年10月29日：

要明确文档中存在的以下句子:

如果您不根据具有顺序值的字段进行查询。

时间戳不能被视为连续的。但是，它仍然可以被认为是连续的。同样的规则也适用于按字母顺序（Customer1，Customer2，Customer3，...），或者几乎所有可以被视为可预测生成价值的东西。

Firestore索引中的这种顺序数据最有可能被写入存储介质上的物理邻近区域，因此存在这种限制。

话虽如此，请注意Firestore使用一种机制将文档映射到相应的位置。这意味着，如果值不是随机分布的，则写入操作将不会正确分布在各个位置上。这就是这种限制存在的原因。

另请注意，您在特定时间内可以向此类位置写入多少数据是有物理限制的。可预测的键/值很可能最终会出现在同一个位置，这实际上是不好的。因此需要进行更多更改才能达到限制。

编辑：2021年7月16日：

由于这个答案听起来有点老套，我将尝试添加使用随时间推移发现的子集合的更多优点：

1. 子集合将始终为您提供更结构化的数据库模式，因为您始终可以引用仅与特定文档相关的子集合。因此，您只能嵌套与特定文档相关的数据。
2. 如前所述，子集合的最大深度为100。因此，这里的一个重要特性是FirestQuery在级别1时的速度与在级别100时一样快。因此不应该担心深度。此功能已测试。
3. 默认情况下，子集合中的查询会被索引，就像顶级集合一样。
4. 在速度方面，查询顶级集合、子集合或集合组并不重要，速度总是相同的，只要查询返回相同数量的文档。发生这种情况是因为查询性能取决于您请求的文档数量，而不是搜索的文档数量。因此查询子集合与查询顶级集合具有相同的效果，完全没有缺点。
5. 在子集合中存储文档时，请注意无需将文档ID存储为字段，因为默认情况下它是引用的一部分。这意味着您可以在子集合中存在的文档中存储更少的数据。更重要的是，如果您将相同的数据保存在顶级集合中，并且您需要创建一个Query，其中EqualTo（）调用orderBy（）调用，则需要索引。
6. 在安全性方面，子集合允许继承安全规则，这很有用，因为我们可以编写越来越少的代码来保护数据库。

就目前而言，如果我发现了其他好处，我会更新答案。

让我们举一个例子。让我们假设我们有一个测验应用程序的数据库模式，如下所示：

Firestore-root
    |
    --- questions (collections)
          |
          --- questionId (document)
                 |
                 --- questionId: "LongQuestionIdOne"
                 |
                 --- title: "Question Title"
                 |
                 --- tags (collections)
                      |
                      --- tagIdOne (document)
                      |     |
                      |     --- tagId: "yR8iLzdBdylFkSzg1k4K"
                      |     |
                      |     --- tagName: "History"
                      |     |
                      |     --- //Other tag properties
                      |
                      --- tagIdTwo (document)
                            |
                            --- tagId: "tUjKPoq2dylFkSzg9cFg"
                            |
                            --- tagName: "Geography"
                            |
                            --- //Other tag properties

其中< code>tags是< code>questionId对象中的子集合。现在，让我们将< code>tags集合创建为顶级集合，如下所示:

Firestore-root
    |
    --- questions (collections)
    |     |
    |     --- questionId (document)
    |            |
    |            --- questionId: "LongQuestionIdOne"
    |            |
    |            --- title: "Question Title"
    |
    --- tags (collections)
          |
          --- tagIdOne (document)
          |     |
          |     --- tagId: "yR8iLzdBdylFkSzg1k4K"
          |     |
          |     --- tagName: "History"
          |     |
          |     --- questionId: "LongQuestionIdOne"
          |     |
          |     --- //Other tag properties
          |
          --- tagIdTwo (document)
                |
                --- tagId: "tUjKPoq2dylFkSzg9cFg"
                |
                --- tagName: "Geography"
                |
                --- questionId: "LongQuestionIdTwo"
                |
                --- //Other tag properties

这两种方法之间的区别是：

• 如果您想查询数据库以获取特定问题的所有标记，使用第一个模式非常简单，因为只需要集合引用（问题-

这种技术称为数据库扁平化，在Firebase中是一种非常常见的做法。因此，仅在需要时使用此技术。因此，在您的情况下，如果您只需要显示单个问题的标签，请使用第一个模式。如果您想以某种方式显示所有问题的所有标签，建议使用第二个模式。

如果你的文档接近1MB的限制，你可以扩展它吗？

如果文档中有对象的子集合，请注意，该子集合的大小不计入1 MiB限制。仅计算存储在文档属性中的数据。

编辑2019年10月1日：

根据@ShahoodulHassan的评论：

因此，您无法使用第一个架构获取所有问题的所有标记？

实际上，现在有了，我们可以使用Firestore集合组查询获得所有问题的所有标签。需要注意的一点是，所有子集合必须具有相同的名称，例如标记。