firestore子集合的优点

Question

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

例如,对于跨越大型集合的单个密钥,firestore查询的时间与从较小的集合中获取所有项目相比如何？

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

人 - >人:{family:'Smith'}

与

家庭 - >家庭:{姓名:'史密斯'} - >人 - >人

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

Answer 1

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

查询所有的人与family 'Smith'从people 顶层集合真的没有任何慢不是要求所有people的在'Smith' family 子集。

这在了解 Cloud Firestore 视频系列的如何构建您的数据一集中进行了解释。

需要注意顶级集合和子集合之间的一些权衡。根据您打算使用的特定查询，您可能需要创建composite indexes以查询顶级集合或collection group indexes查询子集合。这两种指数类型都计入200 指数豁免限制。

这些权衡在“理解集合组查询”博客文章底部附近以及映射、数组和子集合中详细讨论，我的天哪！了解 Cloud Firestore 视频系列的一集。

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

Answer 2

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

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

2 - 默认情况下对查询建立索引:查询性能与结果集的大小成比例,而不是数据集.因此,与集合的大小无关,性能取决于结果集的大小.

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

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