firestore 文档没有深入讨论使用子集合与顶级集合所涉及的权衡，但确实指出它们的灵活性和“可扩展性”较低。鉴于您牺牲了在子集合中设置数据的灵活性，除了精神上令人满意的结构之外，还必须有一些明确的优势。
例如，与从小得多的集合中获取所有项目相比，对大型集合中的单个键进行 firestore 查询的时间如何？
假设我们要为一个家庭单元中的所有人查询一个大型集合“人”。或者，首先按家庭将数据划分为家庭单位。
人 -> 人：{family: 'Smith'}
相对
家庭 -> 家庭：{name:'Smith'} -> 人 -> 人
我希望后者更有效率，但这是正确的吗？每个都有大 O 估计吗？子集合的任何其他优势（例如交易）？
我有一些关于子集合的关键点，在对数据库建模时需要注意这些点。
1 – 子集合为您提供更结构化的数据库。
2 - 默认情况下对查询进行索引：查询性能与结果集的大小成正比，而不是与数据集的大小成正比。所以不管你的集合的大小，性能取决于你的结果集的大小。
3 –每个文档的最大大小为 1MB。例如，如果您的客户文档中有一系列订单，那么为每个客户创建订单子集合可能是个好主意，因为您无法预测客户将拥有多少订单。通过这样做，您无需担心文档的最大大小。
4 –定价：Firestore 向您收取文档读取、写入和删除的费用。因此，当您创建许多子集合而不是在文档中使用数组时，您将需要执行更多的读取、写入和删除操作，从而增加您的费用。
要回答有关效率的原始问题：
family 'Smith'从people 顶级集合中查询所有人确实并不比people在'Smith' family 子集合中查询所有人慢。
这在“了解 Cloud Firestore”视频系列的“如何构建您的数据”一集中进行了解释。
需要注意顶级集合和子集合之间的一些权衡。根据您打算使用的特定查询，您可能需要创建composite indexes查询顶级集合或collection group indexes查询子集合。这两种指数类型都计入200 个指数豁免限制。
这些权衡在了解集合组查询博客文章的底部和地图、数组和子集合中进行了详细讨论，哦，天哪！了解 Cloud Firestore 视频系列的一集。
我已经链接到两个视频的相关部分。
我想知道同样的事情。该文档主要讨论数组与子集合。我的结论是，与顶级集合相比，使用子集合没有明显的优势。子集合之前有一些明显的技术限制，但我认为随着最近引入集合组查询而消除了这些限制。
以下是这两种方法的一些优点：
子合集：
顶级收藏：
托德在 firebase youtube视频中回答了这个问题
1) 如果文档具有不断增加的值（如时间戳），则每分钟可以在单个集合中创建多少文档是有限制的
2) 从性能的角度来看，非常大的集合在离线时表现不佳。但它们通常是值得考虑的好选择。