Meteor versus MongoDB Document Handling

performance
1

I’m new to Meteor and MongoDB and I’m thinking about the best strategy for document design.
In Meteor it is suggested to split documents (for best performance for updates) and in MongoDB it is recommended to use one document if possible (of course for best performance too). Together with ‘transaction’ handling (atomic operations over more than one document) I tend to follow MongoDBs approach. Are there any hints how to deal with this?

2

not to give you a real answer to your question, but i recently stumpled upon a reply from @brucejo within this thread How to get one particular object from collection's document array field? and i really liked it. short but powerful, maybe it will help you as well.

You are working with minimongo, not mongo when doing a client side query. It is helpful to think of minimongo as a mongo-like addressable cache of the mongo objects, e.g. minimongo uses mongo selectors.
Because it is a client side cache it is very cheap to take in the entire document and then use regular js operations on it.

3

In Meteor it is almost always better to normalize your data. This will avoid issues with pagination, publishing large documents over ddp, and limitations on depth of documents inherent in Meteor’s merge box.

3 Likes
4

Very much agree with @copleykj . Having data in separate documents in my opinion helps to avoid a lot of issues in Meteor.

5

Thanks a lot for your quick feedback.
That makes sense to me. In case of normalization transaction handling becomes more important. Think the two way transaction handling described in the meteor help is the best way to handle this problem. Or are there other features in meteor?

6

MongoDB uses 2 phase commits to simulate transactions. I’m not sure what is described in meteor help, but there are serveral packages on atmosphere that are made for this use case, specifically babrahams:transactions stands out. If you need true ACID compliance though you’ll need to either consider changing your DB, or re-engineering your app so that your documents can be denormalized and make use of MongoDB’s document level atomic operations.

1 Like