Migrating from Redis to MongoDB: Real-World Strengths and Weaknesses

DZone 's Guide to

Migrating from Redis to MongoDB: Real-World Strengths and Weaknesses

· Java Zone ·
Free Resource

Sometimes migrating your database to MongoDB is a SQL vs. NoSQL situation - you know, moving away from MySQL, that kind of thing - but when it's NoSQL to NoSQL, it can be a bit more nuanced. This recent post from Lee Kimber on Rackspace's blog explores a client's migration from Redis to MongoDB, and it's a bit more even-handed than most. According to Kimber, the need for NoSQL was clear:

When they approached us for a risk assessment of their need to upgrade their sensor-count from 276 to almost 8,000 (a 29x data-volume increase), it felt as though the decision to migrate to a more complex NoSQL database had already been made.

And also clear was the need for MongoDB:

...we identified during conversation that they had a wrenching need to be more statistically sophisticated. Exploring that need actually powered our recommendation – and their eventual move – to MongoDB.

But for Rackspace, the opposition is not quite so heated; they offer both Redis and MongoDB as a service. In other words, they come from a point of view outside of the all-too-common database-nationalism of the NoSQL world. Key to that point, according to Kimber, is that the MongoDB migration was not a complete abandonment of Redis, but a rearrangement of resources:

Have they dropped Redis? Far from it. They’re using it more than they were. But they’ve changed how they use it. They still use it for key-value data with needs that they know will remain simple into the future. They’re using it as a simple caching store for session data – a technique that, in the different world of web-applications, enables session-heavy web applications to scale by freeing them of the painful out-of-disk or slow disk-IO conditions they so often suffer. Probably the most common of these scenarios are customers who use it as a cache to speed up applications like Magento, where Redis is the primary cache layer in the defense-in-depth caching approach to Magento scalability challenges.

It's an interesting look at the strengths and weaknesses of two databases that work differently in the same space, and a great look at how to maximize your resources by taking advantage of the best (available) technology for each particular job. Check out the full article to get the whole story.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}