对文档嵌套字段使用部分更新会毁掉我的银行帐户吗？

Question

我有一个使用此数据模型的应用程序：

objects: {
  0: { name: 'foo', items: [...] },
  1: { name: 'bar', items: [...] },
  ...
  999: { name: 'z', items: [...] }
}

一开始我并没有想到它会快速增长，现在一些文档有数百个条目，我被迫将我的帐户切换到 Blaze 计划。

我正在尝试看看是否有更好的方法来实现这个模型。 目前我正在使用这种逻辑来修改一些条目“而不修改整个结构”：

await setDoc(
  doc(getFirestore(), `/user/${user.uid}`),
  {
    objects[id]: {
      items: arrayUnion(...) // or arrayRemove
    }
  },
  { merge: true }
)

// Or when I want to remove an object

await setDoc(
  doc(getFirestore(), `/user/${user.uid}`),
  {
    objects[id]: deleteField()
  },
  { merge: true }
)

// Etc...

假设

objects

很大（数千个条目），

arrayUnion

（或

arrayRemove

）是否足够详细以避免更新整个字段。我对 Google Cloud 后端的理解非常有限，通过“更新整个字段”，我的意思是数据内部引用是否被重写（类似于 JS 中的

this.objects = {...}

），它会对计费产生任何影响吗？无论

objects

中的属性数量有多少，都相同？

如果答案是肯定的，当条目数量增加时，将此结构切换为每个对象文档架构是否可以减少计费？

感谢您的帮助

Answer 1

Firestore 对文档读取、文档写入、传出带宽和使用的存储进行计费。有关更多信息，请参阅有关了解 Cloud Firestore 计费和此定价示例的文档。

传入带宽不收费，因此写入操作的大小对该操作的成本没有影响。当然，生成的文档的大小确实会增加您的存储成本。

要考虑的常见替代方案是将这些对象中的每一个存储在它们自己的文档中是否会更好。如果价格是您的差异化因素，请随身携带价格计算器以确定此类变化的影响。