Migrating from Redis to MongoDB: Real-World Strengths and Weaknesses
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.