Alternatives for MongoDB transactions

Hi,

I want to avoid transactions as much as possible.

What i think is best to do (note that i can’t embed it for some reason)

const id = ObjectId();

await Profile.create({
  userId: id,
  count: 0
});

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

// Each user has a profile

My questions

  1. is this solution ok?
  2. other alternatives?

Hi @Chris_Martel ,

What do you mean by is this ok? It will work as two documents will be created but its not atomic and if second operation fail the first won’t be rolled back.

What you can do is add a flag that a profile is considered “registered” after the two operations succeeded and add a flag to the profile:

{
  userId: id,
  count: 0,
  status : "registered"
}

Not sure why you can’t embed but thats the best solution…

Thanks
Pavel

2 Likes

I can’t embed because the count field is frequently updated. Somebody told me to separate them because if the user document is frequently updated and somewhere in my app reading the same user will be slow. I don’t know if its true or not.

Hi @Chris_Martel ,

Have you noticed that your applicaiton is slow when using an embedded structure?

I would not use such a generic conclusion without testing… Are many threads update the count for a single profile? Why is there so many updates, what does this count represent?

I would have a profile like this:

{
 _id  : ... , 
count : 0 , 
 user : 
     {
        fullname : ... ,
         ...
       
     } 

Why do you think reading will be slow?

Ty
Pavel

1 Like

My project is in development.

The count field can also be called views or visits . Popular users (most are) have many visitors.

Embedding is really easier if it guarantees faster reads, in my case.

You completely misinterpreted what I wrote. I specially indicated that it might help but that you should not do it unless you have a performance issue.

That is why I wrote.

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

But since

You should

make it work correctly and then fix performance problem, if any, after.

And by making it work correctly, it means having the best model for the functionality you want. And then and only and only if work on performance issue by tweaking the model, if and only if tweaking the model is the only way to fix your performance issue.

2 Likes

Thank you for replying.

The problem is, I can’t change my project manager’s mind. He told me to do so.
It would be fine if someone had a similar problem but resolved.

Another one of those. So he is not managing. He is micro-managing.

1 Like

Hi @Chris_Martel,

I would encourage your project manager to read some of the relevant forum discussions and review some of the design patterns and anti-patterns that apply to your use case. You have comments from community members with years of experience in MongoDB including supporting some of the largest production deployments :wink: .

If you think this data belongs together and should be committed in a transaction but you want to avoid multi-document transactions, that seems strong motivation to embed in a single document. However, I’m sure the actual use case is more complicated than optimising a single view counter so I would be very cautious about extrapolating comments on a single aspect of your use case to an overall recommendation. There are also practical considerations like resource usage for varying workloads that will be easier to predict by testing and monitoring in a representative environment.

If your project manager needs something more definitive or holistic than community discussion, it may be more appropriate to invest in professional consulting.

The path of least resistance would be to choose the approach recommended by your project manager (which I assume would be based on their MongoDB experience) and refine this later if it leads to performance issues.

Ultimately the correct approach to data modelling is informed by factors including how your application uses data, available resources in your deployment environment, and sensitivity to cost & efficient resource usage.

Regards,
Stennie

2 Likes

Hi Stennie,

I want to thank you all @Pavel_Duchovny @steevej @Stennie
You’re great.

2 Likes

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