对ClickHouse做个简单的性能测试。
ClickHouse简介
ClickHouse是战斗民族Yandex公司出品的OLAP开源数据库，简称CH，也有人简称CK，是目前市面上最快的OLAP数据库。性能远超Vertica、Sybase IQ等。
CH具有以下几个特点：
列式存储，因此数据压缩比高。
向量计算，且支持多核CPU并行计算，并且执行每个SQL时都力求榨干CPU性能。
基于Shared nothing架构，支持分布式方案。
支持主从复制架构。
兼容大部分SQL语法，其语法和MySQL尤其相近。
数据实时更新。
不支持事务，不适合高频更新数据。
建议多用宽表，但不建议总是查询整数据行中的所有列。
简言之，如果你有以下业务场景，可以考虑用CH：
海量数据，但又不希望单节点的存储空间消耗太高。
宽表，为了业务方便，可能会把很多相关数据列都整合到一个表里。
基于SQL的查询方式，提高程序的适用性和可移植性。
性能测试
我选用了CH官方提供的一个测试方案：SSBM (Star Schema Benchmark)。
测试机配置：
- 腾讯云CVM主机- 标准型S5机型- 4核16G- 外挂500G SSD云硬盘
数据盘采用xfs文件系统，ioscheduler采用deadline方式：
[root@yejr.me]# cat /etc/fstab/dev/vdb /data xfs defaults,noatime,nodiratime,nobarrier 0 0[root@yejr.me]# cat /sys/block/vdb/queue/scheduler[mq-deadline] kyber none
生成测试数据。
# 下载SSBM工具[root@yejr.me]# git clone https://github.com/vadimtk/ssb-dbgen.git[root@yejr.me]# cd ssb-dbgen[root@yejr.me]# make# 生成测试数据，机器性能和磁盘有限，所以指定 -s 100[root@yejr.me]# ./dbgen -s 100 -T c[root@yejr.me]# ./dbgen -s 100 -T p[root@yejr.me]# ./dbgen -s 100 -T s[root@yejr.me]# ./dbgen -s 100 -T l[root@yejr.me]# wc -l *tbl 3000000 customer.tbl 1400000 part.tbl 200000 supplier.tbl[root@yejr.me]# ls -l *tbl-rw-r--r-- 1 root root 331529327 Mar 28 21:17 customer.tbl-rw-r--r-- 1 root root 140642413 Mar 28 21:17 part.tbl-rw-r--r-- 1 root root 19462852 Mar 28 21:17 supplier.tbl
创建测试表，根据CH官网提供的建表DDL直接创建即可，参考这里：Star Schema Benchmark（ https://clickhouse.tech/docs/en/getting\_started/example\_datasets/star\_schema/ ）。
导入数据。
[root@yejr.me]# clickhouse-client --query "INSERT INTO customer FORMAT CSV" < customer.tbl[root@yejr.me]# clickhouse-client --query "INSERT INTO part FORMAT CSV" < part.tbl[root@yejr.me]# clickhouse-client --query "INSERT INTO supplier FORMAT CSV" < supplier.tbl[root@yejr.me]# clickhouse-client --query "INSERT INTO lineorder FORMAT CSV" < lineorder.tbl
这是导入测试数据的耗时以及导完后表空间大小的数据。
表
表数据量
耗时（秒）
tbl文件大小
表空间大小
customer
3,000,000
2.923
317M
116M
part
1,400,000
1.573
135M
25M
supplier
200,000
0.305
19M
7.7M
lineorder
600,037,902
837.288
67G
17G
lineorder_flat
600,037,902
2318.616
54G
只看最大的lineorder表，对tbl文件的压缩比可以达到4:1，如果是相对常规的OLTP数据库，其压缩比显然还要更高。
运行SSBM的几个标准查询耗时
SQL
耗时(秒)
扫描行数(10万)
返回行数
Q1.1
2.123
91.01
1
Q1.2
0.320
7.75
1
Q1.3
0.053
1.81
1
Q2.1
17.979
600.04
280
Q2.2
3.625
600.04
56
Q2.3
3.263
600.04
7
Q3.1
6.906
546.67
150
Q3.2
5.330
546.67
600
Q3.3
3.666
546.67
24
Q3.4
0.058
7.76
4
Q4.1
10.110
600.04
35
Q4.2
1.928
144.42
100
Q4.3
1.373
144.42
800
每次扫描这么多数据量，但这些统计分析为主的SQL查询耗时却并不大，足见CH的计算性能了。
今天先简单介绍到这里，以后有机会再继续分享。
由叶老师主讲的知数堂「MySQL优化课」第17期已发车，课程从第15期就升级成MySQL 8.0版本了，现在上车刚刚好，扫码开启MySQL 8.0的修行之旅吧。
另外，叶老师在腾讯课堂的短课程《MySQL性能优化》已开课，本课程讲解读几个MySQL性能优化的核心要素：合理利用索引，降低锁影响，提高事务并发度。
下面是报名小程序码
点“在看”给我一朵小黄花 
本文分享自微信公众号 - 老叶茶馆（iMySQL_WX）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
