Question

I have this schema for support of in-site messaging:

When I send a message to another member, the message is saved to Message table; a record is added to MessageSent table and a record per recipient is added to MessageInbox table. MessageCount is being used to keep track of number of messages in the inbox/send folders and is filled using insert/delete triggers on MessageInbox/MessageSent – this way I can always know how many messages a member has without making an expensive “select count(*)” query.

Also, when I query member’s messages, I join to Member table to get member’s FirstName/LastName.

Now, I will be moving the application to MongoDB, and I’m not quite sure what should be the collection schema. Because there are no joins available in MongoDB, I have to completely denormalize it, so I woudl have MessageInbox, MessageDraft and MessageSent collections with full message information, right?

Then I’m not sure about following:

1. What if a user changes his First/LastName? It will be stored denormalized as sender in some messages, as a part of Recipients in other messages – how do I update it in optimal ways?

2. How do I get message counts? There will be tons of requests at the same time, so it has to be performing well.

Any ideas, comments and suggestions are highly appreciated!

Answer 1

I can offer you some insight as to what I have done to simulate JOINs in MongoDB.

In cases like this, I store the ID of a corresponding user (or multiple users) in a given object, such as your message object in the messages collection.

(Im not suggesting this be your schema, just using it as an example of my approach)

{
    _id: "msg1234",
    from: "user1234",
    to: "user5678",
    subject: "This is the subject",
    body: "This is the body"
} 

I would query the database to get all the messages I need then in my application I would iterate the results and build an array of user IDs. I would filter this array to be unique and then query the database a second time using the $in operator to find any user in the given array.

Then in my application, I would join the results back to the object.

It requires two queries to the database (or potentially more if you want to join other collections) but this illustrates something that many people have been advocating for a long time: Do your JOINs in your application layer. Let the database spend its time querying data, not processing it. You can probably scale your application servers quicker and cheaper than your database anyway.

I am using this pattern to create real time activity feeds in my application and it works flawlessly and fast. I prefer this to denormalizing things that could change like user information because when writing to the database, MongoDB may need to re-write the entire object if the new data doesnt fit in the old data’s place. If I needed to rewrite hundreds (or thousands) of activity items in my database, then it would be a disaster.

Additionally, writes on MongoDB are blocking so if a scenario like I’ve just described were to happen, all reads and writes would be blocked until the write operation is complete. I believe this is scheduled to be addressed in some capacity for the 2.x series but its still not going to be perfect.

Indexed queries, on the other hand, are super fast, even if you need to do two of them to get the data.