Firebase读取缩减：聊天应用好友列表低读取量实现及数据库选型咨询

一、Firestore减少读取次数的可行方案 #

1. 冗余存储好友用户名（推荐） #

在每个用户的好友列表文档中，除存储好友uid外，同步存储对应的用户名。比如用户的friends文档里，每条好友数据格式为{ uid: "xxx", username: "张三" }。

• 用户修改用户名时，通过批量写操作更新所有好友的好友列表中自己的用户名。Firestore批量写一次最多支持500个操作，好友数超过500时分批次处理即可。
• 优势：展示好友列表时只需读取1次用户的好友文档，完全避免额外的用户文档读取。聊天场景中，用户修改用户名的频率远低于查看好友列表的频率，写操作的增加完全值得。

2. 批量读取用户文档 #

如果不想做数据冗余，可收集所有好友的uid，用Firestore的getAll()方法批量获取用户文档。50个好友的情况下，仅需1次读取请求（Firestore批量读取算1次操作，上限500个文档），替代原来的50次单独读取。

3. 分片式用户名字典 #

将全用户的uid-username映射按规则分片存储，比如按uid的首字母、哈希前缀分成多个文档（如user_names_a-f、user_names_g-l等）。

• 获取好友用户名时，先判断每个好友uid所属的分片，仅读取对应分片文档，不用加载全部用户数据。比如好友分布在3个分片，仅需3次读取，远少于50次。
• 每个分片文档的大小可控，不会触发Firestore单文档1MB的限制，扩展性比单文档映射好很多。

二、是否更适合使用Realtime Database？ #

• 适合场景：如果你的应用核心是实时聊天、好友状态同步，Realtime Database的树形结构更高效——可以将好友列表（包含uid和用户名）存在单个路径下，一次读取就能获取所有数据，实时同步的延迟也更低。而且它按数据传输量计费，对于频繁同步小数据的场景成本可能更低。
• 不适合场景：如果需要复杂查询（比如按好友在线状态筛选、按昵称搜索好友等），Firestore的查询能力更灵活、强大，Realtime Database的树形结构在复杂查询上会显得力不从心。
• 总结：如果业务以简单实时同步为主，Realtime Database更适配；如果需要丰富的查询功能，Firestore结合上述优化方案也能高效支撑。

内容的提问来源于stack exchange，提问作者User-92