clickhouse HA 及性能测试

原创

已于 2022-02-17 10:56:56 修改 · 4.9k 阅读

标签

#clickhouse #大数据 #olap #chproxy #性能测试

于 2022-02-17 10:49:40 首次发布

本文档详尽地展示了对ClickHouse集群在生产环境中的性能测试，包括高可用性验证、写入和查询性能测试、租户划分场景、缓存影响分析。测试结果显示，ClickHouse在特定并发下能保持稳定写入，查询性能受数据量和复杂性影响，分区对查询性能提升有限，而开启缓存能显著改善查询效率。测试结论为生产环境提供了有效的部署和优化建议。

逻辑架构图

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”，查询复杂性最难