------ 本文是学习算法的笔记,《数据结构与算法之美》,极客时间的课程 ------
今天来看下,经典数据库 Redis 中常用数据类型,底层都是用哪种数据结构实现的?
Redis 是一种键值(Key-Value)数据库。相对于关系型数据库,Redis 也被叫作非关系型数据库
你MySQL这样的关系型数据库,表的结构比较复杂,会包含很多字段,可以通过SQL语句,来实现非常复杂的查询需求。而Redis客户只包含“键”和“值”两部分,只能通过“键”来查询“值”。正是因为这样简单的存储结构,也让Redis的读写效率非常高。
除此之外,Redis主要是作为内存数据库来使用,也就是说,数据是存储在内存中的。尽管它经常被用作内存数据库,但是,它也支持将数据存储在硬盘中。
Redis中,键的数据类型是字符串,但是为了丰富数据存储的方式,方便开发者使用,值的数据类型很多,它们分别是字符串、列表、字典、集合、有序集合。
“字符串(String)”这种数据类型非常简单,对应到数据结构里,就是字符串。你应该非常熟悉了,这里就不多介绍了。
列表(list)
列表这种数据类型支持存储一组数据。这咱数据类型对应两种实现方法,一种是压缩列表(ziplist),另一种是双向循环链表。
列表中存储的数据量比较小的时候,列表就可以采用压缩列表的方式实现。具体需要同时满足以下两个条件:
关于压缩列表,不是基础数据结构,而是Redis自己设计的一种数据存储结构。它有点类似数组,通过一片连续的内存空间,来存储数据。不过,它跟数组不同的一点是,它允许存储的数据大小不同。具体的存储结构也非常简单,如下图
来看下,压缩列表中的“压缩”该如何理解?
之所以说这种存储结构节省内存,是相较于数组的存储思路而言的。我们知道,数组要求每个元素大小相同,如果我们要存储不同长度的字符串,那我们就需要最大长度的字符串大小作为元素的大小(假设是20个字节)。那当我们存储小于20个字节长度的字符串的时候,便会浪费部分存储空间。
压缩列表这种存储结构,一方面比较节省内存,另一方面可以支持不同类型的数据。而且,因为数据存储在一片连续的内存空间,通过键来获取值为列表类型的数据,读取的效率也非常高。
当列表中存储的数据量比较大的时候,也就是不能同时满足刚刚讲的两个条件的时候,列表就要通过双向循环链表来实现了。
Redis的这种双向链表实现方式,非常值得借鉴。它额外定义一个list结构体,并组织链表的首、尾指针,还有长度信息。这样,在使用的时候就会非常方便。
字典(hash)
字典类型用来存储一组数据时。每个数据又包含键值两部分。字典类型也有两种实现方式。一种是刚刚说的压缩列表,另一种是散列表。
同样,只有当存储数据量比较小的情况下,Redis 才使用压缩列表来实现字典类型。具体需要满足两个两件:
当不能同时满足上面两个条件时,Redis 就使用散列表来实现字典类型。Redis 使用 MurmurHash2这种运行速度快、随机性好的哈希算法作为哈希函数。对于哈希冲突问题,Redis 使用链表法来解决。除此之外,Redis 还支持散列表的动态扩容、缩容。
当数据动态增加之后,散列表的装载因子会不停的变大。为了避免散列表性能下降,当装载因子大于1的时候,Redis 会触发扩容,将散列表扩大到原来大小的2倍左右。
扩容缩容要做大量数据搬移和哈希值的重新计算,所以比较耗时。针对这个问题,Redis使用渐进式扩容策略,将数据的搬移分批进行,避免大量数据一次性搬移的服务停顿。
集合(set)
集合这种数据结构类型用来存储一组不重复的数据。其实现方法有两种,一种是基于有序数组,另一种是基于散列表。
当要存储的数据,同时满足正面两个条件时候,Redis 就采用有序数组,来实现集合这种数据类型。
当不能同时满足这两个条件的时候,Redis 就使用散列表来存储集合中的数据。
有序集合(sortedset)
有序集合这种数据结构,我们在跳表那节就说过。它用来存储一组数据,并且每个数据会附带一个得分。通过得分的大小,我们将数据组织成跳表这样的数据结构,以支持快速地按照得分值、得分区间获取数据。
实际上,跟Redis 的其它数据类型一样,有序集合也并不仅仅只有跳表这一种实现方式。当数据量较小的时候,Redis 会使用压缩列表来实现有序集合。具体点说,使用压缩列表实现的有序集合的前提有两个:
数据结构持久化
尽管Redis 经常会被用途内存数据库,但是,它也支持数据落盘,也就是将内存中的数据存储到硬盘中。这样,当机器断电的时候,存储在Redis中的数据也不会丢失。在机器重新启动之后,Redis 只需要将在座在硬盘中的数据,重新读取到内存,就可能正常工作了。
刚刚我们讲到,Redis的数据格式由“键”和“值”两部分组成。而“值”又支持很多数据类型,比如字符串、列表、字典、集合、有序集合、像字典、集合等类型,底层用到了散列表,散列表中有指针的概念,而指针指向的是内存中的存储地址。那Redis是如何将这样一个跟具体内存地址有关的数据结构存储到磁盘中的呢?
实际上,Redis遇到的这个问题并不特殊,很多场景中都会遇到。 我们把它叫作数据结构的持久化问题,或者对象的持久化问题。
如何将数据结构持久化到硬盘?我们主要有两种解决思路。
第一种清除原有的存储结构,只将数据存储到磁盘中。当我们需要从磁盘还原数据到内存的时候,再重新将数据组织成原来的数据结构。实际上,Redis 采用的就是这种持久化思路国。
不过,这种方式也有一定的弊端。那就是数据从硬盘还原到内存的过程,会耗用比较多的时间。比如我们现在要将散表中的数据存储到磁盘。当我们从磁盘中,取出数据重新构建散列表的时候,需要重新计算每个数据的哈希值。如果磁盘中存储的是几GB的数据,那重建数据结构的耗时就不可忽视了。
第二种方式是保留原来的数据结构,将数据按原有的柳工在你在磁盘中。我们拿到散列表这样的数据结构来举例。我们可以将散列表的大小,每个数据被散列到的槽的编号等信息,都保存在磁盘中。这样在还原数据到内存时,就可以避免重新计算哈希值。