在群聊应用中选择猫鼬模式？

Question

我将基于mongodb设计一个群聊应用程序，有两种模式设计选择，一种设计为一个群组聊天消息的文档，另一种设计为所有群组消息的文档。

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

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搜索消息。

但是我不知道在该组中有成千上万的消息，这意味着在一个组中将有相应的成千上万的文档，这会影响数据库的性能吗？

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

Answer 1

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

这将允许更轻松的可伸缩性，因为您最终不会获得必须过滤的单个庞大集合。

但是，您必须编写用于选择正确集合的逻辑，但这应该是一件微不足道的任务。 缺点是几乎不可能在不影响性能的情况下对多个组进行文本搜索。

Collection limit *

Answer 2

使MongoDB处理huge amounts of data及其PDF Performance Best Practices for MongoDB状态：

  

Avoir大文件

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

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

只需将索引的数量减少到所需的数量（您是否真的需要经常或可以接受该查询的用户查询速度慢得多？），并且您对第一个架构应该满意。实际上，我不确定第二个好处是否有好处。