Usage scenarios for REDIS data types

value is the corresponding data type.

String

Application Scenarios:
String is the most commonly used type of data, and ordinary key/value storage can be classified as such, and value is not only a string, but also a number.

Hash

Application Scenarios:
Let's simply cite an example to describe the application scenario for a hash, such as storing a user information object data that contains the following information:
User ID, the key for the lookup,
The stored value User object contains the name name, age, birthday birthday, and other information,
If you use a common key/value structure to store, there are 2 main storage methods:
The first way is to use the user ID as a lookup key, to encapsulate other information as an object to be stored in a serialized way,
such as: Set u001 "Lie triple, 18,20010101"
The disadvantage of this approach is that the overhead of serialization/deserialization is increased, and when one of the information needs to be modified, the entire object needs to be retrieved, and the modification operation needs to protect concurrency and introduce complex problems such as CAs.
The second method is how many members of this user information object will be saved into the number of key-value, with the user id+ the name of the corresponding property as a unique identifier to obtain the value of the corresponding property,
such as: Mset User:001:name "Lie Triple" User:001:age18 User:001:birthday "20010101"
Although the serialization overhead and concurrency issues are omitted, the user ID is a duplicate storage, and if there is a large amount of such data, the memory waste is very considerable.
The hash provided by Redis is a good solution to this problem, and the Redis hash is actually the internal storage value for a hashmap,
and provides a direct access to this map member's interface,
Example: Hmset user:001 name "Lie Triple" Age Birthday "20010101"
That is, the key is still user Id,value is a map, the map key is a member of the property name, value is the property value,
This allows the data to be modified and accessed directly through its internal map key (Redis is called the internal Map key field), that is, by
The key (User ID) + field (attribute tag) operation corresponds to the attribute data, which does not need to store the data repeatedly, nor does it bring up the problem of serialization and concurrency modification control. A good solution to the problem.

List

Set

Implementation method:
The internal implementation of set is a value that is always null hashmap, which is actually calculated by hashing the way to fast weight, which is also set to provide a judge whether a member is within the cause of the collection.

http://blog.csdn.net/gaogaoshan/article/details/41039581/

In Redis, not all data is stored in memory all the time, which is the biggest difference compared to memcached.

Redis not only supports simple k/v types of data, but also provides storage of data structures such as List,set,hash

Usage scenarios for REDIS data types