Redis——常用数据类型hash

hash

常用命令

hset

HSET key field value [field value ...]

//时间复杂度O(1)
//返回值：设置成功的键值对的个数

hget

HGET key field

//

hdel

HDEL key field [field ...]

//删除hash中指定的字段
//注意： del删除的是key， hdel删除的是field

hkeys

HKEYS key

//查看key对应的哈希表的所有的key
//这个操作会现根据key找到对应的hash，O（1），然后再遍历hash O（n）
//这个操作也有一定的风险，类似于之前的keys*

hvals

HVALS key

//和hkeys相对，能够获取去到hash的所有的value
//时间福再度O（n），n是哈希的元素的个数，如果哈希非常大，这个操作就可能导致redis服务器被阻塞住

hgetall

HGETALL key

//查看key对应的哈希表的所有的key-val

上述hkeys，hvals，hgetall都是存在一定风险的，hash的元素个数太多，执行的耗时会比较长，从而阻塞redis,可以用hscan来渐进式遍历

hmget

HMGET key field [field2 ...]


//查看key中field的value，其中value的顺序和field是匹配的

hlen

HLEN key

//获取hash的元素的个数

hsetnx

HSETNX key field value

//如果key对应的value不存在 filed，就设置其value，如果存在，就失败

hincrby

HINCRBY key field n

//n可以是负数，正数，对key对应的value的整数加n

hdecrby

HDECRBY key field n

//n可以是负数，正数，对key对应的value的整数减n

哈希的编码方式

哈希的内部编码有两种：

• ziplist（压缩列表）：当哈希类型元素个数小于 hash-max-ziplist-entries 配置（默认 512 个）、同时所有值都小于 hash-max-ziplist-value 配置（默认 64 字节）时，Redis 会使用 ziplist 作为哈希的内部实现，ziplist 使用更加紧凑的结构实现多个元素的连续存储，所以在节省内存方面比 hashtable 更加优秀
• 哈希表：当哈希类型无法满足压缩列表（ziplist）的条件时，Redis 会使用哈希表作为哈希的内部实现，因为此时压缩列表的读写效率会下降，而哈希表的读写时间复杂度为 O(1)。

注意：

1. 哈希中的元素个数比较少，使用ziplist表示，元素个数比较多，使用hashtable来表示
2. 每个value的值的长度都比较短，使用ziplist表示，如果某个value的长度太长了，也会转换成hashtable
3. 在Redis的配置文件里可以修改这些参数，如hash-max-ziplist-entries配置(默认512字节)，hash-max-ziplist-value配置(默认64字节)

哈希的应用

关系型数据表保存用户信息

映射关系表示用户信息

这里可以以uid作为key，剩下的作为value字段，当然这种格式也可以使用string类型实现，比如使用Json这样的数据格式

• 如果使用string（Json）的格式来表示UserInfo，万一只想获取其中的某个field，或者修改某个field，就需要把真个Json都读出来，解析成对象，操作field，再重写转成Json字符串，再写回去
• 如果使用hash的方式来表示UserInfo，就可以使用field表示对象的某个属性（数据表的每个列）此时就可以非常方便的修改/获取任何一个属性的值了
• 使用hash的方式，读写field更加直观功效，但是付出的是空间的代价

但是需要注意的是哈希类型和关系型数据库有两点不同之处：

• 哈希类型是稀疏的，而关系型数据库是完全结构化的，例如哈希类型每个键可以有不同的 field，而关系型数据库一旦添加新的列，所有行都要为其设置值，即使为 null。

• 关系数据库可以做复杂的关系查询，而Redis 去模拟关系型复杂查询，例如联表查询、聚合查询等 基本不可能，维护成本⾼。

关系型数据库稀疏性

这里可以看到，上面的 key为uid，但是对应的value信息，还存了一个uid，那么这个uid不存可以吗？当然可以

但是，在工程实践中，一般会把uid在value中再存一份，后续写到相关代码，使用起来会比较方便