使用{year}-Q{n}格式的Firestore文档ID是否会引发性能问题？

结论 #

你用2022-Q1、2022-Q2这类格式做文档ID的设计完全不会引发性能问题，放心用就行。

具体原因 #

先掰明白Firestore官方不让用单调递增ID的本质：
这个规则根本不是针对小数据集的，它要解决的是高写入吞吐量场景下的分布式存储热点问题。Firestore底层是分片的分布式架构，如果你短时间内高并发写入大量字典序连续的文档，所有写请求会全砸在同一个存储分片上，没法把流量分散到多节点扛压，才会出现写入被限流、延迟升高的问题。要触发这个问题，得同时满足两个条件：

• 写入频率足够高，通常要到每秒数百次以上的连续写入
• 写入的文档ID在字典序上严格相邻，扎堆落在同一个分片的键区间里

你的场景两个触发条件一个都不沾：

• 总共才200个文档，就算ID全是连续递增的，这点数据量连单分片性能上限的零头都碰不到，根本不可能触发热点限流。
• 你是每3个月才写1个季度文档，写入间隔长到根本凑不成集中的热点流量。
• 你担心的「字典序相近」对读操作没有半分负面影响，反而这类按年季度命名的ID，字典序和自然时间顺序完全对齐，后续按时间范围查数据的时候连额外排序都省了，反而更好用。

别把最佳实践当硬性教条：官方给的这个最佳实践是给每秒几千几万次写入的大规模业务场景提的避坑点，不是给几百个文档、低写入频率的小场景定的死规矩，完全没必要过度套用。

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