开发者

Redis远程字典服务器 hash类型示例详解

目录
  • 一,hasandroidh基本情况
  • 二,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基本情况

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

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

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

    Redis远程字典服务器 hash类型示例详解

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

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

    二,hash常用命令详解

    2.1 hset,hget,hexists,hdel

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

    Redis远程字典服务器 hash类型示例详解

    2.2 hexists,hdel

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

    Redis远程字典服务器 hash类型示例详解

    2.3 hkeys,hvals

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

    Redis远程字典服务器 hash类型示例详解

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

    2.4 hgetall,hmget

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

    Redis远程字典服务器 hash类型示例详解

    注意:

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

    2.5 hlen,hsetnx

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

    Redis远程字典服务器 hash类型示例详解

    2.6 hincrby,incrbyfloat

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

    Redis远程字典服务器 hash类型示例详解

    三,hash编码方式

    3.1 ziplist

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

    Redis远程字典服务器 hash类型示例详解

     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 演示

    Redis远程字典服务器 hash类型示例详解

    元素很多时就用hashtable来存 

    Redis远程字典服务器 hash类型示例详解

    四,应用场景

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

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

    Redis远程字典服务器 hash类型示例详解

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

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

    到此这篇关于Redis远程字典服务器 hash类型详解的文章就介绍到这了,更多相关Redis hash类型内容请搜索编程客栈(www.devze.com)以前的文章或继续浏览下面的相关文章希望大家以后多多php支持编程客栈(www.devze.com)!

    0

    上一篇:

    下一篇:

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    最新数据库

    数据库排行榜