我应该如何构建 MongoDB 的数据架构？

Question

我有一个聊天室系统，我想使用 MongoDB 作为后端数据库。 以下是实体：

• 房间 - 聊天室 (room_id)
• 用户 - 聊天室中的聊天用户 (room_id, user_name)
• Msg - 聊天室中的消息（room_id、user_name、message）

对于设计架构，我有一些想法：首先，3 collections - 房间、用户和 msgs - 在用户和 msg 文档中有父引用。

另一个想法是为每个房间创建 collections。 如

• db.chatroom.victor
  • db.chatroom.victor.users
  • db.chatroom.victor.msgs
• db.chatroom.john
  • db.chatroom.john.users
  • db.chatroom.john.msgs
• db.chatroom.tom
  • db.chatroom.tom.users
  • db.chatroom.tom.msgs

...

我想如果我可以将文档分成不同的collections，查询效率会高很多。 此外，我可以使用上限 collections 来限制每个房间中的消息数。 但是，我对 MongoDB 并不熟悉。 我不确定这样做是否有任何副作用，或者是否存在任何性能问题来创建大量 collections？ 是否有设计 MongoDB 架构的指南？

谢谢。

Answer 1

您应该始终通过回答 2 个问题来设计您的架构：

• 我应该存储什么数据？ （临时/永久）
• 我将如何访问这些数据？ （大量阅读，大量写入，此处为随机 rw）

您不想将高访问率数据嵌入到文档中（例如每个用户每秒左右访问的聊天消息），最好将其作为单独的集合。

另一方面-聊天室中的用户集合很少更改-您绝对可以嵌入它。

只需使用常识进行设计就可以了

Answer 2

您绝对不想在其他文档中嵌入消息。 它们需要作为单独的文档存储。

我这样说是因为 MongoDB 为它编写的每个文档分配了一定数量的空间。 当它写入一个文档时，它会采用它的当前大小并向文档添加一些空白空间（填充），这样如果它实际上是 1k 大，它可能会变成 1.5k 大，以便为文档的大小留出空间。

聊天消息几乎肯定会大于分配的可用空间。 多条消息绝对会大于可用空间。

问题是，当您尝试在其中嵌入另一个文档（通过更新）时，当一个文档不适合它在磁盘\内存上的当前位置时，数据库必须从磁盘\内存中读取该文档并在数据文件的尾部。

这会导致大量原本不应该存在的磁盘活动——添加的 I/O 会破坏数据库的性能。

Answer 3

考虑所有用例。 你想执行什么样的查询？

• “显示用户正在聊天的房间”。 这不适用于当前架构，您必须向用户添加房间列表或在单独的集合中添加房间列表才能使其正常工作。
• “显示用户在所有房间中发送的所有消息”。 这又是行不通的。
• “从所有房间中删除所有空闲用户”。 使用建议的模式，您必须在每个 room.users 集合上运行此查询。

此外，对 collections 的大小做一些近似。 如果您有 100 个房间，最多有 1000 个用户，那么您存储所有这些映射的集合就有 100000 个条目。 有了不应该成为问题的房间和用户索引，您就不需要单独的 collections。

如果有 100 个用户，您甚至可以将其作为数组嵌入到房间 object 中。 只要确保有一个索引。