Firestore读写成本优化与写入限制问题解决方案咨询

1. 解决单文档写入限制的方案 #

• 分散写入分片：你想到的多文档写入思路完全可行，不用等写入被拒再切换，直接让用户随机选择一个分片文档写入就行，从源头分散单文档的写入压力。没必要单独创建集合，同一集合下开多个写入分片文档就足够。
• 定时合并分片：每日末把所有分片里的内容合并到当日汇总文档，供新用户首次加载。合并时用Firestore事务保证数据不丢，避免合并过程中出现数据不一致。
• 控制分片大小：每个分片文档别存太多内容，按你500条300KB的比例，单个分片放200条以内，避免触发Firestore单文档1MB的大小限制。

2. 兼顾成本与效率的更优架构 #

• 读写分层设计：
  • 写入层：用多个分片文档承接30%的创建/删除请求，分片后并发写入能力直接提升数倍，完全覆盖你的需求。
  • 读取层：每日汇总文档供新用户首次加载，老用户依赖ISAR本地缓存，后续只拉取当日新增的分片内容，不用全量更新。
• 延迟删除优化：用户删除内容时，先在分片文档里标记该内容为已删除，不用实时删除记录。每日合并汇总文档时统一清理已标记的内容，减少实时写入次数。
• 时间维度分片：如果用户量持续增长，可以按半天或几小时创建一批写入分片，进一步分散写入压力，合并逻辑和日汇总一致。
• 本地缓存精细化：ISAR不仅存全量汇总，还单独缓存用户自己发布的内容、最近浏览的帖子，减少后续对Firestore的读取依赖。

3. Firestore Bundle的适用性 #

非常适合你的场景：

• 你的读取占比70%，且核心场景是用户首次加载当日全量内容。Bundle可以预打包好当日汇总文档（甚至包含所有分片内容），用户一次请求就能下载完成，比多次读取文档更省读取次数和流量，直接降低成本。
• 可以在每日合并汇总文档后自动生成Bundle，用户请求时直接返回预生成的静态Bundle，减少Firestore的实时读取负载。

额外优化点 #

• 写入幂等性：给每条UGC生成唯一ID，写入分片时先检查ID是否存在，避免用户重复提交导致的重复内容。
• 自动化合并：用Cloud Functions设置定时触发器，每天凌晨自动执行合并逻辑，不用手动操作，同时合并完成后可以自动清理分片文档或归档到历史集合。
• 增量更新策略：老用户打开应用时，对比本地缓存的汇总文档版本，只拉取当日未合并到汇总的分片内容，不用重新下载全量数据。
• 动态调整分片数：通过Firebase控制台监控分片文档的写入QPS，根据实际流量随时增减分片数量，比如6个不够就加到10个，灵活适配并发需求。

内容的提问来源于stack exchange，提问作者Newbie dev flutter