在创建新应用之前，我想确保定价模式正确无误。
例如，在电话簿应用中，我有一个名为 userList 的集合，其中包含一个用户列表，这些用户是单个文档。
我的列表中有50k用户，这意味着我的收藏中有50k个文档。
如果我要获取userList集合，它将读取所有50k文档。
FireStore允许 50k文档读取。这是否意味着每个文档读取50k文档或读取50k文档？
如同在我的电话簿应用程序的示例中，如果它是50k文档总共读取，我将在一次接听电话中用完免费限制。
答案 0 :(得分：3)
免费配额适用于整个项目。因此，您可以在整个项目下阅读50.000个文档。
阅读50K用户档案文件确实会一次性使用该免费配额。
读取大量文档通常是在使用NoSQL数据库时应该尝试防止的。
访问Firestore的客户端应用程序应该只读取他们将立即向用户显示的数据。并且你无法在屏幕上安装50K用户。
因此，您更有可能在聚合用户集合的情况下进行聚合。例如。比如：
NoSQL数据库的查询功能通常比传统的关系数据库更受限制，因为它们专注于确保读取可伸缩性。在将某些内容写入数据库时，您经常会做额外的工作，如果作为交换，您可以在从数据库中读取时获得更好的性能。
为了获得更好的性能，您需要将这些聚合值存储在数据库中，然后在编写用户配置文件时更新它们。因此，您将拥有一个“userCount”，一个包含“userCount for each unique username”的文档，以及一个“averageUsernameLength”。
有关如何运行此类聚合查询的示例，请参阅：https://firebase.google.com/docs/firestore/solutions/aggregation。对于较低的写入量，您还可以考虑使用云功能更新计数器。
答案 1 :(得分：2)
如果您实际上必须提取整个5万个文档集合，那么您可能应该问的问题是如何正确构建Firestore数据库。
您很有可能需要使用查询 WHERE子句，根据文档中的某些条件来过滤这些文档。每个客户端设备在本地保存5万个文档，听起来好像数据库计划不佳，而且可能存在安全风险。
Each returned document from your query counts as 1 read。如果没有与您的查询匹配的内容，则会收取1读。如果有5万个匹配项，则会收取5万次读取。
例如，您可以检索登录的用户文档，并向1 read收取以下费用：
db.collection('userList').where('uid', '==', clientUID)
注意：从2018年10月10日开始，Firestore每天首50k的费用为每10万次读取收取6美分（USD）。
答案 2 :(得分：0)
不要一次性致电所有用户。您可以限制查询以获取有限数量的用户。当用户滚动查询时，它将获得更多用户。而且没有人会滚动到5万个用户，因此您可以摆脱一大堆成本。这就像在回收视图的情况下节省内存。