Firestore 中 onSnapshot 的性能成本是多少？答案

【问题标题】：What is the performance cost of an onSnapshot in firestore?Firestore 中 onSnapshot 的性能成本是多少？
【发布时间】：2018-05-02 08:42:25
【问题描述】：

我正在设计一个包含（很多）文档的应用程序，这些文档共享给（可能很多）组。

为了构建我的数据模型，我需要了解文档更改是如何从服务器推送到客户端的。

是否所有对数据库的更改都推送到客户端（使用最少的数据）和客户端下载已在onSnapshot 注册的内容？
远程服务器上是否有过滤器被更新并且只有相关数据被推送到客户端？

在模型 (1) 中，添加许多 onSnapshot（每个文档一个）的成本似乎很低。在模型（2）中，它可能很高，但它是服务器的负担？这一切与 Firestore 定价模型有何关系（读取次数）。

感谢您对此的任何提示...

【问题讨论】：

我不明白您在#2 中所描述的内容。 “过滤器”是什么意思？这与 #1 究竟有何不同？
好吧，在 #1 中，客户端过滤以获取有趣的更改，而在 #2 中，服务器执行此过滤工作并且仅将相关数据推送到客户端。
这些对我来说听起来一样。在任何一种情况下，客户端都只会获得相关的更改。
实际上这对于客户端（移动）上的 CPU 使用率和网络带宽是不一样的！这也意味着如果客户端完成了这项工作，我们也可以获取所有内容并使用我们自己的应用程序代码进行过滤。所以我们基本上为整棵树做一个浅 onSnapshot...
您是否只是询问 onSnapshot 是否会在每次只有一个更改时从查询中传输整个匹配文档集？

标签： firebase google-cloud-firestore

【解决方案1】：

其实答案就在code：

/**
 * A PersistentStream that implements the Listen RPC.
 *
 * Once the Listen stream has called the openHandler, any number of listen and
 * unlisten calls calls can be sent to control what changes will be sent from
 * the server for ListenResponses.
 */
export class PersistentListenStream extends PersistentStream< // ...

当我们创建onSnapshot 时，查询被发送到服务器，服务器会记住客户端感兴趣的内容并更新它的通知过滤器。

这意味着我们处于场景 #2 中，它解释了服务器打开连接的成本。

这也意味着我们不关心我们创建了多少onSnapshot。关于客户端，为我们获得的每个文档执行一个 onSnapshot 没有性能问题（但 Firestore 中有一个 Read cost 用于此目的）。

【讨论】：