Mow*_*zer 8 firebase google-cloud-platform google-cloud-firestore
我的目标是在使用 Firebase Cloud Firestore 时优化应用架构的成本。我了解 Cloud Firestore 的定价模型是按读/写计算的。因此,出于成本优化的目的,我正在考虑以下模式。我想知道这是“最佳实践”还是反模式。
这个想法是,每当我创建一个新文档以添加到集合中时,我都会让用户更新第二个“主文档”,其中包含文档内容的某个子集以及来自许多不同用户的许多类似文档的相同内容。
然后,当我去获取列表数据时,我不是获取一个集合并为从集合中读取的每个文档收取费用(多次读取),而是只检索主文档(一次读取)。
在代码中,它将如下所示。
取而代之的是:db.collection("reviews")
.get()
.then(querySnapshot => {
querySnapshot.forEach(doc => {
// doc.data() is never undefined for query doc snapshots
console.log(doc.id, " => ", doc.data());
});
})
Run Code Online (Sandbox Code Playgroud)
我这样做:
const docRef = db.collection("reviews").doc("MasterList");
docRef.get().then(doc => {
if (doc.exists) {
console.log("Document data:", doc.data());
} else {
// doc.data() will be undefined in this case
console.log("No such document!");
}
})
Run Code Online (Sandbox Code Playgroud)
这是成本方面的最佳实践吗?或者这是一种反模式?
编辑: 2021 年 8 月 27 日
为了更好地理解,我写了一篇关于这个主题的文章:
拥有“主文档”的想法是个好主意,因为即使您更改其中的多个属性,您也可以进行单个写入操作,但存在关于约束的问题,文档有限制。因此,当涉及到可以放入文档的数据量时,存在一些限制。根据有关使用和限制的官方文档:
文档的最大大小:1 MiB(1,048,576 字节)
如您所见,单个文档中的数据总量限制为 1 MiB。当我们谈论存储文本时,您可以存储很多内容,但随着文档变大,请注意此限制。
Cloud Firestore 已针对存储大量小型文档进行了优化。所以你应该利用这个功能。即使您需要在单独的集合中复制和更新多个文档,我也建议您以这种方式进行。
PS 如果您担心成本,还可以查看 Firebase 实时数据库并尝试将它们一起使用。工作得很好。
| 归档时间: |
|
| 查看次数: |
2345 次 |
| 最近记录: |