MongoDB Design for "Likes" in a social network

[Henri M]

Hi,

I'm building a photo/video sharing social network using MongoDB. The social network has a feed, profiles and a follower model. I basically followed a similar approach to this article for my "social feed" design: http://blog.mongodb.org/post/65612078649/schema-design-for-social-inboxes-in-mongodb. Specifically, I used the fan-out on write with bucket approach when users posts stories. 

My issue is when a user "likes" a story. I'm currently also using the fan-out on write approach that basically increments/decrements a story's "like count" for every user's feed. I think this might be a bad design since users "like" more frequently than they post. Users can quickly saturate the server by liking and unliking a popular post. 

What design pattern do you guys recommend here? Should I use fan-out on read? Keep using Fan-out on write with Background workers? If the solution is "background workers", what approach do you recommend using for background workers? 'm using Node.js.

Any help is appreciated!

Thanks,

Henri

[Asya Kamsky]

Hi Henri,

Interesting question.   While it's true that users "like" articles (much) more frequently than they post them, the cost of an in-place update of an existing article (increment of counter) is much more efficient and will be handled a lot faster than an insert of a post into the content collection and the cache, since the latter writes the document (in multiple places) and has to update indexes as well.   Incrementing a counter for likes shouldn't impact any indexes and it should be an in-place write.

To be honest, I thought your question was going to be about how to prevent the same user from liking a particular article multiple times - that's something that can be an issue, since just incrementing the counter won't give you a way to track that.   I was assuming that same as with content you would be writing the event "userX liked postY" somewhere where the write will fail if this is a duplicate record so then you would know not to continue to update the like counts in the content and cache collections.

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/bacb3e9f-d1b7-46d1-a985-ca65d814bc35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henri M]

Hey Asya,

Thanks for the reply, makes total sense. I'll stick to the fan-out on write approach for Likes. 

As for Fan-Out story inserts, do you have a recommended approach for breaking down the operation in background worker tasks?

As a side note, I handle duplication by having a Likes collection that keeps track of users who liked a story. It also allows me to display who liked the Story. The Likes Schema looks like this:

var likesSchema = new mongoose.Schema({

sid : {type : mongoose.Schema.ObjectId}, // (story for which these likes belong to)

seq : Number, // bucket #

likes : [ {

_id : { type : mongoose.Schema.ObjectId},

uname : String,

d : Boolean

} ]

});

Thanks!

Henri