实际上，我正在努力寻找最有效的方法来减少Firebase应用程序中的读取次数。
我没有为每个对象创建一个新的文档，而是考虑将每个对象插入同一文档的新字段中。
以下是我在应用程序中使用的一个典型对象：
{
"restaurantName" : "The Love story",
"openingTimes" : {"opening" : "9AM", "closing" : "11pm"},
"numberOfReviews" : 2340
}
根据Firebase的说法，文档的大小限制为1MB，在我的情况下，这足以放置大约2000个对象。
通过在一个文档上制作快照，我可以读取文档的所有字段，路径如下：payload['_document']['proto']['fields']
this.afs.collection('MyCollection').doc('restaurantName').snapshotChanges().subscribe(data => {
console.log('All the fields of my doc = ', payload['_document']['proto']['fields'])
});
这似乎运行良好，每次文档发生更改时只算作1次文档读取，对吗？
这种方法比加载X文档要便宜得多，但告诉我这不是一个好的做法。
有什么理由让我不采用这种方法吗？
谢谢
我认为这是一种糟糕的做法：
Cloud Firestore始终下载完整文档
想象一下，在一个文档中有几个千个字段，并且一些用户对该文档进行贡献，并每秒更改其中的字段。在一分钟内，您将为每个用户获得60 MB(！(这一文档的数据使用情况。
如果将其拆分为多个文档，则每个用户最多只能有1 MB。大多数情况下，用户至少已经缓存了一些文档，这意味着这将再次进一步减少使用量。
Firestore没有为此进行优化
正如我已经谈到的，缓存将根本不起作用。即使99%的字段保持不变，每次其他字段更改时，所有这些值都会更新。
这也会对查询产生负面影响，因为它们是为多个文档构建的。
你会付更多
Cloud Firestore针对文档读取进行了优化——它们并不十分昂贵然而，带宽非常昂贵：
查看Firebase定价和网络成本(您还必须支付并有免费配额(谷歌云定价：
-
您支付
$0.06/100K文档读取。 -
网络定价略有不同；比方说
0.05$/GB网络出口。
因此，在上述情况下，我们可以清楚地看到，差异很容易会大两个数量级(MB出口到K读取(，然而，对于相等的定价，只允许一个数量级。我可以很容易地想象，你用你的方法支付10倍以上的费用，这可能是值得的，这取决于地区。
顺便说一句，我可能弄错了确切的价格。您可以在这里发现Cloud Firestore请求也可以根据带宽计费，显然在您项目的应用程序引擎配额页面上也是如此。
只要文档的大小没有超过1MB的限制，就没有任何技术可以阻止您采用这种方法。
然而，您可能会遇到此数据模型的其他一些限制/复杂性：
- 如果您只想查询一家餐厅怎么办？你会下载2000家餐厅的数据只是为了获得其中一家餐厅的价值吗
- 根据您存储餐厅对象集合(数组或地图(的方式，如果您只想更新一家餐厅的一个元素，则可能需要下载整个集合