Question

I have a chatroom system, and I want to use MongoDB as the backend database. The following are the entities:

• Room – a chatroom (room_id)
• User – a chatting user in chatroom (room_id, user_name)
• Msg – a message in chatroom (room_id, user_name, message)

For designing the schema, I have some ideas: First, 3 collections – room, user and msgs – and there is a parent reference in user and msg documents.

Another idea is to create collections for each room. Such as

• 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

…

I think if I can divide the documents into different collections, it would be much more efficient to query. Also, I can use capped collections to limit the count of messages in each room. However, I am not familiar with MongoDB. I’m not sure if there is any side effect to doing that, or is there any performance problem to create lots of collections? Is there any guideline for designing a MongoDB schema?

Thanks.

Answer 1

you should always design your schema by answering 2 questions:

• what data should i store? (temporary/permanently)
• how will i access that data? (lots of reads on this, lots of writes on that, random rw here)

you don’t want to embed high access rate data into document(like chat messages that are accessed by every user every second or so), it’s better to have it as separate collection.

on the other hand – collection of users in chat room changes rather rarely – you can definitely embed that.

just design using common sense and you’ll be fine