What is Redis? How can it be used a database?

Redis is an open source in memory data store — Redis stands for Remote Dictionary Server.

Redis has many uses, a couple examples are that it can be used as a cache, database, and a message broker. The main purpose of Redis is to make your application faster and more efficient by storing and retrieving data in memory. In this article, I will be talking about Redis in the case of it being used as a database.

So how does using Redis as a database make my application faster?

Well.. it’s because Redis databases are whats called “in memory” databases — which means that data is stored on your RAM(Random Access Memory). And it’s because of this, it improves the performance of your application because data retrieval and persistence to RAM is much faster than the conventional SQL database, as the data for that is stored in formatted computer files on disk ( which takes longer to access ).

Redis is also a non structured query language, meaning there is no database schema. It’s not a document based datastore either like mongoDb. Instead Redis is a multi model database so can store many different types of data stores, in the same database.

If you didn’t have Redis, and you had different data types in your application like graphs, media and relational data for example; you would probably need different data stores for each type. Which means your application set up would be more complex to make these connections, maintenance would also be more difficult too and your application would be slower because of the different networking connections between the data stores.

So how is Redis able to store different data types in the same database?

Firstly, Redis has Redis core. Which is a data store for key/value pairs. If you want to add any other data types to your database, you can choose the data types through Redis modules to extend this.

Redis also includes caching out of the box for your database, because well, that’s one of Redis’ main features :)

This sounds great, but when reading about it initially, I had some doubts:

1 —How can an in memory database persist data if the server was to fail?

2 — How can I recover data if point 1 was to happen?

3 — Scalability? Can it handle multiple request at any one time? And can it run out of memory?

But never fear, Redis has it all covered and I can tell you how…

How can an in memory database persist data if the server was to fail?

If the server that Redis was running on was to fail, because it’s an “in memory” database, yes — ALL of your data would be lost. But there are a couple of ways to safeguard this. It’s best practice to have multiple servers across multiple locations. So if one server goes down, the backup server will take over and your application will continue to run. This is the same concept with Redis. You would have another instance or replica of your Redis database on other servers. So if the master Redis instance was to go down, the replica on another server would take over.

How can I recover data if point 1 was to happen?

So it’s all well and good having multiple copies and multiple servers.. but what if for some reason ALL of our servers were to fail.. well.. we would lose all of our Redis database data!

Doesn’t sound so good now right?

But don’t worry, Redis have a couple of solutions to stop this from happening.

The first thing Redis offer is called snapshotting — this creates a single-file point in time snapshot of your dataset and it’s stored on a disk. You can configure how often to take these snapshots.

However, the downside of this is that it could be a few minutes between each snapshot, so if the server was to go down, and your last snapshot was 20 minutes ago.. you lose completely the last 20 minutes of data.

Next we have Append Only File— this is where it logs every write database operation continuously.. again saved to a disk — which means if the server was to fail with this backup method, Redis will be restored with all the data it had before the server died.

You can also use a combination of snapshotting and append only file for data backups in Redis :) In either case, your data is persisted to a separate server where your Redis database doesn’t run, as it’s best practice to not store your back ups on the same server as your application( backups should also be spread across multiple servers too)

One other thing to note is that because Redis stores data in memory, the size of RAM compared to disk space in your server will be smaller.. which means you will most likely end up using more servers with Redis, than if you had an SQL database that stored the data on disk.. So that is the caveat, Redis is much more faster and efficient, but it comes at a price.

Saying that, Redis have acknowledged this and they have something called Redis On Flash — Basically, frequently accessed data is stored on RAM and infrequently access data is stored on the SSD — which means Redis can use more server storage then if it was just to store data on RAM alone.

Scalability? Can it handle multiple request at any one time? And can it run out of memory?

So we know already that your Redis Database can be ran on multiple servers incase of a server outage. Not only does it serve the purpose of having a backup replica of your Redis database, but it also means that if there is a lot of traffic and it’s too much for one instance of Redis to handle, the other Redis replicas will kick in and help out dealing with these requests.

But what if the amount of data stored per Redis instance is now too big for the server it lives on? If this was to happen, then Redis does something called Sharding. And this is where the data is broken down in to chunks, and each Redis instance will be responsible just for dealing with that chunk of data rather then ALL of your data. Different Redis instances will be responsible for different chunks of your datastore. So by doing this, it reduces the amount of memory each Redis instance uses.

Not only does this solve the memory concerns, but it also means that your Redis database is highly available and highly performant too. This combined with the fact it’s fast anyway being stored in memory.. it’s hard to see why not to use Redis.

But then I hear you say “Jess, how am I supposed to maintain this? Especially with the sharding now.. the scalability alone was enough!”

Don’t worry! :) Because Redis enterprise deals with all of this for you :P

So that’s my quick dive in to Redis, I hope it helped you :)