OLAP新秀ClickHouse性能测试

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方式：

[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文件大小表空间大小customer3,000,0002.923317M116Mpart1,400,0001.573135M25Msupplier200,0000.30519M7.7Mlineorder600,037,902837.28867G17Glineorder_flat600,037,9022318.616

54G

只看最大的lineorder表，对tbl文件的压缩比可以达到4:1，如果是相对常规的OLTP数据库，其压缩比显然还要更高。

运行SSBM的几个标准查询耗时

SQL耗时(秒)扫描行数(10万)返回行数Q1.12.12391.011Q1.20.3207.751Q1.30.0531.811Q2.117.979600.04280Q2.23.625600.0456Q2.33.263600.047Q3.16.906546.67150Q3.25.330546.67600Q3.33.666546.6724Q3.40.0587.764Q4.110.110600.0435Q4.21.928144.42100Q4.31.373144.42800

每次扫描这么多数据量，但这些统计分析为主的SQL查询耗时却并不大，足见CH的计算性能了。

今天先简单介绍到这里，以后有机会再继续分享。

全文完

由我主讲的知数堂「mysql优化课」第17期已发车，我们的课程从第15期就升级成MySQL 8.0版本了，现在上车刚刚好，一起开启MySQL 8.0的修行之旅吧

另外，我在腾讯课堂《MySQL性能优化》精编课程已完结，本课程讲解读几个MySQL性能优化的核心要素：合理利用索引，降低锁影响，提高事务并发度。