Spliting changes in separate collection/table or not?

Question

I am using MongoDB to store products, user accounts and stuff on my server and so far it's going nice.

But now I'm stuck deciding how do I "split" things apart, like:

I have a database where products are stored, but now I want to log every change made (who made it, when, etc).

Should I put that log (array) in the same (product) document, or should I separate the log in a separate collection?

products:
{
   _id: 1234
   product_name: "Some product"
}

product_changes:
{
  _id: ...
  ref_id: 1234
  changes: ["...","..."]
}

or

products:
{
   _id: 1234
   product_name: "Some product"
   changes: ["...","..."]
}

I'm afraid that if I attach too much Objects in one document, that the performance will suffer, and if I separate everything, things begin to "fragment".

Of course, in the example, "changes" is just a tiny array, but in real usage it may be a array with a lot of objects each with time, user_id and changes made. And summing all this up, might turn this single document big.

Any help on this is greatly appreciated.

Answer 1

Since you have 16MB limitation of document size in MongoDB also your access pattern doesn't require to store the messages in the main document. you can go with the following model

Parent Referencing:

Store all your messages in a different collection and refer the main document id as parent document id

or

Embed only the frequently accessed (first 10 or 20) messages with the main document and store all messages in a different collection. So for the first load, you don't need to do $lookup . Only to see the other messages you need the second collection.