Firebase存储方案选型：设备回调消息用集合、子集合还是数组？

结合你提供的业务参数（单设备待处理回调仅 10~100 条、回调触发间隔 ≥15 秒、优先控制读操作成本），最优选择是方案2：将回调队列存储在对应设备文档的 Array 字段中，完全适配你的业务需求，不存在你担心的维护混乱问题，核心理由如下：

• 读成本最低：用户查看单台设备信息时，仅需 1 次读操作就能同时拿到设备基础信息 + 完整待发送回调队列；服务端拉取待发送回调也只需要 1 次读操作，比另外两个方案至少减少 50% 的读次数，成本优势明显
• 维护逻辑简单：单设备最多 100 条回调，远低于 Firestore 单文档 1MB 的大小上限，用数组实现 FIFO 队列的操作非常成熟：新增回调直接调用 arrayUnion 插入队尾，执行完队首回调后调用 arrayRemove 移除即可，也可以直接覆盖更新整个数组，逻辑清晰没有额外负担
• 性能完全达标：单文档读写延迟远低于子集合/根集合查询，15 秒的回调触发间隔完全覆盖操作耗时，即使存在多实例同时操作队列的场景，搭配 Firestore 事务操作数组即可避免并发冲突，实现成本极低

另外两个方案的劣势对比 #

方案1：为每台设备单独建立消息子集合 #

• 读成本最高：不管是服务端拉取回调还是用户查看设备详情，都需要至少 2 次读操作（1 次读设备文档 + 1 次查询子集合），数万台设备的规模下，长期成本会比方案2高一倍以上
• 额外开销高：每个子集合需要维护独立索引，单设备仅百条以内数据的场景下属于过度设计

方案3：建立独立的回调根集合 #

• 读成本偏高：用户查看单设备详情时也需要 2 次读操作，服务端查询单设备下一条回调虽然是 log(n) 时间复杂度，但规模上来后延迟和成本都高于单文档读
• 维护成本高：需要为 deviceID、排序字段建立复合索引，后续数据清理、归档的复杂度也更高

迭代预案 #

如果后续业务调整出现单设备待处理回调超过 1000 条的情况，再切换到方案3即可，当前业务参数下方案2是性价比最高的选择。

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