读取带有子集合的文档的 Firestore 计费答案

【问题标题】：Firestore billing for reading a document with subcollections读取带有子集合的文档的 Firestore 计费
【发布时间】：2019-06-09 00:59:36
【问题描述】：

我正在制作一个应用程序，它会存储用户使用我的应用程序学习了多少分钟。我的 Firestore 数据库以“用户”集合开始，每个用户都有自己的文档，该文档由在 Auth 中生成的用户 ID 命名。

我的问题是，如果我阅读他们的 userID 文档，它的子集合中有很多文档，这算作一次阅读，还是也计算子集合中的文档数？

提前谢谢你。

【问题讨论】：

标签： ios swift firebase google-cloud-firestore

【解决方案1】：

Torewin 的答案大部分是正确的，但它缺少一个重要的细节。它说：

如果您检索文档；在任何地方，它都算作一次阅读

这并不完全正确。缓存文档读取不计费为读取。这是 Firestore 客户端 SDK 的一项重要功能，有助于降低计费成本。如果您使用source option 缓存（选项为“缓存”或“服务器”或“默认”）获取单个文档，则将首先查询缓存，并且您无需计费即可获得该文档。缓存也用于应用离线时的查询结果。

查询结果也是如此。如果文档出于某种原因来自缓存，则不会为该读取计费。

我不确定 Torewin 在 cmets 中的含义是什么：“他们建议您进行多次读取而不是 1 次大读取，因为这样可以省钱”。所有读取在计费方面都是相同的“大小”，仅考虑读取本身的成本。文档的大小仅与 Internet 出口使用成本有关，对此有 documentation on pricing。

值得注意的是，文档不能“包含”其他文档。文档包含在集合或子集合中。这些集合只有一个“路径”来描述他们居住的地方。子集合可以在没有“父”文档的情况下存在。如果文档不存在，但在其下组织了一个集合，则文档 ID 在控制台中以斜体显示。当您使用客户端 API 删除文档时，不会删除其任何子集合。在这方面，删除被称为“浅”。

【讨论】：

感谢您的洞察力。尽管如此，我还是决定重新构建我的数据模型，以便每个请求只需要读取一个文档。这应该会大大降低阅读量。
'文档不能“包含”其他文档'——啊！所以，即使一个文档包含与其他文档的子集合，它不像一个巨大的 JSON 树（低级文档实际上是包含其父子集合的文档的子集）？凉爽的！所以这就是为什么每个文档读取总是花费一个文档，是吗？

【解决方案2】：

如果您指的是从 FireStore 访问 Document（在本例中为您生成的用户 ID）是否需要 1 次阅读？

我想答案是肯定的。

从 Firestore 进行的任何查询或读取都只会提取您要映射到的引用。例如，如果您在 User -> userID -> 3rd document 中抓取第 3 个文档，则只会返回第 3 个文档。该集合中的任何其他文档或除 userID 之外的任何集合中都没有。

这是否回答了您的问题，还是您提出了完全不同的问题？

供参考：https://firebase.google.com/docs/firestore/pricing#operations

编辑：从查询中提取的每个单独的文档都将被收费。例如，如果您拉取父集合（其中包含 6 个文档），您将需要为所有 6 个文档付费。这个想法是只获取您需要的文档或使用光标来恢复长时间运行的查询。例如，如果您只希望与使用特定日期的数据相关的文档（如果您的数据是这样设置的），那么您将只检索该特定文档而不检索集合中其他日期的所有文档.

一种简单的思考方式是：如果您检索文档；在任何地方，它都算作一次读取。

【讨论】：

因此，如果我有一个带有 userID 的文档，它下面还有更多文档，而我只是阅读了整个 userID 文档，那就是一次阅读。拿到文件后，我还能再往里走，找回资料对吧？
啊，如果我理解你的话，告诉我 - 你想阅读整个用户 ID 文档（在阅读中你想要所有的集合和文档，集合和文档 - 等等）所以您可以在初始读取后对其进行本地排序吗？
是的。存储后，我将搜索文档。文件大小不会太大，所以应该没问题。
更新了我的答案。不幸的是，根据 Firebase 文档的措辞，它明确指出，检索到的每个文档都将计为一次阅读。他们建议您进行多次阅读而不是 1 次大阅读，因为这样可以省钱。希望对您有所帮助。
啊，这是一种耻辱，但有道理。非常感谢。