Reading a frequently updated document

Working with Data
,
#1

Hi,

I want to query a user which is frequently updated.
Does it affect the speed of reading the document (user)?

{
    id: 1,
    fullName: 'Jack',
    count: 120
}

Should i create another collection for the count field:

{
  user_id: 1,
  count: 120
}
#2

If the document is frequently updated, you may assume it is part of the working set residing in RAM. So as read is concerned, it is better to have it in the same document, otherwise the working set is bigger, since you now have 2 documents, with indexes, …, for the entity.

However, if it is very frequently update, it might be helpful to separate it. As I have learned recently, a document is completely written when it is updated. So it might be better to have it in a smaller dedicated document. I italicized might because performance is seldom intuitive. There are so many factors, that testing is always best.

That is why, it is better to make it work correctly and then fix performance problem, if any, after.

Something that might, yes in italic, help, is to have a change stream to monitor this value. This way you do not need to read it because you just have it.

1 Like
Alternatives for MongoDB transactions
#3

Thanks.

So I need to create two documents, it should be done inside a transaction.
I found another solution to this, i just want to make sure i’m not wrong.

const id = ObjectId();

await Counter.create({
  user_id: id,
  count: 0
});

await User.create({
  _id: id,
  fullName: 'Jack'
});

When the user is created it means both of the them are created so the order is important.

#4

Hi @Chris_Martel,

If a document is frequently updated it will remain in your working set residing in RAM (as mentioned by @steevej) and will be fast to retrieve. Separating into two documents means there is at least one additional index to maintain (since every collection has an _id index) and probably at least two indexes since you would want a unique index on user_id (although you could save an index by using user_id as the _id value for a count collection).

I assume your actual documents have many more fields which should be taken into consideration.

I recommend reviewing information on schema design patterns to see which may apply to your use case:

A few of the anti-patterns are relevant depending on the other fields in your data model:

There are many factors that go into performance, so I recommend testing and tuning with your use case in a representative environment with some generated data to compare with expected growth. There are tools like mgeneratejs that can be helpful for mocking scenarios including extending based on existing data.

Regards,
Stennie

2 Likes
Alternatives for MongoDB transactions
#5

A must read follow up at Alternatives for MongoDB transactions.

#6

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.