Firestore单文档流与集合流：API状态展示的理论性能对比

方案一：单文档存储所有API状态 #

理论优势 #

• 读取效率拉满：流式获取单文档仅需一次数据库IO，直接定位文档ID即可返回全部数据，网络请求往返次数最少，延迟理论上是最低的。
• 原子更新天然生效：cron job批量更新多API状态时，单文档更新是原子操作，不会出现部分状态更新成功、部分失败的中间态，前端不会读到不一致的数据。

理论劣势 #

• 更新冲突概率高：若存在多实例cron job或其他更新源，单文档的并发更新会触发乐观锁冲突，需额外处理重试逻辑；即便单实例更新，每次都要读写完整文档，API数量增多后文档体积膨胀，更新IO开销会线性上升。
• 存在体积上限瓶颈：以常见文档型数据库为例，单文档有最大体积限制（如MongoDB为16MB），未来API扩展到一定数量后会触及这个限制，无法继续扩容。

方案二：单API对应独立文档 #

理论优势 #

• 更新粒度精准：每次仅更新目标API的文档，IO操作仅涉及小体积数据，并发更新时冲突概率极低（仅同一API被同时更新时才会出现），API数量增加后更新开销不会明显上涨。
• 扩展性与灵活性更强：新增API只需插入新文档，无体积限制；若需筛选特定状态的API（比如仅展示异常状态），可直接通过数据库查询语法完成，无需在应用层处理过滤逻辑。

理论劣势 #

• 读取开销略高：流式获取整个集合需要遍历多个文档，即便有索引优化，数据库IO次数也比单文档多；同时数据序列化/反序列化的开销也会略高于单文档模式。

理论结论 #

如果API数量长期保持极少且稳定，方案一的读取性能理论上更优；但从长期扩展性、更新灵活性来看，方案二的理论性能上限更高，当未来API数量增长或需要精细化状态管理时，方案二的优势会更加显著。

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