Firebase云修复的成本优化模式:从集合中获取文档

Question

我的目标是优化我的应用程序的架构，在使用时要考虑成本。据我所知，Cloud的定价模型是基于每次读写的。因此，为了优化成本，我正在考虑下面的模式。我想知道这是“最佳实践”还是反模式。

这样做的想法是，每当我创建一个新文档以添加到集合中时，我将让用户更新第二个“主文档”，该文档包含文档内容的某些子集，以及来自许多不同用户的许多类似文档的相同内容。

然后，当我去获取列表数据时，我将只检索主文档(一次读取)，而不是获取集合中读取的每个文档的费用(很多次读取)。

在代码中，如下所示。

而不是这样：

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!");
  }
})

这是一个成本方面的最佳做法吗？或者这是反模式？

Answer 1

编辑：8月27日，2021

为了更好的理解，我写了一篇关于这个主题的文章：

• 如何降低修复成本？

拥有一个“主文档”的想法是一个好主意，因为即使您在其中更改了多个属性()，也可以执行单个写操作，但是在约束( 文件有限制 )方面存在问题。因此，当涉及到可以将多少数据放入文档时，会有一些限制。根据有关使用和限制的官方文档

文档的最大大小：1 MiB (1,048,576字节)

如您所见，单个文档中的数据总数仅限于1 MiB。当我们谈到存储文本时，您可以存储很多内容，但是随着文档变得更大，请注意这个限制。

云修复是为存储大型的小型文档集合而优化的。因此，您应该利用这个特性。即使您需要在单独的集合中复制和更新多个文档，我还是建议您继续这样做。

如果你担心成本问题，也可以查看Firebase实时数据库，并尝试将它们一起使用。工作得很好。