大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说OLAP新秀ClickHouse性能测试「建议收藏」,希望您对编程的造诣更进一步.
CH具有以下几个特点：
- 列式存储，因此数据压缩比高。
- 向量计算，且支持多核CPU并行计算，并且执行每个SQL时都力求榨干CPU性能。
- 基于Shared nothing架构，支持分布式方案。
- 支持主从复制架构。
- 兼容大部分SQL语法，其语法和MySQL尤其相近。
- 数据实时更新。
- 不支持事务，不适合高频更新数据。
- 建议多用宽表，但不建议总是查询整数据行中的所有列。
简言之，如果你有以下业务场景，可以考虑用CH：
- 海量数据，但又不希望单节点的存储空间消耗太高。
- 宽表，为了业务方便，可能会把很多相关数据列都整合到一个表里。
- 基于SQL的查询方式，提高程序的适用性和可移植性。
性能测试
我选用了CH官方提供的一个测试方案：SSBM (Star Schema Benchmark)。
测试机配置：
- 腾讯云CVM主机
- 标准型S5机型
- 4核16G
- 外挂500G SSD云硬盘
代码100分
数据盘采用xfs文件系统，ioscheduler采用deadline方式：
代码100分[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/ ）。
导入数据。
代码100分[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性能优化的核心要素：合理利用索引，降低锁影响，提高事务并发度。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/8719.html
