Clickhouse 性能测试
Clickhouse 性能测试
ClickHouse简介
ClickHouse是战斗民族Yandex公司出品的OLAP开源数据库,简称CH,也有人简称CK,是目前市面上最快的
OLAP数据库。性能远超Vertica、Sybase IQ等。ClickHouse可能更适合流式或批次入库的时序数据。
CH具有以下几个特点:
列式存储,因此数据压缩比高。
向量计算,且支持多核CPU并行计算,并且执行每个SQL时都力求榨干CPU性能。
基于Shared nothing架构,支持分布式方案。
支持主从复制架构。
兼容大部分SQL语法,其语法和MySQL尤其相近。
数据实时更新。
不支持事务,不适合高频更新数据。
建议多用宽表,但不建议总是查询整数据行中的所有列。
简言之,如果你有以下业务场景,可以考虑用CH:
海量数据,但又不希望单节点的存储空间消耗太高。
宽表,为了业务方便,可能会把很多相关数据列都整合到一个表里。
基于SQL的查询方式,提高程序的适用性和可移植性。
性能测试
选用了CH官方提供的一个测试方案:SSBM (Star Schema Benchmark)
测试机配置
SSB模型介绍
SSB(Star Schema Benchmark)是麻省州立大学波士顿校区的研究人员定义的基于现实商业应用的数据模型,业界公认用来模拟决策支持类应用,比较公正和中立。
学术界和工业界普遍采用它来评价决策支持技术方面应用的性能。
全方位评测系统的整体商业计算综合能力,对厂商的要求更高。
在银行信贷分析和信用卡分析、电信运营分析、税收分析、烟草行业决策分析中都有广泛的应用。
SSB基准测试包括:
1个事实表:lineorder
4个维度表:customer,part,dwdate,supplier
13条标准SQL查询测试语句:统计查询、多表关联、sum、复杂条件、group by、order by等组合方式
![image-20200427174606665](/Users/7eng/Library/Application Support/typora-user-images/image-20200427174606665.png)
生成测试数据
创建表
根据CH官网提供的建表DDL直接创建即可,参考这里:
[Star Schema Benchmark]:https://clickhouse.tech/docs/en/gettingstarted/exampledatasets/star_schema/
建表语句:
导入数据
生成大宽表
导入后结果
导完后表空间大小的数据
原文件以及表空间及压缩后大小
| 表 | 总行数 | tbl文件大小 | 原始大小 | 压缩大小 | 压缩率(%) | 最终压缩率 |
| :------------- | :-------- | ----------- | :------- | :------- | :-------- | ---------- |
| supplier | 200000 | 17 M | 11.06 M | 7.52 M | 68.02 | 44.24 |
| part | 1400000 | 116 M | 34.29 M | 24.08 M | 70.22 | 20.76 |
| customer | 3000000 | 277 M | 168.74 M | 114.63 M | 67.94 | 41.38 |
| lineorder | 600037902 | 59 G | 24.03 G | 16.67 G | 69.36 | 28.25 |
| lineorder_flat | 600037902 | | 97.03 G | 53.14 G | 54.77 | |
只看最大的lineorder表,对tbl文件的压缩比可以达到4:1,如果是相对常规的OLTP数据库,其压缩比显然还要更高。
查询测试
###### 查询结果比对
| SQL | 耗时(秒) | 扫描行数(10万) | 返回行数 |
| :--: | :------: | :------------: | :------: |
| Q1.1 | 4.170 | 91.01 | 1 |
| Q1.2 | 0.551 | 7.75 | 1 |
| Q1.3 | 0.143 | 1.80 | 1 |
| Q2.1 | 28.421 | 600.04 | 280 |
| Q2.2 | 1.294 | 600.04 | 56 |
| Q2.3 | 1.118 | 600.04 | 7 |
| Q3.1 | 9.061 | 546.67 | 150 |
| Q3.2 | 7.388 | 546.67 | 600 |
| Q3.3 | 2.092 | 546.67 | 24 |
| Q3.4 | 0.064 | 7.75 | 4 |
| Q4.1 | 14.875 | 600.04 | 35 |
| Q4.2 | 0.873 | 144.42 | 100 |
| Q4.3 | 0.838 | 144.42 | 800 |
每次扫描这么多数据量,但这些统计分析为主的SQL查询耗时却并不大,足见CH的计算性能了。
###### Q1.1:
###### Q1.2:
###### Q1.3:
###### Q2.1:
###### Q2.2:
###### Q2.3:
###### Q3.1:
###### Q3.2:
###### Q3.3:
###### Q3.4:
###### Q4.1:
###### Q4.2:
###### Q4.3:
相关优化
关闭虚拟内存,物理内存和虚拟内存的数据交换,会导致查询变慢。
为每一个账户添加joinusenulls配置,左表中的一条记录在右表中不存在,右表的相应字段会返回该字段相应数据类型的默认值,而不是标准SQL中的Null值。
JOIN操作时一定要把数据量小的表放在右边,ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在,所以右表必须是小表。
批量写入数据时,必须控制每个批次的数据中涉及到的分区的数量,在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多,会导致ClickHouse无法及时对新导入的数据进行合并,从而影响查询性能。
尽量减少JOIN时的左右表的数据量,必要时可以提前对某张表进行聚合操作,减少数据条数。有些时候,先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短。
ClickHouse的分布式表性能性价比不如物理表高,建表分区字段值不宜过多,防止数据导入过程磁盘可能会被打满。
CPU一般在50%左右会出现查询波动,达到70%会出现大范围的查询超时,CPU是最关键的指标,要非常关注。
评论