32
loading...
Redis vs MongoDB, fight!
Redis is an in-memory, distributed database that has typically been used as a cache in multiple projects. The advantage over other types of databases is that it doesn't persist data to disk, so all the elements are always in memory. That should speed up reads and writes.
To understand what having a Redis cluster could offer us, we've run some experiments.
The idea behind this experiment is to test if MongoDB and Redis have a significant performance difference when accessing a cache by key. That means writing and reading to and from the cache by a key without further manipulating the value.
The weather service uses MongoDB as a cache to store weather forecasts, not to call the weather provider in every single request. We also added a Redis cache using AWS Elasticache. Let's see how those two compare.
This image shows MongoDB and Redis read time when retrieving forecasts from the cache. MongoDB shows 12ms for p99, 5ms for p90, and 2ms for p50. Redis shows 5ms for p99, 1ms for p90, and around 600µs for p50.
Although Redis performs almost 2x as MongoDB, would that difference justify the system's complexity by having another database? Let's see if we can answer these questions with a new experiment.
In this experiment, we will use Redis to cache the rankings using one of Redis' data structures. In this case, we're going to use a sorted set. This kind of structure allows us to keep a set of elements ordered by a score. In our case, the score will be either the level or the points of a player.
What we did was to add pages of the ranking when they are read from Mongo to Redis, and then every time a ranking request is received, we calculate the ranking using both Mongo and Redis. Since we don't have all players in Redis, the page calculated using Mongo is always returned to the client. The same calculation is done using Redis to compare the difference in time.
This image shows MongoDB and Redis read time when calculating the ranking. MongoDB shows 350ms for p99, 40ms for p90, 15ms for p50, while Redis shows 9ms for p99, 2.5ms for p90, and 1.5ms for p50. That means almost 40x for p99, 16x for p90, and 10x for p50 for Redis compared to MongoDB.
We've seen with these experiments that MongoDB can work pretty decently as a cache when the element is acceded by a key, and MongoDB has an index on that key with a particular TTL. However, Redis' time is always better.
For those use cases where Redis has its own data structure, Redis has no rival, and we strongly recommend its use.
Should we go then and use Redis in production? That's still to be seen. Using Redis as a cache would imply that we have to store the data somewhere else to ensure we can recreate the cache if something goes wrong. We would also need to keep in sync with both the cache and the underlying storing system.
What's clear is that Redis is a useful tool that we could end up needing. We're not sure if we need to start using it just right now, though.
Cover image by Mateusz Wacławek on Unsplash
32