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:
-
Separating Data That is Accessed Together – Data that is accessed together should be stored together.
-
Bloated Documents – Separate frequently used data from infrequently used data in different collections to optimize your performance.
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