硬件环境:
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字段查询的提升