Phoenix_on_HBase性能测试报告

1、Phoenix on HBase性能测试报告· 目的· 软件版本· 硬件环境· 测试工具· 测试说明o 素材· 场景o 数据写入o K-V(RowKey)查询o 即席查询o 并发查询· 结果与分析o 数据写入o K-V(RowKey)查询o 即席查询o 并发查询· 结论· 测试中发现的“特点”目的测试phoenix引擎在hbase上的数据查询与数据写入的性能，探索phoenix的特性和限制软件版本phoenix-4.8.0-HBase-1.1HBase-1.1.6硬件环境四台配置相同的PC机搭建HBase

2、集群环境，其中一台做HMaster，另外三台做Region部件规格CPUIntel(R) Core(TM) i7-4820K CPU 3.70GHz   1U * 4CoreMEM64G测试工具squirrel-sql-3.5.3apache-jmeter-3.0测试说明使用基于jdbc连接的squirrel-sql-3.5.3进行单用户下的sql性能测试使用基于jdbc连接的apache-jmeter-3.0进行多线程并发测试素材Reinfo表（测点基础信息表）列名类型注释是否主键Data_idbigint测点IDPKDataNamevarchar(300)测点名

3、0;DataTypevarchar(100)测点的数据类型（电压、电流、有功、无功等） byzidvarchar(300)变电站编号 orgidvarchar(300)组织机构编号 应用场景：仅用于存放测点的档案信息，用于查询范围的条件检索过滤时使用测试数据规模：5千CurrData表（当日数据表）列名类型注释是否主键Data_idbigint测点IDPKdate_timeDATE时点（2016-09-19 00:00，2016-09-19 00:01 . 2016-09-19 23:59）PKdatafloat测试值 namevarchar(300)测

4、点名（根据reinfo冗余字段） DataTypevarchar(100)测点的数据类型（电压、电流、有功、无功等）（根据reinfo冗余字段） byzidvarchar(300)变电站编号（根据reinfo冗余字段） orgidvarchar(300)组织机构编号（根据reinfo冗余字段） 应用场景：按测点编号进行查询，每次通常查询1个测点的数据，但有时也会查询几个测点的数据测试数据规模：7百万HisData（历史数据表）列名类型注释是否主键Data_idbigint测点IDPKdate_timeDATE时点（2016-09-19 00:00，201

5、6-09-19 00:01 . 2016-09-19 23:59）PKdatafloat测试值 namevarchar(300)测点名（根据reinfo冗余字段） DataTypevarchar(100)测点的数据类型（电压、电流、有功、无功等）（根据reinfo冗余字段） byzidvarchar(300)变电站编号（根据reinfo冗余字段） orgidvarchar(300)组织机构编号（根据reinfo冗余字段） 应用场景：按测点编号进行查询，每次通常查询1个测点的数据，但有时也会查询几个测点的数据测试数据规模：5千万场景数据写入评估数

6、据写入的性能，分别对数据导入和数据插入两种方式评测。数据导入：将文本文件数据装载至目标表。数据插入：使用dml插入数据至目标表。评估并发写的效率CASE 1：数据导入#命令示例./psql.py hostname-2 -t CURRDATA /home/currdata1.csvCASE 2：数据插入/*语句示例*/upsert into currdata select * from currdata1;/*currdata1与currdata结构一致*/ K-V(RowKey)查询根据表的主键（PK）进行K-V查询，场景主要有：单测点单日，单测点多日，多测点单日，多测点多日CASE

7、 1：单测点单日/*sql示例*/select data_id,date_time,data from hisdata where data_id=104708704221266921 and date_time<=TO_DATE('2016-09-20', 'yyyy-MM-dd') and date_time>=TO_DATE('2016-09-20', 'yyyy-MM-dd') order by date_time;CASE 2：单测点多日/*sql示例*/select data_id,date_time,da

8、ta from hisdata where data_id=104708704221266921 and date_time<=TO_DATE('2016-09-20', 'yyyy-MM-dd') and date_time>=TO_DATE('2016-09-18', 'yyyy-MM-dd') order by data_id,date_time;CASE 3：多测点单日/*sql示例*/select data_id,date_time,data from hisdata where data_id>=10

9、4708704221266921 and data_id <=104708704221266931 and date_time<=TO_DATE('2016-09-17', 'yyyy-MM-dd') and date_time>=TO_DATE('2016-09-17', 'yyyy-MM-dd') order by data_id,date_time;CASE 4：多测点多日/*sql示例*/select data_id,date_time,data from hisdata where data_id>

10、;=104708704221266921 and data_id <=104708704221266930 and date_time<=TO_DATE('2016-09-21', 'yyyy-MM-dd') and date_time>=TO_DATE('2016-09-18', 'yyyy-MM-dd') order by data_id,date_time 即席查询模拟OLAP环境下的ad hoc查询，包括聚集查询，连接查询，明细查询等CASE 1：带过滤条件和排序操作的明细查询/*sql示例*/

11、select data_id,date_time,data from hisdata where byzid='0001303' and orgid='8000041' and date_time<=TO_DATE('2016-09-20', 'yyyy-MM-dd') and date_time>=TO_DATE('2016-09-18', 'yyyy-MM-dd') order by data_id,date_timeCASE 2： 全表聚合查询/*sql示例*/select cou

12、nt(*) from hisdataCASE 3：关联查询/*sql示例*/select count(*) from hisDATA c,REINFO r where c.data_id=r.data_idCASE 4：带过滤条件的聚合查询/*sql示例*/select byzid,orgid,max(data),min(data),avg(data) from hisdata where DATATYPE='无功' and date_time<=TO_DATE('2016-09-20', 'yyyy-MM-dd') and date_ti

13、me>=TO_DATE('2016-09-18', 'yyyy-MM-dd') group by byzid,orgid 并发查询采用k-v查询的sql示例作为并发查询的测试素材 结果与分析数据写入写入时长：记录行720w*1720w*2720w*4数据文件大小350mb*1350mb*2350mb*4并行度（进程数）124CASE 1：数据导入201s247s282sCASE 2：数据插入92s132s158s写入效率：记录行720w*1720w*2720w*4数据文件大小350mb*1350mb*2350mb*4并行度（进程数）12

14、4CASE 1：数据导入1.74mb/s2.83mb/s4.96mb/sCASE 2：数据插入3.8mb/s5.3mb/s8.8mb/s结果分析：HBase是一个写很快的系统，并行度越高，写性能越好，笔者测试发现，使用四个并行任务的情况下，集群cpu资源使用率不超过30%，磁盘繁忙程度大致在70%90%，所以只要条件允许，建议配置高速磁盘，尽可能地通过并行方式写入数据，最大化Hbase的效率K-V(RowKey)查询根据电力客户提供的需求，笔者选用720w的数据量作为测试用例，电力客户拥有5000个测点，每分钟一条记录，保留一天的数据，即：5000*60*24=7200000，5kw即一周的数

15、据查询耗时：数据量720w5kwCASE 1：单测点单日20ms40msCASE 2：单测点多日30ms50msCASE 3：多测点单日30ms40msCASE 4：多测点多日120ms290ms结果分析：基于rowkey的查询效率比较高，这也符合HBase的Key-Value特性，数据量越大，查询效率越好，数据量从720w到5kw增长了6X，但查询耗时仅增加了30%100%。但是，返回的结果集应尽量控制在10w以内，返回的记录行越少，响应时间越快。以”case 4“为例，修改sql示例中的过滤条件使其分别返回1w，10w，100w结果集，测试结果如下：结果集行数查询响应时间1w120ms10

16、w990ms100w9.7s 即席查询即席查询主要针对非K-V方式的查询场景，同样也分为720w和5kw测试查询耗时：数据量720w5kwCASE 1：带过滤条件和排序操作的明细查询1.8s13.3sCASE 2： 全表聚合查询1.7s11.4sCASE 3：关联查询3.3s18.3sCASE 4：带过滤条件的聚合查询2s16.1s结果分析：显然，HBase不适合做BI应用中常见的即席查询，Phoenix进行非K-V类的即席查询时，是将所有的目标数据先填入内存，在内存中计算，这样的话效率主要依赖其CBO（查询优化器）和执行计划。测试用例采用的比较简单的查询sql，而生产环境中的统计查

17、询sql比上述用例复杂的多得多，所以，HBase只适合KV方式访问数据。 并发查询根据HBase的特点，仅针对KV方式的查询进行并发测试，为更好地评估软件的性能，将采用5kw的历史数据表（Hisdata）作为测试素材。以下是单用户、10用户、50用户、100用户、200用户的性能测试结果单用户：单位：msavg中位数 90% Line95% Line99% Lineminmax单测点单日 1379132226238单测点多日 3525374437922430多测点单日 2214294519711261多测点多日 29227729231

18、24982631325多测点多日与另外三个示例相比，响应时长要高一个量级，因此，单测点单日、单测点多日、多测点单日归为短查询的并发测试场景，多测点多日归为长查询的并发测试场景10用户并发：（短查询） avg中位数 90% Line95% Line99% Lineminmaxtps单测点单日 9836147456459144593.144456单测点多日 2501962607468061318583.171985多测点单日 11983126483508335103.24823总体 156115260483759148588.798686

19、10用户并发：（长查询） avg中位数 90% Line95% Line99% Lineminmaxtps多测点多日 23552323273327852869113628711.895303总体 23552323273327852869113628711.895303在10用户并发下，长查询的tps只有1.9不到，而短查询约为8.8。不仅如此，并发情况下，单个查询的响应时间明显增加，例如：单用户下测试单测点单日的查询响应时间均值是13ms，10用户并发下达到了98ms，而多测点多日的查询响应时间则由292ms升至2.4s左右。PS：电力客户要求的响应时间

20、在35s。50用户并发：（短查询） avg中位数 90% Line95% Line99% Lineminmaxtps单测点单日 139722486316391564412.71294单测点多日 7897789711155123838125812.64191多测点单日 2311543807857905379313.00187总体 386174827903118015125835.4216450用户并发：（长查询） avg中位数 90% Line95% Line99% Lineminmaxtps多测点多日 1

21、950180013989711834012515623661266571.86617总体 1950180013989711834012515623661266571.8661750用户并发下长查询的tps仍然只有1.9不到，而响应时间均值却达到19.5s，远远超过客户35s的要求，由此可见，基于测试环境的软硬件配置，长查询的并发数在10个左右比较适宜，最大不应超过20。短查询在50并发下，均值仍在1s以内，tps升至35，说明短查询场景还可以承受更大的并发数。 100用户并发：（短查询） avg中位数 90% Line95% Line99% Linemi

22、nmaxtps单测点单日 141693646016301166920.56767单测点多日 1603157120032098217469220920.08153多测点单日 3703114439829884298920.82119总体 70432816761907212911220956.69684 200用户并发：（短查询） avg中位数 90% Line95% Line99% Lineminmaxtps单测点单日 189762441075111422112430.12956单测点多日 315630993

23、74239674228258426429.18898多测点单日 5194316481149115956116330.91716总体 128844532733603409522426483.22006在200用户并发下，只有单测点多日的均值超过3s，另外两个用例的均值仍在1s以内，tps达到83。理论上讲，假如生产环境中的多日查询的频率远低于单日查询，那么此并发数还可以继续增大，限于时间和篇幅，此处不再做进一步的测试。结果分析：对于短查询，Phoenix+HBase在4个节点环境下可以承受200个并发的压力，平均每秒能响应83个请求。而长查询，并发数控制在10个左右较为合适，每秒最多响应1.9个请求。&#