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