Using Redis as Only and Primary Database

Question

Here are the pros and cons of using redis.

Pros

1. Fast

2. transaction (because single threaded)

Cons

1. No secondary key support

2. No reindexing support

3. No reliable change streams unlike mongodb, dynamodb

4. Cost (since all the data has to be kept in memory, we need more and more ram)

5. No reliable persistence. (PS People say that rdb snapshot serves as a back up store for redis but help me understand what happens when we have 12 gb ram and we put 13 gb of data. redis will only have 12 gb of data, but if using the rdb snapshot if I bring up another redis with 20gb ram, will it have all my data or 1 gb is gone forever. How reliable is this mechanism??)

6. No auto balancing of keys. (application level sharding is a must)

Considering the above pros and cons I see only few use cases where we can have redis as Only and Primary data store. Like

1. Session store.

Am I missing anything? What additional capabilities does redis miss than other databases like mongodb, mysql (Here I am only talking about being production ready and reliability not starting nosql vs sql debate :) ).

Misusage

I would request not to close, This is a common mistake people make (choosing redis a primary store, without knowing what they are up against.) and this question can prevent that, – Misusage

We use Redis as our primary data store and have been since 2015 without any issues. It works for us because we can predict a time window (non business hours) when the db will see little to no activity. We use it with combination of RDB and AOF settings with appendOnly set to off in the conf file. We pragmatically turn it on after restarts since appendOnly can overwrite the entire database. Since we can predict a time window of no traffic, that is when we run a BGSAVE to snapshot any pending changes from AOF to RDB and push a backup of this file to AWS S3, keeping last 7 days worth RDB files. – Acetate

Our db size for your reference is approx. 5GB where 2x collections account for 3.5GB of it. In a relational database sense, these 2 collections are transactions and transaction_items, each with approx. 10MM and 15MM entities (aka rows). We’ve written our own serializers in Go to read/write data to this db. I hope this provides you with a small point of reference. – Acetate

Answer 1

Redis in fact is not a data store, nor is intended to do what a database (or maybe file system) was designed to do. As you correctly point out, if you need to store more information than can easily fit into RAM, then an in-memory cache solution such as Redis is no longer suitable. The other big risk with trying to use Redis as you would a database is that should Redis ever go down, you would lose all your state. Note that it is actually possible to configure Redis to take periodic snapshots into a persistent layer, such as a database. But even in this case, your cache would still be vulnerable in between snapshots. To remedy this, you could increase the frequency of database snapshots, but in this limit, your Redis cache would start to behave more like a database than a fast in memory cache.

So for what might Redis be suitable? Redis might be suitable for storing things like application session state. This tends to be reasonably small amounts of information, and also there isn't too much risk should Redis go down (perhaps in the worst case certain users would have to login again).

Overhang

Answer 2

It is possible to configure Redis persistence RDB + AOF and with that option you can use only Redis, but be aware that having RDB + AOF will be impacting Redis performance for write operations and there might be another issues mapping you in-memory data to disk and vice versa.

Redis is in-memory storage and, as you already know, there are some hurdles making it primary database. Also you can try ready-to-go solutions like AWS MemoryDB, which is reliable database and Redis at the same time. If you can't use solutions like that, I don't recommend focusing effort try store data only on Redis and have data backed up by regular, well understood database.

Deming

Answer 3

It is important to consider that the use of Redis is not limited to session management and can offer a range of benefits beyond that. For instance, Redis can be used to store data while logs of data transactions can be saved in DynamoDB, assuming the system is hosted on AWS. This approach allows for lightweight Redis snapshots to be taken periodically, and in the event of a disaster, the system state can be easily recovered from the snapshot and DynamoDB logs. Additionally, Redis (stack) offers modern features such as querying, JSON support, and search, which can be leveraged to design a variety of use-cases beyond session management. While there may be cases where Redis is not the best fit, with proper system design, it can provide a highly consistent and partition-tolerant system that is also flexible.

Toponym

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Electroscope