消息应用程序的MongoDB结构 [英] MongoDB Structure for message app

问题描述

我不禁要思考一种用于处理消息应用程序的好的文档结构.

I am breaking my mind up thinking about a good document structure for handling a message app.

我基本上需要三种(或四种)对象:

I basically need three (or four) types of objects:

1. 用户(用户名，电子邮件，密码等)
2. 联系人列表(包含不同的联系人或联系人组)
3. 对话(对话是一些人之间的消息的集合)
4. 消息(包含消息正文，一些时间戳和创建者.)

我的想法是将联系人嵌入到用户文档中，并将消息嵌入到对话文档中:

My idea was to embed the contacts into the user document and to embed the messages in a conversation document:

1.用户

{
    username: 'dev.puS',
    usernameCanonical: 'dev.pus', // used for unique constraints
    email: '[e-mail],
    emailCanonical: '[e-mail],
    salt: 'some hash',
    password: 'hash with salt',
    logs: { last_login: 12.06.2008, last_password_reset: 04.03.2007 },
    state: { online: true, available: false },
    contacts: [ user_id1, user_id2, user_id3 ]
}

2.对话

{
    members: [ user_id1, user_id2 ],
    messages: [
        { author: user_2, body: 'Hi what's up' },
        { author: user_1, body: 'Nothing out here :(' },
        { author: user_2, body: 'Whanna ask some question on stackoverflow' },
        { author: user_1, body: 'Okay, lets go' }
    ]
}

您如何看待这种模式?

我认为最好将它们分开(因此每个文档都是单独的)，因为每个文档的更新频率都不同.但是我真的没有任何经验，所以听听一些建议是很好的:)

I think it would be better to keep them seperated (so each document for it's own) because each document has different update frequency. But I really don't have any experience about it so it would be good to hear some advices :)

致谢

推荐答案

我看到这个问题很久了，但是对于任何有兴趣的人，都提出了类似的问题，并且一个答案看起来可行

I see that this question is old, but for anyone interested, a similar question was asked and one answer looks viable https://stackoverflow.com/a/30830429/132610

Conversation : {
 id: 123,
 members: [ user_id1, user_id2 ]
}
Message { conversationId: 123, author: user_2, body: 'Hi what's up' }
Message { conversationId: 123, author: user_1, body: 'Whanna ask some question on stackoverflow' }

更新#1

1)可伸缩性:MongoDB具有很好的伸缩性，并且具有非常大的集合.每个集合数十亿条消息.有一种称为分片的技术，可让您将较大的集合拆分为多个节点.

Update #1

1) Scalability: MongoDB scales well with very large collection. Billions of messages per collection. There is a technique called sharding that can allow you to split larger collection to multiple nodes.

2)阅读.由于MongoDB具有索引机制，因此读取可与任何经过微调的数据库引擎媲美.因此阅读不会成为问题.特别是，在对话(小组)的参加者较少的情况下，例如两个人互相发消息.

2) Reading. Since MongoDB has indexing mechanisms, reads are comparable to any fine-tuned database engine. So reading will not be an issue. Especially, when a conversation(group|room) has fewer participants, for example two people messaging each other.

这篇关于消息应用程序的MongoDB结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！