Firestore子集合是否可规避Collection的监听器缩放问题？

1. 子集合messages能否避免监听器缩放问题？ #

能。Firestore的分片是针对*单个集合（或集合组）*进行的，子集合rooms/roomA/messages和rooms/roomB/messages属于两个独立的集合实例，而非同一个顶层集合的一部分。当使用子集合模式时，每个房间的消息集合都是独立的小型集合，符合文档中“拆分为小型collection”的建议。这种设计下，单个子集合的写入率和数据量都被控制在单个分片服务器的处理能力内，监听器只需连接对应子集合的分片服务器，不会出现因单个大型集合拆分多服务器导致的响应变慢风险。

2. 用户A、B的监听体验是否独立？ #

完全独立，用户B不会受用户A的影响。因为rooms/roomA/messages和rooms/roomB/messages是两个完全独立的集合，各自对应不同的分片服务器。Firestore会为每个独立集合的监听器分配独立的变更日志流，大集合的负载不会传导到小集合的监听器上。不管roomA的消息量多大，roomB的监听器只会处理自己子集合的变更，响应速度不受前者影响。

3. 监听集合组vs单个子集合的缩放结论是否正确？ #

这个结论是正确的。监听整个messages集合组时，相当于要监听所有房间下的messages子集合，此时Firestore需要聚合所有子集合的变更日志，涉及的分片服务器数量会随着房间数量增加而增多，和单个大型顶层集合面临的问题本质一致——监听器需要连接多服务器，随着数据量和写入率提升，响应变慢的风险会显著增加。而监听rooms/roomB/messages这类单个子集合时，只需要处理这个小型集合的变更，对应单个分片服务器，不存在多服务器连接的性能问题，能保持高效的监听响应。

内容的提问来源于stack exchange，提问作者Micro