我的目标是在使用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());
});
})
我这样做:
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!");
}
})
这是一种成本明智的最佳做法吗?还是这是反模式?
答案 0 :(得分:2)
拥有“主文档”的想法是一个很好的主意,因为即使您更改其中的多个属性,您也可以进行一次写操作。 约束documents have limits。因此,在文档中可以放入多少数据方面存在一些限制。根据有关用法和限制的官方文档:
文档的最大大小: 1 MiB (1,048,576字节)
如您所见,单个文档中的数据总数限制为1 MiB。当我们谈论存储文本时,可以存储很多,但是随着文档越来越大,请注意这一限制。
Cloud Firestore经过优化,可以存储大量小文件。因此,您应该利用此功能。即使您需要复制和更新单独集合中的多个文档,我还是建议您以这种方式继续进行。
P.S。如果您担心成本,请同时查看Firebase实时数据库并尝试将它们一起使用。工作正常。