实战攻略 | ClickHouse优化之FINAL查询加速

news2024/11/6 5:18:51

【本文作者:擎创科技资深研发 禹鼎侯】

查询时为什么要加FINAL

我们在使用ClickHouse存储数据时,通常会有一些去重的需求,这时候我们可以使用ReplacingMergeTree引擎。这个引擎允许你存储重复数据,但是在merge的时候会根据order by的字段进行去重。

它的去重逻辑是使用新数据覆盖旧数据。

但是很多时候,merge并不是实时的,他可能会在数据插入后几分钟甚至十几分钟后才会进行,而我们对数据的查询却往往却是实时的。这个时候就必然出现一个问题:

那些还没有来得及merge的数据,查询出来会有重复。这与我们所期望的效果是背道而驰的。

事实上,即便是merge发生了,我们也不能保证数据一定没有重复。我们举个简单的例子:

如上图所示:p1~p4是四个原始part,发生合并之后数据进行了去重,最终合并成了p1_4, 对id去重之后有四个值,分别为1,2,3,4, 假设此时又有一个新part p5插入,此时去查询仍然能搜到两条id为2和3数据。

因此,即使发生了合并,我们也不能保证数据就一定是唯一的。

ClickHouse为了解决这个问题,提供了FINAL语法,从字面意义上理解,就是返回merge最终态的数据结果。它的效果与OPTIMIZE FINAL 是一致的。

不过,SELECT FINAL仅是在读时合并,并不会实际将底层数据合并,而OPTIMIZE FINAL则是实实在在的发生合并,这是二者的本质的区别。

FINAL查询会有什么问题

那么大家肯定也已经发现了。这种加了FINAL的查询,性能会有很大的问题!

因为FINAL相当于在查询时执行一次OPTIMIZE FINAL,而这个操作本质上是将同一个partition内的数据合并成一个part。在数据量不大的情况下还好,这个操作还能很快返回,如果数据集比较大,比如单个分区的数据已经达到了上千万级,甚至上亿级,那么一次FINAL可真是要了亲命了。

为了让大家直观的感受到这种性能差距,我们来举个例子。

我们使用ClickHouse官方提供的压测数据来进行举例:

https://clickhouse.com/docs/en/getting-started/example-datasets/opensky#validate-data

建表语句如下:

CREATE TABLE opensky(    `callsign` String,    `number` String,    `icao24` String,    `registration` String,    `typecode` String,    `origin` String,    `destination` String,    `firstseen` DateTime,    `lastseen` DateTime,    `day` DateTime,    `latitude_1` Float64,    `longitude_1` Float64,    `altitude_1` Float64,    `latitude_2` Float64,    `longitude_2` Float64,    `altitude_2` Float64)ENGINE = ReplacingMergeTreePARTITION BY toYYYYMMDD(day)ORDER BY (origin, destination, callsign)

我们将数据导入两遍,这样就一定会得到重复的数据:

ck94 :) select count() from opensky;
SELECT count()FROM opensky
Query id: 0d65affc-873e-4847-9ee0-ae749b091bd1
┌───count()─┐│ 127132244 │└───────────┘
1 row in set. Elapsed: 0.007 sec.

接下来我们来执行一个查询语句:

ck94 :) select avg(altitude_1) from opensky where day >= '2020-10-01 00:00:00' and typecode = 'B737';
SELECT avg(altitude_1)FROM openskyWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: bcb16bd6-91fc-4993-a4de-87e1731d7760
┌────avg(altitude_1)─┐│ 1458.7475907858743 │└────────────────────┘
1 row in set. Elapsed: 0.186 sec. Processed 34.74 million rows, 812.04 MB (186.88 million rows/s., 4.37 GB/s.)Peak memory usage: 14.39 MiB.

可以看到,当我们不使用final时,上面这个sql仅仅使用了0.186秒就返回了结果。

接下来我们看看加了final的效果:

ck94 :) select avg(altitude_1) from opensky final where day >= '2020-10-01 00:00:00' and typecode = 'B737';
SELECT avg(altitude_1)FROM openskyFINALWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: 63f760a6-9bca-4a40-a7b3-237eacae356a
┌────avg(altitude_1)─┐│ 1336.4280164372838 │└────────────────────┘
1 row in set. Elapsed: 12.784 sec. Processed 48.60 million rows, 3.06 GB (3.80 million rows/s., 239.37 MB/s.)Peak memory usage: 4.16 GiB.

上面这个SQL足足耗费了12.784秒!这可是近70倍的差距,我们当前的数据集还不算大,如果数据集再大一点,那么这个查询性能慢的问题将无限扩大化,最终影响到生产使用。

这让老夫如何是好

那么,这个问题如此明显,有没有什么好的优化手段呢?

自然是有的。

接下来就来介绍两种方法来做final查询的优化。

优化手段1:使用PREWHERE

所谓PREWHERE,就是在查询之前,先将数据过滤掉一部分,这样,目标数据集的规模小了,执行FINAL自然会快了。

我们使用EXPLAIN  SYNTAX 执行计划来看一下为啥第一条不加FINAL的SQL快得离谱:

EXPLAIN SYNTAXSELECT avg(altitude_1)FROM openskyWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: 046a721e-7690-4d0b-9457-20e825d0e152
┌─explain─────────────────────────────────────────────────────────┐│ SELECT avg(altitude_1)                                          ││ FROM opensky                                                    ││ PREWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737') │└─────────────────────────────────────────────────────────────────┘
3 rows in set. Elapsed: 0.003 sec. 

可以看到,上面这条SQL,实际上clickhouse优化器已经对其进行改写成了PREWHERE。

我们再看看加了FINAL的执行计划:

EXPLAIN SYNTAXSELECT avg(altitude_1)FROM openskyFINALWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: c4ae0a63-7a55-4216-815a-25ff44ee538e
┌─explain──────────────────────────────────────────────────────┐│ SELECT avg(altitude_1)                                       ││ FROM opensky                                                 ││ FINAL                                                        ││ WHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737') │└──────────────────────────────────────────────────────────────┘

那就离了个大谱了!

为神马就加了个FINAL,他就不能使用PREWHERE优化了?

按照官方的说法: 如果查询条件里带有主键字段,clickhouse会默认会使用PREWHERE进行优化,可以提前减少数据集的大小,一来避免过多内存造成OOM,二来自然是可以加速查询了。

然而十分悲催的是,这个优化对加了FINAL的查询不会生效。

那么我们怎么能让它使用到PREWHERE优化呢?

这里提供两种方法:

一种是显式指定。

ck94 :) select avg(altitude_1) from opensky final prewhere day >= '2020-10-01 00:00:00' and typecode = 'B737';
SELECT avg(altitude_1)FROM openskyFINALPREWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: ce72c7a9-38a1-4ae8-957e-d951e0dd9d0b
┌────avg(altitude_1)─┐│ 1424.1051732278174 │└────────────────────┘
1 row in set. Elapsed: 1.429 sec. Processed 48.60 million rows, 3.06 GB (34.01 million rows/s., 2.14 GB/s.)Peak memory usage: 1.19 GiB.

可以看到,我们改成显式使用PREWHERE之后,查询性能立马减少到了1.429秒,差不多有9倍左右的提升,可见这个提升是巨大的。

第二是利用子查询命中PREWHERE。

那么,有木有什么办法不显式指定PREWHERE,但是让其有这个优化呢?而且我们并不能保证所有的条件都会带上主键索引。

前面介绍过,当查询条件带主键,且不加final的时候,clickhouse会默认使用PREWHERE进行优化,那么我们是不是可以先用子查询命中PREWHERE,然后再final呢?

我们将SQL改成如下样子:

ck94 :) select avg(altitude_1) from opensky where (origin, destination, callsign) in (select origin, destination, callsign from opensky where day >= '2020-10-01 00:00:00' and typecode = 'B737') and day >= '2020-10-01 00:00:00' and typecode = 'B737';
SELECT avg(altitude_1)FROM openskyWHERE ((origin, destination, callsign) IN (    SELECT        origin,        destination,        callsign    FROM opensky    WHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737'))) AND (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')
Query id: 61ae0590-de1a-44b1-866f-0c54a919c762
┌────avg(altitude_1)─┐│ 1458.7475907858748 │└────────────────────┘
1 row in set. Elapsed: 0.768 sec. Processed 69.47 million rows, 4.09 GB (90.43 million rows/s., 5.32 GB/s.)Peak memory usage: 69.15 MiB.

耗时降到了0.768秒,这已经非常接近不加final的裸查询了。牛逼class!

优化手段2:禁用final查询跨分区merge

ClickHouse本身是允许跨分区进行数据替换的,这无疑复杂化了FINAL查询的逻辑。但事实上,只要我们的数据分区合理,这种情况完全可以规避掉。这时候我们可以使用do_not_merge_across_partitions_select_final=1这个配置来禁用跨final查询时分区合并。这意味着clickhouse仅在本分区内进行merge去重。

我们来看看效果:

ck94 :) select avg(altitude_1) from opensky final where day >= '2020-10-01 00:00:00' and typecode = 'B737' SETTINGS do_not_merge_across_partitions_select_final=1;
SELECT avg(altitude_1)FROM openskyFINALWHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')SETTINGS do_not_merge_across_partitions_select_final = 1
Query id: 41aa4fc9-5933-43e1-86bf-a374eab15dd9
┌────avg(altitude_1)─┐│ 1458.6043678101414 │└────────────────────┘
1 row in set. Elapsed: 0.732 sec. Processed 34.74 million rows, 2.18 GB (47.44 million rows/s., 2.98 GB/s.)Peak memory usage: 2.86 GiB.
仅耗时0.732秒,同样牛的一批。

事实上,我们建议在部署集群时,将这个配置作为默认配置进行设置,在知名项目clickhouse-operator 中,这个配置就是默认打开的。

那么,综合上面两种优化手段,这就是最终形态了:

ck94 :) select avg(altitude_1) from opensky where (origin, destination, callsign) in (select origin, destination, callsign from opensky where day >= '2020-10-01 00:00:00' and typecode = 'B737') and day >= '2020-10-01 00:00:00' and typecode = 'B737' SETTINGS do_not_merge_across_partitions_select_final = 1;
SELECT avg(altitude_1)FROM openskyWHERE ((origin, destination, callsign) IN (    SELECT        origin,        destination,        callsign    FROM opensky    WHERE (day >= '2020-10-01 00:00:00') AND (typecode = 'B737'))) AND (day >= '2020-10-01 00:00:00') AND (typecode = 'B737')SETTINGS do_not_merge_across_partitions_select_final = 1
Query id: 298c3d92-67da-4379-8e1d-43f85c99cc2c
┌────avg(altitude_1)─┐│ 1458.7475907858745 │└────────────────────┘
1 row in set. Elapsed: 0.678 sec. Processed 69.47 million rows, 4.09 GB (102.45 million rows/s., 6.03 GB/s.)Peak memory usage: 69.89 MiB.

虽然还是比不加final的要慢一丢丢,但总体上已经到了可以接受的程度了。

———— THE END ————

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2234075.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

labview学习总结

labview学习总结 安装labview的特点一、图形化编程范式二、并行执行机制三、硬件集成能力四、应用领域优势五、开发效率六、系统集成能力**labview基本组成示意图****常用程序结构图解**结语 基础知识介绍界面前后面板的概念平铺式和层叠式 帧的概念结构类型顺序结构for循环whi…

Linux 服务器使用指南:从入门到登录

🌟快来参与讨论💬,点赞👍、收藏⭐、分享📤,共创活力社区。 🌟 🚩博主致力于用通俗易懂且不失专业性的文字,讲解计算机领域那些看似枯燥的知识点🚩 目录 一…

《AI 大模型:重塑软件开发新未来》

引言 在科技的璀璨星河中,AI 大模型宛如一颗耀眼的新星,正以前所未有的力量改写着软件开发的篇章。随着其技术的持续演进,软件开发流程正经历着翻天覆地的变化。从代码自动生成的神奇魔法,到智能测试的精准洞察,AI 大…

acmessl.cn提供接口API方式申请免费ssl证书

目录 一、前沿 二、API接口文档 1、证书可申请列表 简要描述 请求URL 请求方式 返回参数说明 备注 2、证书申请 简要描述 请求URL 请求方式 业务参数 返回示例 返回参数说明 备注 3、证书查询 简要描述 请求URL 请求方式 业务参数 返回参数说明 备注 4、证…

windows server2019下载docker拉取redis等镜像并运行项目

一、基本概念 1、windows server 指由微软公司开发的“Windows”系列中的“服务器”版本。这意味着它是基于Windows操作系统的,但专门设计用于服务器环境,而不是普通的桌面或个人用户使用。主要用途包括服务器功能、用户和资源管理、虚拟化等 2、dock…

Docker-- cgroups资源控制实战

上一篇:容器化和虚拟化 什么是cgroups? cgroups是Linux内核中的一项功能,最初由Google的工程师提出,后来被整合进Linux内核; 它允许用户将一系列系统任务及其子任务整合或分隔到按资源划分等级的不同组内,从而为系统…

解决ImportError: DLL load failed while importing _message: 找不到指定的程序。

C:\software\Anoconda\envs\yolov5_train\python.exe C:\Project\13_yolov5-master\train.py C:\software\Anoconda\envs\yolov5_train\lib\site-packages\torchvision\io\image.py:13: UserWarning: Failed to load image Python extension: [WinError 127] 找不到指定的程序…

超越Axure:探索新一代原型设计工具

Axure RP是一款被广泛认可的快速原型设计工具,专为专业设计师打造,用于创建高效的产品原型图,包括APP和网页的原型图、框架图和结构图等。Axure RP制作的原型图能够实现与实际APP相似的交互效果,便于向用户或客户展示,…

综合项目--博客

一。基础配置: 1.配置主机名,静态IP地址 2.开启防火墙配置 3.部分开启selinux并且配置 4.服务器之间使用同ntp.aliyun.com进行世家能同步 5.服务器之间实现SSH绵密登陆 二。业务需求 1.Sever-NFS-DNS主机配置NFS服务器,将博客网站资源…

dns欺骗

[[Ettercap]] 少不了这个 arp 毒化和流量截取的中间人工具。 dns欺骗原理 什么是 DNS 欺骗? DNS 欺骗(DNS Spoofing) 是一种网络攻击技术,攻击者通过修改 DNS 响应,将目标用户的 DNS 查询结果篡改,指向攻…

危机来临前---- 力扣: 876

危机即将来临 – 链表的中间节点 描述: 给你单链表的头结点 head ,请你找出并返回链表的中间结点。如果有两个中间结点,则返回第二个中间结点。 示例: 何解? 1、遍历找到中间节点 : 这个之在回文链表中找…

SQL Server数据库中,报错:用户名或密码不正确

1、 用户名或密码不正确 2、解决方式 可能是服务器名称不对,检查服务器名称是否是安装sqlserver数据的服务器名称。安装sqlserver数据的服务器,没有开启1433端口,需要开启端口 下一步保证:TCP/IP 状态状态为:已启用 然…

PKG_CHECK_MODULES(FUSE,fuse)

运行 ./configure 命令报错如下: ./configure: line 13934: syntax error near unexpected token FUSE,fuse ./configure: line 13934: PKG_CHECK_MODULES(FUSE,fuse)解决方案: 命令窗口运行如下命令,安装 pkg-config: sudo …

不要只知道deepl翻译,这里有10个专业好用的翻译工具等着你。

deepl翻译的优点还是有很多的,比如翻译的准确性很高,支持翻译的语言有很多,并且支持翻译文件和文本。但是现在翻译工具那么多,大家需要翻译的场景也有很多,怎么能只拥有一个翻译工具呢。所以在这里我帮助大家寻找了一波…

如何检索 LINEMOD 数据集的相机内参

简介 BOP (Benchmark for 6D Object Pose Estimation) 是一个专为6D物体姿态估计而设计的基准测试平台。它为研究人员提供了多种数据集,以帮助评估和比较物体识别和姿态估计算法的性能。官方网站是 BOP,你可以在这里找到丰富的资源和信息。 检索 LINEM…

健康生活的重要性,注重规律作息

在快节奏的现代生活中,健康已成为我们最宝贵的财富。随着生活水平的提高,人们越来越注重养生,追求身心的和谐与平衡。那么,如何在繁忙的日常中实践健康养生,为生活注入新的活力呢?以下是一些实用的建议&…

最简单方式SSH连接局域网中另一台电脑的WSL2

1、首先确认一下WSL2中的SSH服务是否开启: 先安装更新一下,再安装一下ssh服务模块,这里很多人都没有安装过。 sudo apt update sudo apt upgrade sudo apt install openssh-server 2、配置SSH服务器: 打开配置文件&#xff0c…

andrular输入框input监听值传递

效果图&#xff1a; step1: E:\projectgood\ajnine\untitled4\src\app\apple\apple.component.html <button mat-button (click)“openDialog()”>Open dialog step2: E:\projectgood\ajnine\untitled4\src\app\apple\apple.component.ts import {Component, inject}…

数据结构——二叉树(续集)

♥♥♥~~~~~~欢迎光临知星小度博客空间~~~~~~♥♥♥ ♥♥♥零星地变得优秀~也能拼凑出星河~♥♥♥ ♥♥♥我们一起努力成为更好的自己~♥♥♥ ♥♥♥如果这一篇博客对你有帮助~别忘了点赞分享哦~♥♥♥ ♥♥♥如果有什么问题可以评论区留言或者私信我哦~♥♥♥ 在上一篇博客我们…

动态规划 —— dp问题-按摩师

1. 按摩师 题目链接&#xff1a; 面试题 17.16. 按摩师 - 力扣&#xff08;LeetCode&#xff09;https://leetcode.cn/problems/the-masseuse-lcci/description/ 2. 算法原理 状态表示&#xff1a;以某一个位置为结尾或者以某一个位置为起点 dp[i]表示&#xff1a;选择到i位置…