Realtime Database与Firestore：好友关系数据结构选型问询

一、Realtime Database vs Firestore 选型建议 #

Realtime Database 适用场景 #

• 若你的用户群体中，大部分用户好友数在5000以内，且好友关系的读写频率较高，优先考虑Realtime Database。它按带宽+存储计费，而非Firestore的文档读取次数，成本更低。
• 可直接用嵌套对象分状态存储好友关系，比如：

  {
    "acceptedFriends": {"uid1": "accepted", "uid2": "accepted"},
    "pendingFriends": {"uid4": "pending"},
    "declinedFriends": {"uid3": "declined"}
  }
  

  单个节点最大支持10MB，远高于Firestore的1MB限制，常规好友规模完全够用。

Firestore 适用场景 #

• 当你需要复杂查询（如按时间戳排序好友请求、结合用户其他属性过滤），或部分用户好友数可能突破5000上限时，Firestore的灵活性更具优势，但需优化存储结构控制成本。

二、Firestore 现有方案优化 #

方案一（用户文档内嵌Map）优化 #

• 拆分状态存储：将原单一friendsMap拆分为acceptedFriends、pendingFriends、declinedFriends三个独立Map。既缩小单个Map的体积，还能直接读取特定状态的好友列表，无需额外过滤。
• 设置好友数上限：参考主流社交平台的5000好友上限，按每个好友条目约30字节计算，5000条仅约150KB，远低于1MB单文档限制，完全规避容量风险。

方案二（子集合存储）优化 #

• 批量读取降本：使用getAll()方法一次性批量获取多个好友文档，将N次单文档读取合并为1次批量读取，大幅降低读取计费次数。
• 本地缓存复用：对已通过的常用好友状态，在客户端本地缓存（如SharedPreferences、AsyncStorage）或启用Firestore离线缓存，避免重复读取相同数据。
• 按需查询过滤：仅在需要时读取特定状态的好友，比如加载已通过好友时，添加查询条件where("status", "==", "accepted")，避免全量读取子集合所有文档。

三、折中方案：独立Friendships集合 #

创建顶级集合friendships，每个文档代表一组单向好友关系，文档ID可采用{发起方UID}_{接收方UID}的格式，文档内容示例：

{
  "requester": "uid1",
  "recipient": "uid2",
  "status": "accepted",
  "timestamp": 1699999999
}

• 查询用户所有好友时，可通过复合查询：where("requester", "==", 当前UID).where("status", "==", "accepted") 加上 where("recipient", "==", 当前UID).where("status", "==", "accepted")，合并结果得到双向好友列表。
• 优势：既避免用户文档体积膨胀，又能通过批量查询控制读取成本，同时支持按时间戳排序、状态过滤等复杂操作。

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