Firestore创建单文档视图降低成本的模式与注意事项咨询

你这套实现思路是NoSQL文档数据库领域非常成熟的预聚合文档模式（Pre-aggregated Document Pattern），在Firestore场景下也常被称为聚合快照模式，核心逻辑就是针对固定高频的访问场景，提前把分散在多个文档里需要同时读取的数据，预计算整合成单个文档对外提供访问，用极低的预计算写入成本，抵消海量高频读取产生的费用，完全匹配你降低首页访问成本的诉求。

• 严格遵守Firestore单文档硬限制：Firestore单个文档的大小上限为1MiB，设计聚合字段的时候要提前算好单条商品展示项的体积，比如首页只存商品ID、标题、缩略图URL、到手价、活动标签、跳转路径这几个必填字段的话，单条商品数据大概在0.8-1.2KB，算上冗余整个聚合文档最多放800个左右的商品位，要提前设置容量阈值告警，别因为当日上新太多把文档撑爆，导致写入失败、首页拉不到数据。
• 注意写入过程的可用性和数据一致性：每日生成聚合文档的时候，不要直接覆盖线上正在被读取的正式文档，建议先生成临时文档写完所有数据、做过字段完整性校验之后，再更新首页配置里的文档引用指针，避免用户拉到写入到一半的残缺数据；另外要留紧急更新的旁路通道，如果遇到商品临时下架、价格改错、活动临时调整的情况，不用等每日的定时任务，可以直接增量更新聚合文档里的对应条目，避免首页展示错误信息。
• 搭配多层缓存进一步压成本：哪怕每次首页只拉1个文档，DAU百万级的场景下读取次数还是会很高，建议给这个聚合文档配置边缘CDN缓存、客户端本地缓存，缓存TTL可以设为5-15分钟，既不会让用户看到太滞后的数据，又能把Firestore的实际读取量压到原来的几十分之一。
• 做好版本兼容和字段裁剪：聚合文档里只塞首页渲染必须的字段，别把商品详情、SKU明细、售后规则这类首页用不上的内容放进去，既省文档空间，又能减少用户端的加载流量；另外给聚合文档加个schema版本字段，后续迭代首页展示逻辑的时候，旧版本客户端不会因为字段缺失出现渲染崩溃。
• 留好容灾兜底逻辑：定时生成聚合文档的任务要加失败告警，同时至少保留最近3天的历史可用版本，万一当天的文档生成失败、或者写入了错误数据，客户端可以自动回退拉取上一个可用版本，避免首页直接空白。

• Firestore官方数据建模最佳实践中，关于减少文档读取次数、预聚合建模的相关章节
• NoSQL数据建模通用指南中，读优化场景下的预聚合模式相关内容
• 云原生Serverless数据库成本优化的公开实践案例中，高频访问页的聚合快照方案部分

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