我的应用中有 3 个活动的 Firestore 快照侦听器，每个侦听器都侦听不同集合（不是文档，而是整个集合）中的更改。
目前，集合的大小很小，但未来可能会变得更大，所以这会影响性能，还是集合的大小无关紧要？
我知道一次不应该有超过 100 个活动快照，并且经常连接和断开侦听器并不是一个好主意，但找不到任何关于文档/集合的实际大小的信息侦听器所附加的...
【问题讨论】：
标签： javascript firebase google-cloud-platform google-cloud-firestore
可能造成性能问题的不是查询的大小，而是一段时间内的更改次数。如果您有 3 个包含 1000 个文档的集合，其中每 2 分钟会更改一些文档，这不会带来很大的性能问题，但是如果您有 3 个包含 100 个文档的集合/查询，但它们每隔几秒钟就会更新很多文档，您将注意。特别是如果您有在 Firebase 和状态之间同步数据的状态管理。
我会在经常更新的查询中分离侦听器，并将它们留给那些在一段时间内保持不变但可以获得更新的侦听器。例如，在具有下拉列表的应用程序中，这是一个常见原因。它们通常保持不变，但可能会得到更新，因此我们会倾听它们。
也只是为了说清楚。如果它们的尺寸变大，那么它们每个的初始加载当然会花费更长的时间，但这应该是显而易见的。由于 Firestore 的出色离线工作只有在第一次加载时才会被注意到，然后用户将从缓存中获取数据，然后从服务器获取数据，因此他不会注意到它。
【讨论】：
目前，集合的大小很小，但未来可能会变得更大，所以这会影响性能，还是集合的大小无关紧要？
集合的大小无关。重要的是查询返回的文档数量。在 SQL 数据库中，查询速度取决于表中存在的记录数，而在 Firestore 中情况有所不同。
Firestore 中的查询性能取决于您请求的文档数量，而不是您搜索的文档数量。无论您在 1000 个文档的集合中还是在包含 100 MIL 个文档的集合中搜索 10 个文档，响应时间都将始终相同。
话虽如此，如果您在没有limitation 的情况下查询数据库，并且查询返回的文档数量会增加，那么您的查询速度可能会变慢。在这种情况下，您应该始终考虑以较小的块获取数据。这种技术也称为分页。
我知道一次活动快照不应超过 100 个。
对此没有限制。听众很便宜。但是，如果您正在侦听实时更改，则始终考虑根据应用的状态移除侦听器。
在侦听器附加到的文档/集合的实际大小上找不到任何内容。
正如我已经提到的，在获取数据时，集合的大小并不重要。退回的文件数量很重要。关于文档的大小，maximum size of a document is 1 Mib。这不计入性能，因为查询将花费确切的时间，但它需要下载数据。
【讨论】：