1. Special encoding:
Since Redis 2.2, many data types can be optimized for storage space through special encoding. Among them, Hash, List and Sets composed of Integer can all use this method to optimize the storage structure so as to occupy less space. In some cases, 9/10 of the space can be saved.
These special encodings are completely transparent to the use of Redis. In fact, it is just a transaction between CPU and memory. If the memory usage is higher, then more CPU will naturally be consumed when operating data, and vice versa. Redis provides a set of configuration parameters for setting various thresholds related to special encoding, such as:
#如果Hash中字段的数量小于参数值,Redis将对该Key的Hash Value采用特殊编码。 hash-max-zipmap-entries 64 #如果Hash中各个字段的最大长度不超过512字节,Redis也将对该Key的Hash Value采用特殊编码方式。 hash-max-zipmap-value 512 #下面两个参数的含义基本等同于上面两个和Hash相关的参数,只是作用的对象类型为List。 list-max-ziplist-entries 512 list-max-ziplist-value 64 #如果set中整型元素的数量不超过512时,Redis将会采用该特殊编码。 set-max-intset-entries 512
If a value that has been encoded exceeds the maximum limit in the configuration information after being modified. , then Redis will automatically convert it to a normal encoding format. This operation is very fast. However, if you operate it in reverse and convert a large value of normal encoding into a special encoding, Redis's suggestion is to do it first before officially doing it. It is best to simply test the conversion efficiency first, because such conversions are often very inefficient.
2. BIT and Byte level operations:
3. Use Hash as much as possible:
Now we will further prove this statement by learning the storage mechanism of Redis. The special encoding mechanism has been mentioned at the beginning of this blog, and there are two configuration parameters related to the Hash type: hash-max-zipmap-entries and hash-max-zipmap-value. As for their scope of action, they have been given before, so I won’t go into details here. Now let's assume that the number of fields stored in the Hash Value is less than hash-max-zipmap-entries, and the length of each element is also less than hash-max-zipmap-value. In this way, whenever there is a new Hash type Key/Value storage, Redis will create a fixed-length space for the Hash Value. The maximum number of pre-allocated bytes is:
total_bytes = hash-max-zipmap-entries * hash -max-zipmap-value
In this way, the positions of all fields in the Hash have been reserved, and Field/Value can be accessed randomly like accessing an array. The step interval between them is hash-max-zipmap- value. Only when the number of fields in the Hash Value or the length of a new element exceeds the above two parameter values respectively, Redis will consider re-storing them in the form of a Hash Table, otherwise it will always maintain this efficient storage and access. Way. Not only that, since each Key must store some associated system information, such as expiration time, LRU, etc., compared with String type Key/Value, the Hash type greatly reduces the number of Keys (most Keys Represented and stored in the form of a Hash field), thereby further optimizing the efficiency of storage space usage.