时间戳

首页 > 解决方案 > 在 Firebase 中使用字段而不是文档，不好的做法？

typescript - 在 Firebase 中使用字段而不是文档，不好的做法？

问题描述

我实际上是在尝试找到最有效的方法来减少我的 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 文档便宜得多，但有些事情告诉我这不是一个好习惯。

有什么理由我不应该采用这种方法吗？

谢谢

标签： typescriptfirebasegoogle-cloud-firestore

解决方案

我认为这是一个不好的做法：

Cloud Firestore 始终下载完整文档

想象一下，一个文档中有几千个字段，并且有几个用户为这个文档做出贡献，并且每秒都在更改字段。只需一分钟，您将拥有（！）每个用户60 MB的这个文档的数据使用量。

如果您将其拆分为多个文档，则每个用户只能拥有max。大多数时候，用户至少已经缓存了一些文档，这意味着这将再次进一步降低使用率。1 MB

Firestore 未针对它进行优化

正如我已经提到的，缓存 根本不起作用。即使 99% 的字段保持不变，所有这些值也会在每次另一个字段更改时更新。

这也会对查询产生负面影响，因为它们是为多个文档构建的。

你会付出更多

Cloud Firestore 针对文档读取进行了优化——它们并不昂贵。然而，带宽很昂贵：

请参阅Firebase 定价和网络费用（您还必须付费并获得免费配额）Google Cloud 定价：

所以在上面的例子中，我们可以清楚地看到差异可以很容易地大两个数量级（MB 出口到 K 读取），但是，对于相同的定价，只允许一个数量级。我可以很容易地想象您使用您的方法支付 10 倍以上的费用，这可能是值得的，具体取决于地区。

顺便说一句，我可能弄错了确切的定价。您可以在此处发现 Cloud Firestore 请求也可以根据带宽计费，显然在您项目的App Engine 配额页面上。

推荐阅读