二手物料售卖平台Firestore数据库结构设计与读性能优化咨询

你计划调整为每个帖子对应独立文档的根级posts集合的方向是合理的，完全解决了原单文档1MB容量上限的问题，针对你担心的读配额超支问题，可以通过以下手段优化，成本远低于你预估的全量读开销：

• 强制分页加载：首页不要全量拉取所有帖子，搭配limit()和游标分页，首次加载仅拉取10-20条首页展示所需的帖子，用户下滑到底部时再触发下一页查询，单次打开APP仅产生十几到几十次读操作，远低于全量拉取的成本。
• 开启Firestore客户端缓存：开启官方自带的离线持久化能力后，用户二次打开APP时，已经加载过的帖子会直接读取本地缓存，仅新发布/更新的帖子会产生服务端读操作，日常活跃用户的读开销可以降低70%以上。
• 保留轻量汇总页机制：可以复用你原来的AllPosts思路，调整为按时间分片生成汇总文档，比如按天/按周生成daily_summary_20240520这类汇总文档，每个文档只存首页展示所需的精简字段，控制单文档大小不超过1MB，首页首次加载直接读对应时间范围的汇总文档，仅产生1次读操作，用户点击帖子详情、翻页超过汇总范围时再读独立的帖子文档，兼顾成本和扩展性。
• 保留按用户划分的子集合：原有的Posts/{userID}/{postID}的子集合结构不需要改动，用户访问单个店铺时依然走该路径查询，逻辑和之前一致。

上述优化落地后，整体读配额开销和你原方案基本持平，同时解决了大规模场景下的容量上限问题，是当前场景下的最优选择。

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