Firebase Firestore一对一即时聊天数据库结构设计相关问题咨询

原方案可行性与问题 #

你设计的初步结构理论上可以覆盖你提到的4个需求，但存在非常明显的缺陷，完全不适合生产环境使用：

• 需求1可实现：用where("users", "array-contains", 当前登录用户ID)查询chats集合即可获取用户关联的所有会话
• 需求2、4需要额外调整字段：你当前结构里chat级别的created_at是会话创建时间，无法支撑按最新消息排序，需要额外新增last_active_at字段，每次发消息时更新该字段才能实现排序和置顶
• 需求3可实现，但成本极高：你把所有消息嵌套在chat文档的messages字段里，每次查询会话列表都要拉取该会话下的所有历史消息，不仅浪费读取带宽，还会很快触达Firestore单个文档1M的大小上限，单会话消息超过几千条就会无法写入新内容

更优的生产级结构设计 #

建议拆分成分离的会话元数据集合 + 消息子集合的结构，既可以满足所有需求，效率和扩展性都远高于原方案：

1. 集合结构定义 #

会话元数据集合 chats

每个文档对应一个1对1会话，只存会话级的元数据，结构如下：

chats/{chatId}
{
  users: [uid1, uid2], // 两个参与用户的ID，用于查询用户所属会话
  user_info: [ // 可选，提前存储对方用户的昵称、头像，避免每次查会话还要额外查用户表
    {uid: uid1, name: "xxx", avatar: "xxx"},
    {uid: uid2, name: "xxx", avatar: "xxx"}
  ],
  latest_message: "今天晚上一起吃饭吗?", // 最新消息预览内容
  latest_message_sender: uid2, // 最新消息发送者ID
  latest_message_at: 1699999999999, // 最新消息发送时间戳，用于会话排序
  created_at: 1690000000000 // 会话首次创建时间
}

消息子集合 chats/{chatId}/messages

每个会话下独立的消息子集合，单条消息对应一个文档，结构如下：

chats/{chatId}/messages/{messageId}
{
  sender_id: uid2, // 发送者ID
  content: "今天晚上一起吃饭吗?", // 消息内容，如果是媒体类消息存资源地址
  type: "text", // 消息类型：text/image/video/file等
  created_at: 1699999999999, // 消息发送时间
  is_read: false // 可选，用于实现已读未读状态
}

2. 对应需求的实现方式 #

• 需求1（查询用户所有关联会话）：直接执行查询

  db.collection("chats").where("users", "array-contains", 当前登录用户UID)
  

• 需求2（按日期排序会话）：直接在上述查询后拼接排序规则，新消息自动置顶

  .orderBy("latest_message_at", "desc")
  

• 需求3（获取每个会话的最新消息）：查询会话列表时已经从chats文档的latest_message相关字段拿到了最新消息预览，无需额外查询
• 需求4（新消息发送后更新会话排序和最新消息）：发送消息时用批量写入原子执行两个操作即可：
  1. 向对应会话的messages子集合新增一条消息文档
  2. 更新对应chats文档的latest_message、latest_message_sender、latest_message_at三个字段

3. 优化方案的优势 #

• 完全规避了原方案的文档大小上限问题：消息独立存储，会话元数据文档大小永远不会超过限制，支持无限量的消息存储
• 读取成本极低：查询会话列表只需要拉取chats集合的元数据文档，不需要拉任何历史消息，响应速度快，Firestore读取费用也更低
• 扩展性强：后续要加会话置顶、已读未读、消息撤回、删除会话等功能，只需要在对应文档新增字段即可，不需要调整整体结构
• 支持分页查询历史消息：单独的消息子集合可以用limit+orderBy做分页拉取，避免进入聊天界面一次性拉取所有历史消息造成的卡顿

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