Meteor应用中MongoDB多收件人通知及已读状态方案咨询

我在Meteor应用中维护着一个用于用户通知的MongoDB集合Notifications，希望在多收件人场景下依然保持一条通知对应一个文档，同时实现每个用户的已读状态跟踪。

我最初尝试用双数组的方式记录：

{
  ...notification,
  users: [id1, id2, id3],
  read: [id2]
}

但查阅MongoDB文档后发现，这类双数组结构无法建立有效的索引来优化查询。因此我改用了独立集合的方案：新建UnreadNotifications集合，文档结构如下：

{
  notificationID: "notificationid1",
  userID: "id2"
}

具体逻辑是：创建新通知时，为所有目标用户生成对应的未读通知文档；用户标记通知为已读时，删除UnreadNotifications中对应的文档。

想请教这个方案是否合理？存在哪些潜在缺陷？我自己想到一个问题：用户需要先获取所有未读通知记录，才能对应到真实通知判断已读状态，但这似乎不算严重问题。

方案合理性 #

这个方案是MongoDB中处理多用户状态跟踪的典型实践，具备以下优势：

• 索引高效：可以为UnreadNotifications建立{userID: 1, notificationID: 1}的复合唯一索引，既能快速查询单个用户的所有未读通知，又能避免重复创建同一用户同一条通知的未读记录。
• 逻辑简洁：创建通知时批量插入未读记录，标记已读时直接删除文档，代码实现成本低，不易出错。
• 数据解耦：Notifications集合仅存储通知核心内容，不受已读状态逻辑干扰，便于后续做通知内容的统一修改、归档或统计。

潜在缺陷 #

• 存储冗余：若一条通知涉及上千个收件人，就需要创建上千条UnreadNotifications文档，当通知和用户量级较大时，存储成本会显著上升。
• 批量写入性能风险：当通知收件人数量极多（如上万级别），批量插入未读记录的操作可能会占用大量MongoDB写入资源，影响其他业务操作的性能。
• 数据一致性隐患：如果Notifications中的通知被删除，若未同步清理UnreadNotifications中的关联记录，会产生无效的脏数据，需要额外的联动清理逻辑（如删除通知时的批量删除操作，或定时清理任务）。
• 全局统计成本高：若需要统计全平台未读通知总数，需对UnreadNotifications做全集合计数；而原双数组方案可通过计算users.length - read.length的总和实现统计（虽索引效率低，但统计逻辑更简单）。

优化建议 #

• 针对批量写入性能问题，使用MongoDB的bulkWrite操作替代单条插入，提升批量写入效率；若收件人数量过大，可拆分批次执行插入。
• 为UnreadNotifications的notificationID字段建立索引，方便在删除原通知时快速批量清理关联的未读记录。
• 若对存储成本敏感，可考虑将未读通知ID数组存储在用户文档中（如user.unreadNotificationIDs），但此方案在用户量级较大时，数组操作的性能会下降，需根据业务规模权衡。

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