在群聊应用程序上选择猫鼬模式？答案

【问题标题】：choose the mongoose schema on group chat application?在群聊应用程序上选择猫鼬模式？
【发布时间】：2019-09-22 05:51:42
【问题描述】：

我要设计一个基于mongodb的群聊应用，有两种schema设计选择，一种设计为一个文档用于一条群聊消息，另一种设计为一个文档用于所有群消息。

在第一个选项中，可以显示为

var ChatMessageSchema = new Schema({
  fromUserId: ObjectId,
  toTroupeId: ObjectId, 
  text: String,
  sent: Date
}

在第二个选项中，可以显示为

var ChatMessageSchema = new Schema({ 
  toTroupeId: ObjectId, 
  chats:[
     fromUserId: ObjectId,
     text: String,
     sent: Date
  ]
}

两种设计各有利弊，第二种方案的缺点是它很难对用户进行索引和搜索来自用户的消息，而且太多的组消息可能会迫使创建多个文档。

第一个选项似乎更合理，因为如果我们可以正确索引，它可以允许基于 groupid 或 userid 搜索消息。

但是我想知道由于组中有数十万条消息，意味着一个组中会有相应的数十万个文档，这会影响数据库性能吗？

关于这些设计选择的任何想法，第一个选项是最佳选项，还是如何优化它？

【问题讨论】：

【解决方案1】：

我建议第三种选择；为每个组创建一个新集合，例如room_$groupid。在这样的集合中，您可以单独插入每条消息。这将使您获得一个没有过滤器的完整聊天室的好处。您可以简单地从集合中返回最后 200 条左右的消息。

这将使可扩展性更容易，因为您最终不会得到一个必须过滤的大型集合。

但是，您必须编写选择正确集合的逻辑，但这应该是一项相当简单的任务。不利的一面是，几乎不可能对多个组进行文本搜索而不会将性能抛到窗外。

【讨论】：

【解决方案2】：

避免大型文档

16MB 的限制也说明了这一点。

因此可以说 MongoDB 是专门为处理与您的第一个模式相对应的数十万个文档而设计的。

只需将索引数量减少到您需要的数量（您真的需要经常或可以接受该查询慢得多的用户进行查询吗？）您应该可以使用第一个架构。其实我不确定第二个有什么好处。

【讨论】：