CODEWITHSUNDEEP
databasemongodbmongodb-querydata-modeling
Tom
Tom

Reputation: 2661

Where to store a reference to other data models (in mongoDB) for best performance

In my project I have users and circles. Circles can have multiple users and a user can be in multiple circles. Lastly there are events. Each event can have multiple users in one circle. Later, events will get a lot of content, so there will be a lot of stuff to load (images, comments, etc.).

I was thinking that these would be a good data models: 

User =  {
        _id: "uuid",
        name: "string",
        password: "string",
        circles: [Circle._id],
}

Event = {
    _id: "uuid",
    name: "string",
    location: "string",
    circles:Circle._id,
    participants: [User._id],
}

Circle = {
    _id: "uuid",
    name: "string"
}

Once the user logs in, he/she selects one of his circles, users and events in that circle will be displayed.

An API with these data models (I think) would mean to get the users and events from one circle, the database has to search through all users and events and check check if they are in that circle. With a lot of users and events, I think this might not be the most efficient way?

So I was thinking of putting the user and events into arrays of the circle like this: 

User =  {
      _id: "uuid",
      name: "string",
      password: "string",
}

Event = {
     _id: "uuid",
     name: "string",
     location: "string",
     participants: [User._id],
}

Circle = {
     _id: "uuid",
     name: "string",
     users:[User._id],
     events:[Event._id]
}

Now, when the user selects the circle, the circle loads slower, because the users and events have to be loaded first. But I was thinking, that searching for users and events would now be faster. Is this the correct approach/thinking? Would it make sense to keep a reference to the specific circle ids in the User and Event data model?

Upvotes: 0

Views: 62

Answers (1)

HIRA THAKUR
HIRA THAKUR

Reputation: 17757

If you want to use mongoDb to its full strength, I strongly recommend denormalising your data.

If you normalize your data, you might have to use $lookup to club multiple collections. Even if you save up on your harddisk, you will end up with relatively heavier computation.

Assuming that an application generally has 90% of hits as reads and 10% as writes, it makes sense to model your data in read friendly way. Hence highly denormalize your data untill its really necessary to create references to other collection. Optimizations can be later achieved by indexing and caching, but give below scema a thought.

User =  {
        _id: "uuid",
        name: "string",
        password: "string",
        circles: ["circle1","circle2"],
        events : ["event1","event2"]
}

Event = {
     _id: "uuid",
     name: "string",
     location: "string"
}

Circle = {
     _id: "uuid",
     name: "string"
}

Try and know your queries beforehand, archiving most of your data in User collection. circles and events field in User collection can also be an array of objects [{},{}] if there are more properties to be stored.

I am certain that the more collections you club, the more complicated your queries will get and the computation will also be more.

I wont recommend storing userId's in circle or event collections as users may grow over time and you dont want to endup with a collection that has a document with one field storing thousands of array elements. On the contrary a user can be a part of 100's of circles and events, and if we store this data in User collection, it becomes quite easy to query and manage.

Long story short : Do not treat a nosql db as a relational db. It will never fit in. Model your database keeping your future queries in mind. Highly denormalize your data to make your read simpler i.e avoid references.

Upvotes: 1

Related Questions