出乎意料的高不。读

Question

我正在使用Google函数，并通过这些云函数对Firestore执行读、写操作。我们看到在Firestore上的读取操作的数量出乎意料地高，我无法弄清楚它的来源。

每天生成的文档不超过20K。但是每天的阅读数量通常超过2500万。

我正在寻找的是，如何确定云函数中这些大量读取的根本原因。

首先，我捕获了云函数中所有Firestore ()方法的结果大小。但是，所有大小的总和比我前面提到的读计数要低得多。

需要关于如何/实践的建议，以确定这些高读取量产生的源。

Answer 1

您可以使用SnapshotListener作为解决方案，它允许我们实时侦听变化。

如果侦听器断开超过30分钟，您将被收取阅读费，就好像我们已经发送了一个新的查询一样。如果在最坏的情况下，侦听器每31分钟断开一次连接，我们每次要付费50次。

因此，只有当听者不经常断开连接时，这种技术才是可行的。

根据文档，我发现您可以使用get()减少读取的次数。在集合中的每个文档中，必须添加一个名为lastModified的新属性(类型为Date )。创建新文档或编辑现有文档时，必须使用FieldValue.serverTimestamp()设置或更新字段的值。

回顾[消]火基文件，我发现需要避免对按字母顺序关闭文档的高读写率，以避免应用程序中的争用错误。热点是这个问题的术语，如果您的程序执行下列任何一项操作，就会发生此问题：

• 快速创建新文档，并分配自己的ID，这些ID是单调上升的。
• 使用一个分散算法来分配文档ID。
• 如果使用自动文档ID创建新文档，则不能在写入时看到热点。
• 在很少文档的集合中，以快速的速度创建新文档。
• 使用单调增长的字段(如时间戳)快速创建新文档。
• 从集合中删除大量文档。
• 以快速的速度写入数据库，而没有逐渐增长的流量。