硬件环境:

HMaster为虚拟机   配置低

三台RangeServer为实体机

所有例子进行测试,同例子执行时间浮动200毫秒上下(秒出的除外)

每行字段数量:11个

测试全部通过HBase Java Api执行得出

 

没有压缩:

card_base:单列族

行数:1.8亿左右(数据情况,随机模拟17年5月1日到5月7日不同时间的数据,车牌随机)

数据大小: 120G

查询方式

1:单rowkey查询     瞬间返回

2:范围查询   

例子1:查询5月1日晚18点05分10秒苏E车牌

结果:293毫秒得到258条数据

 

例子2:查询5月1日晚18点05分到18点10分苏E车牌的数据(这个苏E其实是模糊查询,也可以是苏开头全部车,也可以精确到车牌,也可以是苏E**123这样的方式,下面同理)

结果:2273毫秒得到19818条数据

 

例子3:查询5月1日晚18点05分到18点15分苏E车牌的数据

结果:4028毫秒得到39691条数据                  

PS:例1、2、3比较说明范围扩大对于HBASE来说性能只是线性下降,只是在于扫描的数据量变大,查询本身性能不影响

 

例子4:查询5月1日晚18点到19点的所有数据的前100条

结果:255毫秒得到100条数据          

PS:这个例子充分说明列式存储对于扫描的优势,该测试基本保证用户通过时间、车牌进行实时带分页查询在大多数情况下是秒回

 

card_other:双列族   --   4个主要字段在base列族,其他字段在other列族

行数: 1.8亿左右 (数据情况,随机模拟17年5月1日到5月7日不同时间的数据,车牌随机)

数据大小: 116G   (两个表虽然数据差不多,都是由于随机rowkey可能存在重复性上的差异,所以会造成很微小的数据量不一致,只是猜测)

查询方式

1:单rowkey查询    瞬间返回

2:范围查询

例子1:查询5月1日晚18点05分到18点15分苏E车牌的数据(列族全部查)

结果:5296毫秒得到36961条数据

PS:由于双列族其实分成了2个文件,和单列族中同样时间段同样数据情况下,多了20-30%查询开销是因为同样一行数据,分在2个文件中,增加扫描成本

 

例子2:和上面例子1一样,查询05分到15分的数据,但是这次只查询base列族

结果:3057毫秒得到39691数据

PS:正面如果只是查询某一个列族,那扫描文件数量会降低,并且由于文件大小相对单列族的来说小了,所以性能提高了,并且根据原理,扫描时间范围越大,差距越明显

 

下面规划:

1:当面只有7天1.8亿数据,之后会根据ROWKEY扩展时间范围和数据量,来测试数据和时间的扩张对查询的影响(根据原理,可能数据量增加十倍百倍,对于指定范围内数据无影响)

2:对于表数据压缩后的性能提高情况

3:二级索引对于非rowkey字段查询的提升