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

2023-10-12 01:20

本文主要是介绍10亿数据秒级查询,ClickHouse太快了!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

 

点击上方蓝色“终端研发部”,选择“设为星标”

学最好的别人,做最好的我们

ClickHouse 在数据分析技术领域早已声名远扬,最近由于项目需求使用到了 ClickHouse 做分析数据库,于是用测试环境做了一个单表 10 亿数据量的性能测试。

本文记录一下测试结果,有做超大数据量分析技术选型需求的朋友可以参考下。

服务器信息

如下:

  • 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:

https://clickhouse.tech/docs/en/getting-started/example-datasets/star-schema/

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

①数据量和空间占用

如下图:

86c9f1fe90f72292ba97e71aecfc7cc0.png

可以看到 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。

性能测试结果汇总

如下图:

91dd32b62bf461755d9b973e8cda1c53.png

在当前软硬件环境下,扫描 6 亿多行数据,常见的分析语句首次运行最慢在 8 秒左右能返回结果。

相同的分析逻辑更换条件再次查询的时候效率有明显的提升,可以缩短到 1 秒左右。

如果只是简单的列查询没有加减乘除、聚合等逻辑,扫描全表 6 亿多行数据首次查询基本可以在 2 秒内执行完成。


 
 
 
 
 
来源:cnblogs.com/asimov/p/14546106.html
版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢!
 
 
 
 

BAT等大厂Java面试经验总结

af22f4d1b1d30c2e025d0d84d217a970.png

想获取 Java大厂面试题学习资料

扫下方二维码回复「BAT」就好了

回复 【加群】获取github掘金交流群
回复 【电子书】获取2020电子书教程
回复 【C】获取全套C语言学习知识手册
回复 【Java】获取java相关的视频教程和资料
回复 【爬虫】获取SpringCloud相关多的学习资料
回复 【Python】即可获得Python基础到进阶的学习教程
回复 【idea破解】即可获得intellij idea相关的破解教程
关注我gitHub掘金,每天发掘一篇好项目,学习技术不迷路!

0e09b4cd9f97b80d3c43165263bbfd30.png

回复 【idea激活】即可获得idea的激活方式

回复 【Java】获取java相关的视频教程和资料

回复 【SpringCloud】获取SpringCloud相关多的学习资料

回复 【python】获取全套0基础Python知识手册

回复 【2020】获取2020java相关面试题教程

回复 【加群】即可加入终端研发部相关的技术交流群

为什么HTTPS是安全的

因为BitMap,白白搭进去8台服务器...

《某厂内部SQL大全 》.PDF

字节跳动一面:i++ 是线程安全的吗?

大家好,欢迎加我微信,很高兴认识你!

在华为鸿蒙 OS 上尝鲜,我的第一个“hello world”,起飞!

相信自己,没有做不到的,只有想不到的

在这里获得的不仅仅是技术!

39a52ae301a55bab6eb61beb1cb0c791.png

fd3fb099b373a89bdb17e1def57c2080.gif

如果喜欢就给个“在看319d933e7f46b950bf60024ebfc4671b.gif

这篇关于10亿数据秒级查询,ClickHouse太快了!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/192209

相关文章

MyBatis-plus处理存储json数据过程

《MyBatis-plus处理存储json数据过程》文章介绍MyBatis-Plus3.4.21处理对象与集合的差异:对象可用内置Handler配合autoResultMap,集合需自定义处理器继承F... 目录1、如果是对象2、如果需要转换的是List集合总结对象和集合分两种情况处理,目前我用的MP的版本

GSON框架下将百度天气JSON数据转JavaBean

《GSON框架下将百度天气JSON数据转JavaBean》这篇文章主要为大家详细介绍了如何在GSON框架下实现将百度天气JSON数据转JavaBean,文中的示例代码讲解详细,感兴趣的小伙伴可以了解下... 目录前言一、百度天气jsON1、请求参数2、返回参数3、属性映射二、GSON属性映射实战1、类对象映

C# LiteDB处理时间序列数据的高性能解决方案

《C#LiteDB处理时间序列数据的高性能解决方案》LiteDB作为.NET生态下的轻量级嵌入式NoSQL数据库,一直是时间序列处理的优选方案,本文将为大家大家简单介绍一下LiteDB处理时间序列数... 目录为什么选择LiteDB处理时间序列数据第一章:LiteDB时间序列数据模型设计1.1 核心设计原则

Java+AI驱动实现PDF文件数据提取与解析

《Java+AI驱动实现PDF文件数据提取与解析》本文将和大家分享一套基于AI的体检报告智能评估方案,详细介绍从PDF上传、内容提取到AI分析、数据存储的全流程自动化实现方法,感兴趣的可以了解下... 目录一、核心流程:从上传到评估的完整链路二、第一步:解析 PDF,提取体检报告内容1. 引入依赖2. 封装

Java实现复杂查询优化的7个技巧小结

《Java实现复杂查询优化的7个技巧小结》在Java项目中,复杂查询是开发者面临的“硬骨头”,本文将通过7个实战技巧,结合代码示例和性能对比,手把手教你如何让复杂查询变得优雅,大家可以根据需求进行选择... 目录一、复杂查询的痛点:为何你的代码“又臭又长”1.1冗余变量与中间状态1.2重复查询与性能陷阱1.

MySQL中查询和展示LONGBLOB类型数据的技巧总结

《MySQL中查询和展示LONGBLOB类型数据的技巧总结》在MySQL中LONGBLOB是一种二进制大对象(BLOB)数据类型,用于存储大量的二进制数据,:本文主要介绍MySQL中查询和展示LO... 目录前言1. 查询 LONGBLOB 数据的大小2. 查询并展示 LONGBLOB 数据2.1 转换为十

使用SpringBoot+InfluxDB实现高效数据存储与查询

《使用SpringBoot+InfluxDB实现高效数据存储与查询》InfluxDB是一个开源的时间序列数据库,特别适合处理带有时间戳的监控数据、指标数据等,下面详细介绍如何在SpringBoot项目... 目录1、项目介绍2、 InfluxDB 介绍3、Spring Boot 配置 InfluxDB4、I

Java整合Protocol Buffers实现高效数据序列化实践

《Java整合ProtocolBuffers实现高效数据序列化实践》ProtocolBuffers是Google开发的一种语言中立、平台中立、可扩展的结构化数据序列化机制,类似于XML但更小、更快... 目录一、Protocol Buffers简介1.1 什么是Protocol Buffers1.2 Pro

Go语言使用Gin处理路由参数和查询参数

《Go语言使用Gin处理路由参数和查询参数》在WebAPI开发中,处理路由参数(PathParameter)和查询参数(QueryParameter)是非常常见的需求,下面我们就来看看Go语言... 目录一、路由参数 vs 查询参数二、Gin 获取路由参数和查询参数三、示例代码四、运行与测试1. 测试编程路

MySQL 数据库表与查询操作实战案例

《MySQL数据库表与查询操作实战案例》本文将通过实际案例,详细介绍MySQL中数据库表的设计、数据插入以及常用的查询操作,帮助初学者快速上手,感兴趣的朋友跟随小编一起看看吧... 目录mysql 数据库表操作与查询实战案例项目一:产品相关数据库设计与创建一、数据库及表结构设计二、数据库与表的创建项目二:员