CN110399371A - 基于Redis数据库的减少内存消耗的方法、存储介质及设备 - Google Patents
基于Redis数据库的减少内存消耗的方法、存储介质及设备 Download PDFInfo
- Publication number
- CN110399371A CN110399371A CN201810369927.0A CN201810369927A CN110399371A CN 110399371 A CN110399371 A CN 110399371A CN 201810369927 A CN201810369927 A CN 201810369927A CN 110399371 A CN110399371 A CN 110399371A
- Authority
- CN
- China
- Prior art keywords
- data
- hash
- type
- redis database
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种基于Redis数据库的减少内存消耗的方法,包括如下步骤:将字符串类型的数据转化成哈希类型的数据;以及根据哈希类型的数据的单个域值对的最大长度和域值对的个数,设置Redis数据库的内建参数,使得Redis数据库使用压缩列表的编码方式对哈希类型的数据进行存储。根据本发明的方法利用了Redis数据库内存的特点,在保证业务数据完整可用的情况下,大大减少了Redis数据库对内存的使用量,从而达到了优化内存的目的。本发明还涉及相关的计算机可读存储介质以及相关电子设备。
Description
技术领域
本发明涉及软件工程领域,尤其涉及一种基于Redis数据库的减少内存消耗的方法,以及相关的计算机可读存储介质和电子设备。
背景技术
在Redis数据库中,所有的数据都是存储在内存中的,而在一些关系型数据库中,例如Mysql,数据是存储在磁盘中的。相较于磁盘,内存资源显得更为重要。如何更高效的使用Redis数据库内存,一直是开发者在探索的问题。
对于Redis数据库的内存优化,传统的做法是减少Redis数据库中键的长度,精简Redis数据库存储的数据内容。这种做法,在某些对业务数据要求不高的情况下确实可行,但是在大多数情况下,关键的业务数据必须要完整地存入Redis数据库中,导致开发者也无法更好地精简Redis数据库中键的长度以及数据的量,因此,急需一种能够大大减少Redis数据库内存消耗的方法。
发明内容
为了克服上述问题的至少一个方面,本发明实施例提供一种基于Redis数据库的减少内存消耗的方法、计算机可读存储介质及电子设备。
根据本发明的一个方面,提供一种基于Redis数据库的减少内存消耗的方法,包括以下步骤:
将字符串类型的数据转化成哈希类型的数据;以及
根据哈希类型的数据的单个域值对的最大长度和域值对的个数,设置Redis数据库的内建参数,使得Redis数据库使用压缩列表的编码方式对哈希类型的数据进行存储。
根据一些实施例,在将字符串类型的数据转化成哈希类型的数据的步骤之后还包括:
设置第一阈值,使得单个哈希类型的数据的域的数量不超过第一阈值。
根据一些实施例,第一阈值不超过1000。
根据一些实施例,设置Redis数据库的内建参数的步骤包括:
设置第二阈值,使得哈希类型的数据的域值对的个数不超过第二阈值;以及
设置第三阈值,使得哈希类型的数据的单个域值对的最大长度不超过第三阈值。
根据一些实施例,在设置Redis数据库的内建参数的步骤之后还包括以下步骤:
删除哈希类型的数据中的过期的域。
根据一些实施例,删除哈希类型的数据中的过期的域的步骤包括以下步骤:
设定第四阈值,判断哈希类型的数据中的域的存在时间是否超过第四阈值,删除哈希类型的数据中的存在时间大于或等于第四阈值的域。
根据一些实施例,判断哈希类型的数据中的域的存在时间是否超过第四阈值的步骤包括以下步骤:
记录哈希类型的数据中的每个域的写入时间,通过定时任务扫描每个域的存在时间,将存在时间与第四阈值进行比较。
根据本发明的另一个方面,提供一种计算机可读存储介质,其上存储有可执行指令,指令在由处理器执行时,可以实现根据上述实施例中的任一项的基于Redis数据库的减少内存消耗的方法的步骤。
根据本发明的又一个方面,提供一种电子设备,其包括:
存储器,用于存储可执行指令;以及
处理器,用于执行存储器中存储的可执行指令,以实现根据上述实施例中的任一项的基于Redis数据库的减少内存消耗的方法的步骤。
与现有技术相比,本发明具有以下优点:将Redis数据库中大量的中小型的字符串类型的数据转化为哈希类型的数据,结合压缩列表的编码方式对转化后的数据进行存储,精准的使用了Redis数据库内存的特点,在保证业务数据完整可用的情况下,大大减少了Redis数据库对内存的使用量,从而达到了优化内存的目的。
附图说明
通过下文中参照附图对本发明所作的描述,本发明的其它目的和优点将显而易见,并可帮助对本发明有全面的理解。
图1是实施根据本发明实施例的基于Redis数据库的减少内存消耗的方法的整体流程图;
图2是根据本发明实施例的计算机可读存储介质的结构示意图;
图3是根据本发明实施例的电子设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本发明。除非另外定义,本发明使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。
本发明提供一种基于Redis数据库的减少内存消耗的方法,根据图1所示,该方法包括以下步骤:
S101,将字符串类型的数据转化成哈希类型的数据。
Redis数据库是一种使用较为广泛的非关系型数据库(NoSQL),在Redis数据库中,数据都存储在内存中。Redis数据库内部是一个键值对(key-value)存储系统,数据主要是通过键值对进行存储。Redis数据库支持存储的值的类型很多,基本的类型包括字符串(string)类型、链表(list)类型、集合(set)类型、有序集合(zset)类型和哈希(hash)类型。在多种存储方式中,字符串类型的存储是Redis数据库最基本的键值对存储类型,也是大多数系统最常见的数据存储场景。字符串类型的数据存储的具体做法是:通过设置指令将键和值进行配对,让键能够指向值对应的地址。例如:
SET media:1234567 987
GET media:1234567
>987
上述例子中1234567可以是照片的地址,987可以是上述照片对应的用户,将每个照片地址作为键,用户地址作为值来组成键值对,并且让照片地址指向对应的用户地址,从而在输入照片地址时能够找到对应的用户地址。这种存储方式非常简便,但是会带来一个问题:大量的字符串类型的存储,将大量消耗Redis数据库的内存资源。有数据显示,使用字符串类型对数据进行存储,1,000,000张照片会用掉70MB的内存,300,000,000张照片就会用掉21GB的内存,由此可见,字符串类型的存储对内存的消耗是十分巨大的。
在本发明实施例中,为了使哈希类型的键值对与Redis数据库的键值对进行区别,可以将哈希类型的“键值对”称作“域(field)值对”。
在本发明实施例中,可以将字符串类型的数据统一存入一个哈希结构中,然后将存入哈希结构中的数据分段,每一段数据再分别使用一个哈希结构进行存储,这样就将字符串类型的数据转化成了哈希类型的数据。这里的哈希结构是指哈希类型存储数据使用的最小单元,可以通过人为设置长度参数来控制哈希结构的大小。
在某些可能的实施例中,在将字符串类型的数据转化成哈希类型的数据的步骤之后还包括:设置第一阈值,使得单个哈希类型的数据的域的数量不超过第一阈值。在每个哈希结构中都存在着域值对,域和值都可以是文字、整数或者二进制数据。同一个哈希结构里面的每个域必须是独一无二、各不相同的,而域的值则没有这一要求,换句话说,不同域的值可以是重复的。哈希结构中的每个域都会消耗CPU,一旦域的数量过多,在Redis数据库内部会产生长列表,而长列表会导致CPU消耗严重,达不到减少内存消耗的效果,因此,需要使得单个哈希类型的数据的域的数量不超过第一阈值。有数据显示,单个哈希类型的数据的域的数量不超过1000时效果较好,例如,单个哈希类型的数据的域的数量可以是600、700或者800,当然不限于上述数字。所以在某些实施例中,第一阈值不超过1000。这样不仅可以减少内存的消耗,还可以提高寻址效率。
S102,根据哈希类型的数据的单个域值对的最大长度和域值对的个数,设置Redis数据库的内建参数,使得Redis数据库使用压缩列表的编码方式对哈希类型的数据进行存储。
Redis数据库针对哈希类型的数据的存储有两种处理方式,一种是使用哈希表(hashtable),另一种是使用压缩列表(ZipList)。hashtable用于存储数据量较大的哈希数据,而ZipList用于存储数据量较少的哈希数据,数据量较少的哈希数据是指单个哈希类型的数据的域的数量不超过第一阈值的哈希数据。ZipList内存结构紧凑,内部表现为数据紧凑排列的一块连续内存数组,适合存储小对象和长度有限的数据。
ZipList是一个经过特殊编码的双向链表,它的设计目标就是为了提高存储效率。ZipList可以用于存储字符串或整数,其中整数是按真正的二进制表示进行编码的,而不是编码成字符串序列。一个普通的双向链表,链表中每一项都占用独立的一块内存,各项之间用地址指针连接起来。这种方式会带来大量的内存碎片,而且地址指针也会占用额外的内存。而ZipList却是将表中每一项存放在前后连续的地址空间内,一个ZipList整体占用一大块内存,这样既不会产生大量的内存碎片,也没有地址指针占用额外的内存,从而大大减少了内存的消耗。ziplist为了在细节上节省内存,对于值的存储采用了变长的编码方式,即,对于比较大的数据,就多用一些字节来存储,而对于比较小的数据,就少用一些字节来存储。这也与哈希结构本身的特性相对应:在单个哈希元素不足一定数量时,哈希结构会进行压缩存储。在本发明的实施例中,为了确保Redis数据库使用压缩列表的编码方式对哈希类型的数据进行存储,需要根据哈希类型的数据的单个域值对的最大长度和域值对的个数设置Redis数据库的内建参数,使得哈希类型的数据满足ZipList的编码要求。
在某些可能的实施例中,设置Redis数据库的内建参数的步骤包括:设置第二阈值,使得哈希类型的数据的域值对的个数不超过第二阈值;以及设置第三阈值,使得哈希类型的数据的单个域值对的最大长度不超过第三阈值。
在某些可能的实施例中,可以使用hash-max-ziplist-entries和hash-max-ziplist-value两个参数分别代表第二阈值和第三阈值,hash-max-ziplist-entries的含义是允许哈希结构在ZipList模型的情况下最多存储的键值对的个数;hash-max-ziplist-value的含义是允许哈希结构在ZipList模型的情况下存储的单个最大的键值对的长度,这里的“ZipList模型”是指将来被ZipList进行编码的对象。如果哈希类型的数据的域值对的个数大于hash-max-ziplist-entries或者哈希类型的数据的单个域值对的最大长度超过了hash-max-ziplist-value,就不能将哈希结构转化为ZipList模型,进而无法使用ZipList进行编码,这样就只能采用hashtable的编码方式,如果使用hashtable编码方式反而会增加内存消耗。
有数据显示,将步骤S101的例子中的数据存成哈希结构,每1,000,000张图片只消耗了16MB的内存,300,000,000张图片只使用了5GB内存,相同的照片,从字符串类型的数据转化为哈希类型的数据,内存消耗就从21GB降低到了5GB,可以从数据上直观地看到,内存的消耗大大降低了。
Redis数据库针对字符串类型的数据的存储是有存在时间的监控的,可以定时将过期的数据删除,以便释放内存。但是,哈希类型的数据的存储没有存在时间的监控,因此,在某些可能的实施例中,对于有删除过期数据的需求的场景,在设置Redis数据库的内建参数之后还需要删除哈希类型的数据中过期的域。
删除哈希类型的数据中过期的域的具体做法如下:设定第四阈值,判断哈希类型的数据中的域的存在时间是否超过第四阈值,删除哈希类型的数据中的存在时间大于或等于第四阈值的域。这里的第四阈值可以根据用户的需求人为设定,例如,可以是1小时,也可以是24小时,甚至可以是一周。当内存不够用的情况下,第四阈值一般设置地比较小,这样能尽快释放内存,而如果内存完全够用,第四阈值可以相对设置大一点,以使得数据保存的时间尽可能长。
判断哈希类型的数据中的域的存在时间是否超过第四阈值的具体做法如下:记录哈希类型的数据中的每个域的写入时间,通过定时任务扫描每个域的存在时间,将存在时间与第四阈值进行比较。这里的定时任务也可以由用户进行设定,即设定每隔多长时间进行一次扫描,设定的时间最好小于第四阈值,从而能够及时找到过期的域。当然,同时也要考虑CPU的情况,扫描的频率过高也会给CPU带来很大的压力,因此,设定的时间也不宜过小。
本发明提出的一种基于ZipList的Redis数据库内存高效使用的实现方法,将Redis数据库中最常见的大量的字符串类型的数据,采用哈希结构存储,通过控制hash-max-ziplist-entries和hash-max-ziplist-value参数,使哈希结构采用Redis数据库的ZipList编码方式,大大减少了Redis数据库的内存开销,提高了Redis数据库的使用效率。
基于同一发明构思,参考图2所示,本发明还提供一种计算机可读存储介质201,其上存储有可执行指令202,可执行指令202在由处理器执行时,可以实现根据上述实施例中的任一项所述的基于Redis数据库的减少内存消耗的方法的步骤。
基于同一发明构思,参考图3所示,本发明还提供一种电子设备301,该电子设备301包括:
存储器310,其用于存储可执行指令311;以及
处理器320,其用于执行存储器310中存储的可执行指令311,以实现如上述实施例中任一项所述的基于Redis数据库的减少内存消耗的方法的步骤。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (9)
1.一种基于Redis数据库的减少内存消耗的方法,其特征在于,包括以下步骤:
将字符串类型的数据转化成哈希类型的数据;以及
根据所述哈希类型的数据的单个域值对的最大长度和域值对的个数,设置所述Redis数据库的内建参数,使得所述Redis数据库使用压缩列表的编码方式对所述哈希类型的数据进行存储。
2.根据权利要求1所述的方法,其特征在于,在所述将字符串类型的数据转化成哈希类型的数据的步骤之后还包括:
设置第一阈值,使得单个哈希类型的数据的域的数量不超过所述第一阈值。
3.根据权利要求2所述的方法,其特征在于,所述第一阈值不超过1000。
4.根据权利要求1所述的方法,其特征在于,设置所述Redis数据库的内建参数的步骤包括:
设置第二阈值,使得所述哈希类型的数据的域值对的个数不超过所述第二阈值;以及
设置第三阈值,使得所述哈希类型的数据的单个域值对的最大长度不超过所述第三阈值。
5.根据权利要求1所述的方法,其特征在于,在设置所述Redis数据库的内建参数的步骤之后还包括以下步骤:
删除所述哈希类型的数据中的过期的域。
6.根据权利要求5所述的方法,其特征在于,删除所述哈希类型的数据中的过期的域的步骤包括以下步骤:
设定第四阈值,判断所述哈希类型的数据中的域的存在时间是否超过所述第四阈值,删除所述哈希类型的数据中的存在时间大于或等于所述第四阈值的域。
7.根据权利要求6所述的方法,其特征在于,判断所述哈希类型的数据中的域的存在时间是否超过所述第四阈值的步骤包括以下步骤:
记录所述哈希类型的数据中的每个域的写入时间,通过定时任务扫描每个域的存在时间,将所述存在时间与所述第四阈值进行比较。
8.一种计算机可读存储介质,其上存储有可执行指令,所述指令在由处理器执行时,实现根据权利要求1-7中的任一项所述的基于Redis数据库的减少内存消耗的方法的步骤。
9.一种电子设备,包括:
存储器,用于存储可执行指令;以及
处理器,用于执行所述存储器中存储的可执行指令,以实现根据权利要求1-7中任一项所述的基于Redis数据库的减少内存消耗的方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810369927.0A CN110399371B (zh) | 2018-04-23 | 2018-04-23 | 基于Redis数据库的减少内存消耗的方法、存储介质及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810369927.0A CN110399371B (zh) | 2018-04-23 | 2018-04-23 | 基于Redis数据库的减少内存消耗的方法、存储介质及设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110399371A true CN110399371A (zh) | 2019-11-01 |
CN110399371B CN110399371B (zh) | 2023-06-23 |
Family
ID=68320114
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810369927.0A Active CN110399371B (zh) | 2018-04-23 | 2018-04-23 | 基于Redis数据库的减少内存消耗的方法、存储介质及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110399371B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113297224A (zh) * | 2021-05-31 | 2021-08-24 | 上海艾麒信息科技股份有限公司 | 一种基于Redis的海量数据分类存储方法及系统 |
CN113297192A (zh) * | 2021-05-31 | 2021-08-24 | 上海艾麒信息科技股份有限公司 | 针对redis hash类型数据控制field过期的方法及系统 |
CN116340275A (zh) * | 2023-03-14 | 2023-06-27 | 深圳乐信软件技术有限公司 | Redis复杂对象内存压缩存储方法、装置及设备 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103544151A (zh) * | 2012-07-09 | 2014-01-29 | 上海斐讯数据通信技术有限公司 | linux系统中数据处理的方法及系统 |
CN107291832A (zh) * | 2017-05-27 | 2017-10-24 | 华南理工大学 | 一种基于列表存储结构的数据存储方法 |
-
2018
- 2018-04-23 CN CN201810369927.0A patent/CN110399371B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103544151A (zh) * | 2012-07-09 | 2014-01-29 | 上海斐讯数据通信技术有限公司 | linux系统中数据处理的方法及系统 |
CN107291832A (zh) * | 2017-05-27 | 2017-10-24 | 华南理工大学 | 一种基于列表存储结构的数据存储方法 |
Non-Patent Citations (1)
Title |
---|
张慧宁等: "Redis压缩列表研究与优化设计", 《计算机工程与应用》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113297224A (zh) * | 2021-05-31 | 2021-08-24 | 上海艾麒信息科技股份有限公司 | 一种基于Redis的海量数据分类存储方法及系统 |
CN113297192A (zh) * | 2021-05-31 | 2021-08-24 | 上海艾麒信息科技股份有限公司 | 针对redis hash类型数据控制field过期的方法及系统 |
CN116340275A (zh) * | 2023-03-14 | 2023-06-27 | 深圳乐信软件技术有限公司 | Redis复杂对象内存压缩存储方法、装置及设备 |
CN116340275B (zh) * | 2023-03-14 | 2024-03-01 | 深圳市乐信信息服务有限公司 | Redis复杂对象内存压缩存储方法、装置及设备 |
Also Published As
Publication number | Publication date |
---|---|
CN110399371B (zh) | 2023-06-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101505263B1 (ko) | 데이터 중복 제거 방법 및 장치 | |
US9047330B2 (en) | Index compression in databases | |
CN101894115B (zh) | 电子文档的图像数据处理方法及其装置 | |
US8719254B2 (en) | Efficient querying using on-demand indexing of monitoring tables | |
CN110399371A (zh) | 基于Redis数据库的减少内存消耗的方法、存储介质及设备 | |
CN110196847A (zh) | 数据处理方法和装置、存储介质及电子装置 | |
CN106547911B (zh) | 一种海量小文件的存取方法和系统 | |
CN106874348A (zh) | 文件存储和索引方法、装置及读取文件的方法 | |
CN111292225B (zh) | 对图形数据进行分区以进行大规模图形处理 | |
WO2019228098A1 (zh) | 一种数据压缩方法及装置 | |
CN107958079A (zh) | 聚合文件删除方法、系统、装置及可读存储介质 | |
CN106528896B (zh) | 一种数据库优化方法和装置 | |
CN108089825B (zh) | 一种基于分布式集群的存储系统 | |
JP7153420B2 (ja) | データベース中にグラフ情報を記憶するためのb木使用 | |
US9292549B2 (en) | Method and system for index serialization | |
CN109558456A (zh) | 一种文件迁移方法、装置、设备及可读存储介质 | |
CN107291832B (zh) | 一种基于列表存储结构的数据存储方法 | |
CN114297196A (zh) | 元数据存储方法、装置、电子设备及存储介质 | |
CN114138792A (zh) | 一种Key-value分离存储方法及系统 | |
KR20150035876A (ko) | 데이터 중복 제거 방법 및 장치 | |
CN110389714A (zh) | 用于数据输入输出的方法、装置和计算机存储介质 | |
CN108920110A (zh) | 一种基于内存计算模式的并行处理大数据存储系统及方法 | |
CN105808451A (zh) | 一种数据缓存方法以及相关装置 | |
US8463759B2 (en) | Method and system for compressing data | |
CN109189345B (zh) | 一种在线数据整理方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
TA01 | Transfer of patent application right | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20230522 Address after: 417000, Room 4283, 4th Floor, Building 31, Wanda Entrepreneurship Park, Jixing North Road, Lianbin Street, Loudi City, Hunan Province Applicant after: Hunan Xianggu Information Technology Co.,Ltd. Address before: 430000 Wuhan Donghu Development Zone, Wuhan, Hubei Province, No. 1 Software Park East Road 4.1 Phase B1 Building 11 Building Applicant before: WUHAN DOUYU NETWORK TECHNOLOGY Co.,Ltd. |
|
GR01 | Patent grant | ||
GR01 | Patent grant |