ClickHouse性能测试

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 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文件大小 表空间大小
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的计算性能了。

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

            </div>
相关文章
|
10月前
|
SQL 分布式计算 测试技术
从 Clickhouse 到阿里云数据库 SelectDB 版内核 Apache Doris:有赞业务场景下性能测试与迁移验证
从 Clickhouse 到阿里云数据库 SelectDB 版内核 Apache Doris 迁移实践:有赞查询提速近 10 倍,OLAP 分析更实时高效!
从 Clickhouse 到阿里云数据库 SelectDB 版内核 Apache Doris:有赞业务场景下性能测试与迁移验证
|
10月前
|
SQL 分布式计算 测试技术
从 Clickhouse 到 Apache Doris:有赞业务场景下性能测试与迁移验证
当前,电商运营的主要痛点不仅来自多变的市场和客户需求,也受困于碎片化用户触达等带来的竞争与挑战。为了深度挖掘用户价值、培养用户忠诚度、实现业绩增长,有赞为商家搭建了全方位 OLAP 分析系统,提供实时与离线分析报表、智能营销与人群圈选等 SaaS 服务。本文将详细介绍有赞从 Clickhouse 至 Apache Doris 的迁移规划和性能对比测试实践,分享如何基于 Apache Doris 统一 OLAP 技术栈,并满足庞大数据体量下的实时分析与极速查询,最终有赞在多个场景下实现查询平均提速 200% 。
273 0
|
存储 SQL 关系型数据库
记一次 ClickHouse 性能测试
本文将对比 MySQL、InfluxDB、ClickHouse 在千万数据量下的写入耗时、聚合查询耗时、磁盘占用等各方面性能指标,并详细记录了测试全过程。
539 0
记一次 ClickHouse 性能测试
|
SQL 存储 并行计算
ClickHouse性能测试
ClickHouse性能测试
|
SQL 分布式计算 Hadoop
来自俄罗斯的ClickHouse列式数据在CentOS7配置和基础性能测试
来自俄罗斯的ClickHouse列式数据在CentOS7配置和基础性能测试 确认当前CPU是否支持安装 [root@master ~]# grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.
2824 0
|
22天前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替&quot;Greater Seattle Area&quot;),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
24 6
|
24天前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
16 2
|
21天前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
19 0
|
23天前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
21 0
|
25天前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
21 0