PhoenixonHBase性能测试报告

1、m 软件版本 硬件环境 测试工具 测试说明o素材.场景o数据写入oK-V(RowKey)查询o即席查询o并发查询 结果与分析o数据写入oK-V(RowKey)查询o即席查询o并发查询 结论 测试中发现的特点”目的测试phoenix引擎在hbase上的数据查询与数据写入的性能，探索phoenix的特性和限制软件版本phoenix-4.8.0-HBase-1.1HBase-1.1.6硬件环境四台配置相同的PC机搭建HBase集群环境，其中一台做HMaster,另外三台做Region部件规格CPUIntel(R)Core(TM)i7-4820KCPU3.70GHz1U*4CoreMEM64GPhoe

2、nixonHBase性能测试报告测试工具squirrel-sql-3.5.3apache-jmeter-3.0测试说明使用基于jdbc连接的squirrel-sql-3.5.3进行单用户下的sql性能测试使用基于jdbc连接的apache-jmeter-3.0进行多线程并发测试素材Reinfo表(测点基础信息表)列名类型注释Data_idbigint测点IDDataNamevarchar(300)测点名测点的数据类型DataTypevarchar(100)(电压、电流、有功、无功等)byzidvarchar(300)变电站编号orgidvarchar(300)组织机构编号是否主键PK应用场景：

3、仅用于存放测点的档案信息，用于查询范围的条件检索过滤时使用测试数据规模：5千CurrData表(当日数据表)列名类型注释Data_idbigint测点ID时点是否主键PKdate_timeDATEdatafloatnamevarchar(300)(2016-09-1900:00,2016-09-1900:01.2016-09-1923:59)测试值测点名(根据reinfo冗余字段)测点的数据类型PKDataTypevarchar(100)(电压、电流、有功、无功等)(根据reinfo冗余字段)byzidvarchar(300)变电站编号(根据reinfo冗余字段)orgidvarchar（30

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

5、reinfo冗余字段）应用场景：按测点编号进行查询，每次通常查询1个测点的数据，但有时也会查询几个测点的数据测试数据规模：5千万场景数据写入评估数据写入的性能，分别对数据导入和数据插入两种方式评测数据导入：将文本文件数据装载至目标表。数据插入：使用dml插入数据至目标表。评估并发写的效率#令示例是否主键PKPKdate_timeDATEdatafloatnamevarchar(300)./psql.pyhostname-2-tCURRDATA/home/currdatal.csvCASE2:数据插入/*语句示例*/upsertintocurrdataselect*fromcurrdatal;/

6、*currdata1 与 currdata 结构一致*/K-V(RowKey)查询根据表的主键(PK)进行K-V查询， 场景主要有： 单测点单日， 单测点多日,多测点单日，多测点多日CASE 1 :单测点单日/*sql 示例*/selectdata_id,date_time,datafromhisdatawheredata_id=104708704221266921anddate_time=TO_DATE(2016-09-20,yyyy-MM-dd)orderbydate_time;CASE 2 :单测点多日/*sql 示例*/selectdata_id,date_time,datafromh

7、isdatawheredata_id=104708704221266921anddate_time=TO_DATE(2016-09-18,yyyy-MM-dd)orderbydata_id,date_time;CASE3:多测点单日/*sql 示例*/selectdata_id,date_time,datafromhisdatawheredata_id=104708704221266921anddata_id=104708704221266931anddate_time=TO_DATE(2016-09-17,yyyy-MM-dd)orderbydata_id,date_time;CASE4:多

8、测点多日/*sql 示例*/selectdata_id,date_time,datafromhisdatawheredata_id=104708704221266921anddata_id=104708704221266930anddate_time=TO_DATE(2016-09-18,yyyy-MM-dd)orderbydata_id,date_time即席查询模拟OLAP环境下的adhoc查询，包括聚集查询，连接查询，明细查询等/*sql 示例*/selectdata_id,date_time,datafromhisdatawherebyzid=0001303andorgid=80000

9、41anddate_time=TO_DATE(2016-09-18,yyyy-MM-dd)orderbydata_id,date_timeCASE 2 :全表聚合查询/*sql 示例*/selectcount(*)fromhisdataCASE 3 :关联查询/*sql 示例*/selectcount(*)fromhisDATAc,REINFOrwherec.data_id=r.data_idCASE 4 :带过滤条件的聚合查询/*sql 示例*/selectbyzid,orgid,max(data),min(data),avg(data)fromhisdatawhereDATATYPE=无功

10、anddate_time=TO_DATE(2016-09-18,yyyy-MM-dd)groupbybyzid,orgid并发查询采用k-v查询的sql示例作为并发查询的测试素材结果与分析数据写入写入时长：记录行720w*1720w*2 720w*4数据文件大小350mb*1 350mb*2350mb*4并行度（进程数）124CASE1:数据导入201s247s282sCASE2:数据插入92s132s158s写入效率：记录行720w*1720w*2720w*4数据文件大小350mb*1 350mb*2350mb*4并行度（进程数）124CASE1:数据导入1.74mb/s2.83mb/s4.

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

12、s40msCASE2:单测点多日30ms50msCASE3:多测点单日30ms40msCASE4:多测点多日120ms290ms结果分析：基于rowkey的查询效率比较高，这也符合HBase的Key-Value特性，数据量越大，查询效率越好，数据量从720w到5kw增长了6X,但查询耗时仅增加了30%100%。但是， 返回的结果集应尽量控制在10w以内， 返回的记录行越少， 响应时间越快。 以case4为例，修改sql示例中的过滤条件使其分别返回1w,10w,100w结果集，测试结果如下：结果集行数查询响应时间1w120ms10w990ms100w9.7s即席查询即席查询主要针对非K-V方式的

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

14、ase的特点，仅针对KV方式的查询进行并发测试，为更好地评估软件的性能，将采用5kw的历史数据表（Hisdata）作为测试素材。以下是单用户、10用户、50用户、100用户、200用户的性能测试结果单用户：单位：msavg中位数90%Line95%Line99%Lineminmax单测点单日1379132226238单测点多日3525374437922430多测点单日2214294519711261多测点多日2922772923124982631325多测点多日与另外三个示例相比，响应时长要高一个量级，因此，单测点单日、单测点多日、多测点单日归为短查询的并发测试场景，多测点多日归为长查询的并发

15、测试场景10用户并发：（短查询）avg中位数90%Line95%Line99%Lineminmaxtps单测点单日9836147456459144593.144456单测点多日2501962607468061318583.171985多测点单日11983126483508335103.24823总体156115260483759148588.79868610用户并发：（长查询）avg中位数90%Line95%Line99%Lineminmaxtps多测点多日23552323273327852869113628711.895303总体23552323273327852869113628711.8

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

17、00187总体386174827903118015125835.4216450用户并发：（长查询）avg中位数90%Line95%Line99%Lineminmaxtps多测点多日1950180013989711834012515623661266571.86617I总体1950180013989711834012515623661266571.86617|50用户并发下长查询的tps仍然只有1.9不到， 而响应时间均值却达到19.5s,远远超过客户35s的要求，由此可见，基于测试环境的软硬件配置，长查询的并发数在10个左右比较适宜，最大不应超过20。短查询在50并发下，均值仍在1s以内，tp

18、s升至35,说明短查询场景还可以承受更大的并发数。100用户并发：（短查询）avg中位数90%Line95%Line99%Lineminmaxtps单测点单日141693646016301166920.56767单测点多日1603157120032098217469220920.08153多测点单日3703114439829884298920.82119总体70432816761907212911220956.69684200用户并发：（短查询）avg中位数90%Line95%Line99%Lineminmaxtps单测点单日189762441075111422112430.12956单测点多

19、日31563099374239674228258426429.18898多测点单日5194316481149115956116330.91716总体128844532733603409522426483.22006在200用户并发下，只有单测点多日的均值超过3s,另外两个用例的均值仍在1s以内，tps达到83。理论上讲，假如生产环境中的多日查询的频率远低于单日查询，那么此并发数还可以继续增大，限于时间和篇幅，此处不再做进一步的测试。结果分析：对于短查询，Phoenix+HBase在4个节点环境下可以承受200个并发的压力,平均每秒能响应83个请求。而长查询，并发数控制在10个左右较为合适，每秒最多响应1.9个请求。结论1. HBase是一个写很快的系统，并行写/分布式写能充分发挥集群的计算资源；2. HBase的Key-Value特性决定了基于rowkey或主键查询的效率