Based on the fact that redis is single-threaded, the use of Redis must be conscious of whether there is a large value, and there are frequent, concurrent access to Redis scenarios, such as a command that takes 10ms, and then 100 concurrently every second, then basically redis will be blocked on this command;
Let's first look at the time complexity of several common commands of Redis:
- keys * Returns all keys. The keys command is best not to be used in a production environment. It will traverse globally, which will be very slow and block other commands.
- dbsize shows how many keys there are, which can be used in production and will not be traversed globally
- exists keyname Check whether the key exists, return 1 if it exists, and return 0 if it does not exist
- del kename delete key returns 1 if successful, and returns 0 if failed. Multiple can be deleted.
- expire keyname seconds Set the expiration time for the key, in seconds
- ttl keyname Query the expiration time of the key. If the return value is -1, it means that it will not expire (permanent key), and -2 means that the key does not exist
- persist keyname Remove the expiration time of the key, it will not expire (permanent Key)
- tpye keyname Check the data type of the key
| Order | time complexity |
|---|---|
| keys | O(n) |
| dbsize | O(1) |
| exists | O(1) |
| of the | O(1) |
| expire | O(1) |
| ttl | O(1) |
| persist | O(1) |
| tpye | O(1) |
Sorting of several complexities,
the difference between O(1), O(n), O(logn), O(nlogn):
There is a function in the parentheses after O, which indicates the relationship between the time-consuming/space-consuming of an algorithm and the amount of data growth. where n represents the amount of input data.
O(1) is the lowest time-space complexity, that is, time-consuming/space-consuming has nothing to do with the size of the input data, no matter how many times the input data increases, the time-consuming/space-consuming will remain the same. The hash algorithm is a typical O(1) time complexity. No matter how large the data size is, the target can be found after one calculation (regardless of conflicts). The time complexity is
O(n), which means that the amount of data increases several times, and the time consumption also increases several times. For example, common traversal algorithms.
O(logn), when the data is increased by n times, the time consumption is increased by logn times (the log here is based on 2, for example, when the data is increased by 256 times, the time consumption is only increased by 8 times, which is a time complexity lower than linearity). Binary search is an O(logn) algorithm. Each search excludes half of the possibilities, and the target can be found by searching 8 times among 256 data.
O(nlogn) is the same, that is, n is multiplied by logn. When the data is increased by 256 times, the time-consuming increase is 256*8=2048 times. This complexity is higher than linear and lower than quadratic. Merge sort is O(nlogn) time complexity.
Comparison of time complexity:
O(1) < O(logn) < O(n) < O(nlogn) < O(n^2) < O(n^3) < O(2^n)
Enter several common commands listed in the above figure, such commands as keys * must be used with caution, but
for example, can the del command really be used casually?
The answer is definitely no. Del large objects are time-consuming (even if Redis 4.0 has asynchronous lazy deletion, but it also consumes performance, and frequent replacement of large memory is one of the factors). At this time, if the del concurrency is high, it will seriously block Redis;
Therefore, the overall conclusion is that commands with high time complexity should be used with caution, and commands with high concurrency and time-consuming should be used with caution to reduce the processing of large objects;
The following collects and organizes the Redis command time complexity query table:
String type:
For example, the following batch operation mset, mget command, the complexity is relatively high, to get 1000 batches? Try higher concurrency? The typical
Hash type is this hgetall, which gets a full amount of tens of thousands of data in the hash, try a little higher concurrency? The data structure of the List type List seems to take a long time for most commands. In fact, rpush and lpush are batch operations. If there are many pushes at the same time, the complexity is naturally O( k ) . The set collection of Redis provides operations such as intersection, union, and difference, that is, the following command sinter suinon sdiff command, the complexity is O(k), so some fans with a large V of tens of millions are a large set, and it is time-consuming to find intersection, union, and difference; ZSet type, that is, a sorted set. le/details/121345797?spm=1001.2014.3001.5501 can refer to the case ) ;
In short, when using Redis, it is necessary to consciously check whether there is a huge value, and it occurs frequently, and accesses Redis concurrently. For example, if a command takes 10ms, and then 100 concurrently every s, then basically Redis will be blocked on this command;