MongoDB vs Redis for user sessions?

Question

I need to load a few fields of information that changes infrequently for validation of routes that a user might access.

Currently, I query mongodb and store those fields in redis alongside any particular state information in a single hash that is keyed by 'user:' + mongodb_user_objectid when a user logs in.

Then I create a session for the http cookie and store this key as a string in redis as well keyed by 'sess:' + session_id.

Would it be better to not copy over the fields from mongodb and deal with updating both redis and mongodb when one of those validation fields may change?

Is there a significant performance difference from reading and writing this session information directly from/to mongodb without using redis as a middleman?

Answer 1

Unfortunately, a definite answer will require a measurement using your setup because there are so many potential factors.

However, my guess is that the overhead of using two datastores outweighs any potential advantages because the reads should be incredibly fast on both DBs:

• Since the sessions will be used often, the collection keeps pretty 'hot' so it will probably remain in RAM if any possible in MongoDB, too
• Losing a session wouldn't be great, but it's not a disaster, so you can write to MongoDB without waiting for a journal commit (which is pretty much the same reliability redis has)
• In either case, most time is (probably) spent on the network stack, and you have to go through that for both DBs

So, in a nutshell, I don't see any reasons why redis would be a lot faster in this case, but again, performance is often guesswork, especially when the details are unknown.