Introduction to Redis Database usage scenarios (avoid misuse of Redis)

Reproduced in: http://www.itxuexiwang.com/a/shujukujishu/redis/2016/0216/122.html?1455854235

Redis is the most popular deep-fried chicken in the NoSQL world, and it is a small, sharp, and practical, especially suited to solving problems that are difficult to solve with traditional relational databases. But Redis is not a silver bullet, there are a lot of problems that suit it, but there are a lot of 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 use the data for the system storage in two different angles, one is divided by the size of the data, divided into big data and small data, the other is divided into cold and hot data according to the data, the thermal data refers to read or write more frequent data, and vice versa is cold data.

Some specific examples can be given 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 the data has only one value, heat is because the number of registered users over time changes very frequently. For example, the user's latest access time data, which is a large amount, hot and cold uneven data, large is the granularity 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 data, hot and cold is not due to active users of the latest access time changes very frequently, However, there may be a large non-active user access time will not change for a long period of time.

In general, Redis is best suited to deal with hot data that is small and hot, and is frequently written or read or written. For large and hot data, if other ways are difficult to solve, you can also consider using Redis, but be very careful to prevent the data from expanding indefinitely. The reasons are as follows:

First, for cold data, regardless of size, it is not recommended to be placed in Redis. Redis data to be all in memory, the resources are precious, cold data in it is a waste, cold data in ordinary storage such as relational database is good.

Second, for thermal data, especially hot data that is written frequently, if the amount is smaller, it is best suited to Redis. For example, the above mentioned site total number of registered users, is the typical Redis used as a counter example. Another example is the forum's latest list, the latest registration list, can control the number of hundreds of to 1000 of the scale, is also a typical redis to do the latest list of how to use.

In addition, for a large amount of heat data (or hot and cold uneven data), use Redis must be more cautious. This type of data can easily cause data bloat, causing Redis to consume huge memory and make the system unbearable. One of the bitter lessons of mint is to put the user's attention (and attention) data in Redis, which is a data-intensive, cold-and-hot, unbalanced figure that takes up nearly ten gigabytes of memory at a millions of user level, making Redis difficult to cope with. For this type of data, you can use the normal storage + caching method.

If you use the right place, such as in a small, hot data situation, Redis is great, and if you use the wrong place, Redis can be costly, so use caution.

Related Hot Word search:

Introduction to Redis Database usage scenarios (avoid misuse of Redis)