Redis database usage scenarios (avoid misuse of Redis) _redis

Redis is currently the NoSQL field of the popular fried chicken, it is like a Swiss Army knife, small, sharp, practical, especially suitable for the use of traditional relational database difficult to solve problems. But Redis is not a silver bullet, there are many problems that are suitable for it, but there are many problems that are not suitable for it to solve. In addition, Redis as a memory database, if used in unsuitable situations, the memory consumption is very considerable, and even make the system unbearable.

We can classify the data used by system storage in two different ways, one is divided by the size of the data, divided into large and small data, the other is according to the data of the cold and heat level division, divided into cool data and thermal data, hot data refers to read or write more frequent data, Vice is cold data.

You can give some concrete examples to illustrate the size of the data and the hot and cold properties. For example, the total number of registered users of the site, which is obviously a small and hot data, small because this data has only one value, the heat is because the number of registered users with time changes very frequently. For example, the user's latest access time data, this is a relatively large, hot and cold uneven data, large is the size of the data is the user level, each user has data, if there are 10 million users, it means that there are 10 million of the data, hot and cold is due to active users of the latest access time changes very frequently, But there may be a large, inactive user. The access time does not change for a long period of time.

Generally speaking, Redis is the most suitable for dealing with small and hot, but also write frequently, or read and write are more frequent hot data. For large and hot data, if other ways are difficult to solve the problem, you can also consider using Redis solution, but must be very cautious to prevent the data from expanding indefinitely. The reasons are as follows:

First of all, for cold data, regardless of size, are not recommended in Redis. Redis data to all in memory, resources valuable, put cold data in which is a waste, cold data in ordinary storage such as relational database is good.

Secondly, for thermal data, especially for frequent thermal data, if the amount is small, it is most suitable for redis. For example, the total number of registered users mentioned above is a typical example of redis used as a counter. For example, the forum's latest published list, the latest registration list, can control the number of hundreds of to 1000 of the scale, but also a typical redis to do the latest list of use.

In addition, for a large amount of thermal data (or hot and cold uneven data), the use of Redis must be more cautious. This type of data can easily cause data bloat, causing Redis to consume large memory and make the system unbearable. A painful lesson of mint is to put the user's attention (and attention) data in Redis, which is a large amount of data, hot and cold is very uneven data, at millions of user level occupies nearly gigabytes of memory, so that redis become difficult to cope with. This type of data should be stored in a normal storage + cache mode.

If you use the right place, such as in small and hot data, Redis performance is great, if the use of the wrong place, Redis will also bring expensive costs, so use caution.