搜索

Clickhouse 亿级数据性能测试

肉眼品世界

共 11673字，需浏览 24分钟

 · 2021-08-13

clickhouse 在数据分析技术领域早已声名远扬，如果还不知道可以 (https://clickhouse.tech/docs/zh/) 了解下。

最近由于项目需求使用到了 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

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

数据量和空间占用

表名列数数据行数原始大小压缩大小压缩率
supplier6200,00011.07 MiB7.53 MiB68
customer73,000,000168.83 MiB114.72 MiB68
part81,400,00034.29 MiB24.08 MiB70
lineorder16600,037,90224.03 GiB16.67 GiB69
lineorder_flat37688,552,212111.38 GiB61.05 GiB55

可以看到 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,000 775万

耗时(秒)：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,000120.242
Q1.2Q1.1增加1个条件运行7,750,000120.040
Q2.1汇总、函数、2列分组、2列排序、首次运行600,040,00028038.558
Q2.2Q2.1增加1个条件运行600,040,0005631.242
Q3.1汇总、函数、3列分组、2列排序、首次运行546,670,00015043.533
Q3.2Q3.1更换条件运行546,670,00060041
Q4.1相减、汇总、函数、2列分组、2列排序、首次运行600,040,0003545.006
Q4.2Q4.1增加2个条件运行144,420,00010040.826

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

来源：https://www.cnblogs.com/asimov/p/14546106.html

推荐阅读：

世界的真实格局分析，地球人类社会底层运行原理

不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）

企业IT技术架构规划方案

论数字化转型——转什么，如何转？

华为干部与人才发展手册（附PPT）

企业10大管理流程图，数字化转型从业者必备！

【中台实践】华为大数据中台架构分享.pdf

华为的数字化转型方法论

华为如何实施数字化转型（附PPT）

超详细280页Docker实战文档！开放下载

华为大数据解决方案（PPT）



浏览 35
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
CVPR 2024｜大视觉模型的开山之作！无需任何语言数据即可打造大视觉模型
↑ 点击蓝字 关注极市平台作者丨科技猛兽编辑丨极市平台极市导读 本文提出一种序列建模 (sequential modeling) 的方法，不使用任何语言数据，训练大视觉模型。>>加入极市CV技术交流群，走在计算机视觉的最前沿本文目录1 序列建模打造大视觉模型(来自 U
极市平台
1
测试新人，如何快速上手一个陌生的系统！
大家好，我是狂师！作为刚入行不久的测试新人，面对一个陌生的系统时，可能会感到有些手足无措。面对一个全新的系统系统，如何快速上手并展开有效的测试工作是一个重要的挑战。本文将探讨测试新人如何通过一系列步骤和策略，快速熟悉并掌握新系统的测试要点，从而提高测试效率和质量。本文旨在为测试新手提供一份指导，帮助
测试开发技术
0
APP 安全测试项总结
一、安装包测试　　1.1、关于反编译　　目的是为了保护公司的知识产权和安全方面的考虑等，一些程序开发人员会在源码中硬编码一些敏感信息，如密码。而且若程序内部一些设计欠佳的逻辑，也可能隐含漏洞，一旦源码泄漏，安全隐患巨大。　　为了避免这些问题，除了代码审核外，通常开发的做法是对代码进行混淆，混淆后源代
测试开发技术
0
自动化测试做得好的标准是什么
自动化测试要做得好的标准，主要包括以下几个方面：一、高覆盖率与精准定位1、测试用例覆盖全面：自动化测试应覆盖产品的核心功能、关键业务流程以及常见的异常场景，确保测试范围广泛，降低遗漏风险。2、问题定位准确：自动化测试应能够精准地识别并定位问题，包括缺陷的位置、产生的原因以及可能的影响，为开发团队提供
测试开发社区
0
Vite 4.3 为何性能爆表？
大厂技术  高级前端  Node进阶点击上方 程序员成长指北，关注公众号回复1，加入高级Node交流群Vite 4.3 相比 Vite 4.2 取得了惊人的性能提升，下面和大家分享一下 Vite 4.3 性能大幅提升的幕后技术细节，深度阅读，全程高能
程序员成长指北
0
【性能监控】如何有效监测网页静态资源大小？
前言作为前端人员肯定经常遇到这样的场景：需求刚上线，产品拿着手机来找你，为什么页面打开这么慢呀，心想自己开发的时候也有注意性能问题呀，不可能会这么夸张。那没办法只能排查下是哪一块影响了页面的整体性能，打开浏览器控制台一看，页面上的这些配图每张都非常大，心想这些配图都这么大，页面怎么快，那么我们有没有
高级前端进阶
0
Linux系统性能优化：七个实战经验
来源公众号：twt社区IT社区原文链接：https://mp.weixin.qq.com/s/Rey0gSnnj-zoAEwE6J-GjwLinux系统的性能是指操作系统完成任务的有效性、稳定性和响应速度。Linux系统管理员可能经常会遇到系统不稳定、响应速度慢等问题，例如在Linux上搭建了一个w
开源Linux
1
21.3K star！推荐一款可视化自动化测试/爬虫/数据采集神器！功能免费且强大！
【温馨提示】由于公众号更改了推送规则，不再按照时间顺序排列，如果不想错过测试开发技术精心准备的的干货文章，请将测试开发技术设为“星标☆”，看完文章在文尾处点亮“在看”！大家好，我是狂师！在大数据时代，信息的获取与分析变得尤为重要。对于开发者、数据分析师乃至非技术人员来说，能够高效地采集网络数据并进行
测试开发技术
4
漫游CPU缓存效应，让你的程序性能飙升！
推荐一个原创技术号-非科班大厂码农，号主是机械专业转行进入腾讯的后端程序员！大多数读者都知道cache是一种快速小型的内存，用以存储最近访问内存位置。这种描述合理而准确，但是更多地了解一些处理器缓存工作中的“烦人”细节对于理解程序运行性能有很大帮助。在这篇博客中，我将运用代码示例来详解 cache工
码农有道公众号
1
小美播报|3月IPTV数据排行榜发布！
小美播报3月IPTV数据排行榜:《与凤行》登顶连续剧榜榜首拥有4.05亿家庭用户的中国IPTV平台已经成为国内主流视听平台，IPTV平台数据对视听产业各环节都具有重要意义。截至2024年4月，全国已有29个省级IPTV加入“看中国”，覆盖全国超2.25亿户家庭、辐射近7亿人。点击查看详情湖南广电与马
流媒体网
0
点赞
评论
收藏
分享

手机扫一扫分享

举报