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的计算性能了。
今天先简单介绍到这里，以后有机会再继续分享。
