快出数量级的性能是怎样炼成的

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 Tair(兼容Redis),内存型 2GB
简介: 我们通过使用开源 SPL 重写了多个金融行业的 SQL 任务,实现了显著的性能提升,如保险公司团保明细单查询提速 2000+ 倍、银行 POS 机交易报表提速 30+ 倍等。这些优化的核心在于使用了更低复杂度的算法,而非依赖硬件加速。SPL 基于离散数据集理论,提供了丰富的高性能算法,使得复杂任务的优化成为可能。更多案例和详细技术解析可参见乾学院的相关课程和图书。

我们之前做过一些性能优化的案例,不算很多,还没有失手过。少则提速数倍,多则数十倍,极端情况还有提速上千倍的。提速一个数量级基本上是常态。之前发过几个,后面还会继续发,感兴趣的可以去乾学院看看具体,简单列举几个:
开源 SPL 提速保险公司团保明细单查询 2000+ 倍
开源 SPL 提升银行自助分析从 5 并发到 100 并发
开源 SPL 提速银行用户画像客群交集计算 200+ 倍
开源 SPL 优化银行预计算固定查询成实时灵活查询
开源 SPL 将银行手机账户查询的预先关联变成实时关联
开源 SPL 提速银行资金头寸报表 20+ 倍
开源 SPL 提速银行贷款协议跑批 10+ 倍
开源 SPL 优化保险公司跑批从 2 小时到 17 分钟
开源 SPL 提速银行 POS 机交易报表 30+ 倍
开源 SPL 提速银行贷款跑批任务 150+ 倍
开源 SPL 提速资产负债表 60 倍

这是怎么做到的呢?
这些被提速的场景都有一个共同点:原先都是用各种数据库(也有 HADOOP/Spark)上的 SQL 实现的,包括查询用的几百行 SQL 也有跑批用的几千行存储过程,然后我们改用集算器的 SPL 重新实现之后就有了这样的效果。
集算器 SPL 有什么神奇之处?是不是能让各种运算跑得更快?
有点遗憾,并没有这样的好事。集算器也是一个软件,而且是用 Java 写的,完成同样运算通常比 C/C++ 写的数据库还要慢一点。
那是怎么回事?

根本原因在于我们用 SPL 实现了不同的算法。软件不能提高硬件的速度,但我们可以设计出更低复杂度的算法,有效地减少计算量,然后速度自然就上去了。一个运算任务本来要做 1 亿次加法,如果能减到 100 万次,那自然就能快 100 倍,即使每次运算都变得稍慢一点,总体性能仍然会提高,这一点也不神奇。
只要能实现高性能算法和存储,用什么技术来做并不重要了。用 C/C++、Java 当然都能做出来。事实上,集算器是用 Java 写的,用 Java 直接实现这些算法原则上还会更快一点,用 C/C一般还能更快(Java 的内存分配消耗时间还是有点多)。
不过,虽然用 Java 和 C能写出比 SPL 更快的代码,但要长得多(估计会长出 50-100 倍),这会导致开发工作量过大,这在实际应用时也是要权衡的一个指标。有时候,跑得快和写着简单其实是一回事,就是能高效率地实现高性能算法。
集算器的 SPL 中强化了结构化数据的数据类型,并提供了很多基础的高性能算法。写代码就是组合运用这些算法,当然会方便得多。要说神奇之处,也就是这一点了。

那么,继续 SQL 就不能做到同样的事吗?
是的。SQL 设计得过于粗线条,关系代数这个理论基础中缺乏很多数据类型和基础运算,很多高性能算法都无法描述,结果只能使用慢算法。虽然现在很多数据库和大数据平台都在工程上有所优化,但也只能针对简单的场景,情况复杂之后数据库的优化器都会“晕”掉,所以解决不了根本问题。这是个理论上的问题,无法在工程层面解决。
SPL 基于的理论基础不再是关系代数,而是我们发明的离散数据集。在这个体系下有更多的数据类型和运算,就能写出更多高性能算法了。SPL 是离散数据集的一种实现,封装了许多现成的算法。用 Java 和 C++ 当然也能从头来实现这个代数体系,因而都能写出来高性能代码。而 SQL 却不可以。

举个简单的例子,我们想在 1 亿条数据中取出前 10 名,用 SQL 写出来是这样的:

select top 10 x,y from T order by x desc

这个语句中有个order by,严格按它执行就会涉及大排序,而排序非常慢。其实我们可以想出一个不用大排序的算法,但用 SQL 却无法描述,只能指望数据库优化器了。对于这句 SQL 描述的简单情况,很多商用数据库确实都能优化,使用不必大排序的算法,性能通常很好。但情况复杂一些,比如在每个分组中取前 10 名,要用窗口函数和子查询把 SQL 写成这样:

select * from
    (select y,*,row_number() over (partition by y order by x desc) rn from T)
where rn<=10

这时候,数据库优化器就会犯晕了,猜不出这句 SQL 的目的,只能老老实实地执行排序的逻辑(这个语句中还是有 order by 的字样),结果性能陡降。
而 SPL 不一样,离散数据集中有普遍集合的概念,TopN 这种运算被认为是和 SUM 和 COUNT 一样的聚合运算,只不过返回值是个集合而已。这时候写出来的取前 10 名的语句中并没有排序动作:

T.groups(;top(-5;x))

分组后的写法也很简单,都不需要执行大排序:

T.groups(y;top(-5;x))

这里 性能优化技巧:TopN 还有关于这个问题的更详细测试对比。

所以,我们做性能优化时要重写代码,不能继续使用 SQL 保持兼容。要读懂原来的逻辑重新实现,这个工作量还是很大的,不过能换来数倍数十倍的性能提升,常常还是值得的。
另外,存储也非常重要,好算法要有合适的存储机制配合才能生效,所以不能继续把数据继续存在数据库里获得高性能,需要搬出来换种办法组织存放。改变存储后,有可能把原来需要缓存的计算过程变成不需要了,原来要遍历多遍的运算变成只遍历一次甚至不用遍历了,减少硬盘访问量对性能的提升非常有效。

从上面这个原理上看,如果我们不能针对计算目标设计出更好的算法,那就做不到提速了。比如一个很简单的大表求和,用 SQL 要做 1 亿次,用 SPL 也要做 1 亿次,那就不可能做得更快,一般还会更慢一点(Java 赶不上 C/C++)。但是,当运算任务足够复杂时,碰到几百上千行的嵌套 N 层 SQL(慢的 SQL 通常也不会太简单),几乎总能找到足够多可优化的环节,所以我们经历过的案子还没有失手过。结果,在实践上用 Java 写出来集算器大幅度超越了 C/C++ 写的数据库,这都是算法造就的。
我们甚至曾经发过一个征询,寻找用 SQL 写的慢过程,我们负责提速一个数量级。

换个角度再看这个提速原理:高性能靠的不是代码,而是代数,代码只是个实现手段而已。其中最关键的是掌握和运用这些算法,而不是 SPL 语法。SPL 语法很简单,比 Java 容易多了,两小时就能基本上手,两三周就能比较熟练了。但算法却没那么简单,需要认真学习反复练习才能掌握。这些案例直接由没有经验的用户自己做常常效果并不好,主要原因也是对算法没有吃透。
反过来,而只要掌握了算法,用什么语法就是个相对次要的问题了(当然用 SQL 这种太粗线条的语言还是不行)。这就像给病人看病,找出病理原因后,能分析出什么成分的药能管用。无论直接购买成药(使用封装过的 SPL),还是上山采药(使用 Java/C++ 硬写),都可以治好病,无非就是麻烦程度和支付成本不同。

可能有读者对 SPL 提供了哪些与 SQL 不同的高性能算法感兴趣,推荐一下乾学院上的性能优化图书和视频课程,有兴趣可前往看看。
我们已经把这些算法都整理成有体系的知识了。有些算法是业界首创的,其它教科书和论文中都找不到。
跟着这些图书课程学习,掌握这些算法后,就可以自己写到快出数量级的高性能代码。即使自己不写代码,也能理解原理,不会再被很多大数据产品喊什么“万亿秒查”的说法忽悠了。

相关文章
|
SQL 算法 Java
【其他】快出数量级的性能是怎样炼成的
【其他】快出数量级的性能是怎样炼成的
42 0
|
7月前
|
自然语言处理 算法
LLM的能力大约每8个月就会翻一倍,速度远超摩尔定律!
【2月更文挑战第27天】LLM的能力大约每8个月就会翻一倍,速度远超摩尔定律!
64 2
LLM的能力大约每8个月就会翻一倍,速度远超摩尔定律!
|
7月前
|
存储 机器学习/深度学习 人工智能
冲破冯诺伊曼瓶颈:探索存内计算与静态随机存储器(SRAM)性能因素
冲破冯诺伊曼瓶颈:探索存内计算与静态随机存储器(SRAM)性能因素
519 6
|
7月前
|
人工智能 安全 测试技术
Infection-2.5登场,训练计算量仅40%、性能直逼GPT-4!
【2月更文挑战第18天】Infection-2.5登场,训练计算量仅40%、性能直逼GPT-4!
75 3
Infection-2.5登场,训练计算量仅40%、性能直逼GPT-4!
|
7月前
|
缓存 Dubbo 应用服务中间件
实现从10s到0.5s的飞跃,揭秘性能提升的秘诀
在数字时代,性能优化对各类技术系统和应用至关重要,关乎用户体验、效率和成本。某团队在面对系统响应慢的问题时,通过梳理逻辑、使用stopwatch排查,发现了数据库、连接池、日志打印和Dubbo配置等问题。他们优化了数据库的索引和锁机制,减少了日志打印的负担,调整了Dubbo的线程配置,并改进了日志组件,最终显著提升了系统性能。性能优化的方法包括代码优化、数据库优化、缓存技术、并发处理和资源管理,这是一个持续且需综合考虑稳定性和可靠性的过程。
59 2
|
7月前
|
缓存 安全 前端开发
5分钟,我把网站性能优化了3倍
5分钟,我把网站性能优化了3倍
|
机器学习/深度学习 计算机视觉
模型大十倍,性能提升几倍?谷歌研究员进行了一番研究
模型大十倍,性能提升几倍?谷歌研究员进行了一番研究
178 0
|
缓存 人工智能 并行计算
小羊驼背后的英雄,伯克利开源LLM推理与服务库:GPU减半、吞吐数十倍猛增
小羊驼背后的英雄,伯克利开源LLM推理与服务库:GPU减半、吞吐数十倍猛增
501 0
|
负载均衡 监控 测试技术
认清性能问题
首先专注于业务上最需要优先修正的程序,而不是从全局调优来改善性能。要重视全局的性能表现,但解决问题要从细节和业务最需要的环节入手。
认清性能问题
|
机器学习/深度学习 存储 并行计算
【ASPLOS 2022】机器学习访存密集计算编译优化框架AStitch,大幅提升任务执行效率
近日,关于机器学习访存密集计算编译优化框架的论文《AStitch: Enabling A New Multi-Dimensional Optimization Space for Memory-Intensive ML Training and Inference on Modern SIMT Architectures》被系统领域顶会ASPLOS 2022接收。
【ASPLOS 2022】机器学习访存密集计算编译优化框架AStitch,大幅提升任务执行效率