collections - firestore 子集合的优点

Question

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

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

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

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

相对

家庭 -> 家庭:{name:'Smith'} -> 人 -> 人

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

Answer 1

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

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

2 - 默认情况下对查询进行索引:查询性能与结果集的大小成正比，而不是与数据集的大小成正比。 所以不管你的集合的大小，性能取决于你的结果集的大小。

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

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