CN113407518A - Hbase数据库的Rowkey设计方法及装置 - Google Patents
Hbase数据库的Rowkey设计方法及装置 Download PDFInfo
- Publication number
- CN113407518A CN113407518A CN202110736994.3A CN202110736994A CN113407518A CN 113407518 A CN113407518 A CN 113407518A CN 202110736994 A CN202110736994 A CN 202110736994A CN 113407518 A CN113407518 A CN 113407518A
- Authority
- CN
- China
- Prior art keywords
- data
- rowkey
- determining
- hbase database
- stored
- 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
- 238000013461 design Methods 0.000 title claims abstract description 60
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000005192 partition Methods 0.000 claims abstract description 80
- 238000004590 computer program Methods 0.000 claims description 16
- 238000013500 data storage Methods 0.000 claims description 15
- 230000003111 delayed effect Effects 0.000 claims description 3
- 230000011218 segmentation Effects 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 150000003839 salts Chemical class 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- 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
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种Hbase数据库的Rowkey设计方法及装置,应用于大数据领域,该方法包括:确定所需存储数据需要占用的分区数量;根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;整合前半段和后半段,得到Rowkey设计值。进行分段设计,根据当前时间和分区数量,确定前半段为顺序字符串,让数据整体作为一个连续的整体,可以有效提高Hbase的读取效率;后半段由离散随机的通用唯一识别码组成,让数据在一定区域内离散存储,有助于提高数据的并行写入效率,既能提高数据的写入性能,又能提高数据的读取性能。
Description
技术领域
本发明涉及大数据技术领域,尤其涉及一种Hbase数据库的Rowkey设计方法及装置。
背景技术
在大数据开发和使用中高性能、大数据量的查询是必不可少的,在当前环境下满足高性能、大数据量特点的数据库非Hbase莫属。Hbase是一个被广泛使用的nosql(notonly sql)数据库,因为其存储数据量大、以及分区服务器访问的特点,而被广泛应用于大数据领域。Hbase在读写数据时需要通过RowKey找到对应的Region(区域),但Rowkey太过连续会影响数据的写入,即过于集中在一个分区,写入速度慢;Rowkey太过分散,又会分布在过多分区,使得数据的查询访问分区过多,查询任务过多,查询效率缓慢。
因而,现有技术中,一是通过Hbase Rowkey加盐,属于添加随机前缀,离散的写在Hbase的各个分区中,但只能提高写性能的需求,却降低了读性能的需求。另一种是Hbase以顺序或者倒序的时间字符串或者时间戳作为Rowkey,却仅能满足单独的读或者写,无法同时兼顾。即现有技术仅能满足单一需求,提高写性能必然会降低读性能,提高读性能必然会降低写性能,无法做到读写兼顾。
发明内容
本发明实施例提供一种Hbase数据库的Rowkey设计方法,用以既能提高数据的写入性能,又能提高数据的读取性能,该方法包括:
根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
本发明实施例还提供一种Hbase数据库的Rowkey设计装置,用以既能提高数据的写入性能,又能提高数据的读取性能,该装置包括:
分区数量确定模块,用于根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
前半段设计值确定模块,用于确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
后半段设计值确定模块,用于生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
Rowkey设计值确定模块,用于整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
本发明实施例还提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述Hbase数据库的Rowkey设计方法。
本发明实施例也提供一种计算机可读存储介质,所述计算机可读存储介质存储有执行上述Hbase数据库的Rowkey设计方法的计算机程序。
本发明实施例中,通过根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;确定数据存储的当前时间,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。基于对Rowkey进行分段设计,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段为顺序字符串,让数据整体作为一个连续的整体,可以有效提高Hbase的读取的效率;后半段由离散随机的通用唯一识别码组成,让数据在一定区域内离散存储,有助于提高数据的并行写入效率,进而既能提高数据的写入性能,又能提高数据的读取性能。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例中Hbase数据库的Rowkey设计方法的示意图。
图2为本发明具体实施例中步骤101的实现方法示意图。
图3为本发明具体实施例中步骤102的实现方法示意图。
图4为本发明具体实施例中Hbase数据库的Rowkey设计方法的示意图。
图5为本发明实施例中Hbase数据库的Rowkey设计装置的示意图。
图6为本发明一具体实施例中Hbase数据库的Rowkey设计装置的示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
为了更好地理解本发明实施例,首先对本发明实施例所涉及的专业术语进行解释:
Hbase:HBase是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
Rowkey:HBase是一个nosql(not only sql)数据库,既然是数据库,增删改查(curd)是对其最主要的操作。而在增删改查的过程中RowKey就充当了主键的作用,它和众多的nosql数据库一样,可以唯一的标识一行记录。
RowKey行键可以是任意字符串,在HBase内部,RowKey保存为字节数组。存储时,数据按照RowKey的字典序(byte order)排序存储。设计RowKey时,要充分利用排序存储这个特性,将经常一起读取的行存储放到一起。
本发明实施例提供了一种Hbase数据库的Rowkey设计方法,用以既能提高数据的写入性能,又能提高数据的读取性能,如图1所示,该方法包括:
步骤101:根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
步骤102:确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
步骤103:生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
步骤104:整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
由图1所示流程可以得知,本发明实施例中,通过根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;确定数据存储的当前时间,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。基于对Rowkey进行分段设计,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段为顺序字符串,让数据整体作为一个连续的整体,可以有效提高Hbase的读取的效率;后半段由离散随机的通用唯一识别码组成,让数据在一定区域内离散存储,有助于提高数据的并行写入效率,进而既能提高数据的写入性能,又能提高数据的读取性能。
具体实施时,首先根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量,具体实施时,如图2所示,包括:
步骤201:确定Hbase数据库的区域大小;
步骤202:根据Hbase数据库的区域大小和所需存储的数据量,确定所需存储数据需要占用的分区数量。
Hbase数据库的区域大小是指Hbase数据库的分区的区域大小,即每个分区能够存储多少数据量。将所需存储的数据量除Hbase数据库的区域大小,即可得到需存储数据需要占用的分区数量。例如具体实施例中,根据需存储数据的数据量计算,需要T个分区才能存储所有数据。
确定所需存储数据需要占用的分区数量后,确定数据存储的当前时间,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段。具体实施过程,如图3所示,包括:
步骤301:确定Hbase数据库并行写入的最小分区数;
步骤302:根据分区数量、Hbase数据库并行写入的最小分区数和当前时间,确定所需存储数据对应的Rowkey的前半段。
其中,数据存储的当前时间是指current_Date(当前会话时间),例如为每月、每天、或者每时。该Hbase数据库并行写入的最小分区数是确保Hbase数据库并行写入时数据接收无延迟的分区数的最小值。例如具体实施例中,计算得到需要并行写入P个分区,才能保证数据接收无延迟,高效接收,且也使分区尽可能得集中。
具体实施例中,按照如下公式,根据分区数量、Hbase数据库并行写入的最小分区数和当前时间,确定所需存储数据对应的Rowkey的前半段:
Rowkey的前半段=当前时间%(分区数量/最小分区数)
即上述具体实施例中,Rowkey的前半段=prefix=当前时间%(T/P)。
确定所需存储数据对应的Rowkey的前半段后,生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段。其中,通用唯一识别码是指UUID(Universally Unique Identifier),是一种软件建构的标准,亦为开放软件基金会组织在分布式计算环境领域的一部分。其目的,是让分布式系统中的所有元素,都能有唯一的辨识信息,而不需要通过中央控制端来做辨识信息的指定。如此一来,每个人都可以创建不与其它人冲突的UUID。在这样的情况下,就不需考虑数据库创建时的名称重复问题。目前最广泛应用的UUID,是微软公司的全局唯一标识符(GUID),而其他重要的应用,则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。另外也可以在e2fsprogs包中的UUID库找到实现。
确定所需存储数据对应的Rowkey的后半段后,整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值,即具体实施例中的Rowkey=prefix+UUID。从而使得设计好的Rowkey,能够使得数据读写时,大范围内连续,小范围内离散,既满足了写入的并行度的要求,提高了写入效率;也满足了读取的高效性和数据的相对集中的要求。
得到所需存储数据对应的Rowkey设计值后,按照设计好的Rowkey对数据进行存储,具体实施例中提供的Hbase数据库的Rowkey设计方法,如图4所示,在图1的基础上,还包括:
步骤401:获取Hbase数据库所需存储数据;
步骤402:将所需存储数据作为一条数据记录,将所需存储数据对应的Rowkey设计值,作为该数据记录的Rowkey,将该数据记录存储于Hbase数据库。
下面给出一具体实例说明本发明实施例如何进行Hbase数据库的Rowkey设计。本例给出了一种在大数据应用下Hbase数据库的Rowkey设计方法。
该方法通过从指定固定数量的分区数、固定的Rowkey分区字段长度、固定的Rowkey分区字段,而使其产生一组始终循环且整体顺序、区域分散的Rowkey。
实现原理:
根据数据量与region大小,确认分区数量parNum。
确定将(每月、每天、或者每时)current_Date(当前会话时间)的数据量,离散分布在固定的几个分区Dispersion(分散)。
根据上述确定的Dispersion值,可以确定使用精确到月、天、时、分的时间currentDate对其取模prefix=currentDate%(parNum/Dispersion)。
为了使上述确定的一段时间currentDate内(每月、每天、或者每时)的数据离散的存储在几个分区内,则Rowkey的后半段以uuid补齐。
通过判断将多久的数据量存放在连续的几个区域,生成Rowkey的前半部分顺序字符串。生成离散无规律的Rowkey后半段字符串,确保同一个区域内连续的几个分区的数据均匀接收。将生成的前半部分顺序字符串和生成的后半部分的离散字符串,按前后顺序拼接即生成新的Rowkey。
通过上述对Hbase数据库的Rowkey的分段式设计:按照时间维度,将一段时间内的数据离散均匀存储(提高写入并行度),在整体上数据又保持着整体的连续性(提高了读取性能),使得适应于大数据量数据实时接收并存储于Hbase数据库,又提高了查询效率。
上述具体应用的实施仅为举例,其余实施方式不再一一赘述。
基于同一发明构思,本发明实施例还提供一种Hbase数据库的Rowkey设计装置,由于Hbase数据库的Rowkey设计装置所解决问题的原理与Hbase数据库的Rowkey设计方法相似,因此Hbase数据库的Rowkey设计装置的实施可以参见Hbase数据库的Rowkey设计方法的实施,重复之处不再赘述,具体结构如图5所示:
分区数量确定模块501,用于根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
前半段设计值确定模块502,用于确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
后半段设计值确定模块503,用于生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
Rowkey设计值确定模块504,用于整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
具体实施例中,分区数量确定模块501,具体用于:
确定Hbase数据库的区域大小;
根据Hbase数据库的区域大小和所需存储的数据量,确定所需存储数据需要占用的分区数量。
具体实施时,前半段设计值确定模块502,具体用于:
确定Hbase数据库并行写入的最小分区数;所述Hbase数据库并行写入的最小分区数是确保Hbase数据库并行写入时数据接收无延迟的分区数的最小值;
根据分区数量、Hbase数据库并行写入的最小分区数和当前时间,确定所需存储数据对应的Rowkey的前半段。
一具体实施例中的Hbase数据库的Rowkey设计装置,如图6所示,在图5的基础上,还包括:
数据存储模块601,用于:
获取Hbase数据库所需存储数据;
将所需存储数据作为一条数据记录,将所需存储数据对应的Rowkey设计值,作为数据记录的Rowkey,将数据记录存储于Hbase数据库。
本发明实施例还提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述Hbase数据库的Rowkey设计方法。
本发明实施例也提供一种计算机可读存储介质,所述计算机可读存储介质存储有执行上述Hbase数据库的Rowkey设计方法的计算机程序。
综上所述,本发明实施例提供的Hbase数据库的Rowkey设计方法及装置具有如下优点:
通过根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;确定数据存储的当前时间,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。基于对Rowkey进行分段设计,根据当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段为顺序字符串,让数据整体作为一个连续的整体,可以有效提高Hbase的读取的效率;后半段由离散随机的通用唯一识别码组成,让数据在一定区域内离散存储,有助于提高数据的并行写入效率,进而既能提高数据的写入性能,又能提高数据的读取性能。
虽然本发明提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的装置或客户端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。
本领域技术人员应明白,本说明书的实施例可提供为方法、装置(系统)或计算机程序产品。因此,本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。术语“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明和简化描述,而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本发明的限制。除非另有明确的规定和限定,术语“安装”、“相连”、“连接”应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或一体地连接;可以是机械连接,也可以是电连接;可以是直接相连,也可以通过中间媒介间接相连,可以是两个元件内部的连通。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含义。需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。本发明并不局限于任何单一的方面,也不局限于任何单一的实施例,也不局限于这些方面和/或实施例的任意组合和/或置换。而且,可以单独使用本发明的每个方面和/或实施例或者与一个或更多其他方面和/或其实施例结合使用。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围,其均应涵盖在本发明的权利要求和说明书的范围当中。
Claims (10)
1.一种Hbase数据库的Rowkey设计方法,其特征在于,包括:
根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
2.如权利要求1所述的Hbase数据库的Rowkey设计方法,其特征在于,根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量,包括:
确定Hbase数据库的区域大小;
根据Hbase数据库的区域大小和所需存储的数据量,确定所需存储数据需要占用的分区数量。
3.如权利要求1所述的Hbase数据库的Rowkey设计方法,其特征在于,确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段,包括:
确定Hbase数据库并行写入的最小分区数;所述Hbase数据库并行写入的最小分区数是确保Hbase数据库并行写入时数据接收无延迟的分区数的最小值;
根据所述分区数量、Hbase数据库并行写入的最小分区数和所述当前时间,确定所需存储数据对应的Rowkey的前半段。
4.如权利要求1所述的Hbase数据库的Rowkey设计方法,其特征在于,还包括:
获取Hbase数据库所需存储数据;
将所需存储数据作为一条数据记录,将所需存储数据对应的Rowkey设计值,作为所述数据记录的Rowkey,将所述数据记录存储于Hbase数据库。
5.一种Hbase数据库的Rowkey设计装置,其特征在于,包括:
分区数量确定模块,用于根据Hbase数据库所需存储的数据量,确定所需存储数据需要占用的分区数量;
前半段设计值确定模块,用于确定数据存储的当前时间,根据所述当前时间和分区数量,确定所需存储数据对应的Rowkey的前半段;
后半段设计值确定模块,用于生成离散随机的通用唯一识别码,确定为所需存储数据对应的Rowkey的后半段;
Rowkey设计值确定模块,用于整合所需存储数据对应的Rowkey的前半段和所需存储数据对应的Rowkey的后半段,得到所需存储数据对应的Rowkey设计值。
6.如权利要求5所述的Hbase数据库的Rowkey设计装置,其特征在于,所述分区数量确定模块,具体用于:
确定Hbase数据库的区域大小;
根据Hbase数据库的区域大小和所需存储的数据量,确定所需存储数据需要占用的分区数量。
7.如权利要求5所述的Hbase数据库的Rowkey设计装置,其特征在于,所述前半段设计值确定模块,具体用于:
确定Hbase数据库并行写入的最小分区数;所述Hbase数据库并行写入的最小分区数是确保Hbase数据库并行写入时数据接收无延迟的分区数的最小值;
根据所述分区数量、Hbase数据库并行写入的最小分区数和所述当前时间,确定所需存储数据对应的Rowkey的前半段。
8.如权利要求5所述的Hbase数据库的Rowkey设计装置,其特征在于,还包括:
数据存储模块,用于:
获取Hbase数据库所需存储数据;
将所需存储数据作为一条数据记录,将所需存储数据对应的Rowkey设计值,作为所述数据记录的Rowkey,将所述数据记录存储于Hbase数据库。
9.一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至4任一所述方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有执行权利要求1至4任一所述方法的计算机程序。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110736994.3A CN113407518B (zh) | 2021-06-30 | 2021-06-30 | Hbase数据库的Rowkey设计方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110736994.3A CN113407518B (zh) | 2021-06-30 | 2021-06-30 | Hbase数据库的Rowkey设计方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113407518A true CN113407518A (zh) | 2021-09-17 |
CN113407518B CN113407518B (zh) | 2024-02-23 |
Family
ID=77680517
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110736994.3A Active CN113407518B (zh) | 2021-06-30 | 2021-06-30 | Hbase数据库的Rowkey设计方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113407518B (zh) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105426437A (zh) * | 2015-11-05 | 2016-03-23 | 西安翔迅科技有限责任公司 | 一种基于HBase的智能交通领域卡口数据存储方法 |
CN110019199A (zh) * | 2017-09-29 | 2019-07-16 | 株式会社理光 | 数据存储、查询方法、装置、设备、计算机可读存储介质 |
CN111104457A (zh) * | 2019-10-30 | 2020-05-05 | 武汉大学 | 基于分布式数据库的海量时空数据管理方法 |
CN111125119A (zh) * | 2019-12-30 | 2020-05-08 | 中科星图股份有限公司 | 一种基于HBase的时空数据存储与索引方法 |
US20200210421A1 (en) * | 2018-12-29 | 2020-07-02 | Wuhan University | Method of storing remote sensing big data in hbase database |
CN111767268A (zh) * | 2020-06-23 | 2020-10-13 | 平安普惠企业管理有限公司 | 数据库表分区方法、装置、电子设备及存储介质 |
-
2021
- 2021-06-30 CN CN202110736994.3A patent/CN113407518B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105426437A (zh) * | 2015-11-05 | 2016-03-23 | 西安翔迅科技有限责任公司 | 一种基于HBase的智能交通领域卡口数据存储方法 |
CN110019199A (zh) * | 2017-09-29 | 2019-07-16 | 株式会社理光 | 数据存储、查询方法、装置、设备、计算机可读存储介质 |
US20200210421A1 (en) * | 2018-12-29 | 2020-07-02 | Wuhan University | Method of storing remote sensing big data in hbase database |
CN111104457A (zh) * | 2019-10-30 | 2020-05-05 | 武汉大学 | 基于分布式数据库的海量时空数据管理方法 |
CN111125119A (zh) * | 2019-12-30 | 2020-05-08 | 中科星图股份有限公司 | 一种基于HBase的时空数据存储与索引方法 |
CN111767268A (zh) * | 2020-06-23 | 2020-10-13 | 平安普惠企业管理有限公司 | 数据库表分区方法、装置、电子设备及存储介质 |
Non-Patent Citations (1)
Title |
---|
葛微;罗圣美;周文辉;赵;唐云;周娟;曲文武;袁春风;黄宜华;: "HiBase:一种基于分层式索引的高效HBase查询技术与系统", 计算机学报, no. 01 * |
Also Published As
Publication number | Publication date |
---|---|
CN113407518B (zh) | 2024-02-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10366053B1 (en) | Consistent randomized record-level splitting of machine learning data | |
US11100420B2 (en) | Input processing for machine learning | |
Vora | Hadoop-HBase for large-scale data | |
US9778996B1 (en) | File system version set infrastructure | |
US20150379425A1 (en) | Consistent filtering of machine learning data | |
CN110795499B (zh) | 基于大数据的集群数据同步方法、装置、设备及存储介质 | |
CN105468473A (zh) | 数据迁移方法及数据迁移装置 | |
US10235379B2 (en) | Identification of high deduplication data | |
US11977532B2 (en) | Log record identification using aggregated log indexes | |
US11048678B2 (en) | Bulk-load for B-trees | |
US10909086B2 (en) | File lookup in a distributed file system | |
CN111159235A (zh) | 数据预分区方法、装置、电子设备及可读存储介质 | |
US9767107B1 (en) | Parallel file system with metadata distributed across partitioned key-value store | |
CN113177090A (zh) | 数据处理方法及装置 | |
CN110825764B (zh) | 一种sql脚本的生成方法、系统、存储介质和处理器 | |
US10262000B1 (en) | Global distributed file append using log-structured file system | |
CN111125090B (zh) | 数据存取方法及装置 | |
US10572452B1 (en) | Context-based read-ahead for B+ tree data structures in a deduplication system | |
CN113407518B (zh) | Hbase数据库的Rowkey设计方法及装置 | |
CN114297196B (zh) | 元数据存储方法、装置、电子设备及存储介质 | |
CN112988696B (zh) | 文件整理方法、装置及相关设备 | |
CN112965939A (zh) | 一种文件合并方法、装置和设备 | |
Kaplanis et al. | HB+ tree: use hadoop and HBase even your data isn't that big | |
WO2022173423A1 (en) | System for retrieval of large datasets in cloud environments | |
ANDOR et al. | NoSQL Database Performance Benchmarking-A Case Study |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |