Firebase高频更新计数器（点赞、时间戳）的索引方案咨询

你的方案整体是合理的，针对需求设计的两个复合索引完全能支撑目标查询场景：

• category（升序）+ likes（降序）：完美匹配「按分类筛选后，按点赞数从高到低排序」的需求
• category（升序）+ publishedDate（降序）：满足「按分类筛选后，按发布时间从新到旧排序」的需求

针对你担忧的点赞高频更新问题，需要重点关注两个点：

1. 单文档写入限流：Firestore单文档默认写入频率上限约为每秒1次，如果单篇文章的点赞更新峰值超过这个阈值，会触发限流，导致部分更新请求失败。如果你的网站有爆款文章可能短时间内获得大量点赞，这个限制会直接影响功能可用性。
2. 索引更新成本：每次更新likes字段，除了文档本身的写入操作，还会触发category+likes复合索引的更新。高频点赞会让索引写入次数大幅增加，而Firestore的索引写入是单独计费的，这会直接推高使用成本。

另外还有几个容易遗漏的优化方向：

• 用分布式计数器拆分点赞压力：如果单篇文章点赞频率很高，建议采用分布式计数器方案——把点赞数拆分到多个子文档中，每次点赞随机更新其中一个子文档，查询时再汇总所有子文档的计数。这种方式能把单文档的写入压力分散开，大幅提升点赞更新的频率上限。
• 按需扩展索引字段：如果业务需要结合时间范围筛选热门文章（比如只看近7天的热门），可以考虑给category+likes索引增加publishedDate作为第三个排序字段，但要注意只有确实有这个查询需求时再创建，避免冗余索引增加成本。
• 定期清理无效索引：在Firebase控制台的Firestore索引页面，查看各索引的实际使用频率，及时删除未被使用的索引，减少不必要的成本支出。

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