消息应用程序的MongoDB结构

Question

我正在考虑一个处理消息应用程序的良好文档结构.

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

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

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

1.用户

{
    username: 'dev.puS',
    usernameCanonical: 'dev.pus', // used for unique constraints
    email: 'developement.pus@gmail.com,
    emailCanonical: 'developement.pus@gmail.com,
    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' }
    ]
}

你怎么看待这个架构？

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

问候

Answer 1

我看到这个问题已经过时了,但对于任何有兴趣的人,都会问一个类似的问题,一个答案看起来很可行/sf/answers/2158130061/

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可以很好地扩展到非常大的集合.每个集合数十亿条消息.有一种称为分片的技术可以允许您将较大的集合拆分为多个节点.

2)阅读.由于MongoDB具有索引机制,因此读取与任何微调数据库引擎相当.所以阅读不会成为问题.特别是,当会话(组室)具有较少的参与者时,例如两个人彼此消息传递.

Answer 2

您的问题确实是架构设计之一。我建议看一下有关MongoDB模式设计的页面，以了解选择和权衡：http : //www.mongodb.org/display/DOCS/Schema+Design

此外，您可能应该查看该文档“另请参见”部分中的链接。我特别推荐视频演示。

最后，您可能应该看一下本文档，以讨论消息传递/注释数据库的三种可能模式，包括每种设计的权衡：http : //docs.mongodb.org/manual/use-cases / storing-comments /