ClickHouse性能测试

对ClickHouse做个简单的性能测试。

ClickHouse简介

ClickHouse是战斗民族Yandex公司出品的OLAP开源数据库，简称CH，也有人简称CK，是目前市面上最快的OLAP数据库。性能远超Vertica、Sybase IQ等。

CH具有以下几个特点：

1. 列式存储，因此数据压缩比高。

2. 向量计算，且支持多核CPU并行计算，并且执行每个SQL时都力求榨干CPU性能。

3. 基于Shared nothing架构，支持分布式方案。

4. 支持主从复制架构。

5. 兼容大部分SQL语法，其语法和MySQL尤其相近。

6. 数据实时更新。

7. 不支持事务，不适合高频更新数据。

8. 建议多用宽表，但不建议总是查询整数据行中的所有列。

简言之，如果你有以下业务场景，可以考虑用CH：

1. 海量数据，但又不希望单节点的存储空间消耗太高。

2. 宽表，为了业务方便，可能会把很多相关数据列都整合到一个表里。

3. 基于SQL的查询方式，提高程序的适用性和可移植性。

性能测试

我选用了CH官方提供的一个测试方案：SSBM (Star Schema Benchmark)。
测试机配置：

- 腾讯云CVM主机
- 标准型S5机型
- 4核16G
- 外挂500G SSD云硬盘

数据盘采用xfs文件系统，ioscheduler采用deadline方式：

[[email protected]]# cat /etc/fstab
/dev/vdb /data xfs defaults,noatime,nodiratime,nobarrier 0 0

[[email protected]]# cat /sys/block/vdb/queue/scheduler
[mq-deadline] kyber none

生成测试数据。

# 下载SSBM工具
[[email protected]]# git clone https://github.com/vadimtk/ssb-dbgen.git
[[email protected]]# cd ssb-dbgen
[[email protected]]# make

# 生成测试数据，机器性能和磁盘有限，所以指定 -s 100
[[email protected]]# ./dbgen -s 100 -T c
[[email protected]]# ./dbgen -s 100 -T p
[[email protected]]# ./dbgen -s 100 -T s
[[email protected]]# ./dbgen -s 100 -T l

[[email protected]]# wc -l *tbl
  3000000 customer.tbl
  1400000 part.tbl
   200000 supplier.tbl

[[email protected]]# 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/ ）。

导入数据。

[[email protected]]# clickhouse-client --query "INSERT INTO customer FORMAT CSV" < customer.tbl
[[email protected]]# clickhouse-client --query "INSERT INTO part FORMAT CSV" < part.tbl
[[email protected]]# clickhouse-client --query "INSERT INTO supplier FORMAT CSV" < supplier.tbl
[[email protected]]# 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性能优化的核心要素：合理利用索引，降低锁影响，提高事务并发度。

下面是报名小程序码

点“在看”给我一朵小黄花