聊天文档结构 MongoDB

Question

我正在构建一个聊天应用程序并使用 mongo 进行存储。我已经建立了一个文档结构。

{
    _id:
    sender_id:
    receiver_id:
    subject:
    created_at:
    updated_at:
    messages: [
        {
            _id:
            message:
            author_id:
            attatchments: [x,y,z],
            read:
            created_at:
        },
        {
            _id:
            message:
            author_id:
            attatchments: [x,y,z],
            read:
            created_at:
        }
    ]
}

我很困惑这在性能和文档大小方面是否是一个好方法。有没有更好的方法来做到这一点，或者这很好？

提前致谢

Answer 1

在 Mongo 中，数据以您要查询的形式存储。

使用关系存储可以轻松解决聊天问题，但是如果您热衷于使用 Mongo，IMO 扁平结构是最好的选择。

您可以为每对发送者和接收者创建唯一的 chatId。将每个聊天消息存储为单独的文档。

{
    _id:
    chatId: 1234,
    sender_id:
    receiver_id:
    subject:
    updated_at:
    message: {
            message:
            messageId: 1,
            author_id:
            attatchments: [x,y,z],
            read:
            created_at:
            }
},
{
    _id:
    chatId: 1234,
    sender_id:
    receiver_id:
    subject:
    updated_at:
    message: {
            message:
            messageId: 2
            author_id:
            attatchments: [x,y,z],
            read:
            created_at:
            }
}

聊天将通过消息（而不是批量）进行。扁平结构让我快速读/写，但也帮助我提供搜索。

我什至可以提供分页，比如在一个窗口中显示最近 20 条消息，用户可以在其中单击以加载更多消息。（类似于下面的东西）

db.collection.find(
  {chatId: 1234, message.messageId: {$gte:1}
).sort({updated_at : -1})
.limit(20)

毫无疑问，文档的数量会增长得非常快，但是当您的字段上有适当的索引时，Mongo 读取总是很棒。

最后，再次阅读我的第一行。“在 Mongo 中，数据以您要查询的形式存储”。如果您有正确的索引，那么拥有大量文档不是问题，这是任何数据存储的基本质量。考虑到 mongo 的数组运算符，我不赞成使用消息数组。

假设每次聊天都有一个包含一系列消息的文档，并且有 10K（或想象任何大量）带有附件的消息。当您查询聊天文档时，您想将所有这些加载到内存中吗？或者您只是对最新的 1 条或 2 条或 20 条消息感兴趣？

现在，关于将单个集合拆分为两个关系集合的事情：IMO 用于任何关系数据存储。

如何做出决定：

设计它的最佳方法是列出您的要求。如果您将聊天商店作为服务公开，请列出该服务将公开的端点。

在不久的将来您可能需要执行多少种不同类型的查询。

什么是搜索键。

您希望在单个 API 调用中返回多少聊天消息。

等等 所有这些答案都将帮助您设计数据存储。