开发者社区> xaubllxwtvaqiu> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

[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 Benchmarkhttps://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.923317M116M
part1,400,0001.573135M25M
supplier200,0000.30519M7.7M
lineorder600,037,902837.28867G17G
lineorder_flat600,037,9022318.616
54G

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

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

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

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

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

            </div>

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
ClickHouse性能测试
ClickHouse性能测试
16 0
ClickHouse性能测试
ClickHouse性能测试
11 0
ClickHouse性能测试
ClickHouse性能测试
19 0
ClickHouse性能测试
ClickHouse性能测试
27 0
ClickHouse性能测试
ClickHouse性能测试
39 0
ClickHouse性能测试
ClickHouse性能测试
23 0
ClickHouse性能测试
ClickHouse性能测试
50 0
ClickHouse性能测试
ClickHouse性能测试
32 0
ClickHouse性能测试
ClickHouse性能测试
66 0
ClickHouse性能测试
ClickHouse性能测试
469 0
7759
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载