Firestore中以用户ID为字段键存储评分的可行性及优化方案咨询

1. 能否将用户ID作为Firestore文档的字段键进行存储？ #

完全可以，但有几个需要留意的细节：

• 字段名合法性：Firestore禁止字段名包含 .、/、#、[、]、= 这类字符，如果你的用户ID里有这些符号，得先做转义或替换处理，否则会写入失败。
• 查询灵活性限制：这种动态字段结构下，如果你想做「找出所有评分≥4的用户」这类操作会非常麻烦——你没法直接用Firestore的查询语句筛选，只能把整个文档读下来在客户端遍历处理，数据量一大性能就会明显下降。

2. 以用户ID为键、评分为值的结构会生成过多自动索引吗？ #

绝对会，这会是个隐形的成本大坑！
Firestore默认会为文档的每个字段自动创建单字段索引。如果你的文档里有几千上万个用户ID作为字段，那Firestore就会自动生成对应数量的索引——这些索引几乎毫无用处（你大概率不会去查询「某个特定用户ID字段等于X」这类条件），但会实实在在占用你的索引配额，导致计费飙升。这种结构的索引成本完全是浪费，非常不推荐。

3. 分片单文档的存储结构有没有更优替代？ #

当前「填满20k字段就建新文档」的分片方式，问题在于查询特定用户评分时需要遍历多个分片文档，效率偏低，而且字段数接近上限时写入也容易出问题。结合你不想单条评分存文档（成本高）、数组容量不够的需求，给你两个更优的方向：

方案一：批次化的数组对象存储 #

把多个用户的评分打包成小对象存在数组里，比如每个文档存1000条左右的 {uid: "user_123", rating: 5} 这样的对象，达到文档大小（1MB）或元素数阈值时就新建分片文档。

• 优势：自动索引只会针对这个数组字段，不会产生大量无用索引；相比动态字段，你可以给每个分片文档加标识（比如存储该分片包含的uid哈希前缀范围），查询时先定位到可能的分片，再在数组里查找目标uid的评分，效率比遍历所有分片高很多。
• 注意：Firestore单文档大小不能超过1MB，所以要计算好每个对象的大小，控制单文档的数组元素数量。

方案二：子集合分片存储 #

给每个主数据（比如某个商品/内容的评分集合）创建子集合，子集合里的每个文档作为一个分片，同样用数组存储批量的评分对象。

• 优势：相比顶层集合的分片，子集合的结构更清晰，权限控制也更灵活；同样能避免大量自动索引的问题，查询时可以通过子集合的文档标识快速定位。

这两种方案都能平衡存储成本和查询效率，比当前的字段分片结构更合理。

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