ClickHouse 为何如此快?

 ClickHouse 具有 ROLAP、在线实时查询、完整的 DBMS、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的 SQL 支持和函数、支持高可用、不依赖 Hadoop 复杂生态、开箱即用等许多特点。特别是它那夸张的查询性能,我想大多数刚接触 ClickHouse 的人也一定会因为它的性能指标而动容。在一系列官方公布的基准测试对比中,ClickHouse 都遥遥领先对手,这其中不乏一些我们耳熟能详的名字。

所有用于对比的数据库都使用了相同配置的服务器,在单个节点的情况下,对一张拥有133个字段的数据表分别在1000万、1亿和10亿三种数据体量下执行基准测试,基准测试的范围涵盖43项SQL查询。在1亿数据集体量的情况下,ClickHouse的平均响应速度是 Vertica 的2.63倍、InfiniDB的17倍、MonetDB 的27倍、Hive 的126倍、MySQL 的429倍以及 Greenplum 的10倍。详细的测试结果可以查阅https://clickhouse.yandex/benchmark.html。

很多用户心中一直会有这样的疑问,为什么 ClickHouse 这么快?因为ClickHouse 是列式存储数据库,所以快;也因为 ClickHouse 使用了向量化引擎,所以快。这些解释都站得住脚,但是依然不能消除全部的疑问。因为这些技术并不是秘密,世面上有很多数据库同样使用了这些技术,但是依然没有ClickHouse这么快。所以我想从另外一个角度来探讨一番ClickHouse的秘诀到底是什么。

首先向各位读者抛出一个疑问:在设计软件架构的时候,做设计的原则应该是自顶向下地去设计,还是应该自下而上地去设计呢?在传统观念中,或者说在我的观念中,自然是自顶向下的设计,通常我们都被教导要做好顶层设计。而ClickHouse 的设计则采用了自下而上的方式。ClickHouse 的原型系统早在2008年就诞生了,在诞生之初它并没有宏伟的规划。相反它的目的很单纯,就是希望能以最快的速度进行 GROUP BY 查询和过滤。他们是如何实践自下而上设计的呢?

 

着眼硬件,先想后做

 

首先从硬件功能层面着手设计,在设计伊始就至少需要想清楚如下几个问题。

  • 我们将要使用的硬件水平是怎样的?包括CPU、内存、硬盘、网络等。

  • 在这样的硬件上,我们需要达到怎样的性能?包括延迟、吞吐量等。

  • 我们准备使用怎样的数据结构?包括 String、HashTable、Vector 等。

  • 选择的这些数据结构,在我们的硬件上会如何工作?

如果能想清楚上面这些问题,那么在动手实现功能之前,就已经能够计算出粗略的性能了。所以,基于将硬件功效最大化的目的,ClickHouse 会在内存中进行GROUP BY,并且使用 HashTable 装载数据。与此同时,他们非常在意 CPU L3级别的缓存,因为一次L3的缓存失效会带来70~100ns的延迟。这意味着在单核 CPU 上,它会浪费4000万次/秒的运算;而在一个32线程的 CPU 上,则可能会浪费5亿次/秒的运算。所以别小看这些细节,一点一滴地将它们累加起来,数据是非常可观的。正因为注意了这些细节,所以 ClickHouse 在基准查询中能做到1.75亿次/秒的数据扫描性能。

 

算法在前,抽象在后

 

常有人念叨:“有时候,选择比努力更重要。”确实,路线选错了再努力也是白搭。在 ClickHouse 的底层实现中,经常会面对一些重复的场景,例如字符串子串查询、数组排序、使用 HashTable 等。如何才能实现性能的最大化呢?算法的选择是重中之重。以字符串为例,有一本专门讲解字符串搜索的书,名为“Handbook of Exact String Matching Algorithms”,列举了35种常见的字符串搜索算法。各位猜一猜 ClickHouse 使用了其中的哪一种?答案是一种都没有。这是为什么呢?因为性能不够快。在字符串搜索方面,针对不同的场景,ClickHouse 最终选择了这些算法:对于常量,使用 Volnitsky 算法;对于非常量,使用 CPU 的向量化执行 SIMD,暴力优化;正则匹配使用 re2 和hyperscan 算法。性能是算法选择的首要考量指标。

 

勇于尝鲜,不行就换

 

除了字符串之外,其余的场景也与它类似,ClickHouse 会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法,ClickHouse 团队会立即将其纳入并进行验证。如果效果不错,就保留使用;如果性能不尽人意,就将其抛弃。

特定场景,特殊优化

 

针对同一个场景的不同状况,选择使用不同的实现方式,尽可能将性能最大化。关于这一点,其实在前面介绍字符串查询时,针对不同场景选择不同算法的思路就有体现了。类似的例子还有很多,例如去重计数 uniqCombined 函数,会根据数据量的不同选择不同的算法:当数据量较小的时候,会选择 Array 保存;当数据量中等的时候,会选择 HashSet;而当数据量很大的时候,则使用HyperLogLog 算法。

对于数据结构比较清晰的场景,会通过代码生成技术实现循环展开,以减少循环次数。接着就是大家熟知的大杀器—向量化执行了。SIMD 被广泛地应用于文本转换、数据过滤、数据解压和 JSON 转换等场景。相较于单纯地使用 CPU,利用寄存器暴力优化也算是一种降维打击了。

 

持续测试,持续改进

 

如果只是单纯地在上述细节上下功夫,还不足以构建出如此强大的ClickHouse,还需要拥有一个能够持续验证、持续改进的机制。由于 Yandex的天然优势,ClickHouse 经常会使用真实的数据进行测试,这一点很好地保证了测试场景的真实性。与此同时,ClickHouse 也是我见过的发版速度最快的开源软件了,差不多每个月都能发布一个版本。没有一个可靠的持续集成环境,这一点是做不到的。正因为拥有这样的发版频率,ClickHouse 才能够快速迭代、快速改进。

所以ClickHouse 的黑魔法并不是一项单一的技术,而是一种自底向上的、追求极致性能的设计思路。这就是它如此之快的秘诀。

本文摘编于《ClickHouse原理解析与应用实战》,经出版方授权发布。

#欢迎来留言#

你用过ClickHouse吗

对此你怎么看?

留言点赞数量最多的前三名

CSDN携手【机械工业出版社】送出

《ClickHouse原理解析与应用实战》一本

截至7月17日12:00点

关于作者:

ClickHouse贡献者之一,ClickHouse布道者,资深架构师,腾讯云最具价值专家TVP,开源爱好者, 十多年IT从业经验,对大数据领域主流技术与解决方案有深入研究,擅长分布式系统的架构设计与整合。曾主导过多款大数据平台级产品的规划、设计与研发工作,一线实战经验丰富。现就职于远光软件股份有限公司,任大数据事业部平台开发部总经理。

更多精彩推荐
☞市场占比 44%,IDC 最新报告:阿里云智能语音市场排名第一
☞华为回应“英国禁用决定”;微信小商店正式上线;Android Studio 4.0.1 发布| 极客头条
☞厉害!从电影花瓶到 Wi-Fi 之母,这才是乘风破浪的姐姐!
☞600 岁的故宫,也上了人工智能的车
☞进程和线程基础知识全家桶,30 张图一套带走
☞解读领跑全国的区块链发展“北京方案”:设专项基金,构建开源生态
点分享点点赞点在看
©️2020 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值