Firestore活动日志存储方案选型：独立集合VS文档内Map，哪种更优？

方案1：独立集合/子集合存日志 #

• 优势：
  • 日志与activity文档彻底解耦，不会因日志量增长触发Firestore单文档1MB的上限限制
  • 支持灵活的日志查询操作：比如按时间范围筛选某activity的日志、跨activity统计日志，无需读取无关数据
  • 写入日志时仅操作日志文档，减少与activity更新操作的并发冲突概率
• 计费说明：每读写一条日志算1次文档操作。批量读取某activity日志时（比如用where("activityId", "==", 目标ID)或子集合查询），返回N条日志则按N次读取计费，逻辑简单清晰

方案2：activity文档内嵌日志列表 #

• 优势：
  • 读取activity时可一次性获取全量日志，仅计1次文档读取，适合日志量极小、每次需与activity同步获取日志的场景
  • 数据结构与activity强绑定，代码逻辑更紧凑，无需跨集合操作
• 劣势：
  • 单文档1MB上限是硬伤，日志量持续增长会很快达到写入限制，后期数据迁移成本极高
  • 新增日志需重写整个activity文档，若activity本身数据量大，会增加写入带宽和计费成本（Firestore按写入数据量收费）
  • 无法单独查询日志：如需筛选近7天的日志，必须先读取完整activity文档再本地过滤，浪费带宽且效率低
  • 并发写入易冲突：多客户端同时添加日志时，极易触发更新冲突，需额外编写冲突处理逻辑

计费与场景维度的选型判断 #

1. 日志读写场景：
   • 若每次获取activity都需同步读取全量日志，且日志量极少（单activity日志≤几十条），方案2的读取计费更划算
   • 若需单独查询日志（如时间筛选、分页）或日志量会持续增长，方案1虽单条操作计费，但长期无上限限制、查询灵活，综合成本更低
2. 数据增长预期：
   • 日志量随时间递增的场景，直接选方案1，方案2的1MB限制会导致后期不可用，迁移成本远高于计费节省
   • 日志量固定且极少的场景，可考虑方案2
3. 并发写入情况：
   • 多客户端同时写日志的场景，方案1的独立文档/子集合写入冲突少，无需复杂处理；方案2易触发冲突，增加开发成本

最佳实践总结 #

绝大多数场景下，方案1（子集合或独立集合）是更稳妥的选择——它规避了文档大小硬限制，支持灵活查询，长期维护成本更低。仅当日志量极小、与activity强绑定且永远无需单独查询日志时，方案2才适合临时使用

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