一种基于HBase高表的主键设计方法技术领域
本发明属于数据库存储技术领域，特别涉及一种基于HBase高表的主键
设计方法。
背景技术
随着信息技术的飞速发展，信息系统需要处理的数据量越来越大，如何
有效的存储和检索海量的数据已经成为制约信息系统发展的重要瓶颈。传统
的关系型数据库经过四十多年的发展，在各个领域都取得了骄人的业绩，伴
随关系型数据库也衍生出了以数据为中心的指导数据库设计的设计范式。
然而，随着数据量的急剧增长，关系型数据库已经越来越不能适应业务
数据的需要，为了应对海量的数据，多种NoSQL数据库被设计用来解决相应
领域的问题，其中HBase为一种开源的列式存储NoSQL数据库，由于NoSQL
数据库的实现和关系型数据库有极大的不同，被设计用来指导关系型数据库
设计的设计范式不能用来指导NoSQL数据库的设计。
通常使用反范式来指导NoSQL数据库的设计，但由于NoSQL数据库通常
为了解决特定的目的而设计，因此用来指导某一数据库设计的反范式方法不
能够用来指导NoSQL数据库的设计，不具有很强的通用性，因此亟需提出一
种具备很强通用性的设计方法用于指导数据库的设计。
发明内容
本发明为了克服上述现有技术的不足，提供了一种基于HBase高表的主
键设计方法，本方法在指导数据库设计时具备很强的通用性。
为实现上述目的，本发明采用了以下技术措施：
一种基于HBase高表的主键设计方法，包括以下步骤：
S1、首先分析应用模式，确定所述应用模式中数据的存储、检索需求，
并确定所述应用模式的数据是否适用于HBase高表；
S2、若数据适用于HBase高表，分析数据的结构，明确主键的组成和排
列顺序，再进行步骤S3操作；若数据不适用于HBase高表，则终止以下操
作；
S3、对主键进行去重处理；
S4、对已经去重处理过的数据，设置数据检索接口；
S5、在应用中使用已经去重处理过的数据。
优选的，步骤S1具体包括以下步骤：
S11、以应用为中心，分析应用模式中数据的事务需求；当数据间有事
务需求时，不适用于HBase高表；当数据间无事务需求时，则数据适用于
HBase高表；
S12、以应用为中心，分析应用模式中数据的存储场景；当数据的并发
写入大于每秒钟一万条记录时或数据不更新时，则数据适用于HBase高表；
S13、以应用为中心，分析应用模式中数据的组成结构；当数据的检索
条件组合可以构成主键时，则数据适用于HBase高表。
优选的，所述检索条件组合为在日常中使用到的几率大于80％的检索条
件。
优选的，所述去重处理包括在主键的末尾添加一个具备唯一性的UUID
或在主键的末尾添加一个从HBase increament API中获取的序号。
进一步的，所述数据检索接口为HBase Scan。
进一步的，所述去重处理的操作在客户端或HBase的协处理器来实现。
本发明的有益效果在于：
1)、本发明以应用为中心，分析应用模式中数据的事务特性、存储场
景、组成结构，并确定所述应用模式的数据是否适用于HBase高表；若数据
适用于HBase高表，分析数据的结构，明确主键的组成和排列顺序，并对主
键进行去重处理，对已经去重处理过的数据，设置对应的数据检索接口，并
在应用中使用该数据。因此本方法提供了一种在使用列式存储数据库HBase
存储海量数据时，其数据主键的设计方法，该方法在设计指导非关系型数据
库设计时具备很强的通用性。
2)、所述去重处理包括在主键的末尾添加一个具备唯一性的UUID或在
主键的末尾添加一个从HBase increament API中获取的序号，该方法稳定
可靠，便利简单，并且确保了数据之间不会重复，保证了数据的唯一性。
附图说明
图1为本发明的流程图；
图2为本发明中确定应用模式的数据适用HBase高表的流程图；
图3为本发明主键的构造图；
图4为本发明的车辆通行数据主键的构造图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行
清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而
不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做
出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，一种基于HBase高表的主键设计方法，包括以下步骤：
S1、分析应用模式，确定所述应用模式的数据的存储、检索需求，确定
所述应用模式的数据是否适用于HBase高表；
S2、若数据适用于HBase高表，分析数据的组成结构，明确主键的组成
和排列顺序；若数据不适用于HBase高表，则终止以下操作；
S3、对主键进行去重处理；
S4、对已经去重处理过的数据，设置对应的数据检索接口；
S5、在应用中使用所述数据。
为了更清楚的说明上述步骤S1中的具体实施流程，下面对S1进行具体
说明，图2示出了步骤S1的具体流程，如下：
S11、以应用为中心，分析应用模式中数据的事务需求；当数据间有事
务需求时，不适用于HBase高表；当数据间无事务需求时，则数据适用于
HBase高表；
所述事务需求是指在更新多条数据时，要么都成功，要么都失败的一种
行为。
S12、以应用为中心，分析应用模式中数据的存储场景；当数据的并发
写入大于每秒钟一万条记录时或数据不更新时，则数据适用于HBase高表；
S13、以应用为中心，分析应用模式中数据的组成结构；当数据的检索
条件组合可以构成主键时，则数据适用于HBase高表。
表1：
名词
解释
NoSQL
非传统关系型数据库的其他各种数据库的总称
HBase
一种开源的列式存储NoSQL数据库
范式
在关系型数据库设计时需要遵循的基本原则
反范式
背离范式的原则，但在某一种场合下工作很好的设计方法
车辆通行数据一般由交通卡口、电子警察前端设备、虚拟卡口系统生成，
以车辆通过交通卡口为例，每一辆车通过某一个交通卡口时，就会生成一条
车辆通行数据，但由于车辆通行数据越来越多，传统的关系型数据库已经无
法胜任如此庞大的数据量。
如图1～4所示，以一种基于HBase高表的主键设计方法为指导，设计
车辆通行数据存储方案的过程，包括：
S1、以应用为中心，分析应用中数据的事务特性
根据车辆通行数据的业务特性，数据生成后，通常不会进行修改，主要
以检索查看、挖掘分析为主，且各条车辆通行数据之间，并没有事务的关系，
因此符合HBase高表进行存储的条件。
S2、以应用为中心，分析应用中数据的存储场景
根据车辆通行数据的业务特性，数据主要应用于对相关敏感车辆的通行
记录进行检索查询，因此这是一种写多读少的业务场景，系统需要承担大量
的并发数据写入，只有较少的数据读取，需要尽量将主键平均的分配在总主
键范围的各个区间上，从而提高写入性能。
S3、以应用为中心，分析数据的组成结构
每一条车辆通行记录都有通行时间When、卡口Where、号码号牌Who的
三个属性，从理论上来说，这三个属性可以唯一确定一条车辆通行记录。
车辆通行数据，通常是以车辆为目标进行检索查询，查询的结果通常需
要按照时间进行排序，根据主键设计原则，需要将主键按照如下顺序进行排
列，号码号牌+通行时间+卡口，在应用中，可以快速的检索出指定号码号牌
的车辆通行记录集。
S4、对主键进行去重处理
由于套牌、前端设备识别错误、时钟不同步等原因，通常会有极少的数
据出现组合主键一致的情况，若主键一致，必须进行去重处理，去重并不是
将重复的数据丢弃不用，而是将主键进行扩展，在尾部追加一个不会重复的
数据，从而使原本主键重复的数据可以同时存储在数据库中。
所述去重处理包括在主键的末尾添加一个具备唯一性的UUID或在主键
的末尾添加一个从HBase increament API中获取的序号。
主键的去重处理，可以在客户端实现，也可以通过HBase的协处理器
来实现。
S5、针对进行去重处理过的数据，设计专门的数据检索接口
由于HBase Get操作需要明确给出数据的主键值，由于UUID是一个随
机生成的唯一值，车辆通行记录的业务主键为号码号牌+通行时间+卡口，因
此，当给定业务主键时，数据检索接口为HBase Scan。
同时，为了应对少数情况下的数据更新业务，需要将数据先通过HBase
Scan API获取其存储主键即号码号牌+通行时间+卡口+UUID，再进行数据更
新。
S6、在应用中使用该数据
在一种基于HBase高表的主键设计方法的基础上，可以设计相应的业务
接口，包括：
1、存储给定的车辆通行数据；
2、检索给定业务主键的车辆通行数据；
3、更新给定业务主键的车辆通行数据；
4、给定号码号牌，返回最新的n条数据。
因此本发明在可以用来指导NoSQL数据库的设计，而且本发明具备很强
的通用性。