Redis集合操作效率

本文详细比较了Redis中五大基本数据类型(String、List、Hash、SortedSet、Set)的底层实现,探讨了双向链表、压缩列表、哈希表、跳表和整数数组在操作效率上的优劣,以及它们的时间复杂度。重点突出了单元素操作、范围操作和统计操作的性能特点,为选择合适的数据结构提供指导。
摘要由CSDN通过智能技术生成

Redis集合操作效率

Redis的基本数据类型主要分为String、List、Hash、Sorted Set、Set五大基本数据类型,其中除String底层采用的是动态字符串外,其余全部采用的是集合类型如下所示。

图片

那么对于五大底层数据结构操作效率到底如何呢?

双向链表

双向链表属于一种基本数据类型,在Java中也有大量的使用,如LinkedList,双向链表克服了单链表指针单向性的问题,其中每一个节点都有前置指针和后置指针,可以方便插入和删除数据元素,但由于双向链表需要维护两个方向的指针,因此添加节点和删除节点维护成本更高,其结构图如下所示

图片

双向链表其功能可以实现先进后出的栈,也可以实现先进先出的队列(或阻塞队列),如下所示

图片

如图我们可以看出,双向链表的检索是通过链表指针逐个查找,效率较低,操作复杂度为O(N)。

压缩列表

压缩列表其实是对数组的改进,数组的定义我们都是了解的,为一片连续的内存空间,申请的内存空间取决于存储的数据类型以及单个元素的长度,每个元素的长度都是固定的,如下所示。

图片

但这样的设计有个缺陷就是当存储的元素长度不固定,那么存储数组在定义时就需要按照存储元素的最大长度定义,这样就会造成内存使用长度远小于内存分配长度如下所示。

图片

Redis基于内存存储,那么对内存的利用就得更加慎重,简单数组这种设计方案明显会浪费内存,这时压缩列表就出现了,压缩列表在创建时同样需要申请一片内存空间,但是每个元素的长度不再固定,而是根据数据的实际长度确定,如下所示。

图片

Redis实际压缩列表结构如下

图片

结构解读如下

  • zlbytes:记录整个压缩列表占用内存字节数。

  • zltail:记录压缩列表表尾节点距离压缩列表的起始地址有多少字节。

  • zllen:压缩列表包含节点个数。

  • zlend:压缩列表结束标识符。

  • entryX:压缩列表的节点元素(包含前一个节点的长度、当前节点的数据内容)。

在压缩列表如果是查找头节点和尾节点我们可以通过表头的三个字段定义所以操作复杂度为O(1)、但对于其它字段都需要逐个查找所以时间复杂度为O(N)。

哈希表

哈希表数据类型和Redis的键值元素保存结构一致,主要通过数组加链表实现,每一个key通过哈希算法得到数组下标,如果发生哈希冲突采用哈希冲突链解决,也就是链表如下所示。

图片

采用哈希表存储虽然会有哈希冲突的问题,但是因为哈希算法的计算,检索不需要遍历整个数组,只需要计算key的哈希值后得到数组下标所以操作复杂度为O(1)。

跳表

对于普通的有序链表而言,遍历元素只能逐个查找,那么在时间复杂度上为O(N),所以针对有序链表这种数据结构推出了跳表的数据结构,跳表在有序链表的基础上增加了多级索引,通过索引的多级跳转可以实现数据的快速定位,如下所示。

图片

跳表这种操作有点类似于二分查找,在新增一级索引后那么查找效率将大大提升,操作复杂度由有序链表的O(N),变为跳表的O(logN)。

整数数组

整数数组顾名思义只能保存整数的数组,结构图其实和普通数组没有什么区别。

图片

但说到整数我们很容易联想到Java中的short、int、long这三种整数类型,都是整数但是占用字节数不一样,redis也是这样有int8_t、int16_t、int32_t或者int64_t的整数值,分别占用1字节、2字节、4字节、8字节,根据数组的定义难道需要定义长度的最大值8个字段的数据长度吗?如果是这样操作,每个元素8个字节但是存储元素却是1个字节这就是对内存的极大浪费,于是redis就推出了整数数组升级的概念。

假设我们保存的初始值是int8_t类型每个元素占用1个字节,如果后续需要保存int16_t或更大字节空间的元素,那么int8_t类型将无法保存,redis会将每个元素空间扩容到int16_t或者更大的字节空间。

图片

通过上图我们可以得到整数列表的操作复杂度和压缩列表类似还是O(N)

总结

通过了解五个集合类型的底层实现我们知道了它们之间的差异,同时也总结出了它们之间的时间复杂度,对比如下。

图片

存在即合理每种集合类型都有应用场景,所以我们应该需要了解各种操作对于集合时间复杂度的影响。

单元素操作

单元素操作如每种集合类型的增删改查操作,如哈希表的HGET、HSET 和 HDEL这些操作的时间复杂度明显就是O(1),那Set集合呢?Set集合底层采用哈希表和整数数组,如果采用的是哈希表那么SADD、SREM复杂度也是 O(1),但如果采用的是整数列表那么时间复杂度明显不同。

这里有个点需要注意的是Hash、Set集合存在批量操作,如果一次性获取、添加M(大于1)个元素如HMGET、SADD时,其时间复杂度为O(M)。

范围操作

集合中的遍历操作,可返回集合中所有元素,这个是不可取的,如Hash 类型的 HGETALL 和 Set 类型的 SMEMBERS,或者返回一个范围的数据如List 类型的 LRANGE 和 ZSet 类型的 ZRANGE,又或者是keys*这类统计操作都需要慎重使用,这类操作不建议在生产中使用,我们可以使用Redis2.8版本提出的SCAN(HSCAN,SSCAN,ZSCAN)渐进式遍历每次返回有限数量的数据避免IO阻塞。

统计操作

集合中计算所有元素个数时,因为压缩列表、双向链表、整数数组这些结构中都包含了元素个数的统计,所以可以高效的完成。

列外情况

对于某些特殊的数据结构如压缩列表和双向链表,这两个数据结构都会记录表头和表尾的偏移量,那么对于 List 类型的 LPOP、RPOP、LPUSH、RPUSH,这些操作在列表头尾增删元素,我们就可以通过偏移量直接定位,高效入队。

注意

我们通过数据类型的底层结构图可以知道只有List的底层结构双向链表和压缩列表时间复杂度都是O(N),我们需要因地制宜的使用List,如list的出队入队效率高,那么我们可以将List应用于FIFO的队列使用,我们不能将List数据类型作为随机读写的集合。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值