Firebase Cloud Firestore的成本优化模式:通过集合获取文档 [英] Cost optimization patterns for Firebase Cloud Firestore: fetching documents over collections

问题描述

我的目标是在使用Firebase Cloud Firestore时以成本优化我的应用程序的体系结构.我了解Cloud Firestore的定价模型是基于每个读/写的.因此，出于成本优化目的，我正在考虑以下模式.我想知道这是最佳实践"还是反模式.

My goal is to optimize my app's architecture for cost when using Firebase Cloud Firestore. I understand Cloud Firestore's pricing model is on a per read/write basis. So I'm considering the following pattern for cost optimization purposes. I want to know whether it's "best practice" or an anti-pattern.

这个想法是，每当我创建一个要添加到集合中的新文档时，我都会让用户更新第二个主文档"，其中包含文档内容的某些子集以及来自许多不同用户的许多相似文档中的相同内容

The idea is that whenever I create a new document to add to a collection, I will have the user update a second "master document" that contains some subset of the doc content plus the same from many similar docs from many different users.

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

Then, when I go to fetch the list data, instead of fetching a collection and getting charges for each document read from the collection (many reads), I retrieve only the master document instead (one read).

在代码中，看起来如下.

In code, it would look as follows.

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

这是一种成本明智的最佳做法吗?还是这是反模式?

Is this a cost-wise best-practice? Or is this an anti-pattern?

推荐答案

拥有主文档"的想法是一个好主意，因为即使更改其中的多个属性，您也可以进行一次写操作但有一个关于约束的问题，文档有限制 .因此，在文档中可以放入多少数据方面存在一些限制.根据有关用法和限制的官方文档:

The idea of having a "master document" is a good one because you'll be able to make a single write operation even if you change multiple properties within it but there is a problem regarding a constraint, documents have limits. So there are some limits when it comes to how much data you can put into a document. According to the official documentation regarding usage and limits:

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

Maximum size for a document: 1 MiB (1,048,576 bytes)

如您所见，单个文档中的数据总数限制为1 MiB.当我们谈论存储文本时，可以存储很多，但是随着文档越来越大，请注意此限制.

As you can see, you are limited to 1 MiB total of data in a single document. When we are talking about storing text, you can store pretty much but as your document getts bigger, be careful about this limitation.

Cloud Firestore经过优化，可以存储大量小文件.因此，您应该利用此功能.即使您需要复制和更新单独集合中的多个文档，我还是建议您以这种方式继续进行.

Cloud Firestore is optimized for storing large collections of small documents. So you should take advantage of this feature. Even if you need to duplicate and update several documents within separate collections, I recommend you go ahead in this way.

P.S.如果您担心成本，请查看Firebase实时数据库并尝试将其一起使用.工作正常.

P.S. If you worry about costs, take also a look at Firebase realtime database and try to use them together. Are working pretty fine.

这篇关于Firebase Cloud Firestore的成本优化模式:通过集合获取文档的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！