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		2318.616	54G

隻看最大的lineorder表，對tbl檔案的壓縮比可以達到4:1，如果是相對正常的OLTP資料庫，其壓縮比顯然還要更高。

運作SSBM的幾個标準查詢耗時

SQL	耗時(秒)	掃描行數(10萬)	傳回行數
Q1.1	2.123	91.01	1
Q1.2	0.320	7.75
Q1.3	0.053	1.81
Q2.1	17.979	600.04	280
Q2.2	3.625		56
Q2.3	3.263		7
Q3.1	6.906	546.67	150
Q3.2	5.330		600
Q3.3	3.666		24
Q3.4	0.058	7.76	4
Q4.1	10.110		35
Q4.2	1.928	144.42	100
Q4.3	1.373		800

每次掃描這麼多資料量，但這些統計分析為主的SQL查詢耗時卻并不大，足見CH的計算性能了。

今天先簡單介紹到這裡，以後有機會再繼續分享。