clickhouse HA 及性能测试

目录

需求说明

逻辑架构图

物体架构图

测试性能

测试指标说明：

sql语句准备

环境准备

测试结论报告

（1） HA测试，停止某台服务，对外服务是否正常访问

（2）spark 以(5/10/20/40)个并发模拟写数据时，读性能(读50/100/150并发）测试

2.1 写并发测试

2.2 qps并发性能测试

（3）租户划分使用场景

（4）缓存

结论

需求说明

---

    针对clickhouse作为生产环境的底层数据存储，为了能保证生产环境服务稳定可用，做如下性能测试：

（1）chproxy + clickhouse 能否实现集群高可用

（2）clickhouse 写性能

（3）clickhouse查询性能

（4）clickhouse开启字段分区能否提高查询性能

（5）chproxy开启缓存对性能影响

    本文档将针对上述方案做验证以及测试输出结果。

逻辑架构图

ch5、ch6等机器构成一个clickhouse集群，用户读写请求直接作用在chproxy，chproxy提供透明的控制访问配置以及读写指标的监控，可实现用户无感知的故障访问切换。对于读服务，chproxy利用distrubute分布式表优秀的sql解析功能实现数据的查询服务；对于写请求，尽量降低写带来的集群IO负载，chproxy穿透distrubute表直接作用在具体表节点上，减少集群表节点数据转发带来的IO。若后期业务的扩展需求，可直接横向扩展机器节点即可。

物体架构图

测试性能

测试指标说明：

本次分别在写线程5/10/20/40/80 每秒写场景下，模拟不同并发读性能，其中读压力测试以10s内，启用500/1000/1500个查询，测试并发场景在不同级别下表sql的性能，用于生产环境clickhouse机器部署参考，测试性能如下所示,在查询过程中将主要捕获如下指标:

  (1)  throughput:用来衡量吞吐量的指标，通常由TPS和QPS来表示

（2）插入的rows/s：反映集群的写入性能

（3）插入的bytes/s：反映集群的写入性能

sql语句准备

  综合上述的情况准备了如下sql：

  Q1: select * from db.table where tenant_id = ${tenant_id} and project_id =${project_id}  limit 20; //该语句组合了“不使用聚合”+“多条件查询”，查询复杂性最小，基本只存在集群带宽瓶颈

  Q2:select count(*) from db.table where  tenant_id = ${tenant_id} and project_id =${project_id}  //该语句组合了“使用聚合”+“多条件查询”，查询复杂性一般

  Q3:select tenant_id,count(*) as c,max(project_id) as m,count(distinct(project_id)) from db.table where  tenant_id = ${tenant_id} group by tenant_id //该语句组合了“多聚合”+“条件查询” ，查询复杂性较难

  Q4:select count(*) from db.table where  tenant_id =${tenant_id} and tenant_id in (select distinct(tenant_id) from db.table2) group by project_id //该语句组合了“聚合”+“过滤”+“跨表join”，查询复杂性最难

环境准备

本次使用3台测试环境物体机16core，64 GIB，该机器上同时搭载有kudu集群，hdfs集群，yarn等服务，当在生产环境部署时，性能会比本次测试优越。在上述的两台机器上按上述物体架构部署3个节点，其中：

192.168.104.93 clickhouse节点，用于接收数据写入及查询

192.168.104.94 clickhouse节点，用于接收数据写入及查询

192.168.104.95 chproxy节点,用于查询服务代理转发

其中192.168.104.93与192.168.104.94互为副本。

测试结论报告

（1） HA测试，停止某台服务，对外服务是否正常访问

  

如左图所示，启动500个线程运行100秒，在100秒过程中，手动kill 192.168.104.94节点上clickhouse服务，在查询结果树种，由于节点下线，该时刻的查询失败，但服务依旧正常执行sql，因此HA验证结果成功。

（2）spark 以(5/10/20/40)个并发模拟写数据时，读性能(读50/100/150并发）测试

2.1 写并发测试

     在测试环境中启动4个并发，写batch为10W时，clickhouse表现性能如下，其中数据写入峰值为80W/s，180MiB/s，平均写入性能为40W/s,90M/s

  

 启动8个并发， 写batch为20W时，clickhouse表现性能表现不稳定，峰值写入103W/s,230M/s，偶尔存在超时失败情况。

 启动20个并发，写batch为20W时，clickhouse表现性能表现写入一段时间后超时失败。

启动40个并发，写batch为20W时，clickhouse表现性能表现写入一段时间后超时失败。

在大批量写入情况下，持续写入并发为2~6,单台机器1~3左右最稳定，写入性能最高（But if you follow the recommendations to insert data in batches of no more than one INSERT per second, it does not create any problems）测试符合预期。同时从图中可以发现数据写入对cpu性能影响很小。

2.2 qps并发性能测试

    在上述4个并发，20W/s写入条件下，对不同量级别的表做并发测试，其中分别在500/1000/1500线程（大于1500情形目前不考虑）在10s内完成向chproxy发送请求不开启缓存的情况下，获取QPS性能结果如下：

table描述\sql类型	Q1	Q2	Q3	Q4	备注
（20W条，1.5M，147个租户）表	150	150	150	150	关联3k表join查询
（80W条，5.3M，147个租户）表	150	150	150	150	关联3k表join查询
（200W条，16M，91个租户）表	150	150	150	150	关联3k表join查询
（800W条，211M，1278个租户）表	150	150	150	150	关联3k表join查询
（2000W条，500M，1278个租户）表	150	150	150	76	关联8000k表join查询
（12000W条，2100M，45个租户）表	150	150	52	150	关联3k表join查询
（80000W条，16000M，45个租户）表	150	150	9.3	4.1	关联1亿表join查询
（20W条，1.5M，147个租户）分区表	150	150	150	150	关联3k表join查询
（80W条，5.3M，147个租户）分区表	150	150	150	150	关联3k表join查询
（200W条，16M，91个租户）分区表	150	150	150	150	关联3k表join查询
（800W条，211M，1278个租户）分区表	150	150	150	150	关联3k表join查询
（2000W条，500M，1278个租户）分区表	150	150	150	77	关联8000k表join查询
（12000W条，2100M，45个租户）分区表	150	150	51	150	关联3k表join查询
（80000W条，16000M，45个租户）分区表	150	150	11	5	关联1亿表join查询

考虑上述的sql查询都在租户下查询实现的，因此单位租户下数据量的多少在一定程度上影响了clickhouse 查询，如20000W表，租户为1278时，进过租户条件过滤后数量量很小，基本没性能影响。尽管在复杂sql查询下存在数据量大的表可能存在查询问题，但这类sql查询不到0.1%的场景，且不存在连续查询情况，因此在真实生产环境下存在并发性能问题的可能性很小.

（3）租户划分使用场景

 

                                   不划分租户                       VS           划分租户

     如上图所示，不同量级的表在划分租户与否的情况下QPS性能几乎一致，分区并不能加速查询，常用于表分区drop等操作使用（partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc）

（4）缓存

    如上图sql分析所示，在真实生产环境中80%的sql查询都查询了重复的sql，重复的数据，如下图在15000并发查询在100内开启缓存时，Q3在（12000W条，2100M，45个租户）分区表上的QPS与不开启缓存Q3在（12000W条，2100M，45个租户）分区表表现对比：

尽管测试sql包含了大量重复的sql查询，可能无法cover生产环境，但缓存的使用拦截了大量查询请求，提高了查询性能。

   

结论

本测试报告结合真实生产环境中sql的类型、大小表使用频率、sql重复查询使用情况做了分析，并以此模拟真实生产环境，围绕clickhouse性能在3台测试环境下展开，并给出了如下性能报告总结：

（1）写并发测试：在持续大批量写入时，单台机器并发建议在1~3左右最稳定，数据写入峰值为80W/s，180MiB/s，平均写入性能为40W/s,90M/s

（2） 在复杂sql查询下存在数据量大的表可能存在查询问题，但正如上述sql分析的那样，这类sql查询不到1%的场景，且不存在连续高并发查询情况，因此在真实生产环境下存在性能问题的可能性为0.

（3）分区并不能加速查询，不需要为特定字段分区

（4）开启缓存