1.Zipmap optimized Hash:
The previous talk of storing an object in a hash type consumes less memory and makes it easier to access the entire object. The reason for saving memory is that when a new hash object is created, it is stored with zipmap. This zipmap is not actually hash table, but zipmap compared to the normal hash implementation can save a lot of the hash itself needs some metadata storage overhead. Although Zipmap's additions, deletions, and lookups are all O (n), there are not too many field numbers for general objects. So the use of Zipmap is also very fast, that is, add delete average or O (1). If the size of field or value exceeds a certain limit, Redis automatically replaces the zipmap with the normal hash implementation internally. This restriction can be specified in the configuration file (the default configuration is in redis.conf in the Redis root directory):
hash-max-zipmap-entries # configuration fields up to a maximum of Hash-max-zipmap-value # configuration value Max is 64 bytes |
2.ziplist Optimization list:
If the type member value of Redisobject is Redis_list, If the list has fewer elements than the configured value List-max-ziplist-entries and the element value string is less than the configured value List-max-ziplist-value it can be encoded into Redis_encoding_ziplist type storage , otherwise use Dict to store (Dict is actually a hash table of an implementation), List uses ziplist data structure to store data, so on the one hand, in order to save memory, on the other hand, the structure of sequential storage, can better utilize the CPU local and prefetch strategy.
The configuration is as follows:
list-max-ziplist-entries # maximum number of configuration elements List-max-ziplist-value # configuration value Max is 64 bytes |
3.intset optimization set:
When the elements in the set set are integers and the number of elements is less than the configured set-max-intset-entries value, the INTSET data structure is stored, otherwise it is converted to dict structure, dict is actually a hash table implementation, key is the element value, Value is null to determine whether an element is contained in the collection for an O (1) time.
There are three types of arrays in Intset: int16_t type, int32_t type, and int64_t type. As to how the choice is that type of array, it is determined by the value range of its saved values, the initialization is int16_t, according to the maximum value in the set in [Int16_min, Int16_max], [Int32_min, Int32_max], [int64_ MIN, Int64_max] The value range to dynamically determine the type of the entire array. For example, set starts with the int16_t type, and when a value range is added to the set in [Int32_min, Int32_max], the array that holds the set is upgraded to an array of int32_t.
The configuration of the Intset element limit is as follows:
set-max-intset-entries # maximum number of configuration elements |
4.ziplist optimized sorted set:
Root hash and list like sorted set also has a way to save memory, when the number of elements of sorted set and the element size is less than a certain limit, it is stored with ziplist.
The configuration of this restriction is as follows:
zset-max-ziplist-entries # maximum number of configuration elements Zset-max-ziplist-value # configuration value Max is 64 bytes |
5. Summary:
Redis provides a lot of ways to optimize memory, the above configuration values are the default configuration, the actual need to adjust according to our specific requirements scenario, and to do a lot of testing to achieve optimal results. It is also necessary to have a good understanding of the data structures of Redis.
Redis Memory storage structure Analysis: http://www.searchtb.com/2011/05/redis-storage.html
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Redis tutorial 4--redis data storage optimization mechanism