MongoDB Structure for message app

Question

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. The user (username, email, password, etc.)
2. The contacts list (containing different contacts or contacts groups)
3. The conversation (a conversation is a collection of messages between some persons)
4. The message (contains the message body, some timestamp and the creator.)

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

1. User

{
    username: 'dev.puS',
    usernameCanonical: 'dev.pus', // used for unique constraints
    email: '[email protected],
    emailCanonical: '[email protected],
    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. Conversation

{
    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' }
    ]
}

What do you think about this schema?

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 :)

Regards

Answer 1

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' }

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) 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.