Redis远程字典服务器(5) —— hash类型详解

发布于:2024-08-15 ⋅ 阅读:(149) ⋅ 点赞:(0)

目录

一,hash基本情况

二,hash常用命令详解

2.1 hset,hget,hexists,hdel

2.2 hexists,hdel

2.3 hkeys,hvals

2.4 hgetall,hmget

2.5 hlen,hsetnx

2.6 hincrby,incrbyfloat

三,hash编码方式

3.1 ziplist

3.2 hashtable

3.3 演示

四,应用场景


一,hash基本情况

哈希是我们目前接触到的数据结构中最重要的一个:

  1. 日常开发中,出场频率非常高
  2. 面试中,非常重要的考点

 Redis自身已经是键值对结构了,就是通过哈希的方式来组织的,而hash类型,就是把key这一层组织完之后,到了value这一层,其中的一种类型还可以再是一个哈希表:

哈希类型中的映射关系通常称为 field-value,⽤于区分 Redis 整体的键值对(key-value), 注意这⾥的 value 是指 field 对应的值,不是键(key)对应的值,请注意 value 在不同上下文的作用。

关于哈希的详细解释以前已经介绍过,传送门:C++&&数据结构——哈希表_c++哈希表-CSDN博客 

二,hash常用命令详解

2.1 hset,hget,hexists,hdel

hset就是同时建立key-valuefield-value键值对,前者是Redis的键值对,后者是value的键值对hget就是查询键值对:

2.2 hexists,hdel

hexists的作用是判断指定key的field是否存在,存在就返回1,否则返回0;hdel就是删除,删除key的某一个field-value,当key的field数量为0时,会顺带把key一起删了:

2.3 hkeys,hvals

hkeys作用是根据key找到所有的field并打印出来;hvals作用是获取所有的field和value,但不会显示field:

当然,像这样的“查询所有”的这种操作,也会有和keys *一样的问题的,但是也有解决方法,就是hscan遍历Redis的hash类型,属于“渐进式遍历”,我们后面再讲~ 

2.4 hgetall,hmget

hgetall相当于把上面两个命令合起来,同时显示field和value,以两两交替的方式打印出来;hgetall是一次查所有,但是我们有时只要查一部分,所以可以用hmget,就是根据命令行输入field获取对应value,可以一次查多个:

注意

  1. hgetall同样有keys * 的问题
  2. hmget的显示顺序和我们命令行输入的field的顺序是一致的
  3. 也有hmset一次设置多个field和value,但是不用,因为hset已经可以支持一次设置多个field和value了

2.5 hlen,hsetnx

hlen是获取hash中field-value键值对的个数;hsetnx和前面的setnx一样,如果field不存在就创建,存在就直接返回:

2.6 hincrby,incrbyfloat

hash类型中field的value也可以当作int处理,hincrby可以加减整数,incrbyfloat可以加减小数:

三,hash编码方式

3.1 ziplist

我们经常用到的压缩有rar,zip,7z等,通常是一些具体的压缩算法,本质是针对数据进行重新编码,不同的数据有不同的特定,结合这些特点进行精妙的计算,重新编码过后,就嫩缩小数据的体积:

 ziplist同理,内部的数据结构也是精心设计的,表示一个普通的哈希表,可能会浪费一定的空间(哈希是一个数组,数组上有些位置有元素,有些没有),使用ziplist就可以节省空间,内部的具体实现我们以后再看源码解析

当然,有好处自然会有坏处:读写元素较慢,如果元素较少,慢的并不明显,所以当哈希的元素个数较少,就会用ziplist去优化

当哈希类型元素个数⼩于 hash-max-ziplist-entries 配置(默认 512 个,我们一般会根据业务修改)、 同时所有值都⼩于 hash-max-ziplist-value 配置(默认 64 字节)时,Redis 会使⽤ ziplist 作为哈 希的内部实现,ziplist 使⽤更加紧凑的结构实现多个元素的连续存储,所以在节省内存⽅⾯⽐ hashtable 更加优秀。

3.2 hashtable

只有“元素个数太少”,“长度比较短”两个条件都具备,才会优化成ziplist,当hash类型⽆法满⾜ 这两个条件时,Redis 会使⽤ hashtable 作为哈希 的内部实现,因为此时 ziplist 的读写效率会下降,⽽ hashtable 的读写时间复杂度为 O(1)。

3.3 演示

元素很多时就用hashtable来存 

四,应用场景

最主要的应用场景还是作为缓存来使用,但是hash类型作为缓存有点特别,下面来具体讲讲

string也是可以用作缓存的,但是Redis是经常和MySQL打交道的,所以如果要存储MySQL表里面那样的结构化数据,使用hash类型更合适一些:

其实上述场景也可以用strin类型也能做到,需要用到 json 这样的数据格式

  1. 但是如果使用json的格式来表示上面的user时,如果我只想获取或修改其中的一个field,就需要把整个json都读出来,解析成对象,然后重写对应的field,再写回去,效率变低
  2. 而使用hash,就可以使用field表示对象的每个舒徐(相当于操作MySQL的每个列),次数就可以非常方便地修改任何一个属性的值了
  3. 但是使用hash的方式,确实读写field更直观和高效,但是付出的是空间的代价,而且还需要控制hash再ziplist和hashtable两种内部编码的转换,可能会造成较大的内存消耗

网站公告

今日签到

点亮在社区的每一天
去签到