使用NoSQL Cloud Firestore按uid统计文章独立浏览量的方案可行性咨询

你当前采用的数组存uid方案的核心缺陷 #

• 硬容量天花板极低：Cloud Firestore单文档存在1MB的存储上限，单个Firebase Auth的uid长度约为28字符，把所有浏览用户uid存在新闻主文档的views数组里时，单篇新闻累计浏览量达到3.6万左右就会触达单文档容量上限，根本无法承载正常的新闻流量规模。
• 读写成本随浏览量线性上涨：哪怕你用arrayUnion做原子写入避免重复加uid，每次操作这个数组都需要Firestore重新序列化整个数组内容，当数组长度达到数千级别时，写入延迟、读取消耗的流量都会明显升高。更麻烦的是，你想读取数组长度的时候，Firestore会把整个数组的全部内容都拉取出来，哪怕你只需要一个长度数值，大量的无效流量消耗会直接拉高账单。
• 核心文档冗余度极高：新闻主文档本身是承载标题、正文、发布时间这类固定展示内容的，当你带着超大的views数组做新闻列表查询、详情页加载时，所有和展示无关的数组内容都会被一并拉取，拖慢页面加载速度。
• 排序效率完全不可用：Firestore不支持直接对数组长度做排序，如果你后续要做“热门新闻排行”功能，根本没法直接基于views数组长度做查询过滤，还得额外维护独立的计数字段，那存全量uid在主文档的意义就基本消失了。

可落地的优化路径 #

按照业务的不同规模，分阶段适配方案即可，不用一开始就上重架构：

冷启动阶段（日活<1万、单篇新闻浏览量<10万） #

完全不需要把全量uid塞在新闻主文档里，做两层拆分即可：

• 在新闻主文档里新增一个纯数字类型的viewCount字段，只存累计独立浏览量的数值，这个字段占的存储空间可以忽略，哪怕累计到百万浏览量也不会影响主文档的容量上限。
• 在每篇新闻文档下挂载一个独立的viewRecords子集合，用来做用户浏览的幂等校验：当用户打开新闻时，先判断这个用户的uid在viewRecords子集合里是否存在，如果不存在，就通过事务给主文档的viewCount做+1操作，同时在viewRecords里写入该用户的首次浏览时间记录。这种结构下，主文档永远是轻量的，viewRecords的存储压力分散在独立的子文档里，不会挤占核心新闻文档的空间。

成长阶段（日活10万+、单篇新闻浏览量破百万） #

直接把独立浏览量的统计逻辑从业务数据库抽离：用埋点系统记录所有用户的浏览行为，在分析侧做用户去重计算出独立浏览量，只把最终的计数值定期同步回新闻主文档的viewCount字段做前端展示缓存，完全不在业务库存储全量的用户浏览明细，把数据库的压力降到最低。

实操提醒：别为了省步骤把所有浏览记录都堆在主文档里，原方案最多能撑几万浏览量，拆分子集合的方案至少能扛100倍以上的流量规模，前期开发成本甚至比原方案还低。

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