3 Collections per user in database

Ops and Admin
1

Would like to know if creating 3 collections per user in a Mongodb is acceptable. Or will it cause any performace and storage issues.
Expecting around 1million users in a period of 2years.

2

Hi @hera_1002,

The thing to keep in mind is that every instance holding the collection data will create a file per collection and a file per every index on the collection.

So if you create 3 collections per user (at least 1 index per collection is default _id) you will endup with 3 million collections and 4 million files.

This number is an exrtreme number which can introduce many problems for MongoDB server. Therefore, I don’t think that this design is scalable.

Can you have 3 collections with a user_id field where you filter user data based on this.

See the following documentation which is relevant for any MongoDB deployment. One of the suggestions is covered under “Reduce Number of Collections”:

Best regards,
Pavel

1 Like
3

Why do you need three collections per user? If you describe the problem you are trying to solve we may be able to propose a better solution.

1 Like
4

I’m a newbie to NoSQL. As of now I have come across a mobile app & I’m asked to continue the development .The database was having 3 collections per user and i wanted to confirm if that’s okay to continue with before putting out concerns to the vendor.

It would be really helpful if you could suggest for my requirement.
I’m supposed to track the user’s routine such as food intake , water intake and exercises everyday .
And my apologies for delayed response
Thanks in advance

5

Hi @hera_1002,

Alright, so there is more then one option to approach this use case and it is really a subject of your data access patterns, how will data be segregated on the screen and its volumes.

A possible option could be the following:

  • Users collection holding all users data like :
{
_id : ...,
Username: ...,
Email : ...,
LoginDate : ...,
TotalCounters : [ { totalDaysUsed : ....} ...]

This collection should endup with max of 2m documents which if correctly indexed is good.

  • Activity collections which should be separated by accumulated dates, for example a weekly basis (or maybe monthly on beginning)
    Activity_202009 , each user will have a daily document:
_id : ...,
UserId : ...,
DayDate: '20200907',
FoodActivities: [ { activityId: xxxx, ... }, {....}],
DrinksActivities : [ { activityId: yyyyy, ... }, {....}],
Excersizes: [{ activityId: zzzz, ... }, {....}],
....
}

In this collection the {UserId : 1, DayDate : 1} should probably be a compound index.

  • Possible to add a reference collection for activity to store extended data and metrics per activity and also split the collection based on date convention weekly ExtendedActivity_202009_week1 :
{ ActivityId: xxxx,
  Properties : [ {k : "metric1", v : "value1}, ... ]

Or

{ ActivityId: xxxx,
  Metric1 : "value1"
...
}

The idea is that this collection will be accessed based on {ActivityId : 1} when you look at a specific activity full view.

With the above design and 1m users will have max of 30M in the activities collection and probably less than that in extended collection per week.

When you grow above 1m consider doing a weekly collection or sharding the environment to expand.

As I mentioned this is one option, the idea is that you keep as few collections as possible and query data in less documents without inflating collections and keeping simple data access patterns.

Best
Pavel

1 Like