clickhouse HA 及性能测试
需求说明
针对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)开启缓存
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库