firestore子集合的优点

Question

firestore文档没有深入讨论使用子集合与顶级集合所涉及的权衡，但确实指出它们不太灵活且不太“可扩展”。鉴于您牺牲了在子集中设置数据的灵活性，除了精神上令人满意的结构之外，必须有一些明确的优势。

例如，对一个大型集合中的单个密钥进行firestore查询的时间与从一个小得多的集合中获取所有项目相比如何？

假设我们想要查询家庭单位中所有人的大型“人物”集合。或者，首先按系列将数据划分为族单位。

人物 - ＆gt; person：{family：'Smith'}

与

家庭 - ＆gt;家庭：{name：'Smith'} - ＆gt;人 - ＆gt;人

我希望后者更有效率，但这是正确的吗？每个人都有大的估计吗？ 子集合的任何其他优点（例如交易）？

Answer 1

关于在建模数据库时需要注意的子集合，我有一些关键点。

1 - 子集合为您提供了更加结构化的数据库。

2 - 默认情况下会对查询建立索引：查询性能与结果集的大小成比例，而不是数据集。 因此，无论您的收藏大小如何，效果取决于结果集的大小。

3 - 每个文档的最大大小为1MB 。例如，如果您的客户文档中有一系列订单，那么为每个客户创建订单子集可能是个好主意，因为您无法预见客户将拥有多少订单。通过这样做，您无需担心文档的最大大小。

4 - 定价：Firestore会向您收取文件读取，写入和删除费用。因此，当您在文档中创建许多子集而不是使用数组时，您将需要执行更多的读取，写入和删除操作，从而增加您的账单。

Answer 2

要回答有关效率的原始问题：

从family 顶级收藏集中查询所有拥有'Smith' people的人的确没有比询问慢people 'Smith' 子集合中的所有family。

“了解云Firestore”视频系列的How to Structure Your Data集对此进行了解释。

要注意的是顶级集合和子集合之间的权衡。根据您打算使用的特定查询，您可能需要创建composite indexes来查询顶级集合，或者创建collection group indexes来查询子集合。这两种索引类型都计入200 index exemptions limit。

在Understanding Collection Group Queries博客文章的底部附近和“了解云Firestore”视频系列的Maps, Arrays and Subcollections, Oh My!集中详细讨论了这些权衡。

我已经链接到两个视频的相关部分。

Answer 3

Todd在Firebase youtube视频中回答了这个问题

1）每分钟可以创建多少个文档存在限制 如果文件的价值始终在增加，则为一个单一收藏 （如时间戳记）

2）非常大的收藏集与 离线时的性能观点。但它们通常是 不错的选择。

Answer 4

我想知道同样的事情。该文档主要讨论数组与子集合。我的结论是，与顶级集合相比，使用子集合没有明显的优势。子集合以前有一些明显的技术局限性，但我认为最近引入的collection group queries消除了这些局限性。

这两种方法都有一些优点：

子集合：

• 您的数据库“感觉”更加结构化，因为列出的顶级集合较少。
• 不需要存储父文档的参考/外键/ id，因为数据库结构暗含了它。您可以通过子收款凭证ref找父母。

顶级收藏：

• 文档更易于删除。使用子集合时，需要确保先删除所有子集合文档，然后再删除父文档。没有为此的API，因此您可能需要滚动自己的辅助函数。
• 根据应用程序的不同，直接在每个（子）文档中具有父ID可能会使处理查询结果更容易。