Most often this DBMS is used as a caching layer for working with data from another, slower DBMS. The best replacement for memcached is if it tells you something. Rarely, but still it can be used as an independent database for data. At the same time, Redis can handle different types of data, including lists, queues, can Pub/Sub, and it's very easy to work with TTL (key lifetime). It works in memory, is very fast, knows how to save data on a disk, and with the support of rewrite (much less load the disk) and load at startup. Almost a fairy tale.
Redis for you, if:
- the data volume is small and very simple scheme that puts "key=value" in the template;
- a simple implementation of Master replication - Slave. Really very simple configuration, just add the wizard instructions to the server config, run Redis Server and the data is already replicated. Although you should probably clarify that setting up flexible (partial) replication is unlikely to work;
- you need a Pub/Sub (queue). To be fair, there are separate Pub/Sub systems that implement this pattern as well as others. Redis implements this quite elegantly and simply, quite possibly you won't need others;
- you need a cache for a slower DBMS, or you just don't want to think about the speed of the DBMS with regard to its volume. An example is a site on Drupal, with the main database in MySQL and a cache in Redis. Conducted tests for the sake of interest to the usual ab, the rate of return of content may increase several times. On ordinary Apache + Redis + mod_php can achieve comparable performance with Nginx + php-fpm, and if you add Redis to Nginx...
There are minuses too, what without them.
- The amount of data should not exceed the amount of free RAM on your server (actually, it can, but then all of them will go into swap, it is much slower, in general it is better to avoid);
- for the sake of performance, there's a rather weak data security. That is, it may well happen that the data has been added, but after the restart it is not. Enabling AOL (append of file) slightly smoothes the situation, but then booting from disk will be quite long;
- transactions and related data is not what it can do. To be more specific, there is Pipeline and Multi/Exec, but it is not exactly a transaction in the classical sense;
- still doesn't know how to cluster and shard normally. There is still no normal implementation.