Redis Research (17)-SORT sorting, redis research sort sorting

Redis Research (17)-SORT sorting, redis research sort sorting

1. Set Operations of Ordered Sets

The set type provides powerful set operation commands, but the ordered set type is required if sorting is required. When designing Redis commands, the author of Redis considers the use cases of different data types. For features that are rarely used or that do not suffer too much performance loss, the author can use existing commands to implement them, redis will not provide commands separately for implementation. This principle enables Redis to maintain relatively simple commands while having powerful functions.

A common use case of Ordered Sets is big data sorting, such as the player ranking of a game. Therefore, it is rare to obtain all the data in the key. Redis also believes that developers do not need to directly obtain all the results after the intersection and Union operations, but want to store the results in a new key for subsequent processing. This explains why the ordered set only has ZINTERSTORE and ZUNIONSTORE commands, but does not have ZINTER and ZUNION commands.

Of course, in actual situations where you need to directly obtain the set operation results, in addition to waiting for Redis to add related commands, we can also use the MULTI, ZINTERSTORE, ZRANGE, DEL, and EXEC commands to implement ZINTER:

MULTIZINTERSTORE tempKey...ZRANGE tempKey...DEL tempKey...EXEC

Ii. sort command

In addition to the ordered set, we can also use the SORT provided by Redis. The SORT command can SORT the list type, set type, and sorted set type keys, and can complete tasks similar to connection queries in relational databases.

For example, the document IDs marked with "ruby" are: "2", "6", "12", and "26 ". Because all elements in the set type are unordered, The SMEMBERS command cannot obtain ordered results. In order to arrange the articles on the tab page in the order of release time (if you do not consider the publishing time before modifying the article release time, it is arranged in the order of the Article ID ), you can use the SORT command as follows:

redis＞SORT tag:ruby:posts1) "2"2) "6"3) "12"4) "26"

In addition to the set type, the SORT command can also SORT the list type and sorted set type:

When sorting an ordered set, the scores of the elements are ignored and only the values of the elements are sorted. For example:

In addition to arranging numbers, the SORT command can also use the ALPHA parameter to arrange non-numeric elements in alphabetical order.

The DESC parameter of the SORT command can be used to SORT elements in the ascending order:

redis＞SORT tag:ruby:posts DESC1) "26"2) "12"3) "6"4) "2"

The SORT command also supports the LIMIT parameter to return results within the specified range. Similar to SQL statements, LIMIT offset count indicates that the first offset element is skipped and the count element is obtained.
The parameters of the SORT command can be used in combination:

redis＞SORT tag:ruby:posts DESC LIMIT 1 21) "12"2) "6"

Iii. BY Parameters

The syntax of the BY parameter is "BY reference key ". The reference key can be a string type key or a field of the hash type key (represented as the key name-> Field name ). If the BY parameter is provided, the SORT command no longer sorts the elements based on their own values, but replaces the first "*" in the reference key with the value of each element and obtains its value, sort the elements based on the value.

When the reference key name does not contain "*" (that is, the constant key name, which is irrelevant to the element value), the SORT command will not perform the sorting operation, because Redis considers this situation meaningless (because all values to be compared are the same ). For example:

In this example, anytext is the constant key name (or even the anytext key does not exist). In this case, the SORT result is the same as the LRANGE result and no sorting operation is performed. The constant key name is useful when you do not need to SORT but need to use the SORT command to obtain data associated with the element.

If the reference key values of several elements are the same, the SORT command compares the values of the elements to determine the order of the elements.

The values of 4 and 1 are both 50, and the order is determined by comparing the values of 4 and 1.

When the reference key of an element does not exist, the default reference key value is 0:

The default value of 5 is 0, and the value of 3 is-10.

Although the reference key supports the hash type, "*" can only be used before the "->" symbol (that is, the key name part) after "->" (that is, the field name part) it is regarded as the field name rather than the value of the element as the placeholder, that is, the constant key name. However, an interesting result is displayed during the actual operation:

As mentioned above, when the reference key name is a constant key name, the SORT command will not perform the sorting operation. However, in the above example, the sorting is performed, and only the elements are sorted. This is because Redis determines whether the reference key name is a constant key name by judging whether the reference key name contains "*", while somekey-> somefield: * contains "*", so it is not a constant key name. Therefore, during sorting, Redis reads the somefield: * field in the somekey for each element ("*" will not be replaced by the delimiter). There is no value in this case, therefore, Redis will be arranged according to the size of the elements themselves.

Iv. GET Parameters

The GET parameter does not affect sorting. It is used to make the returned result of the SORT command not the value of the element, but the key value specified in the GET parameter. The GET parameter rules are the same as the BY parameter. The GET parameter also supports keys of the string type and hash type, and uses "*" as a placeholder.

The corresponding article title is directly returned after sorting

redis＞SORT tag:ruby:posts BY post:*-＞time DESC GET post:*-＞title

A sort command can contain multiple GET parameters (but only one BY parameter ),

redis＞SORT tag:ruby:posts BY post:*-＞time DESC GET post:*-＞title GET post:*-＞time

With n get parameters, each element returns N rows.

GET # returns the value of the element.

V. STORE Parameters

By default, SORT directly returns the sorting result. If you want to save the sorting result, you can use the STORE parameter. If you want to save the result to the sort. result key:

redis＞SORT tag:ruby:posts BY post:*-＞time DESC GET post:*-＞title GET post:*-＞time GET # STORE sort.result

The type of the saved key is the list type. If the key already exists, it will be overwritten. After the STORE parameter is added, the return value of the SORT command is the number of results.

Vi. Performance Optimization

SORT is one of the most powerful and complex commands in Redis. If it is not used well, it will easily become a performance bottleneck. The time complexity of the SORT command is O (n + mlogm). n indicates the number of elements in the list (set or sorted set) to be sorted, and m indicates the number of elements to be returned. When n is large, the performance of the SORT command is relatively low, redis will create a length of n before sorting (one exception is that when the key type is an ordered set and the reference key is a constant key name, the container size is m rather than n) the container to store the elements to be sorted. Although it is a temporary process, if a large amount of data is sorted at the same time, the performance will be seriously affected.

Note the following when using the SORT command during development.
(1) Reduce the number of elements in the key to be sorted as much as possible (make n as small as possible ).
(2) Use the LIMIT parameter to retrieve only the required data (to make m as small as possible ).
(3) If the number of data to be sorted is large, use the STORE parameter to cache the result as much as possible.