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

Redis is the most popular Fried chicken in NoSQL. It is like a Swiss army knife. It is small, sharp and practical. However, Redis is not a silver bullet. There are many problems suitable for it to solve, but also many problems not suitable for it to solve. In addition, as an in-memory database, Redis, if used in the wrong situation, will consume a lot of memory and even make the system unbearable.

We can classify the data stored in the system from two angles: one is divided into big data and small data according to the size of the data; the other is divided into cold data and hot data according to the degree of cold and hot data. Hot data refers to the data that is read or written frequently, and the other 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 a website, which is obviously a small and hot number, small because the data has only one value, hot because the number of registered users changes frequently over time. Again, for example, the user access time latest data, this is 1 quantity is relatively large, uneven and data, is data granularity of user level, each one user has data, if there are 10 million users, 10 million data means, uneven and because the latest active users access time change very frequently, but may have very big one of active users access time for a long time will not change.

In general, Redis works best with small, hot, hot data that is frequently written or read or written. For large, hot data, Redis can be used if it is difficult to solve the problem in other ways, but be careful not to inflate the data indefinitely. Here's why:

First, for cold data, no matter how large or small, it is not recommended to put it in Redis. Redis data should be kept in memory, which is a precious resource. It is a waste to put cold data in it. Cold data should be stored in common storage such as relational database.

Secondly, for the hot data, especially the hot data with frequent writes, if the amount is small, it is the best place to put Redis. For example, the total number of registered users of a website mentioned above is a typical example of an Redis counter. For another example, the latest list of forum posts and the latest registration list can be controlled in the number of hundreds to 1000, which is also the typical way to use redis to make the latest list.

In addition, for large amounts of thermal data (or data with uneven heat and cold), Redis should be used with caution. This type of data can easily lead to data bloat, resulting in Redis consuming too much memory for the system to bear. One of the bitter lessons of peppermint is that it puts the user's attention (and attention) data into Redis, which is a huge amount of data, hot and cold data, which takes up around 10 GB memory at a user level of several million, making Redis hard to deal with. For this type of data, you can use normal storage + caching.

Redis works great if used in the right place, for example, in small, hot data situations, and Redis can be expensive if used in the wrong place, so be careful when using it.