6亿数据秒级查询,ClickHouse太快了!

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: clickhouse 在数据分析技术领域早已声名远扬,如果还不知道可以 点这里 了解下。最近由于项目需求使用到了 clickhouse 做分析数

clickhouse 在数据分析技术领域早已声名远扬,如果还不知道可以 点这里 了解下。

最近由于项目需求使用到了 clickhouse 做分析数据库,于是用测试环境做了一个单表 6 亿数据量的性能测试,记录一下测试结果,有做超大数据量分析技术选型需求的朋友可以参考下。

服务器信息

  • CPU:Intel Xeon Gold 6240 @ 8x 2.594GHz
  • 内存:32G
  • 系统:CentOS 7.6
  • Linux内核版本:3.10.0
  • 磁盘类型:机械硬盘
  • 文件系统:ext4

Clickhouse信息

  • 部署方式:单机部署
  • 版本:20.8.11.17

测试情况

测试数据和测试方法来自 clickshouse 官方的 Star Schema Benchmark

按照官方指导造出了测试数据之后,先看一下数据量和空间占用情况。

数据量和空间占用

表名 列数 数据行数 原始大小 压缩大小 压缩率
supplier 6 200,000 11.07 MiB 7.53 MiB 68
customer 7 3,000,000 168.83 MiB 114.72 MiB 68
part 8 1,400,000 34.29 MiB 24.08 MiB 70
lineorder 16 600,037,902 24.03 GiB 16.67 GiB 69
lineorder_flat 37 688,552,212 111.38 GiB 61.05 GiB 55

可以看到 clickhouse 的压缩率很高,压缩率都在 50 以上,基本可以达到 70 左右。数据体积的减小可以非常有效的减少磁盘空间占用、提高 I/O 性能,这对整体查询性能的提升非常有效。

supplier、customer、part、lineorder 为一个简单的「供应商-客户-订单-地区」的星型模型,lineorder_flat 为根据这个星型模型数据关系合并的大宽表,所有分析都直接在这张大宽表中执行,减少不必要的表关联,符合我们实际工作中的分析建表逻辑。

以下性能测试的所有分析 SQL 都在这张大宽表中运行,未进行表关联查询。

查询性能测试详情

Query 1.1

SELECT sum(LO_EXTENDEDPRICE * LO_DISCOUNT) AS revenue
FROM lineorder_flat
WHERE (toYear(LO_ORDERDATE) = 1993) AND ((LO_DISCOUNT >= 1) AND (LO_DISCOUNT <= 3)) AND (LO_QUANTITY < 25)
    ┌────────revenue─┐
│ 44652567249651 │
└────────────────┘
1 rows in set. Elapsed: 0.242 sec. Processed 91.01 million rows, 728.06 MB (375.91 million rows/s., 3.01 GB/s.)

扫描行数:91,010,000大约9100万

耗时(秒):0.242

查询列数:2

结果行数:1

Query 1.2

SELECT sum(LO_EXTENDEDPRICE * LO_DISCOUNT) AS revenue
FROM lineorder_flat
WHERE (toYYYYMM(LO_ORDERDATE) = 199401) AND ((LO_DISCOUNT >= 4) AND (LO_DISCOUNT <= 6)) AND ((LO_QUANTITY >= 26) AND (LO_QUANTITY <= 35))
    ┌───────revenue─┐
│ 9624332170119 │
└───────────────┘
1 rows in set. Elapsed: 0.040 sec. Processed 7.75 million rows, 61.96 MB (191.44 million rows/s., 1.53 GB/s.)

扫描行数:7,750,000775万

耗时(秒):0.040

查询列数:2

返回行数:1

Query 2.1

SELECT
    sum(LO_REVENUE),
    toYear(LO_ORDERDATE) AS year,
    P_BRAND
FROM lineorder_flat
WHERE (P_CATEGORY = 'MFGR#12') AND (S_REGION = 'AMERICA')
GROUP BY
    year,
    P_BRAND
ORDER BY
    year ASC,
    P_BRAND ASC
    ┌─sum(LO_REVENUE)─┬─year─┬─P_BRAND───┐
    │     64420005618 │ 1992 │ MFGR#121  │
    │     63389346096 │ 1992 │ MFGR#1210 │
    │     ........... │ .... │ ..........│
    │     39679892915 │ 1998 │ MFGR#128  │
    │     35300513083 │ 1998 │ MFGR#129  │
    └─────────────────┴──────┴───────────┘
    280 rows in set. Elapsed: 8.558 sec. Processed 600.04 million rows, 6.20 GB (70.11 million rows/s., 725.04 MB/s.)

扫描行数:600,040,000大约6亿

耗时(秒):8.558

查询列数:3

结果行数:280

Query 2.2

SELECT
    sum(LO_REVENUE),
    toYear(LO_ORDERDATE) AS year,
    P_BRAND
FROM lineorder_flat
WHERE ((P_BRAND >= 'MFGR#2221') AND (P_BRAND <= 'MFGR#2228')) AND (S_REGION = 'ASIA')
GROUP BY
    year,
    P_BRAND
ORDER BY
    year ASC,
    P_BRAND ASC
    ┌─sum(LO_REVENUE)─┬─year─┬─P_BRAND───┐
    │     66450349438 │ 1992 │ MFGR#2221 │
    │     65423264312 │ 1992 │ MFGR#2222 │
    │     ........... │ .... │ ......... │
    │     39907545239 │ 1998 │ MFGR#2227 │
    │     40654201840 │ 1998 │ MFGR#2228 │
    └─────────────────┴──────┴───────────┘
    56 rows in set. Elapsed: 1.242 sec. Processed 600.04 million rows, 5.60 GB (482.97 million rows/s., 4.51 GB/s.)

扫描行数:600,040,000大约6亿

耗时(秒):1.242

查询列数:3

结果行数:56

Query 3.1

SELECT
    C_NATION,
    S_NATION,
    toYear(LO_ORDERDATE) AS year,
    sum(LO_REVENUE) AS revenue
FROM lineorder_flat
WHERE (C_REGION = 'ASIA') AND (S_REGION = 'ASIA') AND (year >= 1992) AND (year <= 1997)
GROUP BY
    C_NATION,
    S_NATION,
    year
ORDER BY
    year ASC,
    revenue DESC
    ┌─C_NATION──┬─S_NATION──┬─year─┬──────revenue─┐
    │ INDIA     │ INDIA     │ 1992 │ 537778456208 │
    │ INDONESIA │ INDIA     │ 1992 │ 536684093041 │
    │ .....     │ .......   │ .... │ ............ │
    │ CHINA     │ CHINA     │ 1997 │ 525562838002 │
    │ JAPAN     │ VIETNAM   │ 1997 │ 525495763677 │
    └───────────┴───────────┴──────┴──────────────┘
    150 rows in set. Elapsed: 3.533 sec. Processed 546.67 million rows, 5.48 GB (154.72 million rows/s., 1.55 GB/s.)

扫描行数:546,670,000大约5亿4千多万

耗时(秒):3.533

查询列数:4

结果行数:150

Query 3.2

SELECT
    C_CITY,
    S_CITY,
    toYear(LO_ORDERDATE) AS year,
    sum(LO_REVENUE) AS revenue
FROM lineorder_flat
WHERE (C_NATION = 'UNITED STATES') AND (S_NATION = 'UNITED STATES') AND (year >= 1992) AND (year <= 1997)
GROUP BY
    C_CITY,
    S_CITY,
    year
ORDER BY
    year ASC,
    revenue DESC
    ┌─C_CITY─────┬─S_CITY─────┬─year─┬────revenue─┐
    │ UNITED ST6 │ UNITED ST6 │ 1992 │ 5694246807 │
    │ UNITED ST0 │ UNITED ST0 │ 1992 │ 5676049026 │
    │ .......... │ .......... │ .... │ .......... │
    │ UNITED ST9 │ UNITED ST9 │ 1997 │ 4836163349 │
    │ UNITED ST9 │ UNITED ST5 │ 1997 │ 4769919410 │
    └────────────┴────────────┴──────┴────────────┘
    600 rows in set. Elapsed: 1.000 sec. Processed 546.67 million rows, 5.56 GB (546.59 million rows/s., 5.56 GB/s.)

扫描行数:546,670,000大约5亿4千多万

耗时(秒):1.00

查询列数:4

结果行数:600

Query 4.1

SELECT
    toYear(LO_ORDERDATE) AS year,
    C_NATION,
    sum(LO_REVENUE - LO_SUPPLYCOST) AS profit
FROM lineorder_flat
WHERE (C_REGION = 'AMERICA') AND (S_REGION = 'AMERICA') AND ((P_MFGR = 'MFGR#1') OR (P_MFGR = 'MFGR#2'))
GROUP BY
    year,
    C_NATION
ORDER BY
    year ASC,
    C_NATION ASC
    ┌─year─┬─C_NATION──────┬────────profit─┐
    │ 1992 │ ARGENTINA     │ 1041983042066 │
    │ 1992 │ BRAZIL        │ 1031193572794 │
    │ .... │ ......        │  ............ │
    │ 1998 │ PERU          │  603980044827 │
    │ 1998 │ UNITED STATES │  605069471323 │
    └──────┴───────────────┴───────────────┘
    35 rows in set. Elapsed: 5.066 sec. Processed 600.04 million rows, 8.41 GB (118.43 million rows/s., 1.66 GB/s.)

扫描行数:600,040,000大约6亿

耗时(秒):5.066

查询列数:4

结果行数:35

Query 4.2

SELECT
    toYear(LO_ORDERDATE) AS year,
    S_NATION,
    P_CATEGORY,
    sum(LO_REVENUE - LO_SUPPLYCOST) AS profit
FROM lineorder_flat
WHERE (C_REGION = 'AMERICA') AND (S_REGION = 'AMERICA') AND ((year = 1997) OR (year = 1998)) AND ((P_MFGR = 'MFGR#1') OR (P_MFGR = 'MFGR#2'))
GROUP BY
    year,
    S_NATION,
    P_CATEGORY
ORDER BY
    year ASC,
    S_NATION ASC,
    P_CATEGORY ASC
    ┌─year─┬─S_NATION──────┬─P_CATEGORY─┬───────profit─┐
    │ 1997 │ ARGENTINA     │ MFGR#11    │ 102369950215 │
    │ 1997 │ ARGENTINA     │ MFGR#12    │ 103052774082 │
    │ .... │ .........     │ .......    │ ............ │
    │ 1998 │ UNITED STATES │ MFGR#24    │  60779388345 │
    │ 1998 │ UNITED STATES │ MFGR#25    │  60042710566 │
    └──────┴───────────────┴────────────┴──────────────┘
    100 rows in set. Elapsed: 0.826 sec. Processed 144.42 million rows, 2.17 GB (174.78 million rows/s., 2.63 GB/s.)

扫描行数:144,420,000大约1亿4千多万

耗时(秒):0.826

查询列数:4

结果行数:100

性能测试结果汇总

查询语句 SQL简要说明 扫描行数 返回行数 查询列数 耗时(秒)
Q1.1 乘积、汇总、4个条件、首次运行 91,010,000 1 2 0.242
Q1.2 Q1.1增加1个条件运行 7,750,000 1 2 0.040
Q2.1 汇总、函数、2列分组、2列排序、首次运行 600,040,000 280 3 8.558
Q2.2 Q2.1增加1个条件运行 600,040,000 56 3 1.242
Q3.1 汇总、函数、3列分组、2列排序、首次运行 546,670,000 150 4 3.533
Q3.2 Q3.1更换条件运行 546,670,000 600 4 1
Q4.1 相减、汇总、函数、2列分组、2列排序、首次运行 600,040,000 35 4 5.006
Q4.2 Q4.1增加2个条件运行 144,420,000 100 4 0.826

在当前软硬件环境下,扫描 6 亿多行数据,常见的分析语句首次运行最慢在 8 秒左右能返回结果,相同的分析逻辑更换条件再次查询的时候效率有明显的提升,可以缩短到 1 秒左右,如果只是简单的列查询没有加减乘除、聚合等逻辑,扫描全表 6 亿多行数据首次查询基本可以在 2 秒内执行完成。

相关文章
|
18天前
|
存储 SQL 缓存
优化ClickHouse查询性能:最佳实践与调优技巧
【10月更文挑战第26天】在大数据分析领域,ClickHouse 以其卓越的查询性能和高效的列式存储机制受到了广泛的关注。作为一名已经有一定 ClickHouse 使用经验的开发者,我深知在实际应用中,合理的表设计、索引优化以及查询优化对于提升 ClickHouse 性能的重要性。本文将结合我的实践经验,分享一些有效的优化策略。
44 3
|
17天前
|
数据采集 存储 分布式计算
ClickHouse大规模数据导入优化:批处理与并行处理
【10月更文挑战第27天】在数据驱动的时代,高效的数据导入和处理能力是企业竞争力的重要组成部分。作为一位数据工程师,我在实际工作中经常遇到需要将大量数据导入ClickHouse的需求。ClickHouse是一款高性能的列式数据库系统,非常适合进行大规模数据的分析和查询。然而,如何优化ClickHouse的数据导入过程,提高导入的效率和速度,是我们面临的一个重要挑战。本文将从我个人的角度出发,详细介绍如何通过批处理、并行处理和数据预处理等技术优化ClickHouse的数据导入过程。
38 0
|
4月前
|
存储 DataWorks 监控
利用 DataWorks 数据推送定期推播 ClickHouse Query 诊断信息
DataWorks 近期上线了数据推送功能,能够将数据库查询的数据组织后推送到各渠道 (如钉钉、飞书、企业微信及 Teams),除了能将业务数据组织后推送,也能将数据库自身提供的监控数据组织后推送,这边我们就以 ClickHouse 为例,定期推播 ClickHouse 的慢 Query、数据量变化等信息,帮助用户掌握 ClickHouse 状态。
247 6
利用 DataWorks 数据推送定期推播 ClickHouse Query 诊断信息
|
4月前
|
负载均衡 数据管理
ClickHouse的分布式查询流程
ClickHouse的分布式查询流程
|
4月前
|
消息中间件 NoSQL Redis
实时计算 Flink版产品使用问题之配置了最大连续失败数不为1,在Kafka的精准一次sink中,如果ck失败了,这批数据是否会丢失
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
5月前
|
分布式计算 运维 DataWorks
MaxCompute产品使用问题之数据如何导出到本地部署的CK
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
5月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替&quot;Greater Seattle Area&quot;),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
59 6
|
5月前
|
JSON NoSQL MongoDB
蓝易云 - mongodb数据如何导入到clickhouse
以上步骤是一种通用的方法,具体的实现可能会根据你的具体需求和数据结构有所不同。
116 1
|
5月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
49 0
|
5月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
53 0